Celeris 推出用于亚秒级智能体循环的基于扩散的 LLM API

Why it matters

Celeris-1 gives diffusion language models a second commercial supplier and tests whether lower latency, rather than another capability gain, can reshape voice and agent software.

Tom Hamer and Jesse Clark 在 7 月 27 日推出了 Celeris-1，使开发者可以访问一种基于 diffusion 的语言模型。Celeris 表示该模型可以在毫秒内完成短时推理调用，并以每秒 1,664 个 token 的速度生成长响应。

这家旧金山的 AI 实验室通过与 OpenAI 兼容的 API 提供 Celeris-1，依据是一则通过 PR Newswire 发布的公告。Celeris 正将该模型定位于语音代理、分类、抽取、工具选择以及其他那些每次模型调用的延迟会在更大软件流程中叠加的工作负载。

“速度会改变你能构建的东西，”Hamer，Celeris 的联合创始人兼 CEO，在公告中说。这句话概括了创始人的押注：模型厂商多年来一直在推动基准性能更高，而延迟仍然是那些需要在实时对话中进行推理或在返回答案前运行数十次内部调用的应用的架构性限制。

Hamer 和 Clark 之前共同创办了 Marqo，这是一家 AI 产品发现和搜索基础设施提供商。Hamer 曾在 AWS 担任工程师，并在 Cambridge 获得机器学习硕士学位。Clark，Celeris 的首席技术官，曾领导 Amazon Robotics 的机器学习工作，在 Stitch Fix 担任首席科学家，并在 Stanford 和 University College London 担任物理研究职位。在他个人的网站上，Clark 表示他领导开发了 Amazon 的 Robin 仓储机器人感知模型，并设计了一个用于 Amazon Robotics AI 的持续学习框架。

Celeris 在其页面上将 Lightspeed Venture Partners, Blackbird Ventures and January Capital 列为支持者。同一投资者群体曾支持 Marqo，这使得 Hamer 和 Clark 在从检索系统转向模型架构时，得到了来自他们之前 AI 基础设施公司的机构支持。

并行生成而非逐令牌排队

大多数广泛部署的语言模型从左到右生成，一次预测一个 token 并将其反馈到模型中再生成下一个。即便推理提供商使用更快的芯片或优化的服务软件，这种顺序过程也限制了生成可以并行化的程度。

Celeris-1 则在每个生成步骤中对响应的多个部分进行精炼。Celeris 将这一过程比作将模糊图像拉入焦点，这个类比借自 diffusion 图像模型。一个于 7 月 23 日发表的技术文章 对 Celeris 的研究方向给出了更精确的描述：混合架构，在语言需要时结合顺序生成，而在其他情况下采用并行解码。

这种区别很重要。Celeris-1 被呈现为一个 diffusion 模型，同时 Celeris 的研究论点保留了一些顺序计算以保持连贯性。商业优势将取决于该架构在多大程度上能识别出哪些响应部分可以一起生成而不牺牲指令遵循或推理准确性。

Celeris 正进入一个由 Inception's Mercury models 开启的类别，后者也使用 diffusion 来并行生成 token。Inception 将 Mercury 2 描述为一种推理 diffusion 模型，在标准 Nvidia GPU 上能够超过每秒 1,000 个 token。第二个商业 API 的出现为开发者提供了另一种可与传统自回归模型以及诸如 Groq 和 Cerebras 之类的专用推理提供商进行对比测试的架构。

速度声明来自 Celeris 自身的测试

Celeris 报告称 Celeris-1 在 MMLU-Pro 上得分为 75.9%，中位服务器响应时间为 158 毫秒。在同一项Celeris 运行的基准测试中，GPT-5 得分为 81.9%，耗时 2.046 秒，GPT-5 mini 得分为 78.5%，耗时 2.495 秒。Celeris 在比较中禁用了被比较模型的推理预算，并使用了每个提供商可用的最快配置。

Celeris 在营销中使用的“接近 GPT-5 智能”的描述基于那一次 MMLU-Pro 的比较。它并没有确立在代码、长上下文工作、工具使用或多步生产代理方面的可比性能。该测试还报告了大多数提供商的模型或服务器处理时间，而 Gemini 的结果是从同址客户端端到端测得的。

Celeris 的方法论引入了额外的限定。Mercury 2 在以标准答案格式表现不佳后被改为不同的零样本强制 chain-of-thought 设置，Celeris 在自己的运行产生格式错误后，用以前发布的分数替换了 Gemini 2.5 Flash 的结果。方法论说明还引用了一个 63.1% 的 Mercury 结果，而主表格报告的是 63.7%。

吞吐量比较是一个单独的测试。在一篇7 月 22 日的输出速度报告中，Celeris 表示 Celeris-1 的中位生成速度为每秒 1,664 个 token，并在约 0.58 秒内完成了大约 1,000 token 的输出。那次运行中 Mercury 2 的生成速度为每秒 324 个 token，而 GPT-5 为每秒 69 个。Celeris 使用了十个长格式提示对每个模型发送 50 个请求，输出上限为 1,024 token。

这些数据尚未被独立复现。由于 Celeris 发布了工作负载、计时基准和输出长度，而不是给出一个无解释的每秒 token 数字，这些数据仍然作为工程主张具有参考价值。考虑使用该 API 的开发者需要在自己的区域并结合自己的提示分布、并发级别和工具调用模式衡量延迟。

一个刻意狭窄的首款产品

最初的 Celeris API 面向紧凑型任务。Celeris 的开发者文档 建议将 Celeris-1 用于简短、结构化的响应，并将提示加上最大输出配额限制为 8,192 token。最大输出设置必须为 256 的正倍数。

这使得 Celeris-1 成为一块针对性的推理基础设施。分类、抽取、查询重写和代理路由很少需要巨大的上下文窗口，但每次调用都可能直接位于对延迟敏感的路径中。将这些步骤的耗时减少数秒，可能比加速单个聊天机器人响应产生更大的产品影响。

Celeris 收费为每百万输入 token $2 和每百万输出 token $6。Celeris 还提供定制企业条款、专用集群和 VPC 部署。现有的 OpenAI 客户可以通过更改 base URL 和 API key 来连接，从而减少进行评估所需的集成工作。

API 的设计透露了创始人的市场进入策略。Hamer 和 Clark 从那些 diffusion 的速度优势可以立即衡量、且受限上下文窗口损害较小的工作负载入手。语音代理和多步软件代理为 Celeris 提供了对其核心主张的实际检验：当每次推理调用的响应时间能够适配普通界面的响应时间时，智能会变成一种不同的基础设施产品。