推出 Inworld Inference

AI 的第一波浪潮是为企业打造的。开发者已经感受到了它，财务团队也是如此，但大多数人还没有看到 AI 改变自己的生活。更大的浪潮是为人打造的：通勤路上的导师、跑步中的教练、等你把话说完的语言伙伴、辛苦一天后可以倾诉的人。如今，只有 2% 的美国家庭和 3% 的美国消费者在 AI 上花费任何钱。^[7] 消费级 AI 正处于 1995 年互联网所处的阶段。

面向个人用户构建是另一个工程问题。在消费级 AI 中，延迟就是收入：当回复变慢时，人们会回到点按按钮。每一轮都会重新发送完整历史，因此提示词比回复长 13 到 36 倍。一次交互会扩展为多次模型调用，从内容审核和记忆到排序以及回复本身。用户每月支付 5 到 20 美元，或者不付费，因此每次调用的成本都必须几乎为零。当消费级应用宕机十分钟时，用户就会转向另一个应用，而企业工作流只会等待。

大型实验室和大多数推理提供商都在企业级和编码领域加倍投入。消费级 AI 在每一项指标上都需要相反的方向。因此，我们构建了 Inworld Inference，首个专为消费级 AI 设计的推理服务，今天它已向所有开发者开放。

与其罗列数千个模型，我们深入优化消费级应用选择的开源模型。从 Gemma 4 到 GLM、DeepSeek 和 MiMo，每个模型都有专属的服务构建：新的注意力内核、实时解码（一个小草稿模型先行写出，完整模型在一次通过中对其进行校验）、在评估能够支撑的地方使用更低精度的权重，以及一个路由器，它会将每一轮对话发回已经持有其上下文的服务器。

同样的研究带来了更低的延迟、更低的成本和更高的可靠性。在 Gemma 4 26B 上，首个 token 的到达速度比 OpenRouter 上中位数提供商快至 7.8 倍，并且相同硬件处理了 9 月时 1.8 倍的请求量，中位数首个 token 更快。在我们重点介绍的五个模型中的三个上，输入价格是不使用你的数据进行训练的任何提供商中最低的。每个提示词最多有 90% 由缓存提供服务，缓存输入成本最多降低 99%。在 GLM 5.3 Flash 上，30 天内超过 2000 万请求中有 99.999% 无错误完成。每个构建版本只有在匹配其替换版本的 eval 分数时才会发布。

消费级 AI 是我们唯一做的事，因此擅长这一点关乎我们的生存。我们提供的几乎每个 token 都来自人们在生活中使用的应用，每月数万亿 token，是 3 月服务量的 25 倍。使用无速率限制的托管模型，并按请求提供服务等级，在它们之间路由并自动故障转移，或自带模型进行专属部署。

01消费级与企业级推理

对于替代昂贵人工工作的企业任务，单个结果即可证明大量计算开销是合理的，并且结果可以等待。消费级应用必须在一个订阅或一个免费会话中持续提供一次又一次的交互，而用户正在等待每一次回复。因此，需要优化的指标是完成一次交互的成本，同时满足产品所需的质量和响应时间。

我们的目标是将这一成本降至每位用户每天几美分，而这只有真正的专家以及真正理解实现该目标所需权衡与技术的 ML 团队才能做到。

FaiStatus by Wishroll

下表将两种工作负载并列展示，并说明我们为每种工作负载构建的内容。

最紧的约束是时间。在对话中，人们在轮次之间会留出 0 到 300 毫秒。^[7] 模型的首个 token 只是该窗口的一部分，因为网络以及语音应用中的语音合成会占用其余部分。因此，在生产负载下，首个 token 必须显著低于 300 毫秒到达。在 Gemma 4 26B 上，中位数首个 token 现在落在 117 毫秒，从而将窗口的大部分留给语音。

第二个差异是每个请求的大小。消费者回合会将整个对话作为提示发送，并收到一条简短回复。在我们服务的截至 9 月 23 日的 28 天内的应用中，提示的中位长度是回复的 13 到 36 倍。企业工作则偏向另一方向，趋向于代码和文档等长输出。

