大家好，我是云默（Yun Mo），是 Friendly AI 的创始工程师。我和我的团队致力于构建推理引擎，以优化模型推理性能。今天我将分享我们如何为前沿开源权重模型打造快速且可靠的推理 API。在深入细节之前，我想先做个小调查：在座有多少人使用闭源前沿模型（如 GPT 或 Claude）？看来大多数人都在用。那么，主要使用开源权重模型的人有多少呢？相比闭源模型，人数较少。我个人最近混合使用两者，但正逐渐将更多工作负载迁移至开源模型。原因在于，如今开源模型已跨越门槛：在编码、推理及智能体（Agentic）基准测试中，GLM 5.2 等模型已与领先专有模型处于同一梯队。

从 Code Arena 排行榜可见，GLM 5.2 排名甚至高于 Claude Opus 4.8，仅次于 GPT-4o。在各类编码、终端及工具使用基准中，GLM 5.2 和 MiniMax M3 也表现强劲。问题已不再是开源模型是否足够好，因为它们确实已经达标；现在的核心问题是：如何在生产环境中快速、可靠地运行它们。基准测试数据往往难以直观反映实际表现，因此我进行了一项实操实验：要求 GLM 5.2 和 Opus 4.8 构建一个塔防游戏。两者均生成了结构相似、质量良好的可运行代码，包含地图和射击机制。考虑到仅用单提示词实现，效果相当不错。

然而，成本差异显著：GLM 5.2 在此任务中便宜了超过 5.6 倍。在需要多次迭代的工作流（如智能体 SL）中，这种差距会迅速累积。这已不仅是模型质量的问题，更是规模化运行的成本承受能力问题。在质量和成本之后，第三个关键因素是提供商的质量，即性能表现。即使模型权重相同，延迟、吞吐量和可靠性也会因运行环境不同而产生巨大差异。OpenRouter 的快照数据显示，这些差异是可测量的。因此，构建 AI 产品时，不仅要选择模型，更要选择能提供最佳性能、可靠性和定价的提供商。

为了进一步说明这一点，我使用了相同的 GLM 5.2 模型和编码智能体工作流来构建一个类似“糖果传奇”的手机游戏（Moto Crush）。结果显示，Friendly AI 在两分钟内生成了游戏，而另一家提供商则需要三分钟以上。模型相同、应用逻辑一致，但体验截然不同。这种差异源于整个推理技术栈：包括模型架构、缓存系统、路由策略、量化方案以及 GPU 协同等。Friendly AI 的价值在于我们并非仅暴露模型 API，而是构建了面向生成式模型的完整堆栈推理引擎。快速可靠的推理并非单一优化，而是批处理、调度、量化、投机解码和协同工作的综合结果。

在现代智能体应用中，输入往往非常长（轻松超过 10k token），而输出相对较短。更重要的是，大量输入在不同请求间是重复的：在许多真实工作负载中，50% 到 90% 的 token 是相同的。从系统角度看，大部分计算成本在于预填充阶段（Prefill），即模型处理整个输入并构建 KV 缓存的过程。如果每次重新计算共享的前缀，都是在浪费延迟和 GPU 周期。当新请求与之前的请求共享前缀时，我们可以复用张量并跳过相应的预填充计算，从而直接降低首 token 延迟（TTFT），避免重新计算大量输入。

然而，要在大规模下实现这一目标需要两个关键机制：首先是缓存感知路由（Cache-aware routing）。在分布式系统中，KV 缓存并非集中式存储，而是分布在各个副本上。路由器必须将传入请求发送到已持有相关前缀缓存的副本，否则复用优势将丧失。其次是缓存层级（Cache hierarchy）。对于大模型和长上下文，KV 缓存极其消耗内存，其大小可能超过模型权重本身。鉴于 GPU VRAM 资源有限且速度最快，我们将缓存视为一个层级：热缓存驻留于 GPU 内存，温缓存在 CPU RAM 中，冷缓存可卸载至 NVMe 或磁盘。系统动态卸载较少使用的块并在需要时预热它们。

通过结合缓存感知路由和分层内存管理，我们显著降低了前缀成本，减少了 TTFT，使长上下文智能体工作流更加高效。接下来是交互速度问题。标准的自回归解码每次生成一个 token，这使得解码过程本质上是串行的；在此过程中，GPU 往往利用率不足。投机解码（Speculative Decoding）改变了这一局面：它不再生成一个 token 就停止，而是提前提出多个候选 token，然后由目标模型在一次传递中验证这些候选者。如果 token 被接受，它们就是“免费”生成的。这在不改变模型输出质量的前提下，提高了每个输出 token 的时间效率。

候选者的生成方式有多种：一种是基于模型的投机（Model-based speculation），它使用小型草稿模型来预测未来的 token。其优势在于可以实现更高的……

接受率，但代价是额外的计算量。另一种方法是模型无关的推测（model-free speculation）。它利用提示或先前输出的模式，因此开销较低，但仅在输出与现有上下文相似时效果最佳。所以关键在于权衡。推测可以提高单次请求的延迟表现，但验证过程会增加批处理的开销。因此最佳策略并非静态不变。在 Friendly AI，我们采取混合方法。运行时可以根据工作负载和请求特征动态选择基于模型的推测或模型无关的推测。

我们还认为推测是可以随时间改进的技术。通过自我进化的推测，草稿模型可以根据实际的服务流量进行适应。预测器持续改进其对生产环境中正在运行的工作负载的预测准确性。接下来我想提到的是可靠性。速度 alone 是不够的，生产级 AI 应用的可靠性也是速度的组成部分。

如果 API 平均速度快但频繁遇到超时、5xx 错误、429 限流或失败等故障，用户体验仍然会崩溃。这对智能体（agentic）工作负载来说尤为重要。正如你所知，智能体可能需要多个模型调用来完成一项任务，如果中间任何一个调用失败，整个工作流都可能被作废。

因此我们不仅优化延迟或吞吐量，而是优化完整的 API 体验，包括错误率、正常运行时间等所有因素。GLM-5.1 Pro 的 OpenAI 快照显示，Friendly AI 不仅速度快，而且高度可靠，正常运行时间超过 99.9%。

我想说的是，许多推理提供商（包括在座的一些）会声称他们很快，在某些基准测试的特定条件下确实如此。但对于你的应用来说，唯一真正重要的基准是你自己的工作负载：包括提示、令牌长度、流量模式和延迟预期。

我们的建议很简单：请将你的工作负载带过来，与我们测试实际体验，关注速度、可靠性、成本和质量。当然，我们构建推理服务正是为了这些生产级工作负载，我们相信能为你提供最佳体验。我们在会场设有展台，请带着你最棘手的问题来，让我们一起解决。

最后我想分享一位客户 Kilo Code 的证言。Kilo Code 是最大的代码智能体平台之一，每周处理数万亿个令牌。他们在过去几年测试了许多不同的推理提供商，在 GLM 模型的分割测试中，他们对 Friendly AI 印象深刻。

与其他许多推理提供商相比，Friendly AI 快了七倍以上，且错误率显著更低。我相信你也能在 Friendly AI 获得类似的体验。如果你正在构建前沿开源模型，请来Friendly AI试用，带上你的真实工作负载，让我们展示快速可靠的推理能带来什么。

这是我的演讲结束部分，如有任何问题欢迎提问。谢谢。