加了 1 个参数，GLM-5.3-Flash 便宜了 6.3 倍

我们问了 GLM-5.3-Flash 一个非常简单的问题：SSH 默认使用哪个端口。它用了 625 个输出 Token，最后才给出答案：“22”。

这不是我们特意挑出来的极端案例，而是 5 次测试的中位数。Qwen3.8-Max 回答同一个问题只用了 156 个 Token。Flash 这些调用中，我们支付的大部分输出成本，其实都花在了用户根本看不到的推理过程上，而这个问题最终的答案只有两个字符。

结果发现，解决办法只需要改一行参数。在请求里加入 reasoning_effort: "low"，同一个问题就只需要 155 个 Token。GLM-5.3-Flash 默认会使用最高的推理强度，但仅从请求本身你根本看不出来。只增加这一个参数，就让 Flash 在我们的整套 Prompt 测试中便宜了 6.3 倍。

这一点对大多数人来讲很重要，因为模型是按 Token 收费的，但价格页面不会告诉你一个模型通常会生成多少 Token。GLM-5.3-Flash 的输出价格只有 Qwen3.8-Max 的十二分之一，也只有 Kimi K3 的三十分之一。为了看看这些纸面价格比例落到真实请求里到底是什么样，我们在 DigitalOcean 无服务器推理上实际跑了 2700 次 API 调用。

使用默认配置时，Flash 相比 Qwen 的成本优势是 2.3 倍，而不是 12 倍。显式配置后，这个优势变成了 14.5 倍；相比 Kimi K3，则达到 106 倍。这几个数字之间的差距，只来自一个参数。本文后面会完整讲清楚我们是怎么找到它的，包括一开始走错的那条路。

整个测试总共花了 14.75 美元。下面所有结果都可以通过这个代码仓库(github.com/Jameshskelton/GLM-Flash-Analysis)复现，包括 Prompt、测试脚本、原始日志，以及重新生成文中所有图表的脚本。

GLM-5.3-Flash 是什么：3200 亿参数，每个 Token 激活 180 亿，采用 MIT 许可证

GLM-5.3-Flash 是 Z.ai GLM-5 系列中首个原生多模态模型，采用 MIT 许可证发布。它并不是在 GLM-5.2 基础上做的一次后训练更新，而是从一个重新训练的基础模型开始，整个架构和训练方案都围绕效率进行了重新设计。

最值得关注的架构数字，也是和成本最相关的数字，是：总参数量 3200 亿，但每个 Token 只激活 180 亿参数。 Z.ai 表示，GLM-5.3-Flash 在多项 Benchmark 上超过 GLM-5.2，而价格只有后者的十分之一；同时在代码和 Agent 任务上接近 Claude Opus 4.8，例如 Terminal-Bench 2.1 得分 84.3，DeepSWE 得分 63.4。

这主要由两项架构变化推动。第一项是将稀疏注意力与线性注意力结合起来的混合注意力设计，这是 GLM 系列首次采用这种架构，目标是在保留长上下文能力的同时，降低长上下文推理成本。第二项是 Manifold-Constrained Hyper-Connections，Z.ai 用它来提升模型扩展效率。这两项设计都建立在一个包含 30 万亿 Token 的多模态预训练语料之上。

如果把它和 DigitalOcean 无服务器推理 最近上线的其他开放权重模型放在一起看，最有意思的是它的计算规模。Qwen3.8-Max 是一个 2.4 万亿参数的模型，每个 Token 激活 950 亿参数；Kimi K3 的规模更大。而 Flash 每个 Token 只激活 180 亿参数——大约只有 Qwen 激活参数量的五分之一，相比 Kimi 则更低得多——但它在 Artificial Analysis Intelligence Index 上的得分几乎和 Kimi K3 Max 一样。

这就是 GLM-5.3-Flash 的核心卖点：以远低于传统大模型的单 Token 计算量，提供接近前沿模型的能力。这也是为什么 DigitalOcean 可以把它的输入价格定在 0.15 美元 / 百万 Token，而 Kimi 则是 3.00 美元 / 百万 Token。

