开源模型质量已达标，核心转向速度与成本

大家好，我是 Yun Mo，FriendliAI 的创始工程师。今天我们将探讨如何为前沿开源权重模型构建快速且可靠的推理 API。目前，许多开发者仍主要使用闭源模型如 GPT 或 Claude，但我观察到越来越多的工作负载正迁移至开源模型。这是因为开源模型在编码、推理和智能体基准测试中已跨越门槛。例如，GLM 5.2 在 Code Arena Leaderboard 上的排名甚至高于 Codex Opus 4.8，仅次于 Claude Sonnet 5。在各类编码终端和工具使用基准测试中，GLM 5.2 与 MiniMax M3 均表现出强劲实力。因此，问题不再是开源模型是否足够好，而是如何在生产中快速、可靠地运行它们。单纯的性能基准数字无法完全反映实际体验，我们需要通过动手实验来验证。

实战对比：相同任务下的成本与体验差异

为了直观展示模型表现，我让 GLM 5.2 和 Opus 4.8 分别构建一个塔防游戏。两者均生成了结构相似、质量良好的可运行代码，包含地图机制和炮塔射击逻辑。然而，在成本方面差异显著：GLM 5.2 的成本比 Opus 4.8 低了超过 5.6 倍。在需要多次迭代的 Agent SL（智能体自我反思）工作流中，这种差距会迅速累积。这说明关键已不仅是模型质量，更是规模化运行的经济可行性。此外，即使使用相同的 GLM 5.2 模型和编码智能体工作流构建“糖果粉碎”风格游戏，不同提供商的体验也大相径庭。FriendliAI 在 2分钟内生成游戏，而另一家提供商需要超过3分钟。这证明模型架构、缓存系统、路由策略、量化策略及 GPU 核心数等推理技术栈共同决定了开发者的实际体验。

长上下文优化：缓存感知路由与层级管理

现代智能体应用的输入往往极长（超过 10k token），且大量重复。数据显示，50% 到 90% 的 token 在不同请求中是相同的。这意味着大部分计算成本集中在预填充（prefill）阶段。如果每次重新计算共享前缀，将浪费延迟和 GPU 周期。FriendliAI 通过复用张量跳过预填充计算，从而降低首 token 延迟（TTFT）。实现这一目标需两大机制：首先是缓存感知路由。在分布式系统中，KV 缓存存在于各个副本中，路由器必须将请求发送至持有相关前缀的副本，否则无法利用复用优势。其次是缓存层级管理。由于 KV 缓存对显存需求极大，甚至超过模型权重本身，我们将缓存视为层级结构：热缓存驻留 GPU 内存，温缓存在 CPU RAM，冷缓存卸载至 NVMe 或磁盘。系统动态管理这些层级以显著降低前缀成本。

提升解码速度：投机解码技术的应用

在标准自回归解码中，模型每次生成一个 token 需经过一次前向传播，导致 GPU 利用率低且解码过程串行化。投机解码（Speculative Decoding）改变了这一局面。该方法预先提出多个候选 token，由目标模型在一次前向传播中验证这些候选项。若被接受，则视为免费生成，从而在不改变模型输出质量的前提下提升每 token 的输出速度。候选项的提出可通过多种方式进行，其中一种主流方法是基于模型的投机（Model-based Speculation）。它使用一个小型草稿模型来预测未来的 token，利用小模型的快速生成能力与大模型的验证效率相结合，进一步优化推理性能。这种全栈式的优化组合——包括批处理、调度、量化和投机解码等——构成了 FriendliAI 的核心价值，确保开发者获得切线级的推理性能。

推测解码的动态权衡与混合策略

在推理加速技术中，投机采样（Speculative Sampling） 存在不同的实现路径及其对应的性能权衡。一种方法依赖于模型本身的预测能力，但这会引入额外的计算开销；另一种方法是无模型推测（Model-free Speculation），它利用提示词或先前输出的模式进行预测。虽然无模型推测的开销较低，但其效果最佳的情况仅限于输出内容与现有上下文高度相似的场景。因此，核心问题在于权衡（Trade-off）：投机采样虽然能改善单个请求的延迟，但验证过程会给批量处理带来额外的开销。鉴于此，最佳策略并非静态不变。

