为了开源，Moonshot 从 Kimi K3.1 Pro 的训练数据里摘掉了网络攻防内容

一、先把官方口径的参数列清楚#

Kimi K3.1 Pro 于 2026 年 10 月 23 日正式发布（开放平台文档站的公告条与文档更新时间均为该日期）。官方口径里的硬信息只有下面这些：

• 它是全新 K3.1 系列的第一个模型，官方称之为「迄今能力最强的 3 万亿级参数模型」；
• 上下文长度 100 万 tokens，原生支持视觉输入；
• 同步推出 kimi-k3.1-pro-highspeed（高速版）：官方说「同等智能，输出速度约 2~3 倍」；
• 「完整模型权重将于 11 月 4 日前发布」；
• 调用门槛：在开放平台完成充值（最低充值金额 10 元）后解锁；新用户注册认证赠送的 15 元代金券不可用于 K3.1 Pro。

这里有一条要划重点：官方只给了「3 万亿级参数」这一个规模口径，没有公布总参数量、激活参数量、层数、专家数量或权重精度。网上流传的具体架构数字属于第三方转述，我没有找到可独立复核的来源，所以本文不采用。真要确认，等 11 月 4 日前权重挂出来之后读 config.json 是最快的路子——这也是我在这个站上做开源模型评测时一直用的办法：官方文档给口径，仓库文件给事实。

二、最值得写的一段：为了能开放权重，主动移除攻防数据#

这是这次发布里最有信息量、也最少被转发的一段。官方把它写在「安全」章节里，逻辑链条相当完整：

1. 观察：随着后训练规模扩大，模型的漏洞研究（也就是攻防）能力持续提升；
2. 溯源：他们发现攻防相关内容嵌在中期训练的通用语料里，攻防任务也存在于强化学习的环境组合中——官方称这是「使用广泛数据进行训练带来的自然副产品」；
3. 对照实验：如果中期训练和强化学习两个阶段都不移除相关数据，下游攻防能力会大幅增强；
4. 处置：最终版在两个阶段都做了识别与移除，同时保留「保障模型实用性所需的通用编程任务」。

关键在第四步的效果是有基准数字的。Moonshot 自研了一个叫 xdev-bench-hard 的基准，按官方描述：题目由专家策划，包含基于源代码的漏洞发现与利用任务；多数任务真实复现了 Linux 内核、Node.js、JavaScriptCore、Exim、VirGL 等软件中近期披露的漏洞，并且各项缓解措施均已启用；每项任务给出存在漏洞的源代码、简短提示和对应二进制文件，智能体要写出漏洞利用程序，在独立沙箱中实现任意代码执行，拿到密钥字符串才算通过。指标用 pass@3，不设严格超时或输出 token 上限。

结果是这样：

• 两个训练阶段都不移除数据：pass@3 90.5%；
• 最终版 K3.1 Pro：pass@3 81.0%。

也就是说，这一刀砍掉了 9.5 个百分点的绝对能力。而官方同时强调，即便如此，K3.1 Pro 的攻防能力仍比前代大幅提升（因为更强的通用编程和长周期调试能力会泛化过来），并且「目前仍落后于那些已公开发布至少三个月的前沿闭源模型」。

配套的还有一段明确的开放权重原则，值得原样记住要点：其一，不希望发布会推进网络攻防能力绝对前沿的开放权重——按设计，K3.1 Pro 的攻击性安全能力低于原本训练流程会产出的水平；其二，计划逐步提升开放权重中可用的攻防能力；其三，认为让这类两用能力逐步扩散、而不是集中在少数闭源系统里，最终会让所有软件更安全，因为更多团队能在自己可控的基础设施上审查自己维护的、很少接受专门安全审查的遗留系统。

站在工程视角，我更在意的是它的形式：能力闸门第一次不是一句公关话术，而是一份带对照实验、带自研基准、带数字、且方向是「往下调」的披露。这套东西是可以反驳的——基准、口径、数字都摆在那里，别人可以质疑基准的区分度、可以质疑 pass@3 的稳定性，但没法说它含糊。对做模型上线的人来说，这比再多的「能力更强」都有参考价值。

同时要说清边界：上面所有数字都来自官方自述，xdev-bench-hard 是自研且未公开的基准，第三方目前无法独立复现这组 90.5% / 81.0%，本文按「官方确认、待独立复核」对待。

三、接入前必须知道的五个工程约束#

