Kimi与GLM规模推理降本术

Cloudflare把开放模型推到了生产规模

Cloudflare近日公开了Kimi与GLM系列模型的规模化推理实践，并将月之暗面Kimi K2.5设为Agents SDK starter的默认模型。更有说服力的是，Cloudflare没有只展示基准测试，而是把Kimi K2.5接入内部安全审计、代码分析和公开代码审查智能体，实际负载已经超过每天70亿Token。

规模化推理是指在多GPU、多节点环境中，以可预测的延迟、吞吐和成本持续运行大模型。 它和“模型能不能启动”是两回事：在实验室里让模型回答一个问题并不难，难的是同时处理大量长上下文请求，还要控制排队、显存碎片、缓存命中率和故障恢复。

Cloudflare披露的账单比模型跑分更值得关注。按照其内部估算，如果继续使用标准等级的商业模型，同一套安全审计工作负载每年需要约240万美元；切换到Kimi K2.5及配套推理栈后，预计成本下降77%，一年节省接近185万美元，剩余成本约55万美元。

这意味着Cloudflare优化的并不是一个偶尔调用的聊天机器人，而是一条每天吞吐70亿Token、全年可能处理约2.56万亿Token的生产管线。对于这种规模，输入价格每降低0.1美元／百万Token，理论上的年度差额都可能达到25.6万美元，缓存和路由策略自然不再是“小优化”。

Kimi K2.5很大，但每次计算没有看起来那么大

Kimi K2.5是月之暗面推出的混合专家大模型，支持256K上下文、视觉输入、多轮工具调用和结构化输出。 这几项能力正好对应代码智能体的核心需求：读取大型代码库、持续保留工具调用历史、分析截图或图表，并把结果交给下游自动化系统。

Kimi K2.5的总参数规模超过1万亿，但每个Token只会激活约320亿参数。其本质是混合专家架构，即模型拥有大量不同“专家”，路由器会针对当前Token选择少量专家参与计算，而不是让全部参数同时工作。

“更小”因此不是指模型文件真的很小，而是指每次推理的有效计算量可以小得多。Kimi K2.5的模型权重体积约560GB，仅把权重装进显存，理论上就至少需要8块80GB H100；考虑KV Cache、运行时缓冲区和并发余量后，生产部署通常还需要更多资源。

GLM是智谱开发的通用语言模型系列，近几代产品同样把代码、工具调用和智能体任务作为重点。 Cloudflare在这次分享中把Kimi与GLM放在同一个规模化推理框架下讨论，说明其目标并非为单一模型搭建专用服务，而是形成能够承载不同开放权重模型的基础设施。

不过，Cloudflare此次公开的数据明显更偏向Kimi K2.5。每天70亿Token、77%成本降幅、Agents SDK默认模型和内部安全审计案例，均有明确的Kimi K2.5指向；GLM更多体现的是这套推理栈对另一类大型模型架构的适配能力。因此，不能把Kimi的成本数据直接套到所有GLM版本上。

| 对比维度 | Kimi K2.5 | GLM系列 | 标准商业前沿模型 | |---|---|---|---| | 模型形态 | 超万亿参数MoE，约320亿参数参与单次计算 | 不同版本参数和架构不同，需按具体版本评估 | 多数不公开完整权重与架构 | | 上下文能力 | 256K Token | 随版本变化 | 通常为长上下文，但限制和计费方式不同 | | 典型优势 | 长上下文、代码、多轮工具调用、视觉输入 | 指令遵循、代码与结构化任务 | 综合能力强，平台配套成熟 | | 部署方式 | 可在自有或云端推理基础设施运行 | 开放版本可自行部署 | 主要通过托管服务使用 | | Cloudflare公开证据 | 每天超70亿Token，年成本预计降低77% | 证明推理栈具备多模型适配能力 | 作为240万美元年度成本基准 | | 主要风险 | 集群复杂、模型升级成本高 | 版本差异大，需要逐项验证 | 成本和平台依赖更强 |

真正的主角是Infire，而不只是Kimi

Infire是Cloudflare为大型语言模型设计的自研推理引擎。 Cloudflare没有简单套用一套现成框架，而是围绕自身GPU集群、网络平台和Workers AI调度体系，对模型加载、并行计算、前缀处理与请求路由进行了针对性优化。

