Kimi K2.7 Code vs GLM-5.2：单次 Agent 跑一趟谁更便宜？（2026）

TL;DR。 按 token 算，Kimi K2.7 Code（moonshotai/kimi-k2.7-code）在每一档上都比 GLM-5.2（z-ai/glm-5.2）便宜：在 ofox.ai 上是 输入 $0.95 vs $1.40、输出 $4.00 vs $4.40、缓存读取 $0.19 vs $0.26。但”每 token 更便宜”和”每次跑更便宜”不是同一个数。一趟典型的跑法（50K 输入、20K 输出、无缓存）里，Kimi 花 $0.1275，GLM 花 $0.1580，便宜 19.3%。缓存命中率一升，这个比例就缩水，而且它还取决于每个模型完成任务实际烧掉多少 token。两者都是开放权重，在 ofox.ai 上换一个字符串就切过去。

标价说 Kimi 赢。账单就没这么简单了，因为单次成本 = 单价 × 消耗的 token，而后半个乘数是跟负载走的。本文给出核实过的价格、一份逐项算过的单次样例，以及那条诚实的边界：哪些答案我能直接算出来，哪些你得在自己的流量上量。

摘要：你该选哪个？

诚实的结论：对于能塞进 256K 上下文的编码 Agent 跑法，把成本敏感型的默认路由指向 moonshotai/kimi-k2.7-code。把 z-ai/glm-5.2 留给真正需要在单次调用里用满 1M 窗口的任务。单价这一层 Kimi 处处占优；单次这一层，在大多数现实配比下 Kimi 也占优，但会随缓存收窄，所以上面这张切分表就是钱真正流动的地方。

快速规格对比

价格是 ofox.ai 网关费率，单位美元/百万 token，2026 年 7 月 16 日从模型目录上读取。规格来自 Hugging Face 模型卡。

进入算账之前，先从这张表里拎出两点。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 最大的优势在输入（便宜 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 完成任务”。第二个问题需要实测，我在文末明确标出。

一趟差 $0.03，绝对数看起来微不足道。上了量就不再微不足道。一个编码 Agent 按这个形态一天猛跑 1,000 趟：

每月九百美元，就一种负载形态，靠改一个字符串的路由。这就是把成本敏感型流量默认指向 Kimi 的理由。

缓存的影响：缓存越高，差距越缩

Code-review Agent 和多轮会话每次调用都会重发同一份仓库上下文，所以很大一部分输入会命中缓存。两个模型的缓存读取都按低于全价输入的费率计费。下面是同一趟 50K 输入 / 20K 输出的跑法，在逐渐升高的缓存命中率下的表现。

每个点位 Kimi 都更便宜，但随缓存升高，差距从 19.3% 掉到 13.6%。原因是结构性的。Kimi 最大的折扣在全价输入上（便宜 32%）。缓存把全价输入变成缓存价输入，而这一档 Kimi 只便宜 27%，同时它把整个输入行往零压。剩下的主要是输出，那里 Kimi 的优势只有薄薄的 9%。所以你缓存得越多，单次成本越被输出主导，Kimi 的输入优势就越不管用。

实操上的读法：如果你的负载是高缓存的 code-review 循环，两个模型很接近，决胜负更可能是输出质量或 256K 对 1M 的上下文上限，而不是单次价格。如果你的负载是低缓存、新上下文的生成，Kimi 的折扣就更接近它完整的 19%。

配比敏感度：比值随输入-输出形态怎么动

缓存是一个杠杆。另一个是原始的输入-输出比值，与缓存无关。把每 token 价格按三种常见负载形态混合，Kimi 的优势会朝一个可预测的方向移动。

这个走势是缓存走势的镜像。输入重的跑法收到 Kimi 那肥厚的 32% 输入折扣，所以优势朝 20% 扩大。输出重的跑法靠的是薄薄的 9% 输出折扣，所以优势朝 11% 收窄。Kimi 在每种形态下都更便宜，但一个读大文件、吐两行答案的摘要 Agent，按比例省得比一个读短 prompt、吐大文件的脚手架 Agent 更多。

