有人每个月花 1 万美元用 AI 编程，结果老板一看账单：这钱花得值吗？——这正是英国金融科技公司 Revolut 曾经遇到的尴尬。
为了让工程师用上 AI，公司先后尝试了 Gemini、Claude Code，但部分工程师每月就能烧掉 1000 美元甚至 1 万美元。可钱花出去了，效率提升却没有达到预期。于是，Revolut 做了一个大胆的决定：不再把 AI 编程的主力押在商业模型上，转而自己去部署智谱的开源模型 GLM。
结果相当惊人：不到一年，AI 编程推理成本下降约 90%，公司约 2000 名工程师的编码时间缩短了 60%，从接手需求到代码合并的交付周期也缩短了约 70%！
Claude 太贵了！有工程师每月烧掉 1 万美元
一开始，Revolut 其实并没有打算自己训练或部署大模型。
2025 年初，公司开始用 Gemini 帮工程师查找资料、阅读技术文档；到了 2026 年初，又引入了 Claude Code，希望进一步提高开发效率。可随着使用规模扩大，成本很快成了问题。
Revolut 运维与基础设施负责人 David Abitbol 透露，有些工程师每个月在 AI 服务上的支出高达1 万美元，但实际获得的投资回报并不明显。公司只好在推广 AI 编程工具时设置严格的 Token 预算。
这下又出现了一个新问题：Token 越贵，工程师越不敢用。他们会把有限的额度留给复杂的代码生成任务，至于调试 Bug、处理 Jira 工单、整理 Confluence 文档等工作，即使 AI 能帮忙，也要考虑一下值不值得消耗 Token。
于是，Revolut 开始寻找更便宜的替代方案，最终将目光投向了智谱的 GLM 系列模型。公司最初采用 GLM-5.1，随后升级到 GLM-5.3，并将自托管模型设为主要的 AI 编程服务。
成本差距非常明显：按照 Abitbol 给出的数据，自托管 GLM-5.1 的输入、输出 Token 综合成本约为每百万 Token 0.30 美元，只有 OpenAI Codex 或 Anthropic Claude Code 等商业服务成本的大约十分之一；整体推理支出也降到了此前商业服务账单的约十分之一。
Token 便宜了，工程师的使用习惯也变了。Abitbol 表示，当 Token 不再那么昂贵时，工程师就不必再精打细算，不用把额度留到季度末，也不必只在最困难的任务上调用 AI——以前是工程师想着怎么省 Token，现在则是想想还有什么工作可以交给 AI。
真正拖慢开发进度的，可能根本不是写代码
Revolut 还分享了一个尤其值得关注的细节。他们统计了公司约 2000 名工程师使用 AI 前后的两项指标：
编码时间：工程师实际花费在编写代码上的时间，以小时计算。
交付周期：从接手一个功能需求，到代码合并并准备部署所需的时间，以天计算。
Abitbol 展示的内部数据表明，采用 GLM 后，编码时间缩短了约 60%，交付周期也缩短了约 70%。不过，他并没有把这些提升简单归功于模型写代码更快：在他看来，工程师每天真正消耗时间的事情远不止编码。
比如，排查 Bug、回复消息、处理 Jira 工单、更新 Confluence 文档，以及跟进各种开发流程。这些工作看起来都不复杂，却会一点点挤占工程师真正写代码的时间。当 AI 使用成本足够低时，工程师就可以把这些零散任务也交给智能体处理，而不是只在写代码时才想起使用 AI。
这也是为什么 Revolut 的交付周期比编码时间缩短的还多：代码写得快，只解决了开发流程中的一部分问题；让 AI 接管代码之外的琐碎工作，才有机会进一步缩短整个交付周期。
56 张英伟达 B200，支撑 2000 名工程师使用 AI
让近 2000 名工程师同时使用自托管大模型，显然不是一件轻松的事。
据介绍，Revolut 选择的 GLM-5.1 总参数量约为 7540 亿，每生成一个 Token，实际激活的参数约为 400 亿。即使采用了混合专家模型（MoE）架构，但模型权重和上下文缓存还需要大量 GPU 显存。
按照Abitbol 的估算，仅存储模型权重就需要约 380GB 显存，每位用户还需要额外占用约 6GB～26GB 显存来维护上下文，具体取决于精度设置。为了支撑 GLM-5.3 的规模化推理，Revolut 最终部署了 56 张英伟达 B200 GPU。
不过，Abitbol 并不认为性能提升只能靠买更多显卡。
在上个月纽约举行的 AI Engineer 大会上，Abitbol 展示了一组很有意思的数据：GPU 数量保持不变，经过推理系统优化后，每秒处理的请求量提升了 76%，首 Token 延迟则从迁移期间的 14.26 秒降到了稳定运行后的 1.68 秒，下降约 88%。
Abitbol 分享，期间团队主要做了以下几件事：
调整模型超参数： 根据真实业务负载优化模型运行配置。
采用 NVFP4 量化： 利用 Blackwell 架构 GPU 支持的低精度计算方案，减少显存占用和计算开销。
拆分 Prefill 和 Decode： 把输入上下文处理与后续 Token 生成分开，针对不同计算阶段进行优化。
优化缓存和上下文配置： 避免为用不上的超长上下文预留过多显存。
尤其是最后一点，Abitbol 的观点相当直接。
百万 Token 上下文是噱头？Revolut 认为 25.6 万就够了
如今，大模型厂商都在努力扩大上下文窗口，100 万 Token 甚至更长的上下文已成为宣传卖点。但 Abitbol 并不认同一味地追求超长上下文：
长上下文就是个骗局（Long context is a scam）。即使你能够提供 100 万 Token 的上下文窗口，实际上 25.6 万 Token 就已经足够了。
为什么？因为上下文越长，模型需要维护的 KV Cache（键值缓存）就越大，占用的 GPU 显存也越多。简单介绍一下，KV Cache 可以理解为模型的临时记忆区，用来存储注意力机制中的 Key 和 Value 张量。这样，模型在继续生成内容时，就不必反复计算之前处理过的信息。
但如果工程师实际只需要几万 Token 的上下文，企业却为每个请求都预留百万 Token 所需的资源，显然会造成浪费。因此，Revolut 更关注实际任务需要多长上下文，以及缓存能否被有效复用。
团队还发现，张量并行配置也很关键：把模型权重分配到 4 张 GPU 上，虽然装得下模型，却未必能给 KV Cache 留出足够空间；改用 8 路张量并行，有时反而能获得更好的整体性能。
经过一系列优化后，目前Revolut 已把首 Token 延迟控制在 3 秒以内，生成速度维持在每秒约 200 个 Token。Abitbol 甚至开玩笑说，如果首 Token 延迟超过 5 秒，他的 Slack 收件箱就会开始被抱怨消息刷屏。
至于生成速度，Abitbol认为每秒 200 个 Token 已经足够。现在工程师更习惯同时启动多个 AI 任务，等任务完成后再回来检查，而不是一直盯着模型逐字输出——他还分享了有趣的一点：下午 5 点以后登录的工程师…生成速度甚至能接近每秒 800 个 Token。
不让 GLM 包办一切，视觉任务仍交给 GPT、Gemini
虽然 GLM-5.3 已成为主要的 AI 编程模型，Revolut 并没有打算彻底告别 Claude、GPT 等商业模型——原因很简单：不同模型各有擅长的领域。
例如，工程师开发 UI 时，经常需要 AI 阅读页面截图、识别界面布局，再根据视觉效果修改代码。面对这些任务，Gemini、GPT 的表现更符合 Revolut 的预期。为此，Revolut 引入了模型路由（Model Router），根据不同任务自动分配模型：
代码生成、文本处理等任务，优先交给自托管的 GLM。
图片识别、视觉理解等任务，则交给 Gemini、GPT 等商业模型。
对于这套方案，Abitbol 表示：“开源现在已成为 Revolut 的优先事项，而且从经济角度来看，我们的方案很有优势。如今账单是固定的，不会在月底突然收到一张金额巨大的账单。前沿模型反而成了例外。”
不过，Revolut 的这条路也不是所有公司都能照搬。56 张 B200 的硬件投入、模型部署、推理优化和日常运维，都不是一笔小开支——而省下来的 API 账单，能不能真正覆盖 GPU 和运维成本，才是这笔账最值得算清楚的地方。
参考链接：https://www.theregister.com/ai-and-ml/2026/11/03/british-fintech-revolut-slashes-ai-coding-costs-10x-by-cutting-out-claude-and-going-self-hosted/5307345
本文来自微信公众号“CSDN”，整理：郑丽媛 ，36氪经授权发布。