这个卖点本身确实成立，对应 Benchmark 数据也来自 Z.ai 官方。但有一个数字几乎没人会公布：一个模型为了得到答案，到底会使用多少 Token。而我们最终发现，相当一部分纸面成本优势，恰恰消耗在这里。

我们如何测量 DigitalOcean 无服务器推理上的实际成本

DigitalOcean 无服务器推理上有三个开放权重模型：glm-5.3-flash、qwen3.8-max 和 kimi-k3。它们在 DigitalOcean 上每百万 Token 的价格如下：

我们准备了两组 Prompt。第一组包含 24 个开放式问题，分为三个难度层级：Tier 1 是类似“SSH 默认端口是什么”这样的简单查询问题；Tier 2 是中等难度分析问题，比如为什么批处理能提高吞吐量，却不一定降低单次请求延迟；Tier 3 则是带多个约束条件的复杂问题，例如在固定预算下选择部署拓扑。所有问题都没有指定输出格式，也没有 System Prompt 和采样参数。第二组包含 20 个有确定答案的任务，用来检查更低成本是否会以牺牲正确率为代价。

每个 Prompt 都会针对每个模型运行 5 次，而且执行顺序随机化。

在看数据之前，需要先说明一个背景。Artificial Analysis 在 Intelligence Index 上给 Kimi K3 和 GLM-5.3-Flash 的评分都是 57。两个模型在同一个独立综合 Benchmark 上得分一样，但输入价格相差 20 倍，输出价格相差 30 倍。这是第三方测量结果，我们没有自行验证。不过，这意味着真正值得问的问题并不是“哪个模型更聪明”，而是“它们各自回答一个问题到底要花多少钱”。

GLM-5.3-Flash 实际成本只比 Qwen3.8-Max 低 2.3 倍，而不是 12 倍

Flash 依然是最便宜的，而且差距很明显。但如果你只是把 Qwen 的单 Token 价格除以 12 来估算基础设施预算，那么最终结果会偏差超过 5 倍，而且偏差方向对你最不利。

Kimi 的价格优势缩水得没那么明显：纸面上是 30 倍，实际是 17 倍。Qwen 则缩水得更多：纸面 12 倍，实际只剩 2.3 倍。这种不对称是一个重要线索，而原因就藏在输出长度里。

为什么：GLM-5.3-Flash 的输出 Token 是 Qwen3.8-Max 的 4 倍以上

在完全相同的 Prompt 下，而且没有给任何模型指定输出格式时，输出 Token 中位数如下：

在简单问题上，Flash 输出的 Token 是 Qwen 的 4.0 倍；到了困难问题，这个比例达到 5.7 倍。这基本已经解释了大部分成本差距。一个每 Token 便宜 12 倍、但要多用 5 倍 Token 的模型，实际当然不可能仍然便宜 12 倍。

这些 Token 都去了哪里？Flash 和 Kimi 都会把推理过程单独放在 reasoning_content 字段里，因此我们可以直接统计。下面是输出 Token 中用于推理的比例中位数：

也就是说，输出账单里大约三分之二到六分之五的 Token，都是用户最终看不到的推理内容。在 Tier 1 和 Tier 2 中，Flash 的推理占比还是三个模型里最高的，而且随着问题难度提高，这个比例还会继续上升，而不是保持不变。

尾部情况比中位数看起来更夸张。Flash 的平均输出长度是 3111 Token，但中位数只有 1409，变异系数超过 1.0。我们记录到最长的一条 Response 达到 15,006 Token，其中 94.7% 都是推理 Token，它回答的是一个部署架构问题。单独这一条 Response 就花了 0.00753 美元，是本次研究中 Flash 平均单次请求成本的 4.8 倍、简单问题中位成本的 24 倍，也是 reasoning_effort: low 下平均请求成本的 30 倍。