把两个杠杆放一起，图景是：Kimi 的单次优势在输入重、低缓存的跑法上最大，在输出重、高缓存的跑法上最小。没有哪种组合能翻转排名。它们只是把赢的幅度在大约 11% 到 20% 之间挪动。

放大账单：这个比值上了量要花多少

单次差额是几分钱。它之所以值得做一次路由决策，是因为 Agent 集群不会只跑一个任务。下面是那趟典型的 50K 输入 / 20K 输出跑法，无缓存，按三个量级铺开，方便你定位自己的开销。

19.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 Code：256K 以下单次更便宜]

这个流程把整个论证编码进去了：上下文上限第一，实测的 token 行为第二，模态第三，Kimi 作为所有漏下来情况的成本默认。大多数团队跳过的那一支是中间那个，因为他们从不跑 A/B，也就从不知道 GLM 是否用更少 token 完成他们的任务。跳过它通常仍然偏向 Kimi，因为有约 38% 的输出余量，但花一小时确认一下值得。

什么时候选 Kimi K2.7 Code

三种 Kimi 明显是单次首选的情况：

1. 能塞进 256K 上下文的跑法。 大多数单任务编码跑法远低于 256K。在这个窗口内 Kimi 每 token 都更便宜，所以在每种配比下单次都更便宜，尤其是输入重的任务，那里 32% 的输入折扣完整落地。
2. 新上下文的输出重生成。 脚手架、测试生成、代码批改应用。低缓存复用意味着完整的输入折扣生效，即便是薄薄的 9% 输出优势，摊到几千趟上也会累积。
3. 成本默认的 Agent 集群。 如果你把大量常规 Agent 跑法路由过来，只把硬骨头升级到别处，Kimi 作为默认行项，按上面建模的形态，每 1,000 趟/天的负载每月省 $915。

Modified MIT 许可加了第四个、更软的理由。如果 Moonshot 之后改了托管定价，权重给你在同一个模型上留了自托管的退路。这个选项即便你永远不用也有价值，因为它给你未来价格波动的暴露封了顶。同样的逻辑适用于走普通 MIT 的 GLM-5.2，所以开放权重不是这两者之间的决胜项，但对任何你本可能默认使用的闭源 API，它是实打实的区别。

什么时候选 GLM-5.2

两种单价更贵的模型反而可能是单次更优选择的情况：

1. 超过 256K 的整仓 prompt。 GLM-5.2 的 1M 上下文约是 Kimi 的 4 倍。一个溢出 256K 的 prompt 在 Kimi 上必须分块重提，每块都会重发重叠的输入。重复的输入 token 会被再次计费，而那正是 Kimi 折扣的所在，所以足够大的单上下文任务能中和甚至反转单价差距。如果你的任务真需要在一次调用里用满 1M，GLM 原生做得到，Kimi 做不到。
2. 你已经实测出 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/B

moonshotai/kimi-k2.7-code 和 z-ai/glm-5.2 都在 https://api.ofox.ai/v1 上走 OpenAI 兼容协议上线。换模型就是换一个字符串。这个脚本才真正回答了上面那些表回答不了的 token 消耗问题。

Python：A/B 两个模型并读取 token 用量

from openai import OpenAI
import os, time

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key=os.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(
        model=model,
        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.ai/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 的任务发给 GLM：

def 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(
    model=pick_model(estimated_input_tokens),
    messages=messages,
)

同一个 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 token（256K）。GLM-5.2 是 1,048,576 token（1M），约大 4 倍。这个差距是单次答案不是”永远选 Kimi”的主要原因。

两个都是开放权重吗？ 是的。Kimi K2.7 Code 走 Modified MIT 许可，GLM-5.2 走 MIT。自托管是应对未来托管价格变动的退路，不过它会加上 GPU 和运维成本。

参考信息来源

• ofox.ai 模型目录：moonshotai/kimi-k2.7-code
• ofox.ai 模型目录：z-ai/glm-5.2
• Kimi K2.7 Code 模型卡（Hugging Face）
• GLM-5.2 模型卡（Hugging Face）
• GLM-5.2 vs GPT-5.5 成本拆解
• GLM-5.2 接入指南
• Kimi K2.7 Code token 削减账单分析
• Kimi K2.7 Code 免费与零成本路径