Kimi K2.6：DeepInfra 架构、基准与 Provider 能力边界

一句话结论

DeepInfra 的整理把 K2.6 的 262K 上下文、Agent Swarm 和编码/搜索分数讲清楚，同时暴露出 provider 级边界：其 API 文档称图像输入未开放，不能直接套用 Kimi 官方多模态结论。

适用场景

• 适合的任务：通过 DeepInfra API 做长上下文代码、搜索和 Agent 编排的初步选型。

• 不适合的任务：要求在 DeepInfra 端直接传图像的任务；文章明确称该 API 不暴露 image input。

• 适用的模型版本：DeepInfra 的 moonshotai/Kimi-K2.6。

• 适用的客户端、Agent 或 API：DeepInfra OpenAI-compatible Chat Completions；不是 Kimi 官方 API 的等价复现。

• 推荐的推理档位和参数：文章示例使用 provider 自己的 temperature 0.7，但这与 Kimi 官方 K2.6 固定 temperature 1.0/thinking 规则不同，正式比较应遵循 provider 文档。

测试环境、输入/配置

• Provider：DeepInfra API，模型名 moonshotai/Kimi-K2.6。

• 架构信息：1T MoE、32B active、384 experts、每 token 8 experts+1 shared、61 layers、262,144 context、MoonViT 400M。

• 数据来源：文章汇总 Moonshot 官方 benchmark，并提供 DeepInfra API 示例；未声明自己重新运行全部基准。

• API 示例：OpenAI-compatible /v1/openai/chat/completions，示例为文本 system/user 消息。

结果数据

文章列出的代表性数字（百分比）：

补充：SWE-Bench Verified 80.2；BrowseComp 单 Agent 83.2、Agent Swarm 86.3；文章称 K2.6 在纯推理 AIME/GPQA 落后 GPT-5.4（AIME 96.4 vs 99.2、GPQA 90.5 vs 92.8）。

结论

该来源适合帮助工程团队区分“模型能力”和“provider 暴露的能力”：K2.6 的原生模型支持多模态，但 DeepInfra API 文章明确把图像输入列为未暴露；长上下文与代码能力仍可作为 provider 侧候选优势。

局限

• 文章大量数字来自 Moonshot 官方资料，不是 DeepInfra 对所有任务的独立受控重跑。

• 文章的 API 示例使用 temperature=0.7，与 Kimi 官方 K2.6 固定参数说明不一致；这是 provider 适配差异，不能当作 Kimi 官方配置。

• 价格和接口可能变化；文章的 $0.75/$3.50 输入/输出价以及 $0.15 cached input 需以当前 DeepInfra pricing 复核。

• “图像输入未开放”是 DeepInfra API 边界，不是 K2.6 原始模型没有视觉能力。

复现步骤

1. 在 DeepInfra 固定 model ID、API 版本、system prompt、temperature 和 max_tokens，记录 token usage。

2. 先复现文本代码/搜索任务，再尝试图像请求，确认 provider 是否仍拒绝或不暴露图像字段。

3. 与 Kimi 官方 API 使用同一任务和成功标准对照；分别记录 thinking、工具、上下文管理和价格。

4. 不把文章引用的官方 benchmark 当作 DeepInfra 的实测结果；只报告自己真正运行过的任务。

原始证据与数据

文章正文直接给出 262,144 context、MoE 结构、DeepInfra endpoint/model ID、基准表和“image input is not exposed through the API”的说明，足以复核 provider 能力边界，但不足以独立复现全部分数。

来源摘录或观察（仅做合规短引）

该文最重要的边界句是 “image input is not exposed via the API”；它与 Kimi 官方 quickstart 的 image/video 输入说明并不矛盾，只说明两者是不同接入面。