Revolut 自托管 GLM-5.3：成本拆解与 API 选型

评估 Revolut 自托管 GLM-5.3 的效果时，多数团队应先做按量付费的 API 试点。保留通往前沿模型的调用路径，用来处理未通过质量检查的任务。只有当自身请求量、延迟要求和运维成本支持这一选择时，再考虑专用托管。

下文区分了 Revolut 报告的结果与面向团队的建议。文档和 API 价格的核查日期为 2026-11-09。

Revolut 实际部署了什么？

Revolut 为约 2,000 名工程师把开放权重 GLM 模型设为默认选项，前沿模型则留给例外任务。其 AI Engineer 演讲与文字稿介绍了从 GLM-5.1 迁移到 GLM-5.3 的过程。后续部署使用了 56 块 Nvidia B200 GPU。

运维指标幻灯片还提到了 Together。不能据此认定 Revolut 买了 56 块 GPU，并部署在自己的场地。幻灯片说明了合作伙伴是谁，但没有交代硬件所有权或完整的运维安排。

模型接入端点与编程客户端是两个独立选择。更换模型不应以替换所有编程客户端为前提。在所述架构中，GLM 负责文本任务，路由器把图像理解请求转给支持视觉的模型。

生产力数据也需要明确边界。Abitbol 报告称，编码耗时指标改善约 60%，交付周期（lead time）改善约 70%。但介绍采用情况的幻灯片将交付周期的改善标为 60%。

这些数据来自 Revolut 的内部观察，并非在相同条件下对比 GLM 与 Claude 的测试结果。它们不能证明改善仅由更换模型造成。

成本降低 90%，究竟比较了什么？

90% 比较的是 Revolut 报告的推理账单，不是雇佣工程师或拥有基础设施的总成本。官方演讲解读称，账单约为此前向前沿模型供应商支付费用的十分之一。账单降至原来的十分之一，就对应 90% 的降幅。

另据 The Register 报道，每百万输入/输出 token $0.30 这一数字属于 Revolut 使用 GLM-5.1 的阶段。应把这项历史 token 单价与报告的总账单降幅分开看。它不是 GLM-5.3 API 的公开费率，也不是 Claude Code 或 Codex 的订阅额度。

运维指标幻灯片还标注了缓存 token 免费。不过，演讲材料没有提供两种方案在可比账期内的用量数据，也缺少运维费用明细。因此无法据此复算完整成本，更不能把 $0.30 称为包含全部摊销费用的总拥有成本。

比较托管报价前，先确认单位成本的分子包括什么。核对 GPU 租金或折旧、配套服务器、网络、存储、电力、支持服务及工程人力。确认哪些费用已经打包在报价中，避免重复计入。

然后定义分母。未缓存输入、缓存读取和生成输出属于不同的计费类别。包含免费缓存读取的平均单价，不能直接与未缓存输入的单价相比。

为什么选择 256K 上下文和低于 3 秒的首 token 延迟？

把 256K 当作需要用实际任务验证的上下文预算，而不是 GLM-5.3 的模型上限。Z.ai 当前模型文档列出的能力是纯文本输入和 1M token 上下文窗口。

Abitbol 所说的“长上下文是骗局”，讲的是推理服务中的取舍。请求越长，保存上下文和处理输入所需的资源就越多。集群规模固定时，能留给并发会话的资源也就越少。

他的实用目标是首 token 延迟低于 3 秒，生成速度约为每秒 200 个 token。这些指标描述了 Revolut 希望达到的使用体验。它们不保证每个无法复用缓存上下文的 256K token 请求，都能在 3 秒内完成输入处理。

试点时，把没有现成缓存可用的冷请求，与能够复用缓存上下文的请求分开测量。分别在常规并发和峰值并发下，记录延迟中位数及第 95 百分位数。还要测量任务完成时间，因为 token 生成速度不包含运行测试或等待工具的耗时。

