推荐标题：Kimi K3 2.8T：超稀疏 MoE、百万上下文与真实部署边界 备选标题1：别只看表面：Kimi K3 2.8T真正要验收什么 备选标题2：一张工程图拆解 Kimi K3 2.8T 备选标题3：Kimi K3 2.8T为什么经常被理解错

超大总参数、稀疏激活和百万上下文是三个不同工程变

研究快照：2026-07-21。完整权重、许可证、模型配置和技术报告在该日期尚未公开。本文讨论的是已经确认的架构与部署边界，不是完整本地部署实测。

摘要

摘要

Kimi K3 最容易被误读的数字是 2.8T。它说明模型拥有巨大的总参数容量，却不能单独回答每个 Token 的计算量、权重需要多少显存、跨节点通信是否可接受、百万上下文如何计费，也不能说明现有 Coding Agent Harness 能否正确保存它需要的状态。

官方资料已经确认：K3 使用 Kimi Delta Attention、Attention Residuals 和 Stable LatentMoE，每次激活 896 个专家中的 16 个；API 原生提供 1M Token 上下文、始终开启的 Thinking、严格 JSON Schema、Partial Mode、Tool Choice 和 Dynamic Tool Loading；官方建议使用拥有 64 个或更多加速器的 Supernode，并计划在 2026 年 7 月 27 日前公开完整权重与技术报告。[S1][S2][S3]

这些信息支持一个更重要的判断：K3 不是“一个更大的聊天模型”，而是一套需要模型架构、推理基础设施、Agent Harness 和成本控制共同配合的生产系统。

1. 先拆开五个经常被混为一谈的问题

1.1 总参数不是每 Token 激活参数

2.8T 表示全部专家和共享模块的参数规模。Stable LatentMoE 每次只激活 16/896 个专家，说明单 Token 的主要专家计算远低于全参数密集执行。它降低的是每步计算量，不会让未激活专家的权重从存储和分布式路由中消失。

因此需要分别回答：

  1. 全部权重需要放在哪里；
  2. 一次前向激活哪些权重；
  3. Expert Parallel 如何路由 Token；
  4. 每层 All-to-All 的通信代价；
  5. 长上下文状态和运行时缓冲占多少空间。

“每次只激活 16 个专家”不能推出“几张消费卡即可部署完整模型”。

1.2 4-bit 权重也不等于工作站可装下

仅计算 2.8T 权重本体：

精度理论权重下限说明
FP16/BF16约 5.6 TB每参数 2 Byte
INT8/FP8 近似约 2.8 TB每参数 1 Byte，仅作容量量级
4-bit约 1.4 TB每参数 0.5 Byte，未计量化元数据

常见设备的总显存：

配置总显存与 1.4 TB 原始 4-bit 下限的关系
8×RTX A6000 48GB384 GB约为下限的 27%
8×RTX 5090 32GB256 GB约为下限的 18%
8×RTX PRO 6000 96GB768 GB约为下限的 55%
64×H100 80GB5.12 TB容量足够，但通信与运行时仍是核心
64×H200 141GB9.024 TB容量更宽裕，不代表自动达到高吞吐

这里还没有加入量化 scale、路由与通信缓冲、CUDA Graph、KV/状态缓存、冗余和故障恢复。完整部署至少需要“权重容量 + 运行时余量 + 高带宽通信域”三个条件。

1.3 稀疏计算仍然需要高带宽通信

MoE 把 Token 分发给不同专家。专家分布在多张卡或多个节点时，路由会把推理问题变成通信问题。官方推荐 64+ 加速器 Supernode，核心信号不是“64 是唯一答案”，而是 K3 预期运行在一个拥有大容量、低延迟、高带宽互联的通信域中。[S1]

一个系统即使在容量上勉强装下全部权重，也可能因为以下原因没有生产价值：

  • Expert All-to-All 占用主要时间；
  • 热门专家负载不均；
  • 跨节点拓扑破坏局部性；
  • 批量太小，无法摊薄通信；
  • 批量太大，首 Token 延迟失控；
  • 容错或副本策略进一步放大资源需求。

因此，K3 的部署问题应从“显存够不够”升级为“拓扑、并行、路由和服务目标是否匹配”。

2. KDA 与百万上下文改变了缓存问题

2. KDA 与百万上下文改变了缓存问题

K3 采用 Kimi Delta Attention。官方同时说明，KDA 对传统 Prefix Cache 实现提出挑战，并计划随模型公开相应的 vLLM 实现。[S1] 这意味着 1M Context 不只是“把窗口调大”，而是同时要求：

  • Attention 状态表示适配 KDA；
  • 请求前缀保持稳定；
  • Agent Harness 不随意改写历史；
  • 缓存键能够覆盖模型、参数和工具状态；
  • 缓存命中、驱逐、TTL 和计费可观测。

官方 API 的缓存命中输入价格为每百万 Token 0.30 美元，未命中输入为 3 美元，输出为 15 美元；官方还称 Coding Workload 的缓存命中率超过 90%。[S4] 这是一条厂商运行数据，不是所有代码仓库都能复现的常量。

一个简化例子：请求包含 1M 输入 Token、20k 输出 Token，其中 90% 输入命中缓存。按公开单价粗略计算：