这也是为什么本文一直使用中位数，而不是平均值。平均值在这里既不能让数据更好看，也会误导读者。

enable_thinking 在 GLM-5.3-Flash、Qwen3.8-Max 和 Kimi K3 上的行为完全不同

DigitalOcean 的 API 端点兼容 OpenAI API，并且会转发 chat_template_kwargs，因此你可以传入 enable_thinking: false，让模型尝试跳过推理过程。很多文章都会直接把它当作关闭思考模式的开关，我们一开始也是这么做的。

我们让每个模型把完整 Prompt Set 各跑了三遍：一次完全不发送思考参数，一次将 enable_thinking 设置为开启，一次设置为关闭。结果，同一个参数在三个模型上的行为完全不同。

在 GLM-5.3-Flash 上，它基本只是改变了推理内容展示的位置。 把它设为 false 之后，reasoning_content 字段确实变空了，所以日志里看不到推理过程了。但输出 Token 反而增加了 20.9%，成本也增加了 11.1%。

推理并没有停止，只是跑进了用户能看到的答案里。比如，在思考模式理论上已经关闭的情况下，模型回答部署拓扑问题时，开头是：

Let me analyze this problem carefully. The setup: - 70B model - Peak traffic: 40 requests/second…

再比如，回答“TTFT 是什么缩写”这种简单问题时：

The user is asking about “TTFT” in the context of LLM inference… Let me think about what I know about TTFT:

我们至少在 120 条 Response 中的 103 条里检测到了残留在可见答案中的 Chain-of-thought。这个检测使用的是关键词启发式规则，因此应该把 103 看作下限，而不是精确总数。在 40 条简单问题中命中了 38 条，在 40 条困难问题中命中了 31 条。

在 Kimi K3 上，同一个参数则能正常生效。 输出 Token 下降了 67.9%，成本下降了 75.5%。每次调用的输入额外 Token 也从 99 个降到 32 个，因为 Chat Template 中的推理模板同样被移除了。

在 Qwen3.8-Max 上，思考模式默认就是关闭的。 DigitalOcean 当前就是以这个配置提供 Qwen。把思考模式打开后，输出 Token 增加了 429%，成本增加了 508%。

所以，enable_thinking 并不是一个可以跨模型直接复用的统一参数。在一个模型上，它可以省 75%；在另一个模型上，它会让成本提高约 5 倍；到了第三个模型，它除了改变你能不能看到推理过程之外，几乎什么也没改变。

而对于 GLM-5.3-Flash 来说，这甚至根本不是正确的控制参数。Model Card 里其实写了另一个参数，只是我们一开始没有仔细看到。

GLM-5.3-Flash 的 reasoning_effort 默认是 max，设置成 low 后成本降低 84%

GLM-5.3-Flash 通过 reasoning_effort 控制推理强度，可设置为 low、high 或 max。Model Card 明确说明：如果不传这个参数，默认就是 max。我们针对同样的 24 个 Prompt，把三个等级都测试了一遍。

这里有两个关键结果。

默认设置确实就是 max。 对同一个 Prompt 和同一次重复测试做配对比较后，默认配置和显式 max 的中位比值是 0.984。也就是说，每一个没有额外配置的 GLM-5.3-Flash 请求，都会使用它最昂贵的推理强度。

降低推理强度可以节省 4～6.3 倍成本。 low 相比默认配置降低了 84% 的成本。这是整个研究中我们测到的最大单项优化幅度，甚至比直接更换模型的影响还大。

而且这种变化并不是统一压缩，而是会根据难度自动调整，这其实正是我们希望看到的行为。下面是不同难度下推理 Token 占比的中位数：

在 low 下，简单问题上的推理基本消失了——推理 Token 只占输出的 3%，而默认设置是 72%。到了困难问题，模型仍然会进行较多推理，大约占 40%。也就是说，这并不是把模型“砍掉脑子”，而是告诉它不要在根本不需要复杂推理的问题上花太多时间。

