Steven Latré：自己运行 AI 模型的经济账

我是 Steven Latré，负责比利时研究机构 imec 的 AI 工作。相较于 AI，imec 在半导体研发领域更为人熟知。我们与合作伙伴研发下一代芯片，但工作范围从晶体管延伸到系统和工作负载。我的职责是把 AI 工作负载与基础设施需求联系起来。

我们自己使用 AI 智能体的经历经过了几个可能很熟悉的阶段。2024 年和 2025 年，我们侧重使用最新的前沿模型。随着计费越来越按 token 用量计算，我们逐渐把任务路由到合适的模型，而不是总选最大的模型。

模型路由是一个容易着手的优化，但随着 token 用量增长，一些组织开始更主动地掌控技术栈。我们从封闭 API 起步，接着优化成本，如今正在探索托管开放权重模型和租用基础设施；未来也可能拥有自己的基础设施。

使用 API 相对直接。自己掌控更多基础设施则会大幅扩大设计空间：团队不仅要关注任务准确率，还要考虑模型选择与可信度、编程智能体运行框架、硬件架构、CPU 与 GPU 的配比，以及 KV 缓存优化。

我们的团队运行了数千次基准测试，研究智能体 AI 从 API 计费转向基础设施和总拥有成本会带来什么变化。我们关注达到一定任务表现需要多少成本，以及哪些运行框架、推理引擎和硬件配置适合这一目标。

我们选择了 SWE-bench Pro 中的长周期编程任务。长任务可能较早适合专用基础设施；高度交互式使用的经济性可能不同。我们改变编程运行框架、API 与开放权重模型、模型规模及硬件配置，并考虑能否支持并发用户。

对每种配置，我们考察任务解决率、延迟和成本，同时提高模型与硬件复杂度。这些结果来自一个基准和一种工作负载，不能直接视为所有 AI 部署方式的通用排名。

模型表现大致分成几组。在我们的测试中，Qwen 和 DeepSeek 等较小模型解决了约 35% 至 40% 的任务。GLM 模型表现处于 Opus 附近，而 Kimi K3 达到 86%。我提到部分基准内容可能出现在其训练数据中；这只是可能性，并非已经证实的结论。

加入硬件成本后，比较结果会改变。在我们的测试中，Qwen 和 DeepSeek 的应用表现大致相当，但硬件需求可能导致 GPU 租赁成本相差四倍。在所比较的配置中，从 GLM 换到 Kimi K3，准确率提高约 20%，租赁 GPU 成本增加约 15%。

成本不会随模型质量平滑变化，而往往呈阶梯状：略有差异的模型可能需要截然不同的硬件架构。选择开放权重模型时，应将实际硬件限制和成本与任务表现一起评估。

并发带来另一个问题：在保持延迟可接受的情况下，多少用户可以共享一台机器？使用 API 时，token 延迟和吞吐量是服务体验的一部分；使用自己的基础设施时，就必须自行管理这些限制。

许多系统受内存限制。模型参数和每个用户的 KV 缓存都必须放得下，而缓存需求会随用户数增加。因此，我们在各模型适用的硬件配置上测试了可舒适支持的并发量。

即便使用更大的硬件，较大模型支持的并发用户数仍显著下降，而且我们的配置慢于 Claude Code 基准。在这些长周期任务中，Kimi K3 配置大约能可靠支持四位并发用户，延迟约为该基准的三倍。

接着，我们从总拥有成本角度比较 API、GPU 租赁和购买。企业也可能出于其他原因选择自有基础设施；我介绍的门槛只适用于这项具体的经济分析。

在我们的较低端系统中，离开 API 的盈亏平衡点约为 89% 的 GPU 利用率，也就是说 GPU 几乎需要持续满负荷运行。对于八张 B200 GPU 这样的大型系统，相应利用率约为 15%。这项比较取决于具体工作负载和分析假设。

对于 GLM 级别的编程助手工作负载，我们的研究找到了从 API 转向基础设施开始具有吸引力的区间，估计可节省约 25% 的成本。这是针对所评估应用和配置的估算，并不保证每个组织都能获得同样结果。

我们还改变了编程运行框架。乍看之下，给定模型时三个框架的任务表现变化不大。这似乎意味着框架影响有限，但在自己承担基础设施费用时，GPU 的实际占用时间就很重要。

不同框架消耗的 token 数量差异很大。在 GLM 的例子中，与比较中的其他框架相比，Codex 生成的 token 约为一半，GPU 实际运行时间也约为一半。因此，任务表现相近并不意味着 GPU 账单相近。

这只是针对一种应用的初步研究。真实企业会混合多种工作负载，使决策更加复杂。我们还没有充分展开量化以及推测解码等优化的影响，而且模型与硬件也在不断变化。

我们正在将基准测试流水线扩展为公开数据集，持续跟踪这一变化中的领域。作为非营利研究机构，imec 也在组建联盟，让软件从业者与芯片及基础设施提供商共同合作，因为双方需要更紧密地协作。