Kimi K3.1 疑似现身 LMArena：匿名代号 Kibitz、SGLang 单日六条加固 PR，月底有望官宣

一个代号，一天之内凑齐四条旁证

2026-10-22 凌晨，LMArena 上多出两个匿名模型：Kibitz 和 Kalmia。名字不带任何厂商前缀，对战记录很快被截图传开。圈子里普遍的判断是，Kibitz 是月之暗面给 Kimi 新模型起的匿名代号，K3.1 在预热。

图：Arena 官方 WebDev Arena 排行榜（2026-10-22 快照，92.1 万票、150 个模型）：GPT-6 Astra (Max) 以 1775 分列第 2，Kimi K3 (Max) 以 1655 分列第 16，同榜直接呈现本文的对标关系

同一天的旁证也密。有人说 SGLang 仓库里出现了两个 K3.1 部署适配提交；有稿子写第三方托管平台已经跑起了 K3.1 部署；还有人称在 Kimi Coding API 端点里看到了 K3.1 的响应记录。三条都指向同一个方向：这个版本不只是存在，它已经在对外服务链路上走了一遍。

放在历史里看更有意思。Kimi K2 当年就是这么出场的，LMArena 官方博客记得清清楚楚：K2 顶着 Kibitz 这个名字匿名参赛，Hard Prompts 拿了第一（1412 分），overall 第四，排在 Grok 4、Gemini 2.5 Pro、ChatGPT o3 后面，是第一个挤进总榜 top5 的开源权重模型。后来的 K2 Thinking（K2-Thinking-0711）走的也是同一条路，首周进 top5。

对，Kibitz 不是新名字。K2 用过，2026 年又出现了一次。这算佐证还是巧合，文末再说。

底座是铁的，先把底座讲清楚。

底座 Kimi K3：参数表全在这

K3 已经正式发布并全量上线。Kimi 开放平台（platform.kimi.ai，由 platform.moonshot.ai 301 过来）全站挂着 "Kimi K3 has launched" 的横幅，文档原话是 "Kimi's most capable model to date, with a 1M-token context window and native visual understanding"，定位写的是长程编码和端到端知识工作。在售型号四项：Kimi K3、Kimi K2.7 Code、Kimi K2.6，外加模型列表页。

2.8 万亿总参数、104B 激活、1M 上下文，这三个数是它的身份。完整架构表抄一遍，写代码的时候真用得上：

项目	数值
总参数 / 激活	2.8T / 104B
层数	93（含 1 层 Dense）
注意力	69 层 KDA + 24 层 Gated MLA
Hidden Dim	7168，96 头
MoE	896 专家选 16，另有 2 个共享专家
Latent MoE 维度	3584（每专家 MoE Hidden 3072）
词表 / 上下文	160K / 1,048,576
激活函数	SiTU-GLU
视觉编码器	MoonViT-V2，401M 参数
量化	MXFP4 权重 + MXFP8 激活（量化感知训练）

模型卡自称 "world's first open 3T-class model"，新架构（KDA、Attention Residuals、Stable LatentMoE）相对 K2 有约 2.5 倍的 scaling 效率提升。这套组合落到实际就是：1M 上下文配 104B 激活，你能把一整个中型代码仓库塞进去，代价是每层只唤醒 16 个专家，显存和速度之间做了很激进的取舍。

图：Kimi K3 官方 Coding 基准图（DeepSWE / FrontierSWE / Terminal Bench 2.1 / Program Bench / SWE Marathon），K3 与 OpenAI、Anthropic 旗舰同框对比

KDA 多说一句。K3 的文本骨干是 KimiLinear，69 层注意力全走 KDA（实现文件头还标了 full-rank KDA gate 和 attn_res_block_size），线性路线在长序列上的开销增长比标准 attention 平缓，1M 窗口才跑得动；剩下 24 层保留 Gated MLA。我的读法是 KDA 管长程吞吐，MLA 那部分管准头，各干各的。量化那栏的"量化感知训练"也值钱：MXFP4 是训练时就按这个精度对齐的，掉点比训完再压小得多，这也是 DeepInfra 敢直接上 mxfp4 部署的前提。