我们还测试了 Model Card 推荐用于 Chat 场景的 clear_thinking: true。结果几乎没有任何可测量变化：配对比值是 0.99，而且成本还略微更高。这个结果也值得记住，避免有人把它误当成一个省钱参数。

只比较 enable_thinking 时，单次请求成本相差 18.5 倍；加入 reasoning_effort 后，相差达到 106 倍

9 种配置——3 个模型 × 3 种思考模式——单次请求成本跨度达到 18.5 倍。

把第 6 行和第 7 行放在一起看。配置得当的 Kimi K3，实际成本甚至低于配置错误的 Qwen3.8-Max，尽管 Kimi 的官方输出价格是 Qwen 的 2.5 倍。仅仅一个布尔参数，就能让 Kimi 从 17.01 倍降到 4.17 倍——这个变化幅度甚至比直接换模型还大。

Flash 的三种 enable_thinking 配置之间成本差距只有 11%。这并不是因为 Flash 没有可调节的参数，而是因为我们一开始调错了参数。把 reasoning_effort 加进来之后，同一张成本阶梯就变成了这样：

此时成本跨度不再是 18.5 倍，而是 106 倍。其中最大的单一影响因素，只是一个模型上的一个参数。

这里还有一个值得单独强调的二阶影响：不同模型的默认配置根本不一致——Qwen 默认关闭思考模式，而 Flash 默认使用最高推理强度。因此，如果你拿几个模型直接“开箱即用”做对比，实际上比较的并不只是模型，而是模型 + 默认配置。绝大多数公开模型对比都会这么做，包括我们自己在补测这些配置之前也是如此。

降低推理强度会影响准确率吗？会，但只出现在困难问题上

看到这里，一个很自然的质疑是：也许贵模型之所以贵，就是因为能力更强，而我们测到的只是“更高质量答案所对应的价格”。

所以我们又构建了第二套任务：20 个有确定答案的问题，包括成本计算、Retry Policy 下的期望值、组合数学问题，以及延迟预算推导。每个问题都要求最后一行严格使用 ANSWER: 固定格式，这样评分可以直接通过字符串提取完成，而不依赖人工判断。测试覆盖 3 个模型、3 种思考模式和 2 种降低后的推理强度，每个配置运行 5 次，总共得到 1099 条可评分 Response。

在默认配置下，三个模型全部拿到了 100%。

在 9 种 enable_thinking 配置中，各模型的准确率都达到或接近 100%，但单个正确答案成本相差了 33 倍。在这个测试范围内，便宜模型并不是因为能力差才便宜。至少在这些任务上，它并没有更差。

但降低推理强度并不是没有代价。 Flash 在默认设置下得分 100%，high 是 98%，而 low 降到 92%。也就是说，省钱确实会带来一定准确率损失，而且我们能明确看到损失发生在哪里：所有错误都出现在 Tier 3 任务中。Tier 1 和 Tier 2 在所有推理强度下都是满分。

在 low 下，一个多步成本建模问题 5 次里错了 3 次——其中两次把正确答案 61.22 写成了 0.6122，这更像是单位错误，而不是纯粹的推理错误。降低推理强度并不会让模型突然不会记忆或算术，而是会降低它维持多步推理链条、并在最后检查结果的能力。

从单个正确答案成本来看，low 依然更划算，因为在这套相对简单的测试里，8% 的失败率仍然抵不过 84% 的成本下降。但我们不会把这个结论直接推广到更复杂的任务上。这里最重要的限制是：我们的任务集对模型来说还是太简单，11 种配置里有 6 种达到 100%。这样的测试足以证明“降低推理强度会带来准确率下降”，但不足以告诉你在真正困难的任务上会下降多少。对于更难的推理任务，可以预期差距会进一步扩大。

结构化输出可以让 GLM-5.3-Flash 重新获得接近纸面价格的成本优势

两组 Prompt 之间有一个重要区别：可验证任务强制要求固定输出格式，而开放式 Prompt 没有任何格式限制。这个原本并不是主要测试变量的差异，最后却变成了整个研究中最有价值的结果之一。