缓存输入：0.9M × $0.30 / M = $0.27
未缓存输入：0.1M × $3.00 / M = $0.30
输出：0.02M × $15.00 / M = $0.30
合计：约 $0.87

如果全部输入未命中，合计约为 $3.30。这个差异说明：百万上下文的经济性主要取决于前缀稳定性，而不是窗口上限本身。实际账单还受请求结构、缓存实现和输出长度影响。

3. Agent Harness 是模型兼容层

K3 的 API 文档要求在多轮对话和 Tool Calling 中完整回传 assistant message，不能只保留 content；Thinking 始终开启，reasoning_effort 可调整；Dynamic Tool Loading 允许先只提供搜索工具，再按需要注入工具定义。[S2][S3]

这使 Harness 成为一等公民。一个成熟 Harness 至少要保存：

Conversation Messages
+ Assistant Thinking State
+ Tool Calls and Tool Results
+ Tool Registry Version
+ System / Repository Instructions
+ Model Parameters
+ Cache-Relevant Prefix

中途切换模型时，另一个模型未必理解 K3 的思考状态、工具调用语义和消息字段；反向切回 K3 时，缺失历史也可能降低稳定性。这不是简单的 OpenAI-compatible endpoint 就能消除的问题。

“协议兼容”应拆成四层：

  1. HTTP 与字段兼容；
  2. 消息和 Tool Schema 兼容；
  3. 隐式状态与 Thinking History 兼容；
  4. 行为、预算和失败恢复兼容。

4. 为什么 Benchmark 不能直接做排行榜

4. 为什么 Benchmark 不能直接做排行榜

官方技术博客的表格脚注显示，不同测试可能使用 Kimi Code、Claude Code、Codex 或其他 Harness，部分结果来自第三方或不同硬件。[S1] 对 Coding Agent 而言，Harness 会决定：

  • 仓库索引方式；
  • Tool 集合；
  • Patch 应用策略；
  • 自动测试与重试；
  • 上下文压缩；
  • 权限与 Sandbox；
  • Token 和时间预算。

因此“模型分数”往往是 Model × Harness × Budget × Environment 的系统结果。真正可比较的评测需要固定 Harness、任务集、推理预算、工具、硬件和失败重试规则。

5. 三种部署路径

5.1 官方 API

适合快速验证模型能力、Tool Calling 和缓存设计。主要风险是供应商依赖、缓存语义不可完全控制、数据合规和费用波动。

5.2 托管 Dedicated Endpoint

适合希望获得容量隔离、稳定配额和更清晰延迟 SLO 的团队。需要确认模型版本固定、缓存可观测、请求日志和数据保留策略。

5.3 自建 Supernode

适合有大量稳定吞吐、硬件和运行时团队、数据隔离要求的组织。真正成本包括：

  • 权重与格式转换；
  • Expert/Tensor/Pipeline Parallel；
  • 高带宽互联；
  • 故障域和副本；
  • 在线调度；
  • 正确性回归；
  • 运维和版本升级。

对单个 8 卡工作站，更现实的用途是：验证小型衍生模型、运行组件级实验、测试 Harness 和缓存策略，而不是完整承载 2.8T 权重。

6. 权重发布后的验证顺序

不要在权重出现后直接运行一个 Demo 就宣布“可部署”。应按以下顺序：

  1. 许可证：商用、衍生、托管、地域和使用限制。
  2. 文件清单：分片数量、总大小、SHA、配置、Tokenizer、视觉组件。
  3. 实际精度：MXFP4/MXFP8 的文件与硬件要求。
  4. 激活规模：共享参数、专家参数、路由和每 Token 激活量。
  5. 运行时支持：vLLM、SGLang、TensorRT-LLM 或官方 Runtime。
  6. 拓扑：64+ 加速器的节点、互联和并行划分。
  7. 最小启动：只验证加载、首 Token 和短请求。
  8. 正确性：固定任务集、Tool、JSON、视觉、长上下文。
  9. 性能：TTFT、TPOT、吞吐、通信、缓存命中。
  10. 统一 Harness：与其他模型进行同条件比较。

7. 可执行评测框架

7. 可执行评测框架

model_snapshot: null
runtime: null
hardware:
  accelerator: null
  count: null
  topology: null
precision:
  weights: null
  activations: null
parallelism:
  expert_parallel: null
  tensor_parallel: null
  pipeline_parallel: null
workloads:
  - short_chat
  - repository_edit
  - tool_calling
  - strict_json
  - vision
  - long_context
metrics:
  - startup_time
  - ttft
  - tokens_per_second
  - cache_hit_rate
  - task_success_rate
  - invalid_tool_call_rate
  - cost_per_successful_task

关键指标不是每秒 Token，而是“每个成功任务的总资源和成本”。

8. 结论

Kimi K3 的价值在于把四个趋势放到同一系统中：超稀疏 MoE、百万上下文、Agent Tool Runtime 和缓存计费。它也暴露了四个新成本：权重与通信、状态兼容、缓存治理和统一评测。

在完整权重和技术报告公开前，最可信的写法不是宣称本地部署成功，而是明确区分：

模型容量
≠ 单 Token 计算
≠ 显存容量
≠ 服务吞吐
≠ Agent 任务成功率

开放权重降低的是获取和控制门槛，不会自动消除基础设施门槛。

来源

来源