Kimi K3 Weights
Kimi K3 License96 个 Safetensors 分片、远程建模与处理代码、配置、Tokenizer 和权重索引；原生制品把路由专家压成 MXFP4。
OPEN WEIGHTS FIELD NOTES
模型专题 · Moonshot AI / 月之暗面 Kimi K3 把 3T 级模型、百万上下文和 Agent 训练接成一套系统
K3 不是把 K2 等比例放大。它沿三个方向同时改造信息流：用 Kimi Delta Attention（Kimi 差分注意力，KDA）压缩长序列状态，用 Attention Residuals（注意力残差，AttnRes）跨深度找表示，再用 Stable LatentMoE（稳定潜空间混合专家）在更窄通道里激活 896 个专家中的 16 个。
先给结论
这次确实开放了完整目标权重，也开放了关键训练基础设施；但没有开放“从数据到 K3 Checkpoint”的端到端复现工程。MoonEP 是专家并行组件，AgentENV 是 Agentic RL 沙箱，二者都不能单独复现 K3 的预训练。
2.78T技术报告精确总参数
104.2B每 Token 激活参数
69 + 24KDA / Gated MLA 层
896 → 16路由专家 / Token
1,048,576最大上下文 Token
1.56086 TB权重索引 Payload
模型卡把前两项四舍五入为 2.8T / 104B；本页架构表优先保留技术报告 Table 1 的精确口径。
四份开放制品，不等于一套完整训练栈
K3 在 2026-07-16 首次发布，官方当时承诺完整权重最迟于 07-27 放出；这次“开放权重”和“开放训练 Infra”都是真的，但要把对象说准确：K3 目标模型、MoonEP、AgentENV、FlashKDA 分别解决权重交付、专家并行、环境执行和 KDA Kernel。训练数据、完整训练框架、集群拓扑、总 Token 与总算力并没有一并公开。
MoonEP
MIT动态复制少量热门专家，使每个 Expert Parallel Rank 恰好接收 S × K 个 Token，并开放 Planner、Dispatch、Combine、Prefetch 与梯度归并。
AgentENV
MIT基于 Firecracker microVM 的分布式沙箱平台，开放 Pause / Resume、Fork、Snapshot、OverlayBD、ublk、CLI、API 与集群部署。
FlashKDA / FLA
代码仓库训练与 Prefill 的 Chunkwise Kernel、设备内上下文并行和跨设备 KDA Context Parallelism 均给出公开实现入口。
- 完整后训练目标权重与推理所需 Python 代码
- MoonEP 通信与在线规划实现、测试和 Benchmark
- AgentENV 的 Rust / Go 服务、CLI、API、Docker 与 Kubernetes 部署
- KDA Kernel、公开技术报告与框架 Day-0 Recipe
- Web / Code / Math / Vision 训练语料与精确混合比例
- 总预训练 Token、GPU 数、训练时长和完整成本
- 把 PP / VP / EP / ZeRO / CP / Offload 全部接好的主训练仓库
- 九个 RL 教师、奖励模型和所有私有环境任务
白话理解
像一支 F1 车队公开了整车、变速箱模块和维修车间软件，也写了工程报告；但没有交出赛季全部遥测、供应链、风洞数据和总装流水线。你能部署、研究和改造 K3，却不能按公开材料原样重训一遍 K3。
93 层，不再是 93 次相同的 Transformer Block
K3 把层按 3:1 组成 Hybrid Attention（混合注意力）：三层 KDA 用固定尺寸递归状态快速推进，一层 Gated Multi-head Latent Attention（门控多头潜变量注意力，Gated MLA）做全局内容检索。23 组之后再补一层 Gated MLA，最终得到 69 KDA + 24 MLA。
文本或视觉 Token
文本查 163,840 位置的 Embedding；图像和视频由 MoonViT-V2 与 Projector 映射到 7,168 维共享空间。
3 KDA + 1 MLA
KDA 把前缀浓缩成状态，MLA 周期性保留对任意历史 Token 的全局内容访问。
896 选 16 + 2
16 个路由专家在 3,584 维潜空间工作；2 个共享专家保持完整 7,168 维公共路径。
Block AttnRes
每层不只吃上层输出，还按 learned pseudo-query 从 Embedding 和更早 Block 中加权取回表示。
层数931 Dense + 92 MoE
Hidden7,168与 K2 相同
Attention Heads96Head dim = 128
Latent MoE3,584主宽度的一半
Expert Hidden3,072每个路由专家
Dense Layer1后 92 层均为 MoE
≈ 2.5×
发布方 Scaling-Law 口径
这是 K3 家族相对 K2 的验证 Loss—训练 FLOPs 拟合曲线水平位移，综合了架构、数据和训练 Recipe；不是推理快 2.5×，也不是只由 KDA 或 MoE 单项贡献。报告没有给原始点、置信区间或可独立复算数据。
百万上下文的关键，不是让所有层都保存百万份 KV
KDA 用递归状态 S承载前缀，状态尺寸与序列长度无关；MLA 仍为每个历史 Token 保存压缩后的 latent KV。于是 K3 的长上下文成本介于“全量 Softmax Attention”和“纯固定状态线性注意力”之间。
KDA 单头递归
Sₜ = (I − βₜkₜkₜᵀ) Diag(αₜ) Sₜ₋₁ + βₜkₜvₜᵀ α 是按通道遗忘多少，β 是本 Token 写入多强；Query 读取更新后的 Sₜ。它不是普通“加权平均”，而是先按通道衰减旧状态，再用 Delta Rule 修正和写入。
g ∈ (-5, 0)
16-Token Tile 内的累计缩放被限制在 BF16 动态范围，使对角 Tile 也能走 Tensor Core Dense Matmul。
按 Token 控输出通道
KDA 和 MLA 都用输入相关的完整投影门控输出，不再沿用 Kimi Linear 的低秩输出门。
没有显式位置编码
位置和近因性主要由 KDA 的递归门与衰减形成；从 64K 延伸到 1M 不需要重调 RoPE 或 YaRN。
传固定状态片段
每个 Rank 计算局部累计变换和从零生成的状态，通过一次 All-Gather 后做前缀组合，而不是交换随长度增长的 KV。
能力边界：NoPE 能避免位置编码插值，不代表模型天然无损外推到无限长度。K3 仍用 8K → 64K → 256K → 1M 的训练课程，并专门合成长距离依赖数据。
一个解决“层太深”，一个解决“专家太宽”
标准残差把所有旧层信息不断加进一个向量，像把 93 份会议纪要压成一页摘要。AttnRes 让当前层按需翻阅更早的 Block；LatentMoE 则先把 Token 从 7,168 维降到 3,584 维，再把它分派给 16 个专科。
8 个层块：前 7 个各 12 层，末块 9 层
技术报告把 Embedding 也作为永远可读的来源，因此处于末块时最多读取 Embedding、7 个已完成 Block 表示和当前 Block 的局部和，共 9 个来源；最终输出再聚合全部 8 个 Block。算术不大，真正成本是保存与搬运表示。
896 ÷ 16 = 56 倍路由稀疏度
Routed Path 在潜空间工作，Shared Path 保持完整宽度。RMSNorm 稳定潜空间聚合；SiTU-GLU（Sigmoid Tanh Unit GLU）用 β₁=4、β₂=25 的软上限控制乘法分支；Quantile Balancing 通过全局 Margin 直方图估计每个专家的目标分位数。
再深一层：Quantile Balancing 为什么比固定步长 Bias 更适合 896 个专家？
传统无辅助损失做法只看某专家比平均负载多还是少，再按固定步长调 Bias；步长小就反应慢，步长大又会振荡。Quantile Balancing 先为每个 Token 取 Top-(k+1) 的 Cutoff，再找使专家刚好接近目标负载 q = m·k/n 的 Margin 分位数。
全局 Batch 可能有数百万 Margin，无法逐个 Gather。K3 对每个专家累计直方图，All-Reduce 的只是几百个 Bin Count；推理时冻结最终 Bias。它平衡的是 Dispatch 选择，不直接改用于加权合并的 Router Probability。
MoonViT-V2 从零开始，与语言主干一起做 Next-Token Prediction
K2.5 的视觉塔从 SigLIP 初始化；K3 改为 27 层、约 401M 参数的 MoonViT-V2，从训练第一天就让文本、图片和视频共享下一 Token 目标。发布方的消融显示它与 SigLIP 初始化基线的视觉成绩相当，但梯度更低、更少 Spike。
不是“先训语言，再接一个眼睛”
- Hidden 1,024、27 层、12 Heads、Patch Size 14
- RMSNorm；线性层与 Attention Projection 去 Bias
- 图片与视频完全共享参数，空间 / 时间 Attention 分解
- 2 × 2 Pixel Shuffle 把视觉 Token 数缩到 1 / 4
- 公开报告支持最高 3,584 × 3,584 像素输入
ImageSpatial patches
+ VideoSpatial + temporal
→ MoonViT-V2共享 401M
→ Projector7,168 维
模态口径存在表格差异：技术报告和 Kimi API 明确支持文本、图片、视频；Hugging Face 模型卡摘要表目前只列 Text / Image，Pipeline 也标为 image-text-to-text。自部署视频要按 Processor、采样策略与具体引擎做端到端验证，不能只看“原生多模态”四个字。
公开了训练方法，没有公开完整训练账
K3 从一开始联合优化文本和视觉。文本覆盖 Web、Code、Mathematics、Knowledge；视觉覆盖 Caption、交错图文、OCR、Perception、Video 和 Visual Coding。长上下文数据还要去重、过滤二进制与无效日志，并合成只有跨越整段 1M 上下文才能解出的任务。
Per-Head Muon + Weight Clip
Q / K / V 的动量矩阵按 Head 分块做 Newton–Schulz Orthogonalization，减少大 Head 主导完整矩阵更新；学习率用 Cosine，1% Linear Warmup，Weight Decay 0.1。
8K → 64K → 256K → 1M
把高成本长序列集中在少量后段预算；NoPE 免去位置插值，但模型仍靠真实长文档、长视频和跨段合成任务学会使用远处证据。
同一 NTP 目标
视觉和文本 Token 在同一序列里联合优化；程序生成 SVG、3D、网页、游戏与 CAD，再把 Code 和 Rendered Visual 配对。
报告中的 3T 级预训练组合
Pipeline Parallelism（流水线并行，PP）+ Virtual Pipeline（虚拟流水阶段，VP）+ Expert Parallelism（专家并行，EP）+ ZeRO-1 + Pipeline ZeRO-2 + Context Parallelism（上下文并行，CP）。大部分 Activation 做 Block-wise FP8，再按 Tensor 粒度组合重算、本机 / 远端 Offload；Muon 只点对点取本 Rank 负责参数的完整矩阵；大图和长视频按 Patch 动态 CP，并把大部分 ViT 计算塞进 Pipeline Bubble。
报告未披露 总预训练 TokenGPU 型号与数量训练时长总 FLOPs精确数据混合完整 Loss Curve
先训练九位专家老师，再蒸馏回一个模型
SFT（Supervised Fine-Tuning，监督微调）先建立工具和长轨迹冷启动；RL 分成 General、General Agents、Coding Agents 三个领域，每个领域再训练 low / high / max 三种推理预算，共九位教师。最后用 MOPD（Multi-Teacher On-Policy Distillation，多教师在策略蒸馏）合并。
完成一部分就更新
每题采 K 条轨迹；达到 λ 比例完成后暂停剩余 Long-tail Rollout，先做 Policy Update，下一迭代优先恢复。每条超长轨迹因此可跨越多个训练迭代。
按题控制预算
以冷启动模型估算每题初始预算，超出 τ · b₀(x) 就把奖励改为 -1；Agent 任务计 Thinking 与 Tool Arguments 的累计输出，而不只数答案长度。
读结果、写 Rubric、逐项打分
非可验证任务由 Generative Reward Model 做 Tournament Comparison，并用长度预算抑制“越啰嗦越高分”的 Reward Hacking。
把九套 Policy 合并
学生按采样到的领域和 Effort 读取对应教师的逐 Token On-Policy Dense Reward；报告称更细的 Top-k Distillation 没带来明确收益。
部署从 SFT 就进入训练合同
路由专家从 SFT 到 RL 全程以 MXFP4 Weight / MXFP8 Activation 做 Quantization-Aware Training（量化感知训练，QAT）；Rollout 与训练使用同一量化方案，避免“训练是高精度、采样是低精度”的 Policy Mismatch。Attention、Shared Expert、Router、Latent Projection、Vision 与 LM Head 仍保持更高精度。
MTP 训练1 Layer
→ 预训练阶段附一层 Multi-Token Prediction（多 Token 预测，MTP），结构与 Backbone Block 对齐。
Draft 微调EAGLE-3 Style
≠ 冻结 Target，只更新 Draft Layer 与多层 Feature Fusion；训练展开 7 步并直接优化接受率损失。
HF 主权重Draft 不在内
公开 Config 的 num_nextn_predict_layers=0，权重索引也没有 MTP / Draft Tensor；Day-0 另用独立 DSpark 权重。
真正难的不是平均负载，而是让每个 Rank 每一步都一样多
Router 即使在全局上平衡，某个 Micro-batch 里也可能把大量 Token 发给少数热门专家。传统 EP 的最热 Rank 决定 Step Time，动态 Shape 还会造成显存碎片。MoonEP 根据当前层、当前 Micro-batch 的路由在线规划少量冗余专家。
当前路由，当前层就规划
GPU Planner 读取本轮路由，生成专家副本布局与 Token 目的位置；仓库证明每 Rank 至多 E / R 个冗余专家槽即可保证存在完全均衡方案。解析成本模型用于后续 Expert-GEMM 调度，不是这里的均衡性证明。
直接写到远端最终位置
Planner 先算每个 Token 的目标位置，Dispatch / Combine 返回通信 Buffer View，省掉 Comm Buffer 与 User Buffer 的来回复制。
不用逐层问 GPU 到底来了多少 Token
每 Rank 固定 S × K，Group GEMM Shape 预先已知，消除逐层 Host Synchronization，并避免动态 Activation Shape 碎片。
复制专家的梯度归回 Home Rank
冗余槽用独立 Reduce Buffer，反向后通过 NVLink Remote Read 聚合到所有者参数梯度，再清空临时槽。
Benchmark 与硬件边界：MoonEP 仓库的公开图是在 H20、EP=8、扫描 Router Imbalance 下与 DeepEP v2 对比；它证明该实现对负载倾斜更稳，不等于 K3 全训练吞吐、所有 GPU / 网络拓扑或所有 Shape 都获得同样倍率。仓库当前列出的可用设备是 NVIDIA GPU，Zhenwu PPU 仍在评审中；测试环境要求多卡与 NVLink。
白话理解
普通做法像把顾客送到固定分店：热门店排长队，冷门店闲着。MoonEP 会临时把热门厨师和食材复制到空闲分店，再把顾客直接送到最终餐桌；结账时，把临时分店学到的更新汇总回原店。复制的是专家执行位置，不是多训练一套独立模型。
暂停模型并不够，浏览器、文件和数据库也要原地冻结
Partial Rollout 让轨迹跨迭代；但如果只保留对话和 KV，Agent 重新回来时，文件系统、应用状态与 Tool Side Effect 已经丢了。AgentENV 用 Firecracker microVM 保存环境的内存与磁盘增量，和模型侧状态一起恢复。
Agent 等模型推理时，报告称可占 Sandbox 生命周期最多 98%；暂停后释放 CPU 与内存，下一轮再恢复。
从完全相同状态复制独立 Sandbox，可让 Reward Judge 检查结果而不污染原轨迹，也能并行探索后续分支。
只保存上次以后变脏的 Memory Page 与文件系统变化，并持久化到 S3-Compatible Object Storage 或共享文件系统。
OverlayBD 按需拉 OCI Image，ublk 提供 I/O，Copy-on-write、共享 Page Cache 与 Memory Ballooning 提高密度。
最低 Checkpoint 133 ms、Resume 49 ms、最高 6.5× Overcommit，绑定 Moonshot 的真实训练 / 评测环境。
Snapshot-backed Boot / Resume < 50 ms、Pause < 100 ms、重磁盘修改下 Incremental Snapshot < 100 ms；操作和测试口径不同，不能互相替换。
当前开源版没有 Authorization。
仓库明确警告不要把 AgentENV API 暴露到公网，只能放在可信网络或鉴权代理后；运行还要求 Linux Kernel 6.8+、安装脚本面向 Ubuntu 24.04，并需要 /dev/kvm。
96 个分片，权重 Payload 约 1.42 TiB
HF 仓库不是“2.8T × 0.5 Byte = 1.4 TB”这么简单：只有 92 层路由专家的三组矩阵做 MXFP4 Pack，Attention、共享专家、Router、潜空间投影、视觉塔、Embedding 和 LM Head 保持更高精度，还要保存 Scale。
Weight Map497,220
索引中的 Tensor Name → Shard 映射数量。
Routed Packed247,296
92 MoE 层 × 896 Experts × W1 / W2 / W3。
Scale Tensors247,296
每个 Packed Expert Matrix 配一份 Weight Scale。
File Header≈ 72.26 MiB
96 个 Safetensors 文件大小与 Payload 的差额。
使用、修改、分发、微调与商业化
保留 Copyright 与 License Notice，并遵守法律；权重、配置、推理与训练代码都纳入同一自定义 License 定义。
12 个月合计营收超过 2,000 万美元
若 Licensee 或关联方经营模型推理 / 微调服务，且任意连续 12 个月总营收超过阈值，商业使用前须与 Moonshot 另签协议。
1 亿 MAU 或月营收 2,000 万美元
使用 K3 或衍生物的商业产品或服务超过任一阈值，UI 需显著显示 “Kimi K3”；内部使用与官方 / 认证伙伴访问有豁免。
许可判断：K3 是“开放完整权重”，不是 OSI 意义下无附加商业条件的标准 Open Source License。MoonEP 与 AgentENV 则是 MIT。以上是条款摘要，不代替你的法务审查。
目标模型太大，缓存和草稿都必须理解 KDA
K3 的 Prefix Cache 必须在同一 Token 边界同时恢复 MLA KV 和 KDA Recurrent / Convolution State。投机解码还要处理“草稿被拒绝后，KDA 状态已经往前走”的回滚问题；K3 选择缓存更小的 Projected Inputs，再在片上重放被接受的状态。
8 × B300 或 8 × MI355X
vLLM Day-0 指南给出的最容易启动路线；B300 单卡容量高于 B200，二者不能只按“8 张”横向比较。
至少 16 张
vLLM 说明 K3 在这一代硬件需要 16 张 B200 / GB200；生产通常继续扩到多节点 EP / DP 与 RDMA / NVLink。
64+ Accelerator Supernode
Moonshot 官方博客为高带宽域内的推理效率建议 64 张以上 Supernode；这是推荐拓扑，不是所有自部署的强制下限。
Target-only 参考点118 tok/sRandom 8K 输入 / 1K 输出
≠ DSpark 参考点370 tok/sSPEED Bench · single user
→ 证据边界非 A/B16 GB300，但 Workload 不同
Day-0 依赖 FlashInfer 等 Pre-release 组件；不要把普通稳定版 pip install vllm 当成完整生产路径。
K3 Hybrid Cache 仍在演进，需显式传 --enable-prefix-caching；默认值与其他模型不同。
vLLM 报告偶发 K3 输出自身 Parser 不识别的 Tool Format，得到空 tool_calls；生产需 Schema 验证、重试或 Strict Structured Calling。
多轮与 Tool Loop 必须把完整 Assistant Message 原样传回，包括 reasoning_content 和 tool_calls。
先用 API 验证任务，再决定是否建设 3T 级集群
官方模型 ID 是 kimi-k3，OpenAI-Compatible Endpoint 为 https://api.moonshot.ai/v1。K3 永远开启 Thinking，只能用顶层 reasoning_effort 在 low、high、max 之间调预算。
model = "kimi-k3" Temperature 1.0、top_p 0.95、n=1、Presence / Frequency Penalty 0 均为固定值；官方建议省略，不要把不同采样参数硬塞进去。
1M总上下文
128K默认 Max Completion
1M可设 Max Completion 上限*
256自动缓存最短前缀
* 输入、历史、Thinking、Tool Result 与输出共同占用总窗口，不是额外再送 1M 输出。
图片 + 视频
图片用 Base64 或 ms://file-id；公共图片 URL 当前不支持。视频先上传 File，再传 video_url。
Strict JSON Schema
只解析最终 message.content，不要把 reasoning_content 当 JSON 结果。
工具可在历史中途加载
完整 Tool Definition 放进 System Message；服务器不替你保存，后续请求必须继续携带。
保持长前缀字节不变
Regular Request 自动尝试缓存，无需 Cache ID；前一请求 Prompt 少于 256 Token 则不保留。
Launch Price Snapshot · 2026-07-28 · USD / 1M Token
$0.30Cache-hit Input
$3.00Cache-miss Input
$15.00Output
来源为官方发布博客；价格与缓存政策属于动态事实，上线预算前重新查 Pricing Page。
K3 很强，但发布方自己也没有说“全面第一”
技术报告明确写 K3 整体仍落后于 Claude Fable 5 与 GPT-5.6 Sol。比“看谁字体加粗”更重要的是：K3 统一用 max Effort、Temperature 1.0，但不同任务仍换 Kimi Code、Claude Code、Codex、工具、压缩策略与运行次数。
- GPQA Diamond
- 93.5单步 · top-p .95
- Terminal-Bench 2.1
- 88.3Kimi Code
- BrowseComp
- 91.2300K 触发压缩
- OSWorld-Verified
- 84.8Agent Harness
- OmniDocBench
- 91.1视觉 · 3 次均值
BrowseComp 在完整 1M、不做 Context Management 时为 90.4；它说明大窗口能直接跑，不说明压缩一定损害所有任务。
57.1
Artificial Analysis Intelligence Index v4.1，报告时 #4 / 580。
74.7%
Vals Index，报告时 #2 / 39。
1,678
WebDev Arena Elo，报告时 #1 / 99。
1,486
Text Arena Elo，报告时 #8 / 200。
同一个 K3 Target Checkpoint
max Effort 与最大生成长度
Kimi Code / Claude Code / Codex
Python、Browser、Terminal 与权限
单次、3 次均值或 Pass@5
动态榜单边界：Elo 会随新增对局漂移；Artificial Analysis、Vals 与 Arena 各自的任务分布不同。这里保留技术报告发布时的第三方快照，不把它们外推成永久排名或你的业务成功率。
它适合长程 Agent，不代表应该放开手脚替人做决定
K3 的训练强调长时间、高难度、可反复验证的任务。官方同时把“过度主动”列为限制：面对小问题或模糊意图时，它可能替用户做未授权决定。越能行动，越需要显式权限与停止条件。
长、复杂、可验证、有基础设施
- 大型代码仓库、GPU Kernel 与编译系统
- 跨网页、PDF、表格与图片的知识工作
- 需要百万上下文和视觉反馈的持续任务
- 有测试、Sandbox、Budget、Checkpoint 和审批
- 能承担多机开放权重集群的研究与私有化
短、便宜、低风险，或没有控制面
- 毫秒级分类、抽取和短改写
- 消费级单机 / 单卡部署
- 不能完整保存 Thinking History 的旧 Harness
- 没有 Schema、权限与副作用审计的工具执行
- 把 1M 窗口当成事实正确与无限记忆保证
总 Token、GPU、训练时长、FLOPs、精确数据混合与完整 Checkpoint 轨迹未公开。
MoonEP、AgentENV 和 FlashKDA 是组件，没有公开把所有并行、Offload 与数据管线接成 K3 的主训练仓库。
Day-0 依赖 Pre-release Docker；Prefix Cache 默认关闭，Tool Parser 仍有偶发边界问题。
官方承认相对最强闭源模型仍有体验差距，并提示 Thinking History 敏感与过度主动。
最终判断
K3 的真正创新不是一个 2.8T 数字，而是三条信息流和三套系统账同时闭环：KDA + MLA 管序列，AttnRes 管深度，LatentMoE 管宽度；MoonEP 管专家负载，Partial Rollout + AgentENV 管百万 Token 轨迹，Hybrid Cache + DSpark 管线上延迟。要采用它，先用 20～50 个真实长任务同时测成功率、权限事故、Token / Tool 成本和恢复率，再决定 API 还是自部署。
这篇专题的证据来自哪里
架构与训练优先使用技术报告、机器可读 Config 和权重索引；开源范围直接核对 GitHub 仓库；部署采用 vLLM / SGLang Day-0 文档；动态 API、价格与排行榜以 2026-07-28 为核查边界。
01
Kimi K3 技术报告
↗ 02架构、训练、RL、Infrastructure、评测与公开边界
Kimi K3 Hugging Face
↗ 03完整权重、模型卡、部署入口与推理用法
Kimi K3 Config
↗ 0493 层、KDA / MLA 排布、MoE、量化与视觉编码器字段
权重索引
↗ 05497,220 个 Tensor 映射与精确 Payload 字节数
Kimi K3 License
↗ 06商业服务、超大产品署名与内部使用条款
Kimi K3 官方博客
↗ 07发布日期、产品定位、案例、API 价格与限制
MoonEP
↗ 08完全均衡专家并行、零拷贝通信、H20 EP=8 Benchmark 与 MIT 代码
AgentENV
↗ 09K3 Agentic RL 沙箱、生命周期、前置条件与无鉴权警告
AgentENV 架构文档
↗ 10Gateway、Scheduler、AgentENV、存储与节点协作
FlashKDA
↗ 11KDA 训练与 Prefill Kernel
Flash Linear Attention
↗ 12KDA / DeltaNet 实现与 KCP 公开入口
Kimi Linear
↗ 13KDA 的前身、Chunkwise 表达与混合注意力
LatentMoE
↗ 14潜空间专家计算的原始机制
vLLM Day-0 Support
↗ 15硬件起点、Hybrid Cache、DSpark、性能与已知生产问题
vLLM K3 Recipe
↗ 16Docker、并行与启动参数
SGLang K3 Cookbook
↗ 17SGLang 自部署路径
Kimi K3 DSpark
↗ 18独立 Draft 权重、7-Token Block 与训练数据
Kimi K3 API Quickstart
↗ 19Thinking、视觉、工具、缓存与长度合同
Thinking Effort
↗ 20low / high / max 与历史回传
Kimi K3 Pricing
↗ 托管服务价格入口与动态能力说明
复算说明：1,560,860,324,864 bytes 来自权重索引 metadata.total_size；497,220 是 weight_map 键数；247,296 = 92 × 896 × 3，对应所有路由专家的 W1 / W2 / W3 Packed Weight，索引中有同量 Weight Scale。以上是文件与 Tensor 账，不是运行时峰值显存。