结构化输出对 Flash 的压缩效果比另外两个模型更明显，而 Flash 的冗长输出恰恰就是此前侵蚀它价格优势的主要原因。因此，Flash 的实际成本优势会随着工作负载形式变化：

在结构化输出下，Flash 几乎完全兑现了官方价格暗示的成本优势；而在完全不受约束的开放式输出中，它相对 Qwen 只能兑现大约五分之一。

但这里也有一个不能忽略的限制。我们还把 8 个简单问题重新测试了一遍，只在结尾加上一句 “Answer in one sentence.”。结果三个模型的输出 Token 都下降了 70%～91%，效果甚至比思考参数在其中两个模型上的影响还大。但推理 Token 占比几乎没变化：Flash 从 72% 变成 77%，Kimi 则始终是 65%。

也就是说，这条指令压缩的是最终答案，而不是模型内部的推理过程。你仍然会把相同比例的账单花在用户看不到的推理上，只是整个账单本身变小了。

不同工作负载应该使用什么 reasoning_effort？

在 GLM-5.3-Flash 上显式设置 reasoning_effort。 如果不设置，它就会使用 max，也就是最昂贵的配置。这是整个测试中影响最大的单一成本调节手段。

对于分类、信息提取、模型路由、格式转换和简单查询，使用 reasoning_effort: low。 在所有低于复杂多步推理的任务上，它没有带来准确率损失，但相比默认配置便宜了 6.3 倍。

对于混合工作负载，high 比默认配置更适合作为默认值。 在我们的任务集上，它相比 max 便宜 4 倍，准确率是 98%，而默认配置是 100%。如果你只想选择一个设置长期使用，优先考虑这个。

对于真正困难的多步推理，保持 max。 我们在降低推理强度后看到的所有错误都出现在 Tier 3，而我们的测试集本身还不够难，无法准确告诉你在更复杂任务中性能会下降多少。

如果输出是开放式且没有长度限制，预算应该基于实际 Token，而不是官方价格。 先跑 100 次具有代表性的真实请求，再根据实际 Token 量估算。

如果你已经在使用 Kimi K3，可以测试工作负载是否能接受 enable_thinking: false。 在我们的测试里，它节省了 75% 成本，但准确率下降了 2 个百分点。

如果你正在使用 Qwen3.8-Max，并考虑打开思考模式，要先注意它会让成本增加约 5 倍。 开启之前，最好先验证它是否真的能带来实际收益。

不要在 GLM-5.3-Flash 上使用 enable_thinking: false 并期待它能省钱。我们的测试中，它反而让成本增加了 11%。同样，也不要指望 clear_thinking: true 能改变成本，因为实测没有效果。

目前，这三个模型都已经可以通过 DigitalOcean 无服务器推理 使用。API 端点兼容 OpenAI，地址是 https://inference.do-ai.run/v1，因此要在自己的工作负载上复现这些测试，基本只需要修改 Base URL 和模型 ID：glm-5.3-flash、qwen3.8-max 或 kimi-k3。本文所有测试都是通过这个 API 端点，使用标准 openai Python Client 完成的。

为什么要在 DigitalOcean 上运行 GLM-5.3-Flash，而不是其他平台？

先坦诚说明一点：本文使用的价格并不是 DigitalOcean 独有。GLM-5.3-Flash 采用 MIT 许可证，Z.ai 公布的官方价格与我们测试使用的价格一致，因此单纯看模型的单 Token 成本，并不足以成为选择某个托管平台的理由。如果有人以明显更低的价格提供完全相同的模型权重，要么是平台自己做了折扣，要么比较的其实不是同一件东西。

真正不同的，是 Token 周围的整套基础设施。这次测试过程中，有三个因素很重要，而它们在生产环境里同样重要。