权重仓库 2026-07-27 创建，8900 多 star，license 标 Other（对应 Kimi K3 License）。顺带纠正一个流传较广的说法：所谓 "7-16 以 1679 分登顶 Frontend Code Arena"，时间上比仓库创建早了 11 天。7-16 更可能是 Arena 匿名测试的计分时间，开源是 7 月底的事，两件事别混着引用。

图：MoonshotAI/Kimi-K3 官方 GitHub 仓库卡（9k stars / 761 forks），K3.1 的开源底座仓库，可兼作仓库热度佐证

现在就能跑的三条路

一、DeepInfra 直接调

DeepInfra 上 moonshotai/Kimi-K3 已经在线，mxfp4 量化，上下文 1,048,576，Modality 标 Text + Image。定价 $2.85 输入 /$14.25 输出 / $0.285 缓存命中，都是每 1M token。OpenAI 兼容接口，curl 就能通：

curl https://api.deepinfra.com/v1/openai/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPINFRA_TOKEN" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {"role": "user", "content": "下面是这段构建日志，把报错归类，给出出现最多的三类原因和对应修复建议：\n<日志内容>"}
    ],
    "max_tokens": 2048
  }'

K3 默认满推理力度，会先想一大段再吐答案，首 token 等十几二十秒别以为挂了。返回里盯两个地方：usage 里缓存相关字段是否非零（OpenAI 兼容接口的通用结构），以及 completion tokens 实际消耗。后者直接决定账单，K3 的输出价不便宜，后面算给你看。

二、官方平台

platform.kimi.ai 文档写得很明确：示例默认用最新模型 kimi-k3，推理力度走顶层请求字段 reasoning_effort，支持 low / high / max，默认 max。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["KIMI_API_KEY"],
    base_url="https://api.moonshot.ai/v1",  # 以控制台给出的 endpoint 为准
)

resp = client.chat.completions.create(
    model="kimi-k3",
    reasoning_effort="high",   # 不写就是 max，慢且贵
    messages=[{"role": "user", "content": "review 这段 diff，重点看并发问题"}],
)

reasoning_effort 是顶层字段，不塞 messages，也不是 extra_body 里的嵌套结构，从别的 OpenAI 兼容端点迁脚本过来最容易在这栽。探索阶段调 low，验收再上 max。

工具调用的流程跟 OpenAI 那套一致：请求里带 tools 数组，返回 tool_calls，本地执行完把结果以 role=tool 塞回去，第二轮拿最终答案。请求体长这样：

{
  "model": "kimi-k3",
  "reasoning_effort": "high",
  "messages": [{"role": "user", "content": "看下 MoonshotAI/Kimi-K3 仓库最新的 open issue"}],
  "tools": [{
    "type": "function",
    "function": {
      "name": "list_issues",
      "description": "列出指定 GitHub 仓库的 issue",
      "parameters": {
        "type": "object",
        "properties": {
          "repo": {"type": "string"},
          "state": {"type": "string", "enum": ["open", "closed"]}
        },
        "required": ["repo"]
      }
    }
  }]
}

拿到 tool_calls 里模型填好的参数，本地去跑 GitHub API，结果塞回对话再发一次，这才轮到最终答案。K3 在这一步的可靠性有数撑着：MCPMark-Verified 94.5，是官方评测表里它赢 Fable 最多的项目之一。文档也单开了一页 K3 API Tool Calling Best Practices，主推 K3 做 agent 场景，这跟爆料里 K3.1 重点提升部署与工具调用稳定性的方向能对上。

还有两句值得记的原话：纯代码生成和编辑场景想要更快输出，换 kimi-k2.7-code-highspeed；要调 K2.6 就写 kimi-k2.6。视觉输入有限制，图片不超过 4K 分辨率，视频不超过 1080p。

三、自部署 SGLang

主分支已经完整支持 K3，实现在 python/sglang/srt/models/kimi_k3.py，3867 行。文件头注释把 K3 特有的东西列全了：Attention Residual（attn_res_block_size）、Latent MoE（routed_expert_hidden_size）、SiTU 激活、MLA output gate、Full-rank KDA gate；文本骨干 KimiLinear，视觉塔 MoonViT3d。

