截至 10-16 仍未官宣：Kimi K3.1「三档推理 + 百万上下文」传闻跟踪，政企选型该盯住什么

传闻从哪里来：接口标识与开放平台预告页

目前流传的信息链有两环：其一是 Wccftech 9-23 的报道，称从月之暗面内部接口响应中发现 K3.1 标识，预计 2026 年 10 月发布（据报道，官方未证实）；其二是据媒体报道，官方开放平台已现「K3.1」预告页——这一环节即便属实，也仅能证明产品排期存在，不构成任何参数承诺。内部接口标识属于工程痕迹，「标识先现、发布延期」的情况在行业内并不罕见，因此本文对全部特性一律按传闻处理，不做任何确定性表述。

• 9-23 Wccftech 报道：从月之暗面内部接口响应发现 K3.1 标识，预计 2026 年 10 月发布（据报道，官方未证实）；
• 开放平台预告页：据媒体报道已现「K3.1」预告页，仅能证明排期存在，不构成参数承诺；
• 截至 10-16：月之暗面仍未官宣 K3.1 发布日期与参数。

三个传闻特性逐一拆解：档位、上下文、多智能体

据媒体报道（均未经官方证实），K3.1 的传闻特性有三：一是 Low/High/Max 三档推理强度，若属实，推理档位将成为显性的「成本旋钮」——政企可以按任务价值分配档位，把低价值任务压到低档计费；二是 ExtraLong（约 100 万）上下文，对应长文档、大代码库整库入窗场景；三是 Agent 与 Swarm（多智能体群）模式，指向多智能体编排能力的产品化。三项传闻若逐一落地，将直接改写本地部署与云端 API 的选型对比口径——但每一项都需要以官方资料为准，目前均无官方确认。

作为参照，K3 于 2026 年 7 月发布（官方资料）：2.8 万亿参数、原生视觉能力、100 万 Token 上下文窗口，采用 Kimi Delta Attention、Attention Residuals 和稀疏 MoE 架构。K3.1 相对 K3 的传闻增量（均未经官方证实）主要落在「推理强度分档」与「多智能体模式」上。放到本地部署场景看：「档位」对应模型规格与推理参数的选择，成本旋钮从「按次计费」变成「算力分配」；百万级上下文决定大代码库、长文档能否「整库入窗」，直接影响本地部署下 RAG 链路是切块检索还是整窗直读；Swarm 模式在政企语境里最复杂，内网环境下的权限边界、调用链可审计性都要重新设计。

政企选型该盯住什么：传闻不进 RFP

这篇跟踪对政企选型的价值，不是「预测 K3.1」，而是把三件事讲清楚——传闻的信息链与置信度、传闻特性对应的评估维度、官宣前本地部署评估该锚定的基线。建议：官宣前，不要把 K3.1 的任何传闻特性写入 RFP 硬性条款；官宣后，重点验证三件事——档位间的实际成本差、百万上下文在长文档/代码库任务上的有效长度（而非窗口标称值）、Swarm 模式在受控内网环境下的可审计性。本地化部署的评估基线，仍应以 K3 官方资料为准，叠加数据不出域与国产化适配、等保三级/密评合规的准入要求。传闻会过时，评估框架不会——采购决策只锚定官方资料与本地实测。

• 评估口径：推理成本、长文档处理、多智能体编排三个维度，可先基于 K3 官方资料与实测评估，官宣后只需「替换对比对象」；
• 硬件基线/实测：llama.cpp + 7900 XTX 24G 单机 55+ token/s；UOS 25/麒麟 V10/欧拉适配；等保三级/密评/备案材料包交付；三年 TCO 约为云 API 1/6~1/8；
• 选型纪律：K3.1 列观察项而非决策依据，官宣后按官方资料逐项更新对比数据点。