周边技术栈都在同一个地方。 Token 价格只是推理账单的一部分。如果向量数据库、对象存储和应用服务器在一家 Cloud，而模型部署在另一家，那么每次 Retrieval 都需要支付出站流量费用，还要承担跨平台往返延迟。对于一个每次请求需要进行多次 Retrieval 的 RAG Pipeline 来说，这种跨平台请求增加的延迟，甚至可能高于模型自身的首 Token 延迟（TTFT）——而这些成本和延迟都不会出现在单 Token 价格比较里。如果推理服务和 Managed Postgres、Spaces、App Platform 部署在同一平台上，就可以避免这一次跨平台跳转。

一个账号，一张账单。 无服务器推理的使用量和其他 DigitalOcean 基础设施都会出现在同一个 DigitalOcean 账号和同一张账单上。这听起来只是管理上的便利，但如果你真正尝试过审计一张拆在三个平台、使用三种计费模式和三套 Token 统计规则的推理账单，就会知道差别有多大。这也意味着，测试一个新模型时不需要重新走一套独立采购流程。

还有一条可以离开按 Token 计费的路径。 本文所有测试都使用无服务器推理。如果你的工作负载继续增长，例如需要持续高吞吐、流量更加稳定可预测，或者对资源隔离有要求，那么专属推理可以继续提供相同的 OpenAI-compatible API，同时使用预留 Capacity，因此迁移更像是一次配置调整，而不是重写应用。再往下一层，GPU Droplets 允许你在自己的 GPU 实例上运行自己的推理服务——这确实属于一次真正的架构调整，但依然可以在同一个账号下完成，不需要更换 Cloud Provider。

这些因素都不会出现在单纯的 Token 单价比较中，而这恰恰是重点。单 Token 价格是最容易比较的数字，但正如本文前面的测试所展示的，它反而最不可能单独决定你的最终账单。

测试方法：这些数字是如何得到的

所有测试都运行在 DigitalOcean 无服务器推理的 https://inference.do-ai.run/v1 API 端点上，该端点兼容 OpenAI API。

没有发送任何采样参数。 我们没有设置 Temperature、top_p 或 Penalty。Kimi K3 使用固定采样参数，因此如果只给另外两个模型设置这些参数，就会引入新的不对称，后面还得额外解释。三个模型全部使用平台默认值。

使用非流式输出，并设置 max_tokens=32000。 早期一次测试使用 8000 Token 上限，结果 Flash 的 Tier 3 Response 有 20% 被截断——也就是说，Token Budget 用完时模型还在进行推理，甚至还没输出最终答案。本文最终使用的数据中没有任何截断记录，所有 finish_reason 都是 stop。

随机化执行顺序。 完整的“模型 × Prompt × 重复次数”测试矩阵使用固定 Seed 打乱执行顺序，这样平台随着时间产生的性能变化会平均分散到各模型，而不是集中影响最后执行的那个模型。

Token 统计。 DigitalOcean 的 usage Object 不会单独统计推理 Token，completion_tokens_details 返回的是 null。但模型会把推理内容放在 Message 的 reasoning_content 字段中。我们使用每个模型自己的 Tokenizer 在本地统计这部分 Token，再与实际计费的 completion_tokens 对齐。剩余差值是每个模型固定的 Chat Template Offset：Flash 为 +2，Qwen 为 +1，Kimi 为 +13。固定 Offset 通常说明 Tokenizer 使用正确；如果这个差值随机波动，就意味着我们的统计方式有问题。本文所有比例都基于实际计费 Token，并保留这些 Offset。

推理控制参数通过三种不同方式发送，因为它们不能互换。enable_thinking 和 clear_thinking 放在 chat_template_kwargs 中，而 reasoning_effort 放在 Request Body 顶层。每一次请求都会记录它实际发送的 extra_body。我们没有因为 API 返回 200 就假设参数真的生效，而是通过实际行为验证：不同测试组会针对同样的 Prompt 和重复次数做配对比较。如果参数被忽略，那么 Token 分布应该几乎没有差异。