该工作负载已在 Inworld 上大规模运行。在最常用的 Gemma 4 模型上，我们每天处理的 token 数量最高可达 OpenRouter 公开报告的其平台上所有提供商合计每日 token 数量的 1.8 倍。

我们还以更快的速度提供这些模型。OpenRouter 会公布每个模型各提供商的首 token 延迟。与这些测量结果相比：^[6]

• Gemma 4 26B：在比较的提供商中，首 token 中位数（0.17 秒）和 p95（0.31 秒）最低。其中位数比中位数提供商快 3.6 倍，p95 比中位数提供商快 7.8 倍，输入价格比中位数提供商低近 40%。
• MiMo 2.6 Pro：OpenRouter 上提供商中最低的输入价格，同时首 token 中位数（0.39 秒）和 p95（0.91 秒）也最低。其中位数比次快提供商快 2.6 倍，p95 比次快提供商快 4.6 倍。

以下各部分涵盖消费者应用所发起的调用，然后介绍每项技术及其对应用带来的改变。

02消费者推理任务，以及我们如何服务每一项

消费者应用不会只发起一种模型调用。单个回合可以检查消息的安全性、分类用户想要什么、读取其记忆、撰写回复、调用工具，并在之后更新记忆。这些调用中的每一个都有不同的规模、不同的截止时间和不同的预算，而围绕其中一种构建的提供商会让其余调用变慢或变贵。

同样的工作支撑着每一行：为每个模型构建的内核与解码、保持每个会话缓存热度的路由器、对照评估检查精度，以及按请求划分的服务层级，使每次调用都能获得所需的速度或价格。

03服务挑战：长上下文输入，短回复输出

消费级应用具有独特的流量模式。它们发送非常长的上下文以获取简短回复，因此处理和复用输入与生成速度同样重要。并且，一次用户操作触发的每次调用都有各自的大小和截止时间，如下面的时间线所示。

一个包含 3,500 个 token 历史和一个 200 token 回复的对话回合，将大部分工作放在提示词上。长对话会把平均值拉得远高于中位数：在 GLM 5.3 Flash 上，平均请求输入 13,433 个 token，输出 309 个 token。

答案更长的故事会将权重转向解码。两个阶段会触及不同的限制。预填充，即处理输入的工作，受计算能力限制，并能从缓存复用和批处理中获益。解码，即生成输出的工作，受内存带宽限制，当每一步成本更低或一次生成多个 token 时会更快。

因此，我们在轮次的两侧都进行优化。在提示词一侧，我们避免重新计算模型已经见过的上下文，并使用分块预填充将长提示词分段处理，从而不会拖慢正在向其他用户流式返回的回复。在输出一侧，我们让每个解码步骤更便宜，并让每个步骤生成多个 token。由于后台摘要可以等待，而回复不能，每个请求都带有服务等级。接下来两节先介绍提示词一侧，再介绍输出一侧。

04面向大规模长对话的 KV 感知路由

每一轮都会重新发送迄今为止的对话。前缀缓存保留模型已处理上下文的注意力键和值（KV 缓存），因此引擎只计算提示中的新部分。每个回复仍然都是新生成的。^[2]

在集群规模下，难点在于放置。一个对话的缓存驻留在服务其上一轮请求的副本上，而另一个副本可能有更多空闲容量。我们的路由器是 KV 感知的。它对提示词中的每个块进行哈希，跟踪哪个副本持有哪个块，并根据两点为每个副本打分：它已持有该请求前缀的多少，以及它有多忙。将每一轮都发送到最热的缓存会导致其过载，因此该分数在复用与负载之间进行权衡，并基于代表性流量进行调优。无法放入加速器内存的 KV 会溢出到主机内存，而不是被逐出并重新计算。

内置于每个引擎中，逐模型实现

缓存命中率是我们最密切关注的指标之一，因为它既决定回复开始得有多快，也决定这一轮的成本。要在真实流量上将其提高，仅开启前缀缓存是不够的。不同模型和引擎对缓存上下文的表示方式不同：用于实时解码的草稿模式、混合注意力布局、循环状态和数据并行秩，都会改变提示词 token 如何变成缓存块，并且只有当路由器的视图与引擎的视图一致时，路由器才能找到匹配。

