有人每月烧掉1万美元，嫌Claude太贵，这家公司改用GLM：56张B200扛起2000名工程师，AI成本直降90% - 赛马二重彩
有人每月砸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和运维成本，才是这笔账最值得算清楚的地方。
本文来自微信公众号“CSDN”，整理：郑丽媛，36氪经授权发布。