"So speculation can improve per request latency but validation as overhead to the batch. So the best strategy is not static."（推测可以改善每个请求的延迟，但验证会给批次带来开销。因此最佳策略不是静态的。）

FriendliAI 采取了一种混合方法（Hybrid Approach），运行时可以根据工作负载和请求特征动态选择基于模型的推测或无模型推测。此外，他们还将投机采样视为一种可以随时间改进的机制。自进化推测（Self-evolving Speculation） 允许草稿模型根据实际的服务流量进行适应。这意味着投机者能够持续改进其对生产环境中正在运行的工作负载的预测能力，从而在长期运行中不断优化性能。

可靠性是生产环境速度的核心组成部分

仅仅追求速度是不够的，生产级 AI 应用的可靠性本身就是速度的一部分。如果一个 API 平均响应很快，但频繁出现超时、5xx 错误、429 限流或失败等情况，用户体验依然会崩溃。这一点对于智能体工作负载（Agentic Workloads） 尤为重要，因为一个任务可能需要多个模型调用来完成。如果中间任何一个阶段失败，整个工作流程都可能被无效化。

因此，FriendliAI 不仅仅优化延迟或吞吐量，而是致力于优化完整的 API 体验（Full API Experience），包括错误率、正常运行时间等指标。通过展示 GLM-5.1 Pro 的快照数据，他们证明 FriendliAI 不仅速度快，而且具有极高的可靠性，正常运行时间超过 99.9%。许多推理提供商可能在特定基准测试或条件下声称速度快，但对于应用程序而言，唯一真正重要的基准是用户自己的工作负载（Your Own Workload）。这包括用户的提示词、Token 长度、流量模式以及延迟预期。

真实客户案例与实战测试邀请

为了验证上述观点，演讲者分享了一个来自 Kilo Code 的客户证言。Kilo Code 是最大的编码智能体平台之一，每周处理数万亿个 Token。在过去几年中，他们测试了多种不同的推理提供商。在针对 GLM 模型的拆分测试（Split Test）中，Kilo Code 对 FriendliAI 的表现印象深刻。数据显示，与其他许多推理提供商相比，FriendliAI 快了七倍以上（Over seven times faster），并且具有显著更低的错误率。这一案例有力地证明了在真实生产环境中，FriendliAI 能够提供卓越的速度和可靠性。

"Compared with many other inference provider, friendly AI was over like seven times faster and had a sign significantly lower error rate."（与许多其他推理提供商相比，FriendliAI 快了七倍以上，并且错误率显著更低。）

基于这些实际成果，FriendliAI 建议开发者不要仅依赖第三方基准测试，而是将自己的工作负载带到平台上进行测试。通过实际体验速度、可靠性、成本和质量的综合表现，开发者可以验证 FriendliAI 是否能为其特定的前沿开源模型构建需求提供最佳体验。演讲最后呼吁用户带着最具挑战性的问题前来，共同解决生产环境中的推理难题。

结论

开源模型在编码与推理能力上已跨越门槛，核心竞争焦点转向生产环境中的速度、成本及可靠性。实证表明，相同模型在不同提供商处存在显著差异：FriendliAI 通过缓存感知路由、层级管理及混合投机解码等技术，在 GLM-5.2 等模型上实现了比竞品快七倍以上的响应速度，并维持超 99.9% 的正常运行时间。Kilo Code 案例证实，这种全栈优化能大幅降低错误率并提升吞吐量。

然而，第三方基准测试无法完全反映实际体验。最佳策略并非静态不变，而是需根据工作负载动态调整推测机制。开发者不应仅依赖通用数据，而应将自身提示词、流量模式及延迟预期带入平台进行拆分测试。唯有通过真实工作负载的验证，才能确认特定推理提供商在速度、成本与质量上的综合优势。