Kimi K3 官方发布说明：长程 Agent、多模态案例与边界

一句话结论

官方材料把 Kimi K3 定位为适合长程编码、视觉闭环、知识工作和研究型 Agent 的 2.8T/104B-active 模型，同时明确承认总体仍落后 Claude Fable 5 与 GPT-5.6 Sol。

测试环境

• 模型：Kimi K3，2.8T 参数、16/896 专家激活、1M context、原生视觉。

• 官方产品：Kimi.com、Kimi Work、Kimi Code、Kimi API。

• 默认设置：发布时 max thinking；官方脚注说明评测使用 max、temperature=1.0、top-p=1.0。

• API 价格：cache-hit 输入 $0.30/M，cache-miss 输入 $3/M，输出 $15/M。

输入/配置

• 长程 Agent 必须保留完整 thinking history；官方建议使用兼容 harness，例如 Kimi Code，不要在会话中途切换模型。

• 官方建议对过度主动行为增加更明确的 system prompt 或 AGENTS.md 边界。

• Kimi Code 中可通过 /model 选择 Kimi K3；官方 API 模型名为 kimi-k3。

结果数据

• GPU kernel 优化：官方称 K3 与带 fallback 的 Fable 5 竞争力相当，明显超过 Opus 4.8、GPT-5.6 Sol 和 GPT-5.5；每个模型在相同 sandbox 中最多 24 小时优化、重写和 benchmark 四个任务。

• MiniTriton：官方案例称模型从 MLIR/IR 到 PTX codegen 构建完整编译器，并在部分 roofline workload 上达到或超过 Triton/torch.compile。

• 芯片设计：官方称一次 48 小时 autonomous run 完成设计、优化和验证，模拟达到 100 MHz、8,700+ tokens/s；这些是发布方案例数据。

• 科研工作流：官方称约两小时完成通常需 1–2 周的 I–Love–Q 复现，审阅/交叉验证 20+ 论文、评估 300+ EOS、生成 3,000+ 行 Python 和交互式 dashboard。

• 知识工作：一个 ASIC 研究案例使用 120+ 轮递归改进、2.8k+ web searches/fetches、1.1k+ terminal data pulls、11k+ 页面、87 份季度报告和 99 份原始 PDF。

• 多模态创作：官方展示截图闭环的游戏/前端/CAD，以及从 56 个素材片段进行剪辑和多轮修订的案例。

结论

这些案例支持把 K3 作为“长程、工具密集、需要视觉或大文档上下文”的候选模型；它们不支持“所有任务都胜过闭源模型”的结论。官方自己把总体性能放在 Fable 5 和 GPT-5.6 Sol 之后，并指出用户体验仍有差距。

局限

• 页面主要是官方案例叙述，没有公开每个案例的完整输入、随机种子、工具日志、失败率或可下载产物。

• 不同 benchmark 使用 Kimi Code、Claude Code 或 Codex 等不同 harness；官方数字不能直接当作同 harness 对照。

• max thinking 和高 token 用量可能造成高延迟、高成本；模型过度主动时可能在模糊指令下替用户做决定。

• 评测案例不等于生产 SLA；企业应使用自己的仓库、数据和验收标准做 pilot。

复现步骤

1. 在 Kimi Code 或官方 API 选择 kimi-k3，固定 harness、模型版本、温度、top-p、工具权限和停止条件。

2. 选择一个真实长程任务，例如仓库级修复、截图驱动 UI 修复或多文档研究；保存初始输入与数据快照。

3. 强制保留完整 assistant reasoning/tool-call history，并为过度主动行为设置显式权限边界。

4. 记录成功率、工具调用数、总输出 token、耗时、人工修改量和可交付物质量；与一个已知基线模型做相同任务对照。

原始证据与数据

官方页面的可核验字段包括模型架构、API 价格、默认 thinking、案例运行时长/轮次/文件数量，以及对 thinking history、过度主动和用户体验差距的限制说明。

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

官方结论为：“While its overall performance still trails the most powerful proprietary models”。