因此，我们将路由器集成到每个模型的服务路径中，并在生产流量上测量命中率。这项工作大致使 GLM 5.3 Flash 的缓存命中率翻倍，在 5,000 个生产请求的重放中从 25% 提升到 47%，并在 DeepSeek V4.1 Flash 上将其提高到三倍。我们的技术栈在同时来自许多应用的混合流量上保持高命中率，而在某客户的专用部署中，生产环境中的缓存命中率可达 80%。^[1]

针对你的应用。 MiMo 2.6 Pro 将缓存输入标价每百万 token 0.0036 美元，未缓存输入标价 0.425 美元，因此每个缓存 token 的成本低 99%。当提示词的 90% 来自缓存时，该轮次的输入成本会下降约 89%，并且只有十分之一的提示词需要在回复开始前处理。

内部机制。每个缓存块都会跳过其对应的预填充部分。随着每个提示词中来自缓存的部分越来越多，每个副本可以同时承载更多对话，并且随着对话变长，首 token 时间的增长要慢得多。

05通过针对特定模型的解码和精度实现更快的回复

人们会两次体验延迟：等待响应开始，以及等待其结束。首 token 时间（TTFT）衡量第一次等待。token 间延迟（ITL）决定流式输出的节奏。服务配置必须在应用的生产并发下同时处理这两者。

起草与验证，针对每个模型进行调优

实时解码是我们基于推测解码的草稿-验证服务方法。一个轻量级草稿模型提出若干 token，目标模型在一次前向传播中一起验证它们，接受连续 token 直到第一次拒绝。通过精确的接受和纠正，生成可以在每个目标模型步骤中推进多个 token，同时保持目标模型的输出分布，质量相同。^[3]

我们为每个模型优化草稿模型和验证步骤。Gemma 4 使用 Google 为其发布的草稿模型，GLM 和 DeepSeek 使用它们自己的多 token 预测层。在专用部署中，经客户批准，我们会使用该应用流量的样本训练草稿模型。能更准确预测该应用输出的草稿模型，在每次验证步骤中会有更多 token 被接受，我们在生产负载下测量收益，因为草稿开销、接受率和并发都会影响它。

split-KV 上的验证注意力：最高快 7.5×

在 Gemma 4 26B 这一混合专家模型上，验证步骤被证明是瓶颈。验证一个 7-token 草稿时，每条序列会通过注意力发送 8 个查询 token，而默认内核仅在单 token 解码时使用其更快的 split-KV 路径。验证回退到一个 2D 内核，该内核将工作拆分为约 60 个块，并使芯片的大部分计算单元空闲。

我们修改了内核，使最多 16 个查询 token 的验证批次走 split-KV 路径。在模型的全局（完整上下文）注意力层上，验证注意力快了 3.4 到 7.5 倍，注意力占每个解码步骤的比例从 27.5% 降至 16.5%。完整构建还将整个验证步骤作为一个捕获的图运行，并将草稿长度设为 7 个 token，在重放的生产流量上，将 ITL p50 从 6.4 ms 降至 5.2 ms，将 TTFT p50 从 154 ms 降至 117 ms，数学和推理分数相同。^[1]

针对你的应用。ITL 决定回复流式输出的速度：在每 token 5.2 毫秒的情况下，200-token 的回复在开始后约一秒完成。更快的解码步骤还能让每个加速器处理更多请求，这正是保持低价的原因。

内部机制。Decode 受内存带宽限制：每一步都会读取所有权重，以在每个序列中生成一个 token。草稿使一次权重读取能够生成多个 token，因此验证步骤的速度决定了收益。当注意力占步骤的比例从 27.5% 降至 16.5% 时，批处理中的每个请求都变快了。

评测分数相同，每个 token 的字节数更少

