# Token 工厂：大规模 AI 推理基础设施的工程实践 > **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 > > **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/ > > **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。 ## 一、基础信息 - **会议类型**:专题演讲 - **Persona**:AI 基础架构师 - **时间信息**:6月23日 | 16:00 - 16:30 - **标题**:Token 工厂：大规模 AI 推理基础设施的工程实践 - **PDF 资料**:有 - **视频回放**:有 ## 演讲人信息 ### 会议信息 - **地点**:上海世博中心(2026 亚马逊云科技中国峰会) - **日期**:2026年6月23日(Day 1) - **时间**:16:00 - 16:30 - **会议类型**:专题演讲 - **面向 Persona**:AI 基础架构师 ### 亚马逊云科技演讲人 - **汪其香**:资深解决方案架构师 ### 客户 / 合作伙伴演讲人 - **唐安波**（硅基流动）:解决方案总监 ## 二、会议资料 PDF 转录内容 --- Page 1 --- 2026年6月23日-24日 上海·世博中心 --- Page 3 --- SESSION 304 经济时代，算力的新战场 Token 大规模 AI 推理基础设施的工程实践 唐安波 汪其香 硅基流动 亚马逊云科技解决方案架构师 解决方案总监 --- Page 4 --- 推理的供需挑战 01 / INFERENCE USERS 02 / COMPUTE DEMAND × 100 8M → 800M of last-gen 两年内100× 增长，推理用户从千万级冲向十亿级 推理模型的算力需求，是上一代生成式 AI 模型的100 倍 Source: NVIDIA Jensen Huang · GTC 2025 Source: NVIDIA · GTC 2025 Keynote --- Page 5 --- 推理需求，正在快速增长 THE SURGE OF INFERENCE DEMAND PER-QUERY TOKEN CONSUMPTION (log scale) 01 / SCALE 单次回答的 Token 消耗 · 指数级跃升 模型上线即持续产出 Token, 消耗随用户与频率攀升 每一次问答、每一次 Agent 调用，都是新增的算力账单 02 / TEST-TIME COMPUTE 思考链推理模型, 单次推理~100× 算力 Source: NVIDIA GTC 2025 03 / AGENTIC Agent 单任务消耗 是普通 Chatbot 的 5-30 倍 每一步 AI 交互形态的演化都会带来 Token 消耗的指数级上升 Source: Gartner 2026 · 多步 fan-out 调用 MARKET AI 推理市场$106B (2025) → $255B (2030) CAGR 19.2% --- Page 6 --- 超大模型对推理基础设施提出新要求 THE FOUR WALLS OF INFERENCE AT SCALE WALL 01 / LATENCY WALL 02 / UNIT ECONOMICS 模型规模持续增长 单位经济模型恶化 模型参数规模从70B,400B 到1T,持续演进 Token 越来越便宜，企业 AI 账单却越来越贵——用量爆炸性增长 集群推理优化提高 token 性价比 长文本，高 Cache 命中率成为推理负载新模式 超大集群成为推理基础设施的核心竞争力 ↓280× ↑320% Llama 3 DeepSeek Kimi K2.5 两年 Token 单价/ 同期企业 AI 支出 Source: Epoch AI · Intel 2025 WALL 03 / UTILIZATION WALL 04 / ENTERPRISE SLA GPU 利用率不足与资源浪费 企业级稳定性不足 显存/ 算力单元/ 带宽，三者难以同时拉满 多租户隔离· SLA 保障· 灰度发布· 可观测性 GPU 空闲率高达 ~70% 可用性 99.9%+硬要求 KV-Cache 碎片、Prefill/Decode 错配、批处理粒度不匹配 Source: Hedgehog 2025 传统在线服务的标配，与推理引擎尽力而为模式存在天然冲突 Source: Flexential 2025 于是，我们需要一座 Token 工厂——把推理变成可工业化、可规模化、可经济化的生产线 --- Page 7 --- 加速 普惠人类 AGI --- Page 8 --- 硅基流动：打造标准化、超高效能的生成式 AI Infra 产品 人工智能 应用层 AI 赋能应用软件 将生成式 AI Infra 产品化 AI Infra 降低 AI 应用开发和使用门槛 模型 模型推理部署 模型微调 多模态模型推理 大语言模型推理 极致性能优化 中间层 模型训练 降低规模化部署成本 SiliconDiff SiliconLLM • 较早实现 SD 1 秒出图 • 较 vLLM 最高提升 10X+ SiliconBrain SiliconBrain • 较 PyTorch 性能提升 3X+ • 支持 MoE 架构 攻坚 AI Infra 技术难点 • 主流应用框架支持 • 消费卡测试结果全球 领先 形成标准化产品 AI 算力 硬件层 --- Page 9 --- Token:AGI 时代的核心基础资源 自然语言处理的最小单元 - Token Token 是大模型处理信息的最小计量单位，是 AI 模型理解与生成语言的基础粒子。当前我国日均 词元调用量已超过140 万亿，相比2024 年初的1000 亿增长了1000 多倍，相比2025 年底的 100 万亿，三个月时间又增长了40% 多。 AI 智能时代的"算力货币" Token 具有可计量、可定价、可交易的核心属性，正在成为连接技术供给 与商业需求的核心"结 算单位",是衡量 AI 模型活跃度与产业价值的关键指标，如同数字经济的新型"水电资源"。 --- Page 10 --- 大模型网关智能路由分发+大模型框架层推理加速+算力层动态伸缩 = 大幅提升集群吞吐 请求 智能网关 • 上下文长度感知 Qwen/Qwen3-32B • Prefix cache 感知 推理池 大模型网关智能路由分发 • LoRA 感知 长上 • 负载感知 Prefix 金融 医疗 下文 Cache LoRA LoRA • ... 加速 匹配 • 模型快速适配 模型仓库 模型微调 • 内置大模型最佳实践 大模型推理服务平台 100+ 大模型/最佳实践 全链路微调/场景化 • 大模型高效微调 • 一键部署快速启动 模型部署 …… 快速拉起模型服务 • …… • 适配多种算力芯片 SiliconLLM SiliconDiff 大语言模型推理 文生图/视频 • 算子优化、通信优化、调度优化 高性能推理框架 • ... SiliconAudio ... 语音生成 • 弹性扩缩容 算力智能调度 • 基于请求队列、性能等多 维度指标 --- Page 11 --- 全链路大模型推理优化，一键部署最佳实践，体系化推理加速，端到端运维观测 一键部署 推理优化 运维观测 分级 模型权重+框架镜像分发 推理业务全链路可观测 算子加速 PD 集群编排 智能网关 KV Cache 数十秒 0 侵入 2-4x 3x 60% 10x 千亿参数模型下载和预热 透明埋点 加速 效率提升 降低 提速 长文本及多轮 数分钟 PD 实例自动 智能路由 对话 0 侵入 自研推理框架 模型推理框架加载 扩缩容 多 LoRA 加载 KV Cache 命 推理业务可观测 中率 智能网关 最佳实践模版 大 EP+PD 分离分布式推理引擎 RoCE 全链路观测 已适配模型权重文件100+ Prefill Decode 推理加速框架镜像 一键部署服务 KV Cache 分级缓存 --- Page 12 --- 灵活的算力调度：推出 SiliconFlow FaaS,为灵 活可调度的 AI 负载设计的新一代算力引擎 算力资源管理需兼顾负载与利用效率 低算力储备造成资源过载 高算力储备导致利用率低 多租户下算力调度重要性更高 弹性灵活的算力调度是 降低推理成本、提升算力 利用效率的关键要素 客户 A 业务负载 客户 B 业务负载 算力资源 Function as a Service 帮助用户 灵活、便捷、可靠 的 新一代 Serverless GPU 调度平台 将推理服务部署到云端算力之上 算力资源弹性伸缩 异构算力无感融合 极致的成本管控 算力自由调度,0 资源浪费 多集群异构算力统一纳管 支持命中缓存计费 12 --- Page 13 --- 多样化模型选择：基于对推理加速的深刻理解和 超强的推理引擎架构，最快适配主流开源模型 SiliconFlow 推理引擎具备极强的抽象能力，基于扎实的通用优化框架与 140+ 主流模型适配 95%+ 发布当天适配 前瞻性策略迭代更新，将不同模型的适配与加速沉淀为可复用的标准化路径 最全 最新 --- Page 14 --- 全栈自研产品架构：基于高性能推理能力，满足 多层次的 AI 应用部署需求 模型微调及托管 Workflow 开发 Workflow 托管 算力→应用 广泛的开源 开发工具链 满足个性化开发需求 BizyAir AI apps 全链路部署 全周期服务 社区支持 公有云 MaaS 私有云 MaaS 标准化的 低成本的 高安全性的 模型服务 部署方案 公有部署产品 私有部署产品 BYOC 一体机 Bring Your Own Cloud FaaS 弹性扩缩容 支持昇腾+ 英伟达 云端调度 异构算力纳管 Function as a Service 算力集群 秒级响应 大语言模型 图像/视频模型 语音模型 …… 140+ 主流模型 GPT 模型 MoE 模型 全面适配 当天上线 最多3 天上线 高性能推理引擎 算力优化 多种底层算力 消费级芯片 芯片 达到商用水准 --- Page 15 --- 用户心智：最受开发者欢迎的 API 供应商之一, 主流 Marketplace 安装量领先 在主流开发者 Marketplace 和第三方统计报告 上的使用量处于第一梯队，整体领先主流云厂商与头部 模型公司，已与同领域创业公司拉开约300 倍差距，已在开发者群体中建立极强的用户心智 IDC 2026年5月发布，硅基流动在中国 MaaS 市场 Token 使用量排名第 四，唯一进入前五名的创业公司 --- Page 16 --- 硅基流动在 Token 供应链各环节领跑全行业，打 造 Token 经济中的"超级供应商" 全球领先的新一代 AI Native Cloud,不做简单的 API 转售，而是针对多种模型和算力底 层重构的推理引擎。开发者可以针对特定场景选择最佳的"模型 x 算力"组合，彻底解 决多模型组合及性价比问题，这背后是扎实的"AI 供应链基础设施" 最丰富的算力方案 最灵活的算力调度 最全的模型选择 算力资源弹性伸缩 异构算力无感融合 ... 算力成本极致管控 ... 全面适配多种算力芯片 经过检验的云服务架构能力 全面适配加速140+ 款主流开源模型 满足国内外多元化的客户需求 多 SKU"模型 x 算力"云端秒级响应 绝大多数模型发布当天完成适配 16 --- Page 17 --- 携手亚马逊云科技打造全球 Token 工厂 算力资源丰富 弹性与规模 全球化服务 • 全球 30+ 区域提供多种高 • 应对流量波峰，支撑大规 • 遍布全球的基础设施与网 性能计算实例 模 Token 生产 络加速能力 • SiliconFlow 可按需获取大 • 确保 Token 生产的"工厂产 • SiliconFlow 为海外开发者 规模异构算力，快速匹配 能"始终匹配实际需求，同 与企业客户就近提供推理 不同模型对算力的差异化 时最大化资源利用率、控 服务，实现低延迟、高可 需求 制成本 用的全球化 Token 交付 --- Page 18 --- 基于亚马逊云科技的全球化部署 GLOBAL INFERENCE, POWERED BY 亚马逊云科技 SYSTEM ARCHITECTURE 01 / GLOBAL RESOURCE POOL 全球算力资源池 覆盖多大洲多区域 的 GPU 资源，就近接入、就近推理，从基础设施层面降低 端到端延迟 02 / ELASTIC SCHEDULING GPU 弹性调度 按流量动态伸缩、跨 Region 资源融通，峰谷错峰提升整体利用率 03 / FOUNDATION STACK 算力 · 网络· 存储协同优化 GPU 算力集群+ 高带宽低延迟网络+ 高吞吐对象存储，三层协同支撑大规 模推理 04 / HIGH AVAILABILITY 企业级稳定性与容灾 多可用区部署、故障自动转移、全链路可观测 全球用户的每一次 Token 请求，都能就近、稳定、低延迟地完成 --- Page 19 --- 亚马逊云科技 GPU 使用方式 按需使用 容量预留 容量块 EC2 竞价实例 按需预置 预留容量 加速计算实例 可能会中断 可变用量 稳态运行 有时间限制 价格低 灵活性高 更高可用性 低延迟集群 * 最新超大规模实例：以 Capacity Blocks 为主（按时段预留集群） --- Page 20 --- GPU 竞价实例 解决成本问题 Spot 实例是空闲 EC2 容量，可作为购买选项提供给客户，并享受大幅折扣 可中断 空闲 EC2 容量 高达 90% 的按需价格折扣 如果 EC2 特定容量池需要恢复 与按需部署相同的基础 Spot 价格基于 EC2 实例的长期供需趋势 容量,Spot 实例可能会中断, 架构 （无竞价） 并在中断前 2 分钟发出警告 --- Page 21 --- Spot GPU 的使用模式 弹性扩容 微调、基准测试工作负载 实验、开发 - 低负载持续使用，突发实时灵活推理 - 用 偶尔短时爆发 Spot 实例作为弹性扩容, 补充峰值推理容量 --- Page 22 --- Spot 中断最佳实践 - 灵活性，中断处理 实例灵活 EC2 实例再平衡信号 使用尽可能多且深的容量池 （主动式） • 不同实例类型 • 不同实例大小 ▪ 当您的 Spot 实例面临较高的中断风险时的通知 • 不同可用区 ▪ 内置支持与 EC2 Auto Scaling、EKS 托管节点组 地区灵活 等服务的集成 Spot 实例终止通知 时间灵活 （被动） 时间灵活和/或价格灵活可以进 ▪ 在 Spot 实例被中断前 2 分钟做出响应 一步降低中断率, ▪ 内置支持相同的亚马逊云科技服务 提高应用程序正常运行的时间 ▪ 中断处理(亚马逊云科技提供了推荐用例的最佳实践 方案) 价格灵活 --- Page 23 --- Spot Placement Score (SPS) • 能够指示在给定时间点，哪些实例类型和区域最有可能成功启动 Spot 实例 • P 系列特殊情况 - 支持单一实例类型请求 " aws ec2 get-spot-placement-scores --Region us-east-1 • SPS 需要实例多样性（至少 3 种类型）才能给出可靠分数 --instance-types p5en.48xlarge --target-capacity 1920 • 策略: --target-capacity-unit-type vcpu • 根据性能需求（模型大小、GPU 性能、驱动程序等）混合使用不同加速器 --Region-names us-east-2 us-west-1" • 使用 SPS 识别最适合用例的区域和时间 23 --- Page 24 --- SPOT Placement Score Tracker • SPS Tracker 提供一段时间内 的趋势分析，帮助识别多样化 策略 • 实时、短期、突发推理 - 识别 最优区域 • 时间灵活的研发、实验、模型 调优 - 识别最优时间 github.com/aws-solutions-library-samples/guidance-for-ec2-spot-placement-score-tracker --- Page 25 --- 总结 THREE TAKEAWAYS 01 02 03 TOKEN FACTORY FULL-STACK OPTIMIZATION OPTIMAL TCO Token 工厂 = 全栈优化实现 亚马逊云科技全球算力+ 工业化推理生产体系 10× 性能提升 SiliconFlow 推理引擎 把推理从「手工作坊」升级为可规模化、可经济化、可工程化的 从调度、引擎、KV-Cache 到底层算力，全栈端到端协同优化 全球资源池+ 工业级推理引擎，性能、稳定性、成本三者兼得 生产线 --- Page 26 --- Thank you contact@siliconflow.cn 清华科技园启迪科技大厦 D 座 23 层 扫码关注"硅基流动"公众号 ## 三、会议回放视频转录内容 Hello 大家下午好 然后我们这个 Session 主要是跟我们的客户 硅基流动一起跟大家去聊一下 在现在这个 Token 经济时代 说我们怎么去做这种大规模的推理的集群 以及硅基流动能够提供的一些解决方案 其实我们会看到 在现在这个应用的背景下面 整个需求端其实是有非常大的 这个爆发式的增长的 其实会看到在两年内整个推理的用户有大概100倍的一个增长 这个可能是大家都有共识的 因为整个 AI 应用的使用的用户量 会有非常大的一个暴增 另外一个点就是说 除了用户的量会有非常大的上涨以外 在模型侧 这一侧本身它的对于算力的需求 其实也是非常的增加了非常多 因为一方面是我们看到现在的模型 它模型本身的 size 变得越来越大 另外一个方面是我们看到 Agentic 应用 它的使用场景对于算力的需求也是会越来越高 然后我们展开去看一下就是看到说 整个推理需求 快速增长的背后 第一个是我们刚刚提到模型 它的整个参数量变得越来越大了 另外一个是会看到我们把更多的算力放在了推理侧 以前我们可能想要改进模型的能力的时候 我们把模型的参数不断的加大 然后在训练的时候用更多的数据去做一个训练 再到 Reasoning Model 出现了以后 我们把更多的算力放在了推理的这个时候 在这块的话 那就是说我们在推理侧的需求 对于算力的需求是会越来越多的 然后我们看这个图的话 就是看到在最开始 2023年最开始有这种 Chatbot 的场景出现的时候 我们更多的使用场景的就是说这种单轮的问答 这个时候推理侧的集群的压力相对来说 其实比起现在来说是小很多的 然后再到第二个阶段是 我们出现了 Naive RAG 或者多轮对话这样的一些场景 然后对于推理侧单次的请求 其实就已经有一个比较大的增长了 那个时候很多模型追求的 就是长上下文去做这样的事情 然后再到第三个阶段的话 就比如说从去年类似于 COT 然后 Reasoning Model 这样出现了 以后我们可能单次的推理的请求 它的 token 数量又来了一个10 倍的上涨 那再到现在 现在这个阶段的话 我们看到这个 Agent 这个应用里面 可能一个应用里面挂了很多个 Tool 然后中间还会有一些沙箱的一些应用 我们每一次的调用会把工具调用的结果 放到这个模型里面 然后再次去调用不同的工具 得到最后的一个结果 然后所以我们就看到对于单次的请求来说 它消耗的算力可能到达了以前的30倍往上 所以我们看到每一次跟 AI 的这种应用交互模式的变化 其实对应的底层就是对于 Token 的消耗的指数级的一个上升 在对应到背后的话 其实就是看到说我们去做推理集群的时候 我们对于推理有这么大的需求 对于底层的算力也有非常大的一个压力 那我们对于做模型 hosting 的场景来说 其实就会有更多的一个要求 有几个方面 第一个就是我们看到模型的规模变得越来越大 这个时候比如说从我们以前听到的一个模型70B 我们那个时候听到已经觉得很大了 到现在我们看到已经有400B 然后包括1T 这种模型 然后不确定说未来还会不会更大 因为我们也没有看到说 scaling law 就到了尽头 然后另外就是说我们看到集群部署 比如说现在开始去做一些 PD 分离 然后我们看到很多的推理厂商 他们底层的算力池都是几百台这样的一个节点 那这个模型的规模持续增长 带来的底层集群的规模也会越来越大 然后另外一个就是我们看到 虽然现在 Token 好像一直在降价 但是我们企业整体的 AI 的这个账单 其实会越来越多的 那就是因为说我们的 Token 越来越便宜 但是现在的整个场景里面 对于 Token 的消耗量是不断的在上涨的 然后再往下的话就是我们看到整个 在这种大规模的推理的 GPU 的节点下面 对 GPU 的利用率怎么把它压到最强 那其实这个也是需要我们的团队有 更多的这种工程优化的一个实践的 另外的话就是我们看到在现在调用这个 Token 有不同的这个场景 我们可以从不同的 SaaS 平台去调用 我们也可以自己去布一些机器来调用这个 Token 那其实这块的话就是面临 如果我们做一个企业级的应用 那我们是要求说我们这个模型的接口的 可用性是更高的 那其实我们看到很多的客户呢 他其实是会根据自己不同的这个场景 去算一笔账就细化到每一个 Token 的粒度上说 我们怎么把这个单价做到最低 就比如说有些客户会因为说 他的场景是这种 cache 命中率非常高的 那他算一笔账说他去调这种第三方的 SaaS 平台 和自己部署的这个场景里面 他如果自己去部署 能把前面说的这个难点做到更强的话 那其实他的这个单位的 Token 其实成本是会做到更低的 那在你可能在其他的场景 所以就没有一个统一的一个 model 就告诉大家说你就应该选 SaaS 或者就应该选自己去部署 这个其实是看你自己推理的基础设施 以及你们有什么样的资源能够去做这个事情 做这样的一个技术的选型 然后这一块的话 就是我们接下来就会请到 硅基流动的同事 因为硅基流动他们其实是国内 就是专注在整个做大规模推理集群的这么一个厂商 然后我们请这个硅基流动的同事来给大家讲一下 他们这块的一些产品和架构 谢谢汪老师 然后我是那个来自硅基流动的唐安波 后边由我给大家介绍一下 硅基流动在这个大模型推理场景下做的一些事儿 对 然后先简单介绍一下 我们整个的这个大体的一个技术栈 那其实主要是分为几个层面 那第一个层面呢 相当于是底层的这个算力的纳管 那其实硅基流动下边有一个 比较大的一个算力的规模 那目前来讲我们每天的 token 都是几万亿的 然后同时我们的用户基本上 我们的用户应该是在1000万的开发者 然后企业级用户在1万多 然后同时模型大概有140多款的开源模型 所以基于这么大的一个数据量 其实我们在下边有很多的这个数据中心的一些算力 那首先第一件事我们要把这些算力给管起来 那第二件事是说 我们要把这些算力去推出更好的一个性能 在我们这种大模型的这个场景下 比如说我们在一些 coding 的场景 在一些 long context 的场景 然后在这种超长输入的 然后或者说对时延要求非常高的这些场景 那怎么样才能去推好 实际上我们有这种自研的大模型的推理框架 就是我们的 SiliconLLM 和 SiliconDiff 然后分别 比如说去推这种大语言模型 以及这种生图生视频的一些多模态的模型 然后当然我们也提供了一些像微调和训练之类的 这里简单再啰嗦一句 就是硅基流动其实前身是一流科技 那我们之前其实一直是做这个模型训练的训练框架的 然后再往上的话 实际上是模型层 那模型层这块的话 实际上我们做了很多跟这个算力中间的适配 以及调优就举个例子 比如说我们 DeepSeek 也好或者 Qwen 也好 我们会在这个像英伟达一些算力上 我们会去做一些优化 那这优化的中间其实包括了很多 就比如说我们会优化一些这种底层的一些矩阵算法 比如 GEMM 算子 包括说像这种 MoE 架构模型里面的一些 All-to-All 或者这种 MoE 相关的一些通信的算子 这块其实都会去进行一个优化 那核心是说我们要把这个模型在这个算力 即使是比如说英伟达 然后是 h100 或者说像 h200 的不同的算力上 其实我们也要进行不同的优化的过程 然后这个相当于是我们做的核心的 英伟达层面的事情 然后再往上其实就我们的这一些生态的伙伴 然后来对接我们的一些 API 接口 对 这块其实也简单在讲一下 就是实际上我们观察到的是说 从去年到今年整个的 Token 的流量 其实真的是一个非常陡峭的一个指数级的一个增长 那这里边实际上给整个推理带来了 不同的一些技术的演进 我们举一个例子 其实去年可能大家在讲推理框架的时候 都会讲到 我们要做 KV Cache 的分级卸载等等 但实际上去年的场景 其实它并没有特别长的一些长上下文 基本上大家可能的输入输出可能在几 K 之间 那这种情况下实际上 我们把整个 KV Cache 卸载 offload 到整个存储当中去 再往回捞 其实它对整个场景的收益其实并不那么高 但今年不一样 那今年我们会有这种 Vibe Coding 然后像 long context 场景 Manus 等等 那它的整个输入是巨长无比的 而且同时因为是说输入长 而且您比如以 coding 为举例子 那通常企业级用户 它不像比如说举例子像我 对吧 偶尔我们要写个小程序 应用小 APP 应用 那可能就几行提示词 然后反反复复地去操练 那可能就是我们当天就完成了 后边可能也不怎么用了 因为它本质上是个 demo 但真正企业级 coding 的时候 其实大家基于一个工程化的场景 那底下比如说一些 infra 的代码 或者说一些数据访问层的一些代码 它并不是每天每时每刻在变的 那这时候其实就会涉及到 这个代码的持久化问题 那持久化的一个时间周期 其实就相当于是也依据这个场景来变化的 那举个例子 比如说代码我们可能一个月两个月 可能都是在开发某一个项目 那这时候实际上 我们就可能持久化要做跨天 跨几天 那这样的话 它的整个缓存命中率会更高 然后这里边实际上都是 从去年到今年的一些变化 然后还有这个的话 实际上是我们整个推理 实际上我们从两条线来看 一条是纵向的 一条是横向的 那这个相当于是从流量的角度来看的 这件事 就一个纵向的 那从网关层面来讲的话 因为其实在公有云侧 实际上整个的用户的体量还是非常大的 那用户体量大的话 就是我们整个的场景也是非常丰富的 那举个例子 比如说我们有一些客服的场景 那客服的场景 它的通常的情况是说 它的输入输出比较短 但是它对那个响应的要求非常高 那比如说我问一个机器人 它几秒钟还没回答 我就觉得是不是一个系统问题了 那这是一种情况 那另外一种情况 比如说我们也有一些客户做这种 舆情分析之类的 那它的场景是什么 它是说 比如说我会去跑批 然后我会有大量的非结构化 这种文本 那这时候其实它的诉求是什么 它不一定是说我首字延迟要很快 它只要是说 比如说我能两小时之内 或者三小时之内 能把这一批文档给处理完 它要的是说单位时间内的吞吐的能力 那这一些实际上它反馈下来 其实对整个模型推理实例的要求都不一样的 那同时在网关层面 实际上我们会根据这些不同的流量的特征 当然这种不同的长上下文 只是一种其中的策略 然后我们会把这些流量去往下做一个分发 那往下分发的话 实际上是由我们整个推理机群去做的 那推理机群里边 其实有一些可能是我负责一些这种小规模流量 有一些像 PD 分离的一些机群 我们会去处置一些更大规模的这种流量 和更大规模的吞吐 那当然就是从网关层面 还会有一些别的一些应用 其实如果大家之前用过硅基的 线上的平台时候 可能发现里边还有一些 LoRA 微调的能力 那这时候其实我们也会把一些 Multi-LoRA 等等一些能力 也会通过网关的形式去做 然后还有一些其实可能会涉及到 这种跨机群的分布式的一些 Prefix Cache 的一些感知的策略 那核心的逻辑是说 我要尽量去命中复用 KV Cache 然后来降低算力的消耗 同时来降低算力成本 提升整个推理的效率 然后再往下的话 就是我们会分为几个层面 就是模型服务平台 那模型服务平台这层 其实核心的价值 核心的工作 其实它主要是做模型的运营 运维 就模型的权重 我们之前我上线部署 然后扩缩等等 包括一些最佳实践的模板 然后再往下 就是我们硅基的自研的推理框架 然后再往下实际上是整个算力调度 那算力调度实际上也会根据流量 去做不同的扩缩容的策略 这里面其实包括 比如说像 PD 分离 我们根据不同的 P 节点和 D 节点 去做相应的扩缩容 然后这块的话 是我们从横向的模型的一个周期去看的 其实刚才主要是围绕着流量 这块其实主要是围绕着 这个模型的部署推理到观测 实际上在部署阶段 其实大家去布一个大模型 现在都非常大 就是从基本上几百 G 对吧 那几百 G 的情况下 首先是说我们要去把它快速的拉起来 那如何是说我在这种 跨节点的集群当中去把它快速拉起来 其实这里边有很多一些加速的策略 以及说一些拉起服务的时候 可能有一些类似于 Lazy Load 的一些方案 然后核心是说 我要快速地把这个镜像给拉起来 然后还有一个是说 为了快速拉起来 我们不可能是说 每一次我拉的时候再要去做很多配置 那这里实际上 我们会把很多不同场景的推理的实践 其实相当于是有一套最佳实践的样 就相当于是在我们的自己的平台里边 那在中间这块其实核心的就是整个推理的 infra 这块的一个优化 那其实最原子的就是推理框架 那推理框架里边最原子的就是一些算子的优化 那通过算子优化 首先我们实现了单个模型实例的一个优化 就举个例子 比如说我们拿一台机器布一个模型 那这时候我们相当于是通过硅基自研的推理框架 把它性能给优化上来 那这其实达到了一定的推理的优化 然后再往上 实际上比如说我们到达集群规模到达了四台 那四台的部署方案 比如说一种是说我还是一台一个实例 那就相当于是四组 那另外一种可能是说 我拿四台机器直接做 PD 比如说它是2P2D 的方案 那这时候其实我们测算下来 基本上同等规模的 PD 分离的这个集群数量 和非 PD 分离的相比来讲 它的并发可能是三到四倍 当然这个在不同的输出情况下 它的效果是不太一样的 那整体而言来讲 它绝对是大于同等 集群数量的吞吐的 然后还有一个 就是网关实际上在整个调度层面 也是非常有价值的体现的 就说如果说是一些不合理的流量 其实是会把某些集群给打爆 那打爆的情况下就会造成 忙的忙死 闲的闲死 那这种其实就非常不好 就像咱们做团队管理一样对吧 那本质上是说我们通过网关 其实是可以把不同集群的整个的吞吐 进一步的做一个扩展 然后还有就是一个 KV Cache 那 KV Cache 实际上在今年其实提的非常多 那去年其实大家基本上都停留在一些技术交流 坦白来讲 那今年实际上我们其实会做这种集中式的 分布式的这种 KV Cache 的缓存池 那它的好处是什么呢 就首先我们从 HBM 降到 DRAM 就比如说从 HBM 降级到 Offload 到 DRAM 上 那它本质上相当于是在一个 PD 分离的一个单个的 一个实例当中的 那这时候因为是说云端 它其实是很多的跨集群的很多的集群 那我们如何是说 比如在一个地方里面有两个 DeepSeek 那它两个都是 PD 分离的 那我为了复用 KV Cache 的话 一种策略是说 上次是 A 集群推的 那我尽量打在 A 集群上 下一次如果说 即使 B 集群闲着 那我也不会推 那这种情况其实就会造成一个问题 A 其实会更很繁忙很繁忙 如果策略不对的话 那通过说 KV 的卸载 比如说我卸到存储里面 那这时候其实 KV Cache 其实本质上和推理的实例已经解耦了 那解耦的好处是说 我无论实例 但我无论流量打到 A 也好 还是 B 也好 那本质上我都可以从存储里面 把这个 KV Cache 给 retrieve 出来 那我们来配置资源 然后调度整个集群等等 但是实际上这也相当于是一种 被动式的这种相当于是一种策略 那现在实际上我们也推出了 SiliconFlow FaaS 那这个其实可以理解为 就类似于 CPU 时代的 这个函数级服务的这种模式 那解决的主要问题 其实是两种 那我们清长客户 他自己会去配一些算力资源 但是他配的时候 他肯定会很纠结 我按照波峰去配的话 我可能会超配 我按照波谷去配的话 我可能会被业务部门会吐槽 怎么算力又不够了之类的 这种情况下 其实他可以采用我们云端的 FaaS 的策略 就是 FaaS 相当于是说 我弹性扩缩容 然后在某一个时间周期内 那客户可以根据他的一些业务的指标 就比如说他的 QPS 大于多少的时候 或者他的 TTFT TPS 大于多少 那这些指标是可以去配的 那达到一定的业务指标以后 实际上整个 FaaS 平台 就相当于是帮他可以去 扩相应的模型实例 就比如我扩一个 Qwen 32B 的模型 扩一个 Qwen 72B 的模型等等 那以此来帮他相当于是削峰填谷这个策略 然后达到整个模型服务的一个相对平稳的这么一个效果 对然后这个简单看一下 就我们硅基其实整个平台上提供的这个模型服务 反正我们在源源不断的更新这个最新的模型 实际上现在应该是 Qwen 2.5 之类应该都有了 对然后这个是我们的一些产品体系 那产品体系其实包含了底层最独立的 就比如说我们的这个推理框架 然后再往上就刚才提到的 FaaS 的这个弹性扩缩容 然后还有一些像那个私有化的一些产品 我们也提供私有化的整个部署的方案 然后还有像我们的其实还有一个 BizyAir 的一个 那个生图生视频的这么一个站点 大家感兴趣也可以去看看 那核心是说我们会把很多这种第三方的开源的一些 比如像 SDXL 等等这些工具链 这些模型包括像类似 ComfyUI 的这种工具链 然后通过 B/S 架构 然后来个提供出来 那这时候其实我们可以做一些这种工作流的托管 对然后这块可以简单看一下 其实就是有一份报告就 IDC 那边 25年其实分析下来是说 硅基流动现在其实目前排名国内第四 就在 MaaS Token 方面 实际上挺不容易的 就从创业公司的角度来讲 就是独立第三方里边相当于是第一名 对然后排在这个 对然后其实我们在开发者生态圈 其实也挺受欢迎的 就包括像 Dify 像 OpenRouter 里边其实都有蛮大的调用量的 对这个其实在总结一下 就第一是说我们会以更多的这种算力的方案 就因为实际上我们会底下会有很多的算力 比如说像英伟达 AMD 等等 那这些我们都会把模型在不同的算力上 去做一个优化 包括不同的部署方案 刚才提到的 PD 分离等等 然后还有就是调度的策略 就刚才提到 FaaS 一些调度策略 然后还有就是模型 那模型实际上我们是在源源不断持续的 去进行一个跟进 适配 然后提供给咱们广大的开发者和企业级的用户 行 我介绍到此 谢谢大家 然后前面硅基流动的唐老师给大家讲了 很多硅基流动在上层在底层算力上面 做了他们很多的优化 把整个算力的利用率达到一个极致 那他们整个在底层的话 其实是用到了亚马逊云科技上面 比较多的一些服务 第一个我们会看到说 在全球范围来看的话 亚马逊云科技上面会有非常多的 这个算力资源 因为大家都知道 算力在现阶段来说 就是非常珍贵的一个资源 然后第二块的话 就是我们在海外其实会有 非常多的资源以及实例都有 第二个方面的话 就是前面看到说 在硅基流动其实它有非常多的波峰和波谷 它提供在它的 SaaS 平台 或者它提供给用户的算力的时候 那怎么应对它的波峰和波谷 那一会我们会讲到 其实在亚马逊云科技上面 会有非常多使用 GPU 的一个方式 然后第三个的话 就是在去走向全球化的过程当中 除了算力以外 还会有其他的一些基础设施 都会跟亚马逊云科技 有比较多的一个合作 然后我们提到说 我们有不同的选择 一方面我们可以用这种 SaaS 的平台 去使用一些 token 然后另外一方面我们也提到说 如果我们想要自己去 host 这样的一些模型 那我们就要考虑到说 以什么样的方式去使用这个 GPU 那其实在亚马逊云科技上面 会有不同的方式去用 第一个就是按需 那按需的话就相对来说 它是最灵活的一个资源 然后第二个的话 就是现在我们很多用 GPU 的客户 都会用到的一种方式 叫做容量预留 那现在容量预留这种方式 和容量块这两个其实是类似的 就是你预留一个时间段说 比如说我要在今天晚上7点 到明天晚上7点 我要去用几台机器 然后在这个时间段 如果有容量的话 你就可以把它给预留下来 你到了对应的时间点 你就可以开出对应的机器 然后这种方式的话 对于按需使用来说 它的折扣相对 它是会有一定的折扣的 然后因为它的灵活性 没有那么高 你是按时间去预定的 那它的话主要是提供是按天级别 这样去使用一些不同的一个算力 然后最后一个就是 我们今天会讲到的 就是竞价的这种方式 可能以前熟悉亚马逊 云的都听过 我们上面有 Spot 的这个机器 会看到说 它以这个很便宜的价格 能够拿到机器 那同样的在现在这个 AI 时代 GPU 的机器也同样 可以以这种竞价的方式去拿到 然后竞价的这种实例 就是它的折扣相对来说是很高的 那我们可以 就我们前面提到的 我们要把整个 token 的单价算到最低 那我们就需要去了解说 怎么用到最便宜的这个算力资源 那亚马逊云科技上的这个 Spot 的话 其实相对来说就是一种方式 那可以理解呢 就是我们把亚马逊云科技上说 多余的一些资源 放到了这个竞价的这个池子里面 那就让说在多出来的这部分资源 大家可以以很便宜的方式去用到 那这个里面就是会有一个 但是就是说这个机器呢 就是可能会中断的 那我们考虑到说 整个 Spot 的使用 因为它会出现中断的这么一个情况 那我们就适合把它用在一些什么样的场景呢 第一个是说我们去做一些微调 第二个是说我们有一些实验性质的 或者是说一些短时的一些开发的任务 我们可以用这种 Spot 的方式去用 另外一个就是我们前面其实有提到硅基流动 他们也在海外大规模的 有在用这样的一些机器 那就说有一些灵活的推理的这个任务 比如说我接下来马上要发新模型 或者发新的应用了 我需要很快速的有一批算力资源上来 因为大家可能采购过 GPU 的都知道 现在国内去采购一些 GPU 可能需要很长的一个时间段 那 Spot 的这个资源 就是能够在你指定的区域 快速的把这个机器给开出来 然后帮你支撑说 我接下来有一到两天的这么一个 波峰的一个情况 那另外就是我们提到 它虽然有中断的这个情况产生 我们怎么把它给用好呢 其实它里面 以前可能用过的都会知道 大家跟大家聊的时候 它都说只有一个提前两分钟的一个通知 给到你的这个机器 你必须在提前两分钟 把你这个机器上面所有的负载移出来 那其实现在 Spot 它还会有一个新的信号 叫这个 rebalance 信号 在 GPU 的这个场景下 它大概会在提前一个小时 就有这样的一个信号 但它是一个概率性的 就是它可能会说 有90% 的概率这台机器会被回收 但是这个两分钟的信号 是一个确定性的 所以提前一小时的信号 我们官方的说的是 在 GPU 的这个场景下 它的可信度是很高的 所以你可以在提前一个小时的时间 收到这个信号之后 把你这台机器 去做一个灵活的处理 那这样大家用 Spot 的机器的场景 其实就会多很多 然后另外一个 还会有一个场景就是说 我们很多时候要去查 我们很多时候要去查哪个区域有机器 其实我们现在有一个新的 API 就是叫这个 SPS 分数 大家在用亚马逊云科技的这个同学呢 就可以用这种 CLI 的方式直接去查 就比如说你可以给出一个实例说 我要在哪个区域 用什么机器 然后我要用多少台 然后它会返回给你一个分数 就说如果说这个评分 你拿到的是9 的话 它大概率就能够 你在这个机器就能开出来 这么多台机器 如果当前这个池子的 得分 就比如说返回给你6分 或者比这个更低的分数 那大概率你在这个区域 就是开不起来机器的 所以这个也是我们要在 以这个用这个 Spot 机器 就这两个结合起来 你就能够知道说 我什么时候能够拿到机器 什么时候这个机器会被回收掉 那这样的话 你就能搭建一个非常灵活的 一个算力的池子 然后前面那个 因为我们是用这种 命令行的方式去查 然后我们也有做好一个方案 就是说 直接有一个这种 Dashboard 然后让大家可以去 它会定时的去跑说不同的区域 哪些区域有对应的机器 然后会有一个得分 然后这样的话 就可以做成一个跨区域的 一个池子 我今天可以在北美拿 今天北美的这个 Spot 的池子 相对来说比较深 我们就可以在这边拿到机器 然后明天可能 就是美东的这个池子 相对来说比较多了 那我们就可以把这个资源 挪到另外一个区域里面 因为在现在这种 整个的应用里面 我们对于这种 就是用户的使用习惯 也是对于这种推理返回的时间 其实没有那么的敏感 所以很多的这种 做推理机群的这个厂商 他们底层 就是在不同的区域 去做不同的这个资源池 然后在用户需要的时候 还调度到不同的区域里面 去进行一个使用 然后有了这些 我们前面提到的这些 不同的 API 的话 那就是能够让大家 很灵活的用到 亚马逊云科技上面 这些便宜的 GPU 的一个资源 对 然后总结起来的话 就是说 第一个就是在我们当前这个时代里面 对于推理侧的 整个算力的需求是 有非常高的一个增长 然后另外一个就是说 如果我们可以用这种 SaaS 的平台 比如说像硅基流动 我们有这么强大的算力 就是我们有自己的一些算力资源 或者有一些自己的场景 能够去做自己 自定义的一些部署的时候 你可以选择说用 结合亚马逊云科技上面的一些服务 自己去做一些整个 模型的部署 去做整个应用的 就自己去做整个调用 所以就会有不同的方式 和灵活性提供给到大家 对 然后这个就是今天 Session 的所有的内容 谢谢大家的时间