Infire同时组合了数据并行、张量并行和专家并行。三者解决的是不同层面的问题：数据并行通过复制模型处理更多请求，张量并行把一次矩阵运算拆到多块GPU，专家并行则把MoE模型中的不同专家分散到不同设备。

对于Kimi K2.5这类超大MoE模型，专家并行尤其关键。模型虽然每次只激活约320亿参数，但被选中的专家可能分布在不同GPU上；如果节点间通信速度不够快，GPU就会把时间浪费在等待数据，而不是执行计算。

Cloudflare的网络基础设施在这里形成了现实优势。大模型服务并不只是GPU数量竞赛，GPU之间、节点之间和区域之间的数据移动同样会决定吞吐与延迟。对于专家路由频繁、上下文很长的模型，网络延迟会被每一层计算持续放大。

| 推理机制 | 解决的问题 | 对生产负载的意义 | |---|---|---| | 数据并行 | 单个模型副本并发不足 | 通过多个副本扩展请求吞吐 | | 张量并行 | 单块GPU无法容纳或高效计算模型层 | 将矩阵运算拆分到多块GPU | | 专家并行 | MoE专家数量多、分布复杂 | 让不同GPU分别承载不同专家 | | 分离式前缀处理 | 长输入和逐Token生成争抢相同资源 | 分开调度Prefill与Decode负载 | | 前缀缓存 | 智能体反复发送相同上下文 | 避免重复计算和重复计费 | | 会话亲和 | 请求落到不同实例导致缓存失效 | 让同一会话尽量命中同一模型实例 | | 异步批处理 | 非实时任务挤占在线请求容量 | 将扫描、研究任务放入后台队列 |

Prefill与Decode必须分开看

Prefill是模型一次性读取输入上下文并建立KV Cache的阶段，Decode则是模型逐个生成输出Token的阶段。 Prefill更像批量阅读，能够大量使用GPU并行能力；Decode更像边想边写，每一步都依赖上一步结果，更容易受显存带宽和请求调度影响。

Cloudflare采用了分离式前缀处理架构，把两类计算交给更适合的资源池。这样做可以避免一个携带20万Token代码库的请求，占住负责实时输出的GPU，导致其他用户明明只问了一个短问题，却长时间看不到第一个Token。

这项设计对智能体比对普通聊天更重要。一个代码智能体可能连续调用搜索、文件读取、测试和终端工具40次，每次都带上不断变长的历史上下文；如果每一步都重新处理完整前缀，真正烧钱的往往不是最后生成的答案，而是被重复读取几十遍的仓库信息和工具日志。

前缀缓存需要和会话路由一起使用

前缀缓存是把已经计算过的输入上下文及其KV Cache保存下来，在后续请求中直接复用。 Cloudflare为缓存命中的输入Token提供折扣，这对系统提示词固定、对话历史持续累积的智能体工作流尤其有价值。

前缀缓存的难点不是“存下来”，而是让下一次请求准确找到它。如果同一会话第一次落到GPU集群A，第二次却被路由到集群B，而两边没有共享对应缓存，那么理论上的缓存能力再强也不会产生实际收益。

Cloudflare因此增加了x-session-affinity请求头，用于将同一会话尽量路由到同一个模型实例或相同缓存域。OpenCode与Agents SDK starter已经内置相关支持，开发者不必自己维护一套复杂的会话到实例映射。

会话亲和并不等于永久绑定。生产系统仍需要在实例过载、GPU故障或模型升级时重新调度，因此更合理的理解是“提高路由稳定性”，而不是保证某个会话永远停留在同一块GPU上。

异步批处理把“不着急”的任务移出快车道

异步批次推理是把不要求即时返回的请求放进队列，由平台在可用算力出现时批量执行。 Cloudflare表示，其内部异步任务通常可以在5分钟内完成，这个时延不适合聊天，却很适合代码扫描、依赖审计、研究整理和离线评测。

异步推理的价值在于提高GPU利用率。在线服务必须为流量峰值预留容量，而批处理任务可以填补低谷，并通过相似长度请求分组减少Padding浪费，让同一批次中的GPU工作更加整齐。

对开发团队而言，异步队列还提供了一种更直接的优先级管理方式。面向用户的交互请求继续走同步通道，夜间仓库扫描和大规模评测则进入异步队列，两者不会再用相同的速率限制争抢资源。

77%降本不能简单理解成模型单价便宜77%

