Revolut弃用Claude改GLM：56张B200撑2000工程师，AI成本降90%
真正拖慢开发进度的，可能根本不是写代码。
有工程师每月在AI编程上花掉1万美元，老板看到账单难免要问一句：这钱花得值吗？英国金融科技公司Revolut就碰上过这样的尴尬。
为了让工程师用上AI，这家公司先后试过Gemini和
Claude Code，可部分工程师一个月就能烧掉1000美元，甚至1万美元。钱是花出去了，效率提升却没达到预期。Revolut随后做了个大胆的决定：AI编程的主力不再押在商业模型上，转而自行部署智谱的开源模型GLM。
从拿到需求到代码合并，交付周期缩短约70%；约2000名工程师的编码时间少了60%；AI编程推理成本在不到一年里降了约90%。这些数字摆在一起，效果相当惊人。
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%。
他提到，这段时间团队主要动了这几处：
一是调整模型超参数，按真实业务负载去优化模型的运行配置。
二是上 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