先提供相关文件和检索到的依据，不要为了用满窗口而填入更多内容。为输出预留空间。对比扩大上下文前后通过验收的任务表现，只有扩大上下文带来的改善足以抵消额外成本或延迟时，才提高上下文预算。

哪些部分需要 GPU 容量和运维投入？

要复现 Revolut 的推理服务性能，必须针对具体负载调优，不能只加载同一份模型权重。性能幻灯片显示，在同样的 56 块 B200 GPU 上，首 token 延迟从 14.26 秒降到了 1.68 秒。

这意味着等待首 token 的时间减少了约 88%。它不代表每项编码任务都快了 88%。

演讲讨论了 FP4 量化，以及 prefill 与 decode 分离。Prefill 即预填充阶段，负责处理输入。Decode 即解码阶段，负责生成输出 token。这些推理服务配置需要容量测试，也需要运维人员负责处理调优后出现的性能或任务质量下降。

56 块 GPU 也不是加载 GLM-5.3 的最低硬件要求。当前 vLLM 部署指南介绍了使用 8 块 H200 或 H20 GPU 的单节点 FP8 部署。这种更小的配置不保证达到 Revolut 的并发量、延迟或成本水平。

试点专用托管时，要求在拟用硬件上回放具有代表性的智能体会话。固定模型权重版本、精度、上下文预算和峰值并发量。只有任务结果通过验收、延迟也在可接受范围内，才扩大容量。

没有 56 块 GPU，团队能先借鉴什么？

先借鉴默认模型策略和评估方法，再考虑复制基础设施。以下是建议的试点方案，不是对 Revolut 内部配置的还原。

从代码仓库中选出 20 项代表性任务，例如修复缺陷、编写测试、重构和修改文档。让 GLM-5.3 与当前模型从相同的起始提交运行。保持编程客户端、工具权限、验收测试和评审标准不变。

每次运行使用独立的工作副本。成功的任务必须读取所需文件，产出可供评审的变更，并通过约定的检查。仅在聊天中给出看似合理的回答还不够。

明确规定请求如何分流：

• 只需处理文本的常规编程任务交给 GLM-5.3。
• 需要解读图像的任务交给已批准使用的视觉模型。
• 一次修复尝试失败后，或评审者明确要求时，转交前沿模型并记录原因。

这套策略只是评估起点，不代表适用于所有任务的最优重试次数。两条调用路径都必须遵守已批准的数据处理规则和工具权限。

要在客户端实现路由，可以参考 Claude Code Router 配置指南。这是一种实现选择，不代表 Revolut 使用了这个软件包。

记录输入、缓存输入、输出 token，以及失败尝试、转交前沿模型的费用、总耗时和人工评审时间。比较每项通过验收的任务所需的总支出。编码智能体单任务成本指南解释了为什么仅凭较低的 token 单价无法做出选择。

只有达到质量门槛的任务类别，才把 GLM-5.3 设为默认模型。如果额外重试或评审吃掉了节省的费用，就保留原来的调用路径。

通过 API 使用 GLM-5.3 要花多少钱？

Z.ai 标准 API 可以提供可测量的基线，无需先承诺投入 GPU 资源。截至 2026-11-09，其公开价格列出的 GLM-5.3 费率如下，币种为 USD：

token 类别	每百万 token 的价格
未缓存输入	$1.40
缓存输入	$0.26
输出	$4.40

缓存输入的存储标为限时免费。不要把这项临时条件视为永久条款。

以 1 亿个输入 token、1000 万个输出 token 的假设用量为例，未使用缓存时的模型 token 费用为：

100 × $1.40 + 10 × $4.40 = $184.00

如果其中 9000 万个输入 token 按缓存命中计费，估算费用变为：

10 × $1.40 + 90 × $0.26 + 10 × $4.40 = $81.40

这些是计算示例，不是实测账单。示例假设不使用付费工具，只计算模型 token 费用。90% 的缓存占比也是示例假设，不是对实际负载的承诺。