更便宜的构建版本只有在得分相同时才会发布。每个构建版本都必须在我们自己的评测中与它所替换的生产构建版本保持一致，包括 MATH、MMLU-Pro 和 GSM8K。在该门槛内，每一层都运行在其评测允许的最低精度下。在 Gemma 4 31B 上，承载大部分权重的 MLP 以 4 位浮点（NVFP4）运行，而注意力和 KV 缓存保持为 FP8。

该门禁在发布前捕获回归问题。它发现了 FP8 注意力中的一个缩放 bug，修复后使 MATH 从 87.4 恢复到 89.6。它还阻止了一个服务成本降低 80% 的构建，因为该构建在 MATH 上损失了 5 分。

针对你的应用。每个权重占用更少的字节，使你的应用增长时推理依然可负担，同时保持相同的延迟和质量。这也是 Gemma 4 26B 定价为每百万输入 token $0.07、输出 $0.34 的部分原因。

06持续优化，逐个模型进行

我们的工作不会在模型上线时停止。我们持续分析生产流量，以提升响应时间、服务效率和可靠性，从加速生成的新注意力内核，到解决需要定期重启的内存泄漏。每项更改在发布前都会针对我们的质量基准进行评估。下表展示了这些改进中的一部分及其实测结果。

实测服务改进

我们托管的多个模型中，按工作类型选出的部分变更。每个结果均为指定模型和指标在变更前后对比；“basis”列说明测量方式和时间。重放使用真实生产流量。^[1]

在生产环境中跟踪效果

这些收益在生产环境中同样成立。在 Gemma 4 26B 上，每个服务实例现在处理的请求量约为 9 月时的 1.8 倍，而 7 天中位 TTFT 从 178 ms 降至 161 ms。在 Gemma 4 31B 上，一周的优化使重放生产提示词下的中位 TTFT 快了 2.8 倍，在相同评测分数下从 943 ms 降至 336 ms；在生产环境中，即使流量上升 26%，日中位数也从 365 ms 降至 271 ms。在一次重放中，DeepSeek V4 Flash 上的缓存感知路由使最慢的 1% 首 token 快了约 10 倍，从 9.4 s 降至 0.87 s。^[1]

07灵活的服务层级与高可靠性

有人等待的回复需要快速响应；后台摘要可以等待并优先考虑更低成本。我们的四个服务层级让你可以为每个请求选择合适的平衡，使用相同的模型权重。按请求设置 service_tier，或为你的 API 密钥或工作区选择默认值。

同一模型权重的服务选项。可用性和承诺取决于模型和服务。

可靠服务是各个层级的优先事项。在 30 天内，GLM 5.3 Flash 处理了超过 2000 万请求，失败 98 次，成功率为 99.9995%，其中将服务器错误、超时和容量拒绝计入失败。在所有托管模型中，超过 99.99% 的请求在没有服务器错误的情况下完成；该整体指标仅统计服务器错误。^[1]

大约每百万次请求出现 4.8 次失败，如果某人每天发出 100 次请求，大约每六年会遇到一次失败，按返回给你应用的最终状态计数。当某个服务池饱和或不可用时，路由器可以将请求重定向到另一个服务池，有助于保持你的应用响应，而无需你管理各服务池之间的恢复。

08路由：故障转移、条件与 A/B 分流

只需配置一次主模型和兼容的回退模型，您的应用即可恢复，而无需自行构建模型切换逻辑。在 models 中列出回退模型，并设置 fallback.ttft_timeout 以指定等待主模型首个 token 的时长。如果超过该期限，路由器会尝试列表中的下一个模型。已保存的路由器还可以根据请求的元数据或消息，使用以 CEL（通用表达式语言）编写的条件进行路由，按权重在变体之间拆分流量以进行 A/B 测试，并使用 user 让每个用户保持在同一个变体上。当路由中的模型是我们托管的模型时，每个尝试的模型都会保留上文所述的缓存和实时解码。

每个响应都会说明发生了什么。metadata.attempts 列出每个尝试过的模型、其首 token 时间以及是否成功，而 metadata.reasoning 说明路由为何走向了该路径，因此你仅凭响应即可调试路由决策。

