*****[](https://ofox.io/zh/models)[](https://app.ofox.io/) **TL;DR。** 按 token 算Kimi K2.7 Codemoonshotai/kimi-k2.7-code在每一档上都比 GLM-5.2z-ai/glm-5.2便宜在 ofox.io 上是输入 $0.95 vs $1.40、输出 $4.00 vs $4.40、缓存读取 $0.19 vs $0.26。但”每 token 更便宜”和”每次跑更便宜”不是同一个数。一趟典型的跑法50K 输入、20K 输出、无缓存里Kimi 花$0.1275GLM 花 $0.1580便宜 19.3%*。缓存命中率一升这个比例就缩水而且它还取决于每个模型完成任务实际烧掉多少 token。两者都是开放权重在 ofox.io 上换一个字符串就切过去。标价说 Kimi 赢。账单就没这么简单了因为单次成本 单价 × 消耗的 token而后半个乘数是跟负载走的。本文给出核实过的价格、一份逐项算过的单次样例以及那条诚实的边界哪些答案我能直接算出来哪些你得在自己的流量上量。摘要你该选哪个场景选谁原因上下文低于 256K 的成本敏感型编码跑法Kimi K2.7 Code50K/20K 无缓存一趟便宜 19.3%每档 token 都更便宜输出主导的生成脚手架、代码批改Kimi K2.7 Code输出 $4.00/M vs $4.40/M而这类跑法输出占大头单次调用塞进超过 256K 的整仓 promptGLM-5.21M 上下文 vs 256K省掉分块和重复输入 token高缓存命中的 code-review 循环两可略偏 KimiKimi 缓存读取更便宜$0.19 vs $0.26/M但缓存会压缩 Kimi 的单次优势隔离网络或必须 fork 的部署都行自托管Kimi 是 Modified MITGLM-5.2 是 MIT都放出了开放权重想用真实数字而不是一张表做决定跑下面的 A/B 循环每次跑消耗多少 token 是跟负载走的本文没测诚实的结论对于能塞进 256K 上下文的编码 Agent 跑法把成本敏感型的默认路由指向moonshotai/kimi-k2.7-code。把z-ai/glm-5.2留给真正需要在单次调用里用满 1M 窗口的任务。单价这一层 Kimi 处处占优单次这一层在大多数现实配比下 Kimi 也占优但会随缓存收窄所以上面这张切分表就是钱真正流动的地方。快速规格对比价格是 ofox.io 网关费率单位美元/百万 token2026 年 7 月 16 日从模型目录上读取。规格来自 Hugging Face 模型卡。规格Kimi K2.7 CodeGLM-5.2ofox 模型 IDmoonshotai/kimi-k2.7-codez-ai/glm-5.2详情页ofox.io/models/moonshotai/kimi-k2.7-codeofox.io/models/z-ai/glm-5.2输入价$0.95 / M$1.40 / M输出价$4.00 / M$4.40 / M缓存读取价$0.19 / M$0.26 / M上下文窗口262,144 token256K1,048,576 token1M架构MoE总参 1T / 激活 32B约 753B 参数厂商Moonshot AI智谱Z.ai权重开放Modified MIT开放MITofox 变体纯文本 “Code”完整模型进入算账之前先从这张表里拎出两点。Kimi 在三档计费轴上都更便宜所以任何负载在 Kimi 上每 token 都付得更少。而上下文窗口的差距不小。GLM-5.2 的 1M 大约是 Kimi 256K 的 4 倍正是这一条规格让单次的答案不只是”永远选 Kimi”。一个溢出 256K 的 prompt 在 Kimi 上必须分块重发而重复的输入 token 恰恰是 Kimi 折扣所在所以足够大的单上下文任务能把差距往 GLM 这边拉回来。ofox 上只提供 Kimi 的纯文本 Code 变体所以这是一场代码与文本的对比不是多模态对比。如果你的 Agent 需要附带截图或图表这两个都不是那一段流水线该用的模型。每 token vs 每次跑容易踩坑的区别常见的错误是把价格表当成跑法对比来读。单次成本是run_cost (input_tokens × input_price) (cached_input_tokens × cache_price) (output_tokens × output_price)价格是固定的、已核实。token 数不是固定的。它取决于你的 prompt 大小、多少输入命中缓存、以及模型完成任务吐了多少输出 token。每一项里价格那一半 Kimi 都赢。token 那一半才是一个”更便宜”的模型在某次具体跑法里仍可能输的地方如果它在到达终点的路上烧掉更多 token。下面是逐档的图景也就是 Kimi 能赢多少的天花板计费轴Kimi K2.7 CodeGLM-5.2Kimi 便宜幅度输入$0.95/M$1.40/M32.1%输出$4.00/M$4.40/M9.1%缓存读取$0.19/M$0.26/M26.9%注意这里的不对称。Kimi 最大的优势在输入便宜 32%和缓存便宜 27%。输出上只便宜 9%。所以一次跑的形态决定了你实际能收多少优势。输入重的跑法收到大折扣。输出重的跑法收到小折扣。而缓存反直觉地在削弱 Kimi 的相对优势因为一个缓存输入 token 花 $0.19 而不是 $0.95正好压缩了 Kimi 领先 32% 的那一行。逐项算一遍一趟典型的 Agent 跑法拿一趟具体的 Agent 跑法把两份账单都算出来。下面这个形态是一趟合理的单任务编码跑法读一段上下文推理吐一个 patch。我对两个模型都固定住的跑法是50,000 输入 token几个文件的上下文加指令20,000 输出 token推理加吐出的 diff缓存在下面单独处理先从无缓存开始我没有任何一方对”每个模型完成同一任务要消耗多少 token”的基准数据所以我把两个模型的 token 数固定成一样只变价格。这样能干净地把价格效应隔离出来。这也意味着这些数字回答的是”如果两个模型吐一样的 token谁更便宜”而不是”谁用更少 token 完成任务”。第二个问题需要实测我在文末明确标出。计费项Kimi K2.7 CodeGLM-5.2输入50K50K × $0.95/M $0.047550K × $1.40/M $0.0700输出20K20K × $4.00/M $0.080020K × $4.40/M $0.0880单次合计$0.1275$0.1580差额$0.0305Kimi 便宜 19.3%一趟差 $0.03绝对数看起来微不足道。上了量就不再微不足道。一个编码 Agent 按这个形态一天猛跑 1,000 趟模型每次跑每天1,000 趟每月Kimi K2.7 Code$0.1275$127.50~$3,825GLM-5.2$0.1580$158.00~$4,740省下$0.0305$30.50~$915每月九百美元就一种负载形态靠改一个字符串的路由。这就是把成本敏感型流量默认指向 Kimi 的理由。缓存的影响缓存越高差距越缩Code-review Agent 和多轮会话每次调用都会重发同一份仓库上下文所以很大一部分输入会命中缓存。两个模型的缓存读取都按低于全价输入的费率计费。下面是同一趟 50K 输入 / 20K 输出的跑法在逐渐升高的缓存命中率下的表现。输入缓存命中Kimi 单次成本GLM-5.2 单次成本Kimi 便宜幅度0%全价$0.1275$0.158019.3%50%25K 命中缓存$0.1085$0.129516.2%80%40K 命中缓存$0.0971$0.112413.6%每个点位 Kimi 都更便宜但随缓存升高差距从 19.3% 掉到 13.6%。原因是结构性的。Kimi 最大的折扣在全价输入上便宜 32%。缓存把全价输入变成缓存价输入而这一档 Kimi 只便宜 27%同时它把整个输入行往零压。剩下的主要是输出那里 Kimi 的优势只有薄薄的 9%。所以你缓存得越多单次成本越被输出主导Kimi 的输入优势就越不管用。实操上的读法如果你的负载是高缓存的 code-review 循环两个模型很接近决胜负更可能是输出质量或 256K 对 1M 的上下文上限而不是单次价格。如果你的负载是低缓存、新上下文的生成Kimi 的折扣就更接近它完整的 19%。配比敏感度比值随输入-输出形态怎么动缓存是一个杠杆。另一个是原始的输入-输出比值与缓存无关。把每 token 价格按三种常见负载形态混合Kimi 的优势会朝一个可预测的方向移动。负载形态Kimi 混合 $/MGLM 混合 $/MKimi 便宜幅度3:1 输入重长上下文读取短 patch$1.71$2.1520.3%2:1 典型编码$1.97$2.4018.1%1:1 聊天式往返$2.48$2.9014.7%1:3 输出重的生成$3.24$3.6511.3%这个走势是缓存走势的镜像。输入重的跑法收到 Kimi 那肥厚的 32% 输入折扣所以优势朝 20% 扩大。输出重的跑法靠的是薄薄的 9% 输出折扣所以优势朝 11% 收窄。Kimi 在每种形态下都更便宜但一个读大文件、吐两行答案的摘要 Agent按比例省得比一个读短 prompt、吐大文件的脚手架 Agent 更多。把两个杠杆放一起图景是Kimi 的单次优势在输入重、低缓存的跑法上最大在输出重、高缓存的跑法上最小。没有哪种组合能翻转排名。它们只是把赢的幅度在大约 11% 到 20% 之间挪动。放大账单这个比值上了量要花多少单次差额是几分钱。它之所以值得做一次路由决策是因为 Agent 集群不会只跑一个任务。下面是那趟典型的 50K 输入 / 20K 输出跑法无缓存按三个量级铺开方便你定位自己的开销。每天跑数Kimi 每天GLM 每天Kimi 每月GLM 每月每月省下1,000$127.50$158.00~$3,825~$4,740~$91510,000$1,275$1,580~$38,250~$47,400~$9,150100,000$12,750$15,800~$382,500~$474,000~$91,50019.3% 的差距在每个量级都成立因为它是跑法形态的属性不是量的属性。变的只是绝对开销。一天一千趟省下的钱够买一个监控工具。一天十万趟省下的钱够养一个小团队。你的集群落在这张表哪一行就是模型选择不再是舍入误差的地方。Token 消耗这张暗牌我测不了的部分上面所有内容都把两个模型的 token 数固定成一样。那是一个刻意的简化也是整个对比的承重注脚。单次成本 价格 × token。价格我核实了。token 我没量因为没有任何一方发布过官方基准说明这两个模型各自要消耗多少输入、思考、输出 token 才能完成同一个 Agent 任务。任何人在没有可复现脚本的情况下报给你一个”Kimi 少用 15% token”的数字都是在猜。下面说明它为什么重要作为一个盈亏平衡点而不是一个基准在 50K 输入的这趟跑法里GLM-5.2 总共花 $0.1580。Kimi 50K 输入花 $0.0475在追平 GLM 之前还剩 $0.1105 的预算。按 $4.00/M 输出算这份预算能买约27,600 个输出 token。所以 Kimi 可以比 GLM 的 20,000 多吐大约1.38 倍输出成本仍打平或更低。反过来看如果 GLM-5.2 在某个任务上倾向于用明显更少的输出 token 收尾它更高的单价就能在那个任务上被部分或完全抵消。一旦允许两个模型吐不同的 token 数单价赢家就不自动是单次赢家。在这个跑法形态上Kimi 在价格优势翻转之前还有约 38% 的余量这是个舒服的缓冲但它是缓冲不是无穷。输出这个数字里还藏着一个褶皱。两个模型都会吐思考 token而思考 token 按输出计费。Kimi K2.7 Code 是思考模型Moonshot 记录了这一代相对上一代在思考 token 用量上的下降这本身是另一条成本线在 token 削减分析里讲过。放到跨模型对比里它意味着”输出 token”这一行不只是可见的答案而是答案加推理且这个拆分因模型和任务难度而异。一个为了到达同一答案而推理更多的模型即便输出单价更低在输出上也付得更多。这是 token 消耗那半个等式必须实测、不能假设的又一个原因。要填平这个缺口唯一诚实的办法是在你的真实任务上跑两个模型从每条响应里读resp.usage。下面的 A/B 循环打印的正是这个。决策流程哪种跑法用哪个模型flowchart TD A[新的 Agent 跑法] -- B{输入超过 256K token} B --|是| C[GLM-5.2需要 1M 窗口] B --|否| D{实测的 token 差距偏向 GLM} D --|是| E[GLM-5.2更少输出 token 抵消单价] D --|否或未实测| F{需要视觉/多模态} F --|是| G[路由到视觉模型不是这两个] F --|否| H[Kimi K2.7 Code256K 以下单次更便宜]这个流程把整个论证编码进去了上下文上限第一实测的 token 行为第二模态第三Kimi 作为所有漏下来情况的成本默认。大多数团队跳过的那一支是中间那个因为他们从不跑 A/B也就从不知道 GLM 是否用更少 token 完成他们的任务。跳过它通常仍然偏向 Kimi因为有约 38% 的输出余量但花一小时确认一下值得。什么时候选 Kimi K2.7 Code三种 Kimi 明显是单次首选的情况能塞进 256K 上下文的跑法。大多数单任务编码跑法远低于 256K。在这个窗口内 Kimi 每 token 都更便宜所以在每种配比下单次都更便宜尤其是输入重的任务那里 32% 的输入折扣完整落地。新上下文的输出重生成。脚手架、测试生成、代码批改应用。低缓存复用意味着完整的输入折扣生效即便是薄薄的 9% 输出优势摊到几千趟上也会累积。成本默认的 Agent 集群。如果你把大量常规 Agent 跑法路由过来只把硬骨头升级到别处Kimi 作为默认行项按上面建模的形态每 1,000 趟/天的负载每月省 $915。Modified MIT 许可加了第四个、更软的理由。如果 Moonshot 之后改了托管定价权重给你在同一个模型上留了自托管的退路。这个选项即便你永远不用也有价值因为它给你未来价格波动的暴露封了顶。同样的逻辑适用于走普通 MIT 的 GLM-5.2所以开放权重不是这两者之间的决胜项但对任何你本可能默认使用的闭源 API它是实打实的区别。什么时候选 GLM-5.2两种单价更贵的模型反而可能是单次更优选择的情况超过 256K 的整仓 prompt。GLM-5.2 的 1M 上下文约是 Kimi 的 4 倍。一个溢出 256K 的 prompt 在 Kimi 上必须分块重提每块都会重发重叠的输入。重复的输入 token 会被再次计费而那正是 Kimi 折扣的所在所以足够大的单上下文任务能中和甚至反转单价差距。如果你的任务真需要在一次调用里用满 1MGLM 原生做得到Kimi 做不到。你已经实测出 token 消耗差距。如果你自己的 A/B 显示 GLM 在你的具体任务上用足够少的输出 token 收尾、足以盖过它 4.4 对 4.0 的输出单价那就信你的数据别信这张表。盈亏平衡点是上面那个跑法形态约 1.38 倍的输出余量超过它的负载偏向 GLM。两种情况有一个共同主题它们都是成本等式里 token 那一半压过价格那一半的场景。1M 上下文这一条是硬覆盖因为一个塞不进 256K 的任务在 Kimi 上单次调用根本跑不了而分块会成倍增加你要付的输入 token。实测差距这一条是软覆盖只有你手里有真实数据时才成立。没有那份数据价格那一半赢而价格那一半指向 Kimi。这就是值得记住的不对称要在成本上给 GLM 撑腰你需要一个具体理由而 Kimi 是那个不需要任何理由、光凭费率表就成立的成本默认。什么时候两个都不该选如果你的 Agent 需要视觉截图、图表、PDF 页面ofox 上纯文本的 Kimi Code 变体做不了而 GLM-5.2 的成本优势对一个它本也不擅长的任务毫无意义。把多模态那一段路由到视觉模型把这两个留给文本与代码的活。关于横跨 ofox 目录的更广路由模式包括哪里该把 Claude 模型拉进来做升级见 GLM-5.2 vs GPT-5.5 成本拆解它在更高的价位段上走了同一套每 token 对每账单的逻辑。通过 ofox 试两个一个循环搞定 A/Bmoonshotai/kimi-k2.7-code和z-ai/glm-5.2都在https://api.ofox.io/v1上走 OpenAI 兼容协议上线。换模型就是换一个字符串。这个脚本才真正回答了上面那些表回答不了的 token 消耗问题。PythonA/B 两个模型并读取 token 用量from openai import OpenAI import os, time client OpenAI(base_urlhttps://api.ofox.io/v1, api_keyos.environ[OFOX_API_KEY]) prompt Refactor this module for async I/O and add early returns on empty input: ... for model in [moonshotai/kimi-k2.7-code, z-ai/glm-5.2]: t0 time.time() resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], ) dt time.time() - t0 u resp.usage print(f{model}: {dt:.1f}s in{u.prompt_tokens} out{u.completion_tokens})prompt_tokens和completion_tokens字段就是成本等式里缺的那一半。把它们乘上核实过的价格你就得到你自己任务上的真实单次成本而不是上面那些表里的等 token 近似。在你确定路由默认之前先在你实际负载的 20 到 30 个代表性用例上跑一遍。Node同样的形态import OpenAI from openai; const client new OpenAI({ baseURL: https://api.ofox.io/v1, apiKey: process.env.OFOX_API_KEY, }); const prompt Refactor this module for async I/O and add early returns on empty input: ...; for (const model of [moonshotai/kimi-k2.7-code, z-ai/glm-5.2]) { const t0 Date.now(); const resp await client.chat.completions.create({ model, messages: [{ role: user, content: prompt }], }); const u resp.usage; console.log(${model}: ${(Date.now() - t0) / 1000}s in${u.prompt_tokens} out${u.completion_tokens}); }生产路由一行切换模型拿到自己的 token 数字后生产路由就是一个函数。把成本敏感型流量默认给 Kimi把超过 256K 的任务发给 GLMdef pick_model(input_tokens: int) - str: if input_tokens 256_000: return z-ai/glm-5.2 # needs the 1M window return moonshotai/kimi-k2.7-code # cheaper per run under 256K resp client.chat.completions.create( modelpick_model(estimated_input_tokens), messagesmessages, )同一个 key、同一个端点、同一条计费行。ofox 账单上的模型列会告诉你每条请求花了多少所以你可以在一周后拿这份切分去对真实开销做校验。相关的 Kimi 成本工作见一次 30% 的思考 token 削减到底能不能降你的 K2.7 账单以及 Kimi K2.7 Code 的免费与零成本路径。FAQ按 token 单价算Kimi K2.7 Code 比 GLM-5.2 便宜吗每一档都便宜。Kimi 输入便宜 32%$0.95 vs $1.40/M、输出便宜 9%$4.00 vs $4.40/M、缓存读取便宜 27%$0.19 vs $0.26/M。这就意味着每次跑更便宜吗在大多数现实负载形态下是的但幅度会变。一趟 50K 输入 / 20K 输出的跑法无缓存时 Kimi 便宜 19.3%80% 缓存命中时便宜 13.6%。缓存越高省得越少因为 Kimi 最大的折扣在全价输入上。GLM-5.2 有没有可能每次跑更便宜有两种方式。如果一个任务溢出 Kimi 的 256K 上下文、必须分块重复的输入 token 能把折扣吃光。以及如果 GLM 在你的具体任务上用足够少的输出 token 收尾它更高的输出单价能被抵消。在你自己的任务上实测 token 消耗才能知道。上下文窗口差多少Kimi K2.7 Code 是 262,144 token256K。GLM-5.2 是 1,048,576 token1M约大 4 倍。这个差距是单次答案不是”永远选 Kimi”的主要原因。两个都是开放权重吗是的。Kimi K2.7 Code 走 Modified MIT 许可GLM-5.2 走 MIT。自托管是应对未来托管价格变动的退路不过它会加上 GPU 和运维成本。参考信息来源ofox.io 模型目录moonshotai/kimi-k2.7-codeofox.io 模型目录z-ai/glm-5.2Kimi K2.7 Code 模型卡Hugging FaceGLM-5.2 模型卡Hugging FaceGLM-5.2 vs GPT-5.5 成本拆解GLM-5.2 接入指南Kimi K2.7 Code token 削减账单分析Kimi K2.7 Code 免费与零成本路径