Revolut 的 David Abitbol：大规模自托管 AI 编程模型

我是 David Abitbol，负责 Revolut 的 AI 运营。我想分享我们如何使用专用 GPU 为工程团队提供开放权重模型，以及我们在速度、成本和受监管银行的运营方面学到了什么。这些数字来自我们的具体配置，并不是普遍保证。

Revolut 是一家欧洲数字银行。在这次演讲中，我介绍公司服务于 45 个市场的 8000 万客户。公司重视产品交付，因此工程文化和交付速度对我们很重要。

一张工程工作图表覆盖了约 2000 名工程师的样本，跟踪从接手功能到合并并准备部署的交付时间，以及编码时间。这些趋势展示了采用工具期间发生的变化，但演讲没有建立受控的因果比较。

时间线从 2025 年 1 月使用 Gemini 开始，随后团队尝试 Claude Code，并在 2026 年 1 月更大规模地推出带支出限制的 Claude/Codex。我报告了 Gemini 带来的初步改善，但当时我们对昂贵前沿模型的投资回报持怀疑态度，因此设置了严格预算。

我们希望工程师能自由使用 token，不必担心月底账单。大约从 2026 年 4 月开始，我们自托管 GLM 模型。我报告编码和交付时间大幅下降；配套幻灯片概括为交付时间改善 60%，而我的口头说明是编码时间改善 60%、交付时间改善 70%。

对我而言，更大的启示是编码本身不是唯一瓶颈。工程师还要花时间查找信息，使用 Jira 和 Confluence 等工具。减少对 token 预算的顾虑后，他们可以在更多工作流程中使用 AI，而不是只把额度留给最困难的任务。

开放模型成为我们的默认选择，因为相对可预测的账单更容易规划。对于前沿模型表现更好的任务，我们仍会使用它们。我们的配置使用 56 块 B200 GPU 运行 GLM 5.3，为约 2000 名工程师提供服务；幻灯片注明该部署与 Together 合作。

我关注的用户体验指标是首 token 延迟。我们的目标是低于 3 秒；根据我的经验，一旦超过 5 秒，Slack 上的抱怨就会增加。对于我们的交互场景，每秒约 200 个输出 token 已经足够，尤其是工程师越来越多地并行运行任务。

我报告的配置综合成本约为每百万输入和输出 token 0.30 美元，幻灯片对缓存另作说明。我说，这份账单约为此前向 Anthropic 和 OpenAI 支出的一成。这个比较只适用于我们的工作负载和账单，不是通用价格报价。

如果没有调优，仅仅把模型权重放到 GPU 上运行，性能可能很差。在我们的数据中，相同的 56 块 GPU 最终以更低的首 token 延迟处理了更多请求。图表将迁移阶段与稳定配置对比：每秒请求数提高 76%，该延迟指标降低 88%。

这里没有秘密配方：上下文长度、量化、张量并行和缓存行为都很重要。我认为，对我们的工作负载来说，100 万 token 上下文往往不值得付出缓存成本；我还讨论了 FP4 和缓存命中率。这些选择应结合实际负载与质量要求测试。

我们的文本模型不能处理图像，因此可以把视觉任务路由到其他模型，同时让文本模型继续负责主要编码任务。端点提供兼容接口，可以与不同的编程运行框架或应用一起使用。这种分工让团队能够根据输入选择合适的工具。

对于受监管的银行，我介绍了人工监督、沙箱权限、数据隐私和遥测方面的控制措施。在获准地点的基础设施上托管模型权重，会改变推理发生的位置，但地点本身不能证明合规，也不能消除安全风险。

我们的做法是为不希望智能体自由执行的操作设置权限边界和人工批准。我还提到内部人员滥用和提示注入等风险，并强调日志对于调查事故和审计使用情况的重要性。我对监管和数据保留的说明描述的是我们的做法，不应视为适用于所有情况的法律结论。