pip install "sglang[all]"

python -m sglang.launch_server \
  --model moonshotai/Kimi-K3 \
  --tp 8 \
  --trust-remote-code

这是通用起手式，tp 数按卡来。MXFP4 权重按 4 bit 算也要 1.4TB 出头，八张 141G 的卡加起来 1.1TB 多，装不下完整权重。自部署这事对绝大多数人，停留在读代码层面就够了。

真正的看点在 10-22 当天的 PR：#45817 把共享专家输出挪到产出流上，#45757 做原生输出校验和终态失败传播，#45721 和 #45716 把 tool-call 参数从整段缓冲改成增量流式，#45713 在 AMD gfx950 上默认启用 KDA fused decode kernel，#45856 和 #45828 搞 FP8 decode 与 SiTU 量化。

六条集中在一天，修的全是流式、失败传播、量化这类"对外暴露 API 前才会补"的东西。这是圈子里判断 K3.1 临近的最硬一条：推理栈在为新版本打磨，不是给老版本打补丁。

踩坑提示

输出价。 $14.25/M token，是 K2.6（DeepInfra 上$0.75 in / $3.5 out，262K 上下文）的 4 倍。1M 上下文的模型，prompt 轻松几十万 token，输入侧靠缓存命中能压到$0.285，但 cache 写入另算：retain 5 分钟是 1.25 倍价（$3.5625/M），retain 1 小时直接翻倍到$5.70/M。长对话高频调用的场景，这笔账得先算再上。

默认 max。 不写 reasoning_effort 就是全力思考，延迟和成本一起上去。写脚本的时候显式带上，别靠默认值。

别把传闻当已上线。 DeepInfra 全量模型列表（/v1/openai/models，176 个模型）里 Kimi 系只有 K2.6 和 K3 两个，没有 K3.1；官方文档里搜不到 K3.1；SGLang 主分支没有 kimi_k3_1.py（404）；sglang 仓库全文搜 "K3.1"、"Kalmia"、"Kibitz" 都是 0 结果。"DeepInfra 已跑 K3.1 部署"这条，至少在公开模型列表层面找不到对应物，只能当传闻听。

对比：官方口径里没有 GPT-6 Astra

官方评测表对比的六列是 Kimi K3 (max)、Claude Fable 5 (max, w/ fallback)、GPT-5.6 Sol (max)、Claude Opus 4.8 (max)、GPT-5.5 (xhigh)、GLM-5.2 (max)，脚注注明全部成绩 reasoning_effort=max、temperature=1.0。

K3 赢的硬数字：GPQA Diamond 93.5（Fable 92.6）、Terminal-Bench 2.1 拿下 88.3、FrontierSWE 81.2、SWE-Marathon 42.0 对 Fable 的 35.0、BrowseComp 91.2、MCPMark-Verified 94.5 对 87.4。这数一个比一个夸张，但都出自官方模型卡。

输的也不少：HLE-Full 43.5/56.0，Fable 是 53.3/63.0；CritPt 23.4 对 28.6；GDPval-AA v2 Elo 1686，Fable 1747、GPT-5.6 Sol 1736；连 Kimi 自家的 Code Bench 2.0 都是 72.9 对 Fable 的 76.9。

图：Kimi K3 官方 General Agents / Visual Agents 基准图（GDPval-AA v2 Elo、JobBench、Automation Bench、BrowseComp 等），K3 相对 GPT 与 Claude 的整体位置

这组数字给"直追 GPT-6 Astra"泼了盆冷水。官方口径里没有 Astra 这个对标物，最接近的 GPT-5.6 Sol 在 GDPval Elo 上还压 K3 一头。SWE-Marathon 和 MCPMark 两项是真领先，长程任务加工具调用，恰好是爆料里 K3.1 打磨的方向，这倒是自洽的。