看过基准就该看接口了。K3.1 Pro 的 API 有几个和常见 OpenAI 兼容模型不一样的地方，踩上去会浪费一整轮调试：

第一，思考关不掉。 官方 FAQ 的原话是「目前关不了，K3.1 Pro 始终开启思考模式」。你能调的是强度：顶层参数 reasoning_effort 支持 low / high / max 三档，默认 max。觉得思考过程太长，就把强度降到 low。

第二，采样参数是固定值。 官方明确列出 temperature=1.0、top_p=0.95、n=1、presence_penalty=0、frequency_penalty=0 为固定值，并「建议不要显式传入」。别把别家的调参习惯直接搬过来。

第三，输出上限的默认值很高。 max_completion_tokens 默认 131072，最大可设置为 1048576。默认就这么高，意味着一次长程任务很容易把输出 token 拉满，成本估算时不能按「几百 token 的输出」去拍脑袋。

第四，视觉输入不支持公网 URL。 图片要传 base64（data:image/png;base64,...）或 ms://<file-id>，而且消息的 content 必须是对象数组，不能是序列化后的字符串。这一点最容易踩：本地调试时把 content 直接拼成字符串，报错信息通常不会告诉你格式问题出在这里。

第五，速率限制跟你的累计充值额绑在一起。 官方文档写明：累计充值金额同时决定账户等级与速率限制，也就是并发数、RPM（每分钟请求数）、TPM（每分钟 token 数）、TPD（每天 token 数）。这意味着上线前不能按「我有一个 key 就能跑」去估容量，得先确认自己落在哪一档，再决定要不要提前充值提额。

这五条约束里，有三条是「业务侧不需要记住、但必须在封装层处理掉」的：视觉的 content 必须是数组、max_completion_tokens 默认给到 131072、思考关不掉只能降强度。把它们一次性收进一个请求构造器，比让每个调用点各自记住要可靠得多：

def build_request(user_text, *, images=None, effort="low", max_out=32768):
    """封装层：把这版模型的固定约束一次处理掉。"""
    content = []
    for b64 in images or []:
        content.append({"type": "image_url",
                        "image_url": {"url": f"data:image/png;base64,{b64}"}})
    content.append({"type": "text", "text": user_text})
    return {
        "model": "kimi-k3.1-pro",
        "reasoning_effort": effort,            # low / high / max，默认 max
        "max_completion_tokens": max_out,      # 默认 131072，业务侧显式收窄
        "messages": [{"role": "user", "content": content}],   # 必须是数组
    }

四、可直接跑的代码#

最小调用先确认线路通不通（官方文档给的 curl 形状）：

curl https://api.moonshot.cn/v1/chat/completions \
  --header "Authorization: Bearer $MOONSHOT_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "kimi-k3.1-pro",
    "messages": [{"role": "user", "content": "用一句话介绍 Kimi K3.1 Pro。"}]
  }'

Python 侧用 OpenAI 兼容客户端，注意 reasoning_effort 是请求顶层参数：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.moonshot.cn/v1",
)

completion = client.chat.completions.create(
    model="kimi-k3.1-pro",
    reasoning_effort="low",          # low / high / max，默认 max
    messages=[{"role": "user", "content": "把一个 200 行的 shell 脚本改写成 Python，并解释每一处行为差异。"}],
)

print(completion.choices[0].message.content)

流式输出时，推理内容和最终答案分成两个增量字段：reasoning_content 和 content。做 agent 前端时把两者分开渲染，别混在一个气泡里：