用实际响应中的 usage.prompt_tokens_details.cached_tokens 字段区分缓存输入。Z.ai 在上下文缓存指南中说明了该字段。

2026-11-09 核查的 BetterToken 目录也列出了 glm-5.3。其 OpenCode GLM 接入指南使用 OpenAI 兼容基础地址 https://www.bettertoken.ai/v1。根据实测的 token 用量构成比较当前价格。这条 API 接入路径不复现 Revolut 的基础设施成本结构，也不包含编程工具订阅。

要检查 Z.ai 访问是否正常，请按其 HTTP API 指南创建 Standard API Key。本例使用已充值的标准 API 账户。

在已安装 curl 的 Bash 中运行以下命令。第一条命令会静默等待密钥输入。粘贴密钥并按 Enter，屏幕不会显示密钥字符。

read -rs ZAI_API_KEY && export ZAI_API_KEY

curl --silent --show-error \
  --write-out '\nHTTP %{http_code}\n' \
  "https://api.z.ai/api/paas/v4/chat/completions" \
  -H "Authorization: Bearer $ZAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "glm-5.3",
    "messages": [
      {"role": "user", "content": "Return exactly READY."}
    ]
  }'

Chat Completion 参考文档说明了这个端点和响应格式。检查 HTTP 状态是否为 200、choices[0].message.content 是否非空，以及是否存在 usage 对象。预期回答是 READY。这只检查访问是否正常，不验证编码质量或工具执行。

遇到 HTTP 429 时，先查看 JSON 中的错误码，再决定是否重试。Z.ai 的 1113 表示余额不足或没有资源包，1302 表示请求速率受限。前者应为实际使用的 API 账户充值，后者应降低请求频率。这些含义仅对应 Z.ai 的错误码参考文档。

Yingjun Wu 的 35% 盈亏平衡点能直接套用吗？

不能。Wu 分析的是对外销售 DeepSeek V4.1 Flash 推理服务，而不是为内部工程团队提供 GLM-5.3。

在他 2026 年 11 月 2 日更新的分析中，H200 即使满负载运行，也无法覆盖租金。B300 方案则在利用率约 35% 时达到盈亏平衡。H200 方案按每块 GPU 每小时计算，收入约为 $1.60，租金为 $3.99。按这些四舍五入后的数值计算，尚未计入其他费用时，每块 GPU 每小时就有 $2.39 的缺口。

他的计算没有包含带宽、人力和备用容量费用。应把这些输入值视为作者设定场景中的条件，而不是当前租赁报价，也不是本文复现的测量结果。

值得借鉴的是计算方法。评估内部自托管时，用部署后实际能够省去的 API 支出，替换对外销售 token 的收入。根据自己的模型、缓存占比、可达到的吞吐量、质量检查和延迟要求重新计算。

团队应该选择哪种部署方式？

需求不确定，或团队缺少推理服务运维人员时，选择按量付费 API。当多次测量表明，可省去的 API 支出足以覆盖完整的托管报价，再重新评估这一选择。

需求稳定，但不打算拥有和运维硬件时，试点供应商提供的专用托管算力。合同应明确升级、容量限制、故障、数据存放位置和支持服务的责任归属。核对供应商要求团队承诺购买的资源或服务，并与团队在同一周期内可合理预期的需求比较。如果合同承诺超出团队可合理预期的需求，就继续按量付费。

当控制要求足以支撑这项投入，而且团队有能力维护时，再选择自行运行推理系统。如果峰值负载下的延迟、质量回退或人员成本抵消了预期收益，就应改变方案。

签约前，比较各方案每项通过验收的任务的总成本，并完成峰值负载回放测试。准备完整的月度预算，并明确运维负责人。把闲置容量和例外调用前沿模型的费用也算进去。用工程团队自托管总拥有成本模型完善整体预算，而不是直接把 Revolut 在 GLM-5.1 阶段的历史数字当成自己的成本预测。