因为路由器将缓慢的首 token 视为失败，一个停滞的模型会使该轮次花费超时时间加上回退模型的首 token 时间（上述追踪中为 300 + 157 ms），而不是第一个模型本可能花费的时长，并且你的应用无需重试逻辑。

09你的模型，针对你的应用进行优化

从托管的开放模型开始，并为每个任务选择合适的服务层级。当您的应用需要专属模型时，目标是以更低的成本和更低的延迟，为您的用户提供更好的智能体，我们将与您一起在专用部署上构建它。

您可以自带权重，也可以与我们的工程师合作，使用已批准的数据集和针对应用的具体评估进行后训练。我们会将质量与您当前运行的模型进行对比，然后针对效率进行调优，直到新模型以更低的成本达到您的质量目标。后训练会改变模型的行为；基于您的流量训练的草稿模型只会改变我们提供服务的速度，因此我们会分别评估这两者。

部署还可以包含自定义内核、根据您流量调优的缓存路由，以及与流量相匹配的容量。在 Gemma 4 31B 上，我们自己的注意力内核在满载时每秒处理的 token 数约为标准内核的 4 倍，而一位客户的 31B 微调模型在我们将其转换为 4 位权重后，吞吐量提升了 35%。上线后，我们会持续针对您的流量对部署进行性能剖析，并且只有当某项变更在生产负载下仍能保持其收益时，才会发布。

10客户：Status 和 Latitude

对于 Wishroll 的 Status，我们与团队一起完成了针对性提示词、应用专属评估器和生产负载测试，新配置将他们的 AI 成本削减了 95% 以上，同时保持或提升了内容质量。这一节省既来自上述工作，也来自更低的 token 价格。^[4]

与 Inworld 合作的真正优势在于，这是一种持续的合作关系，使我们能够不断优化性能，并持续降低成本，因为现在我们有一支机器学习专家团队与我们一起工作。

FaiStatus by Wishroll

Latitude 的 Voyage 每回合会发起大量调用。大约 20 项 AI 任务每回合与故事生成一起运行，这使得 Latitude 在 Inworld 上的前六周内累计产生了数千万次推理调用。我们承载 World Engine 任务——即每回合应用故事规则的调用——以及故事模型，包括 Latitude 自己的微调模型。团队在一天内迁移了第一个生产推理任务，在一周内迁移了一半引擎流量，在大约一个月内迁移了全部故事模型流量。用户等待的是组合工作流，因此每个辅助调用都必须在回合内完成。^[5]

11开始使用兼容 OpenAI 的 API

对于 Chat Completions，请设置 Inworld 基础 URL、你的 API 密钥和一个模型 ID。流式传输的工作方式与 OpenAI 相同。

python · openai sdk · 流式

import os
from openai import OpenAI

api_key = os.environ["INWORLD_API_KEY"]

client = OpenAI(
    base_url="https://api.inworld.ai/v1",
    api_key=api_key,
    default_headers={"Authorization": f"Basic {api_key}"},
)

stream = client.chat.completions.create(
    model="inworld/models/gemma-4-26b-a4b-it",
    messages=[
        {
            "role": "system",
            "content": "You reply to users of a running app. "
                       "Keep replies short and encouraging.",
        },
        {
            "role": "user",
            "content": "I finally finished my first 10k run today.",
        },
    ],
    max_tokens=128,
    stream=True,
)

with stream:
    for chunk in stream:
        if chunk.choices and chunk.choices[0].delta.content:
            print(chunk.choices[0].delta.content, end="", flush=True)
print()

Gemma 4 26B 的标价为每百万输入 token 0.07 美元，缓存 0.035 美元，输出 0.34 美元，比不拿你的数据进行训练的中位数提供商低近 40%。这些是 Default 费率；随着规模扩大，可获得更低费率。每个托管模型，连同其价格和缓存输入费率，都在 模型页面 上。你可以先在浏览器中无需 API 密钥，在 playground 中试用任何模型。

浏览模型 · 获取 API 密钥 · 联系我们的工程师了解您应用的部署。