stream = client.chat.completions.create(
    model="kimi-k3.1-pro",
    messages=[{"role": "user", "content": "解释为什么天空是蓝色的。"}],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta
    reasoning = getattr(delta, "reasoning_content", None)
    if reasoning:
        print(reasoning, end="", flush=True)   # 思考过程
    if delta.content:
        print(delta.content, end="", flush=True)  # 最终答案

多轮对话和工具调用时有一条官方注意事项：把 API 返回的完整 assistant message 原样加入下一次请求，不要只保留 content。只留 content 会丢掉工具调用需要的结构化信息。

五、把成本算清楚：缓存 TTL 是这次最实用的细节#

K3.1 Pro 的上下文缓存是自动的，不需要手动建缓存：满足条件的前缀写入缓存后，命中部分按缓存命中价格计费，写入则会产生一次性的缓存写入费用。TTL 支持 5m（默认）和 1h 两档。官方给的选择建议很直白：连续追问这类间隔很短的场景用默认 5m；间隔可能超过 5 分钟，就显式传 prompt_cache_options.ttl 选 1h，避免缓存过期后重复写入。

另外两个容易漏的细节：缓存按块存储，不足一整块的部分写不进去，会算作未命中；计费不按上下文长度分段，所有用量统一按量付费。

单价方面要说清楚来源。官方定价页（platform.kimi.com/docs/pricing/chat）的表格是前端渲染的，直接抓取拿到的是空表，所以本文不引用官方单价。可核的是第三方镜像：OpenRouter 上 kimi-k3.1-pro 的上架价格为输入 $2 / 百万 token、输出 $10 / 百万 token，与媒体报道口径一致。最终以你控制台的真实账单为准。

下面这个估算器是我自己写的，你可以直接跑，也可以把单价换成账单上的实际值：

def cost(tokens_in, tokens_out, tokens_cached, in_price, out_price, cache_hit_price):
    fresh_in = max(0, tokens_in - tokens_cached)
    return (fresh_in * in_price + tokens_cached * cache_hit_price + tokens_out * out_price) / 1_000_000

turns, prefix, new_in, out = 20, 200_000, 2_000, 8_000
total_in = turns * (prefix + new_in)     # 4,040,000
total_out = turns * out                  # 160,000

print(cost(total_in, total_out, 0, 2.0, 10.0, 2.0))                      # 不命中缓存
print(cost(total_in, total_out, turns * prefix, 2.0, 10.0, 0.4))          # 命中价按 0.4 假设

我实际跑出来的结果是：20 轮、每轮重发 20 万 token 的稳定前缀、每轮新增 2000 token 输入、8000 token 输出，合计输入 404 万 token、输出 16 万 token。前缀完全不命中缓存时成本 9.68 美元；把命中价假设成 0.4 时降到 3.28 美元，差价 6.40 美元。注意：官方没有公开缓存命中价，脚本里默认把它设成等于输入价（即不假设任何折扣），0.4 那一档纯粹是敏感性分析。这也是本文想强调的做法——单价这种会变、且自家文档抓不全的数字，写死在代码里当参数，比抄在文档里可靠。

六、这份文档没说的#

保持诚实，把边界列出来：

• 架构细节未公开：总参数、激活参数、专家数、权重精度、许可证条款，官方文档都没给。11 月 4 日前的权重发布是目前唯一有日期的承诺。
• 基准是自研的：xdev-bench-hard 未公开题目，90.5% → 81.0% 这组数字目前只有官方一个来源。
• Terminal-Bench 4.0 与内部基准：官方给出 K3.1 Pro 在 Terminal-Bench 4.0 上 65.7%，同段写明超过 GPT-6 Astra（58.2%）、与 Claude Opus 5.5（66.4%）差距微弱；内部基准 Kimi Code Bench 3.0 Long-horizon 为 61.2%（K3 为 55.95%）。这些同样是官方自报成绩。
• 事实准确性优化：官方在一组被用户标记过事实错误的去标识化对话上做压力测试，单项事实陈述错误率从 23.35% 降到 6.85%，含至少一处事实错误的回答比例约为前代的 46.4%；官方自己注明这是刻意聚焦易错场景的压力测试，不代表日常水平。这个自我限定写得很老实，值得记一笔。
• 和我站上那篇《把 Kimi K3 塞进八张 AMD 卡》不重叠：那篇讲的是推理栈与硬件部署，这篇讲的是发布策略与训练数据治理，两者的关注对象不同。

总结#

Kimi K3.1 Pro 这次发布有两层值得记住的东西。表层是能力：3 万亿级参数、100 万上下文、Terminal-Bench 4.0 拿到 65.7%、内部长程基准 61.2%、事实准确性明显回补。里层是方法：为了能让开放权重在 11 月 4 日前发布，Moonshot 在中期训练和强化学习两个阶段主动移除了网络攻防相关数据，并用自研的 xdev-bench-hard 把代价量化成 90.5% → 81.0%，同时给出「不发布推进攻防绝对前沿的开放权重」这条原则。

对做工程的人，最实际的启发是三点：能力闸门可以被量化，也应该被量化；接入前把固定参数、思考不可关、视觉只收 base64 这几条写进你的封装层；单价别信二手转述，做成参数、用真实账单回填。权重要到 11 月 4 日前才齐，在那之前，这份文档里最值钱的部分其实是那段「我们自己砍了什么、砍了多少」。