编辑 | 姜篇
David Abitbol：有工程师每月花 1000 美元，也有人花到 1 万美元。我们只好先设预算上限。
David Abitbol：现在这张账单，大约是过去付给 Anthropic 和 OpenAI 时的十分之一。
David Abitbol：工程师的卡点未必在写代码。让他们少花时间翻邮件、处理 Jira 和 Confluence，也能加快交付。
说这话的是 Revolut 的 AI 运营负责人 David Abitbol。
面对约 2000 名工程师，公司没有靠继续压低额度控制成本，而是把日常编程任务转给自托管 GLM，Claude Code 和 Codex 仍可用，但不再是默认选项。
David 展示的配置用了 56 张 B200，混合 Token 成本约为每百万 0.30 美元。GPU 没有增加，首 Token 等待时间却从 14.26 秒降到 1.68 秒。
David 谈早期高额花费与严格额度
下面按 David 的演讲展开；数字均是他报告的 Revolut 内部数据。
Claude Code 刚推开，账单就把额度卡住了
David 先展示了一张覆盖约 2000 名工程师的内部曲线。图里有两条线：一条是编码时间，另一条是交付周期，也就是工程师接到一个功能，到代码合并、准备部署之间隔了多久。他关心的是后面那条线有没有缩短。
Revolut 早先用 Gemini 帮工程师查资料、读文档。后来团队推广 Claude Code，花费很快变得难以预测。
David Abitbol：我们看到有工程师每月花 1000 美元，也有花到 1 万美元的，但没看到相称的回报。所以最初推出时，我们设了严格的预算上限。
预算上限控制住了账单，也给工程师传递了一个信号：Token 很贵，先留给最棘手的任务。查一份旧文档、理清 Jira 里的来回讨论、从邮件中找前因后果，这些零碎工作仍由人自己做。
David Abitbol：我们接着问，能不能用低得多的成本，给工程师足够的 Token，让他们不必带着 " 花钱的负罪感 " 使用 AI？于是我们开始看开放模型。
他之后又说，额度松动时，工程师不必再把 Token 留到季度末，或者只在最难的任务上才舍得调用模型。模型能否进入日常开发，价格本身就在决定。
把 GLM 当日常选择，前沿模型留给例外
Revolut 从 2026 年 4 月前后开始自托管开放权重模型。最初在团队里跑的是 GLM5.1；David 展示当前配置时，提到用 56 张 B200 服务约 2000 名工程师，运行 GLM5.3。
这里的 " 自托管 " 是把模型放在自己选择的算力上运行。权重可以自行部署，GPU 和运维仍然要付钱。
David Abitbol：现在开放模型是 Revolut 的优先选择，账单比较平稳，月底不会突然冒出一笔吓人的费用。我们当然还用 Codex、Claude Code，最新模型很强，只是把它们留给更适合的特殊任务。
David 解释 Revolut 的模型分工
演讲幻灯片还写出几个运行指标：约 2000 名工程师、首 Token 尽量在 3 秒内出现、互动速度约每秒 200 个 Token，以及每百万 Token 约 0.30 美元的混合成本。
原演讲的指标页。要点：56 张 B200 服务约 2000 名工程师；首 Token 目标低于 3 秒；混合 Token 成本约 0.30 美元 / 百万
David Abitbol：自托管 GLM 后，我们算出的混合 Token 成本是每百万约 30 美分。现在这张账单，大约是过去付给 Anthropic 和 OpenAI 时的十分之一。
David 报告 Revolut 内部的账单对比
这也不是 " 换成便宜模型，就能直接省 90%"。56 张 B200 要花钱，机器也得有人维护。
David 给出的，是 Revolut 在自己的使用规模和部署条件下算出的结果。
GPU 一张没加，先把等待时间压下去
自托管之后，工程师会碰到另一个问题：模型便宜了，等它开口却要十几秒，也没人愿意反复用。
David 说，他们把首 Token 出现的时间作为重点指标，目标是 3 秒以内；超过 5 秒，抱怨就会涌进他的 Slack。每秒生成约 200 个 Token，对当时的互动任务已经够用。
工程师习惯常并行启动任务，稍后再来看结果，不必一直盯着屏幕等模型逐字输出。
David Abitbol：如果只是买来 GPU，把模型权重装上去就开始推理，性能会很糟。你怎么设参数，取决于工程师真正发来的请求。我们得先把现有机器调好，而不是立刻加机器。
他拿出一页调优曲线。迁移阶段，首 Token 等待为 14.26 秒；稳定配置阶段降至 1.68 秒。同期请求量上升，图中报告每秒请求数提高 76%、首 Token 延迟降低 88%，GPU 数量始终是 56 张 B200。图里的两个时间点对应迁移中和稳定后的状态，并非一次单独调参的对照实验。
David 强调调优期间没有增加 GPU 数量
原演讲的性能曲线。要点：同为 56 张 B200，每秒请求数上升 76%，首 Token 等待从 14.26 秒降到 1.68 秒
百万 Token 上下文，David 说先别开满
讲到调参，David 直言：长上下文是个 " 骗局 "。他在反对什么？
David Abitbol：模型即使支持百万 Token 的上下文，也不意味着每个编程任务都要按这个长度来配。你得认真看实际请求需要多大的上下文。
David 提醒不要只看模型支持的最大上下文
模型处理更长的输入，需要在显存里留出更多空间保存中间状态。给每次请求都预留超大的窗口，同一批 GPU 能同时接住的任务就会变少。David 谈的取舍是：根据编程任务实际使用的长度设窗口，再看缓存能否复用那些反复送进模型的代码上下文。
量化和并行方式也在这笔账里。他提到，在自家的 Blackwell 硬件上使用 FP4；一个大模型的权重即便能塞进 4 张 GPU，若留给 KV 缓存的空间不够，实际负载下反而可能需要 8 张。听起来像是 " 多用卡 "，目的却是别让显存被权重占满，导致并发请求排队。
这些都是 Revolut 那套模型、设备和请求分布下的选择。David 反复强调，先看负载，再调配置。
写代码的模型，没必要顺便负责看图
自托管的主模型侧重文本编程，有的任务却需要读设计稿或识别图片。David 没有为了让一个模型包办一切，改用自己认为编程能力更弱、但能看图的模型。
David Abitbol：我们会保留更适合写代码的模型，再想办法处理图像。可以让本地路由器把看图的请求转给 Gemini 等视觉模型，主要的编程任务仍交给 GLM。
原演讲把生产环境分成文本模型、视觉模型与工具入口
接入端也不能让工程师换一套陌生界面。David 说，他们使用兼容 OpenAI 接口的服务，让自托管模型能接到 OpenCode、Codex 等编程工具里。工程师看到的还是熟悉的工作入口，背后调用哪一个模型，则按任务来分。
这样，工程师不必为了读一张设计稿，就把日常编程也交给不擅长代码的视觉模型。
Token 便宜了，节省时间的地方变了
回到开头那张曲线。David 口头介绍说，采用自托管模型后，编码时间改善约 60%，从接手功能到合并待部署的周期改善约 70%。但他的幻灯片又把交付周期改善标为 60%。两处口径不一致，不能拿其中一个数字写成已经核定的统一结果。
原演讲展示约 2000 名工程师的编码时间与交付周期曲线
他从曲线里读出的变化倒很容易理解：工程师一天的工作，不只发生在 IDE 里。找一封旧邮件、看一段 Jira 讨论、翻 Confluence 里的历史决策，这些事分散在写代码的前后。AI 便宜到可以随手用，才有机会帮人接走这些零碎步骤。
David Abitbol：我们发现，工程工作里的卡点不一定是编码。你可以少花不少时间翻邮箱、处理 Jira 和 Confluence。额度宽松之后，工程师才会愿意把这些任务也交给模型。
David 谈工程师在编码之外花费的时间
这仍是 David 对内部曲线的解释。演讲没有提供排除其他变化后的对照实验，不能说交付周期的改善全由 GLM 或自托管造成；可以确认的是，Revolut 把编码时间和交付周期分开测量，没有只拿 " 写了多少代码 " 衡量这次投入。
写在最后
56 张 B200 不是多数团队的起点。看见 " 账单降到十分之一 "，也不必马上去排 GPU 采购计划。
先导出一个月的编程 Agent 账单，看看哪些任务每天都在重复调用模型，哪些只在疑难问题上偶尔出现；再量一下工程师实际要等多久、请求通常塞进多少上下文。高频任务和少数难题能否分开跑，决定了便宜模型有没有用武之地。
Revolut 最初用额度控制成本，工程师便开始攒着 Token。后来账单、等待时间和工具入口一起变了，他们才敢把查邮件、翻文档这些事也交给 AI。对开发团队而言，省钱只是起点：省下的 Token，究竟让哪一段工作真正快了？
参考链接：
https://www.youtube.com/watch?v=Ok6QdZHCcI8
——好文链接——
" 界面已死 " 喊早了！谷歌 CEO 皮查伊谈 Agent 时代的界面：Agent 替人办事，但是屏幕还得留给人
登录后才可以发布评论哦
打开小程序可以发布评论哦