Cloudflare给出的77%是特定安全审计负载下的综合成本变化，而不是Kimi K2.5公开标价与某个闭源模型标价的直接差值。这个结果同时包含模型选择、缓存折扣、输入输出比例、批处理效率、GPU利用率以及内部基础设施摊销。

按照240万美元年度基准计算，降低77%后约为55.2万美元，节省约184.8万美元。若按每天70亿Token全年运行估算，原方案的综合成本约为0.94美元／百万Token，新方案约为0.22美元／百万Token，但这个数字只是从总账反推的工作负载均价，不能当作Workers AI的公开单价。

这种区别非常重要。安全审计智能体可能拥有较高的前缀缓存命中率，也可能以输入Token为主；一个输出很长、缓存命中率很低的内容生成产品，即使使用相同模型，也未必能复现77%的降幅。

“更安全”首先来自审计覆盖率，而不是模型自动可信

Cloudflare所说的“更安全”，更现实的含义是安全审计变得足够便宜，可以高频、持续地运行。过去因为成本只能抽样检查的代码，现在可以在每次提交或合并请求中进行自动扫描，这会直接提高漏洞发现覆盖率。

Cloudflare已经在OpenCode环境中把Kimi K2.5作为编程智能体使用，并部署名为Bonk的公开代码审查智能体。相比一次演示，持续运行的代码审查管线更能检验模型是否会在长上下文、工具失败和重复任务中保持稳定。

开放权重模型也能给数据治理带来更多选择。企业可以把模型运行在明确的基础设施边界内，缩短代码、日志和安全报告经过的处理链路，但这并不自动代表数据不会被记录或跨区域流动，最终仍取决于平台配置、日志策略和合规设置。

模型本身同样不能成为安全边界。Kimi和GLM仍可能受到提示词注入、恶意仓库内容、工具参数污染和幻觉影响，因此代码审计智能体必须使用最小权限，限制终端、文件写入和网络访问，并对高风险修改保留人工复核。

Cloudflare证明的是工程经济性，不是模型胜负

Cloudflare这次分享最有价值的部分，不是宣布Kimi或GLM在某项榜单上击败了谁，而是证明开放模型已经能够进入每天数十亿Token的生产负载。对开发者来说，这比单次跑分更接近真实采购决策。

Kimi K2.5成为Agents SDK starter默认模型，也不意味着它适合所有场景。默认模型要平衡能力、上下文、可用性和成本；如果业务更依赖严格的结构化输出、低延迟短回答或特定语言能力，GLM或其他模型仍值得使用真实任务进行对照测试。

Cloudflare也没有公开足够信息让外界完整复现这笔成本账。GPU型号与数量、平均输入输出比例、缓存命中率、并发水平、错误重试率和服务等级都会影响结论，因此77%应该被视为一个经过生产验证的案例，而不是适用于所有团队的保证值。

开发团队最值得抄的是四层拆分法

模型、推理引擎、请求调度和业务权限应该被当作四个独立层次优化。 只比较每百万Token价格，很容易忽视真正决定总成本和安全性的系统因素。

1. 模型层先看任务匹配。 长上下文代码任务可以优先测试Kimi K2.5，强调结构化输出或特定指令遵循时再加入GLM对照组。
2. 推理层关注GPU利用率。 超大MoE模型必须同时考虑张量并行、专家并行、KV Cache容量和跨节点通信。
3. 调度层拆分实时与离线请求。 用户交互走同步服务，扫描、评测和研究任务走异步批处理。
4. 应用层限制智能体权限。 模型可以读取什么、调用什么工具、是否能够写文件和执行命令，必须由外部策略控制。

Cloudflare给出的最终答案并不是“换成更便宜的模型”这么简单，而是让合适的模型运行在合适的推理栈上，再通过缓存、路由和任务分级消灭重复计算。Kimi与GLM只是这套体系中最显眼的一层，Infire和平台调度才是把每天70亿Token变成可承受账单的关键。

参考来源

• MoonshotAI Kimi-K2项目：月之暗面公开的Kimi K2模型资料与相关技术说明。
• Kimi K2.5模型页面：Kimi K2.5的模型卡、架构信息与使用限制。
• THUDM GLM-4项目：GLM系列的官方开源项目，可用于了解模型能力与工具调用设计。

本文核心运行数据来自Cloudflare于2026年8月初发布的技术文章《Smaller, faster, safer: running Kimi and GLM at scale》；受参考链接域名范围限制，文末未附Cloudflare站外链接。