Astra 本身的公开信息也乱。一个说法是 2026-06-22 发布，公告标题 "Welcome to the AGI era"，自称首个达到 Preparedness Framework Critical 网络安全阈值的模型；另一个说法把日期放到 09-03。两个日期对不上，OpenAI 官网又有反爬，这条只能按传闻处理。拿一个日期都定不下来的模型当对标基准，这个对比本身就要打折。

价格顺手摆在一起：K3 是 $2.85 in /$14.25 out / 1M 上下文，K2.6 是 $0.75 /$3.5 / 262K 上下文。什么时候用哪个，我的分法很简单：上下文超 200K、或者要喂图喂视频的，没得选，K3；日常短上下文的代码活，K2.6 便宜 4 倍，没必要硬上。

争议与边界

Kibitz 复用旧名这件事值得多说两句。

"K 系新模型先上 Arena 匿名测"这个惯例是真的，有 LMArena 官方博客背书。厂商愿意匿名上，逻辑不难猜：盲测防品牌先入为主，成绩干净；真跑进 top5，揭晓当天就是一波免费传播，K2 那句"第一个进总榜 top5 的开源权重模型"就是这么挣来的。对开发者还有个实际好处：匿名期能免费用上还没官宣的模型，这是整条爆料链里唯一能亲手验证的一环。

但 2026 年 Kibitz 又冒出来，就有两种解释了：月之暗面刻意复用旧代号保持连贯，或者匿名名池撞车。前者的佐证强度高，后者基本等于零。眼下没有证据区分这两种。

SGLang 那两条 K3.1 适配提交和 API 端点响应记录，目前都是单源，公开仓库和模型列表里复现不了。GitHub 搜索的全文索引有延迟，这不等于爆料是假的，也不等于能当事实写。稳妥的表述是：有一条完整的传闻链，链上每一环都还没被独立验证。

版本号本身也是个暗示。K3 在 9 月已经出过一次小幅提升版（K3-0903）。如果 K3.1 的提升集中在部署与工具调用稳定性上，那它跟"性能直追 Astra"之间隔着不小的距离。小版本号加推理栈加固 PR，指向的更像一次工程向迭代。

我倒觉得，四类公开痕迹的可信度大致这么排：第三方托管平台模型列表（硬证据，上了就是上了）> 推理栈 PR（强旁证，但可能只是给 K3 本身加固）> Arena 匿名代号（中等，命名撞车风险）> API 端点嗅探记录（弱，截图成本太低）。下次再看到类似爆料，照这个顺序核对一遍，能省不少事。

月底会不会官宣

会的话，最早的信号大概率不在发布会，在 DeepInfra 的模型列表和 SGLang 的仓库。列表里多出 K3.1、仓库里合入 kimi_k3_1.py，这两件事的时间点基本就贴着官宣。

我的判断是：K3.1 大概率是一次工程向版本，重点在部署稳定性和 tool-call 流式这些 SGLang 正在修的地方。真要看能力跃迁，得等 K4。

留一个眼下没人答得上的问题：Arena 的匿名名池到底有多小，才会让 K2 和 K3.1 撞上同一个 Kibitz。

参考链接

• LMArena 官方博客：Kimi K2 以匿名代号 Kibitz 首秀并进入总榜 top5 的评测记录 blog.lmarena.ai/blog/kimi-k…
• Kimi 开放平台文档：Kimi K3 已上线、模型定位与 reasoning_effort 字段说明 platform.kimi.ai/docs/overvi…
• DeepInfra：moonshotai/Kimi-K3 模型卡，含架构参数表与定价 deepinfra.com/moonshotai/…
• DeepInfra：全量模型列表，Kimi 系仅有 K2.6 与 K3 两个 api.deepinfra.com/v1/openai/m…
• GitHub：MoonshotAI/Kimi-K3 权重仓库，2026-07-27 创建 github.com/MoonshotAI/…
• GitHub：SGLang 主分支 kimi_k3.py 模型实现，3867 行 github.com/sgl-project…
• SGLang PR #45757：K3 原生输出校验与终态失败传播 github.com/sgl-project…
• SGLang PR #45716：tool-call 参数改为增量流式 github.com/sgl-project…
• SGLang PR #45713：AMD gfx950 默认启用 KDA fused decode kernel github.com/sgl-project…