Fireworks 对 Kimi K2.5 官方 API 与部署栈的质量对照

一句话结论

Fireworks 用 Kimi 官方 API 做对照发现，生产质量不仅由模型决定：K2.5 的 chat template、EOS/思考边界、reasoning_content null、采样参数和负载错误都会改变 tool-call 结果，Fireworks 的代表性分数接近官方但存在细微差异。

测试环境

• 对照：Kimi model card、Kimi official API measured by Fireworks、Fireworks API。

• 质量层：prompt formatting、stream/non-stream tool calling、grammar-constrained generation、numerical correctness、超时/断开/错误码、SDK/proxy 兼容。

• 评测层：deterministic unit tests、one-turn、agentic multi-turn、multimodal、周期回归；KVV、SWE-Agent、Terminus-2、Eval Protocol。

• 重复：大多数结果 avg@3；Tau-Bench avg@4；SWE-Bench avg@2。

输入/配置

Fireworks 报告：SWE-Bench 使用 SWE-Agent；Terminal-Bench 2 使用 Terminus 2；AIME/MMMU/OCR/K2VV 使用 Kimi KVV。SWE-Bench Fireworks 将 max output 提高到 32k，且官方 harness 未明确 max_tokens；Terminal-Bench 强制 non-thinking。

结果数据

结论

Fireworks 的实测支持“正确部署可接近官方结果”，但也发现必须处理思考阶段 EOS、null reasoning_content、采样参数、空 200 响应和多轮工具调用；生产选型应评估完整 serving stack 而非只比较模型卡。

局限

• Fireworks 具有 provider 立场，代码/修复细节与官方 KVV 结果部分依赖其自有服务。

• 分数多为少量重复（2–4 次），不能代表所有任务方差。

• “1/10 成本、2–3×速度”等宣传比较依赖 provider 条件，不是普遍价格/吞吐保证。

• Terminal non-thinking、SWE custom harness 与官方 API 条件不一致，跨列比较需谨慎。

复现步骤

1. 对同一 prompt、模型 snapshot、工具 schema、采样和 max tokens，分别调用官方 API、Fireworks 和自托管 endpoint。

2. 运行单轮/多轮、stream/non-stream、Thinking/Instant、视觉和 grammar-constrained tool tests。

3. 验证 chat template、reasoning_content null 过滤、EOS guard、HTTP 429/空 200、超时与重试。

4. 按每个 harness 报告 score、调用成功率、错误类型、延迟和成本，避免用一次 SWE 分数概括部署质量。