使用中位数，而不是平均值，原因前面已经解释过。5 次重复测试足以支持一个中位数和范围，但不足以给出非常窄的置信区间。

这项研究的限制

本文测的是单次请求成本和单个正确答案成本，而不是完成整个任务的成本。 没有 Sandbox、多轮 Agent Loop，也没有代码执行。Agent 工作负载显然是下一步最值得测的方向，但我们目前还没有做。

模型能力通过第三方数据保持可比，而不是由我们重新测试。 Artificial Analysis 在 Intelligence Index 上给 Kimi K3 和 GLM-5.3-Flash 都打了 57 分。这是他们的测量结果，不是我们的，我们也没有尝试复现。

可验证任务集太简单。 11 种配置里有 6 种拿到了 100%。这套测试足以发现降低推理强度会让准确率下降——low 下是 92%——但不足以告诉你在真正困难的工作负载中会下降多少。因此，这里的准确率比较只能说明：在这一难度、这一类任务上，模型表现接近，不能推广到更广泛场景。

我们一开始测试错了参数。 最初的实验使用了 enable_thinking，但这并不是 GLM-5.3-Flash Model Card 推荐的控制方式。直到我们重新仔细阅读 Model Card 后，才发现真正应该使用的是 reasoning_effort，而这个参数显著改变了结论。本文仍然保留 enable_thinking 的测试结果，但应该把它理解为“这个参数在模型上的行为”，而不是“模型能不能减少推理”的最终结论。

我们的答案 Key 有一道题写错了。 在延迟预算任务中，45 条 Response 全部回答 43，而我们的答案 Key 写的是 42。后来确认模型是对的：第一个 Token 在 TTFT 时已经到达，只有后续 Token 才会继续增加总延迟。我们修正了答案 Key，并且选择公开这个问题，因为一个永远不会出错的固定答案 Key，很多时候只是因为根本没人真正检查过。

Kimi K3 有 12 条 Response 存在无法解释的计费 Token。 这些记录里的 completion_tokens 比实际返回的推理内容 + 最终答案多出 85～391 Token。在大约 1000 条 Kimi Record 中共有 12 条出现这种情况，我们没能解释原因。Flash 和 Qwen 没有出现类似尾部现象。

2700 次调用里有 1 次失败。 这次请求在重试 5 次之后仍然返回 HTTP 429。

297 条记录触发了 Prompt Cache。 每次都恰好缓存 128 Token，因为相同 Prompt 在后续重复测试中命中了 Cache。这只会影响输入成本，而输入成本在这组账单里占比很小。我们没有人为禁用它，而是保留了真实行为。

两套 Prompt Set 的 Token 数不能直接互相比。 可验证任务额外带有格式说明，而开放式 Prompt 没有。应该比较同一个任务集内不同模型之间的比例，而不是跨两个任务集比较绝对 Token 数。

所有数据都只是某一时间点的结果。 价格、Serving Default 和模型版本都会变化。代码仓库里记录了本次测试所使用的价格快照日期。

自己复现这些测试

代码仓库(github.com/Jameshskelton/GLM-Flash-Analysis)中包含固定版本的 Prompt Set 及其 SHA256、测试脚本、所有原始 Response Log、Grader，以及重新生成本文全部数字和图表的分析脚本。使用的模型 ID 分别是 glm-5.3-flash、qwen3.8-max 和 kimi-k3。

整个研究大约只需要 14 美元和半天时间。

如果你重新运行后得到不同的数据，欢迎提交 Issue。我们也很想知道结果。

FAQ

GLM-5.3-Flash 是 DigitalOcean 无服务器推理上最便宜的模型吗？

在我们的测试范围内，是的，而且在所有测试配置中都是最便宜的。默认设置下，它的单次请求成本是 0.00156 美元，Qwen3.8-Max 为 0.00361 美元，Kimi K3 为 0.02661 美元。设置 reasoning_effort: low 后，成本进一步降到 0.00025 美元——比 Qwen 便宜 14.5 倍，比 Kimi 便宜 106 倍。

关闭思考模式能降低成本吗？

取决于模型，也取决于你使用的是哪个参数。在 Kimi K3 上，enable_thinking: false 可以降低 75.5% 的成本。Qwen3.8-Max 默认已经关闭思考模式。而在 GLM-5.3-Flash 上，enable_thinking: false 反而让成本增加了 11.1%，因为模型继续在用户可见答案里进行推理；真正有效的参数是 reasoning_effort，最多可以降低 84% 成本。

GLM-5.3-Flash 默认的 reasoning_effort 是什么？

max。如果请求里没有发送 reasoning_effort，模型就会运行在 max。我们针对完全相同的 Prompt，把未设置和显式 max 做了对比，中位比值是 0.984。这意味着每个未显式配置的请求，实际上都运行在最昂贵的设置。

降低推理强度会影响准确率吗？

会，主要出现在困难问题上。在 20 个可验证任务中，GLM-5.3-Flash 默认配置得分 100%，high 为 98%，low 为 92%。所有失败都发生在多步推理任务上，简单任务在所有等级下都没有受到影响。

为什么我的 LLM 账单比价格页面算出来的高？

最可能的原因是输出 Token 数量。推理模型会生成大量计费但不会展示给用户的 Token。在我们的测试中，这部分占输出费用的 65%～84%。单 Token 价格只告诉你单价，却不会告诉你最终会生成多少 Token。

LLM 账单里推理 Token 占多少？

GLM-5.3-Flash 默认设置下，简单问题中位数为 72%，困难问题会上升到 84%。使用 reasoning_effort: low 后，简单问题降到 3%，困难问题约为 40%。Kimi K3 则从 65% 上升到 82%。Qwen3.8-Max 默认关闭思考模式，因此默认不会承担这部分额外推理成本。

便宜模型的答案会更差吗？

在默认配置下没有。我们一共评分了 899 条 Response，覆盖 3 个模型和各自 3 种 enable_thinking 模式。在有确定答案的问题上，三个模型都达到或接近 100%；最低的是关闭思考模式的 Kimi K3，为 98%。但单个正确答案成本相差达到 33 倍。降低 GLM-5.3-Flash 的推理强度确实会影响准确率：high 为 98%，low 为 92%。因此完整评分数据一共包含 11 种配置、1099 条 Response。

在哪里可以运行 GLM-5.3-Flash？

模型权重采用 MIT 许可证，并已经发布在 Hugging Face，因此既可以自行部署，也可以通过任何提供该模型的平台运行。我们是在 DigitalOcean 无服务器推理上进行测试的，目前它与 Qwen3.8-Max、Kimi K3 都可以通过 https://inference.do-ai.run/v1 这个兼容 OpenAI 的 API 端点调用，GLM-5.3-Flash 的模型 ID 是 glm-5.3-flash。

GLM-5.3-Flash 在 DigitalOcean 上比其他平台更便宜吗？

单 Token 价格并不是差异点：这个模型是开放权重模型，而且 DigitalOcean 的价格与 Z.ai 公布的官方价格一致。真正会影响总成本的，是模型与其他技术栈之间的距离——例如每次 Retrieval 产生的出站流量和网络往返延迟并不会体现在单 Token 价格比较中——以及当工作负载增长后，能不能在不重新迁移整套平台的情况下切换到专属 Capacity。

如何降低输出 Token 成本？

有三个主要手段，按影响大小排序。第一，在 GLM-5.3-Flash 上显式设置 reasoning_effort：low 比默认便宜 6.3 倍，high 便宜 4 倍。第二，限制输出格式：强制使用固定答案结构，让 Flash 的输出 Token 中位数降低了 80.4%。第三，加上简洁回答要求，例如 “Answer in one sentence”，可以让三个模型在简单问题上的输出减少 70%～91%。其中只有第一个方法真正降低了账单里推理 Token 所占的比例；另外两个方法只是让总账单变小，而推理 Token 占比基本不变。