【Kimi K3开放日技术解析】模型权重、技术报告与关键Infra同步开放
文章目录Kimi K3开放日技术解析模型权重、技术报告与关键Infra同步开放一、引言二、从“模型发布”到“技术栈开放”2.1 开放日交付了什么2.2 为什么要把三层内容同时交付三、模型权重2.8T 不是唯一值得看的数字3.1 模型卡披露的完整骨架3.2 开放权重不等于无限制开源四、技术报告K3 如何同时扩展长度、深度与宽度4.1 序列长度KDA 与 Gated MLA 的 3:1 混合4.2 网络深度AttnRes 不再只依赖上一层4.3 模型宽度Stable LatentMoE 把稀疏做到 896 选 16五、关键 Infra把论文结构变成可训练、可服务的系统5.1 FlashKDA为递归注意力定制 GPU 内核5.2 KDA Context Parallelism跨卡传状态而不是传整段 KV5.3 MoonEP用动态冗余专家消除最慢那张卡5.4 百万 token Agentic RL状态管理比生成速度更难5.5 在线服务同时管理 KDA 状态与 MLA KV Cache六、横向对比K3 开放的是模型还是一套方法论七、工程实践不同团队应该如何接入八、总结Kimi K3开放日技术解析模型权重、技术报告与关键Infra同步开放一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.com2026 年 7 月中旬月之暗面先用 Kimi K3 把“3T 级开放模型”推到台前到 7 月 28 日这场发布才真正补齐最后一块拼图完整模型权重、47 页技术报告以及围绕 KDA 内核和专家并行的关键 Infra 技术同步开放。这次开放日的价值不只是让开发者多了一个可以下载的模型。一个 2.8 万亿参数、原生多模态、支持 100 万 token 上下文的 MoE 模型真正的门槛从来不只在权重而在“怎么训稳、怎么跑快、怎么把百万上下文服务化”。月之暗面这次把模型、论文和部分系统实现放在同一张桌子上外界终于可以沿着同一条证据链检查 K3 的架构选择、训练方法与工程代价。本文不再重复一遍发布会跑分而是聚焦三个问题究竟开放了什么、关键 Infra 解决了什么、普通开发者和企业应该如何看待这次开放。二、从“模型发布”到“技术栈开放”2.1 开放日交付了什么开放层级主要内容开放入口实际价值模型权重2.8T 总参数、104B 激活参数的 Kimi K3 完整权重Hugging Face、ModelScope、GitHub 模型卡可研究、微调、私有部署和构建衍生模型技术报告47 页《Kimi K3: Open Frontier Intelligence》Kimi K3 官方 GitHub 仓库披露架构、预训练、后训练、Infra、评测与案例KDA 内核FlashKDA高性能 Kimi Delta Attention 内核MoonshotAI/FlashKDA让 KDA 的训练与长上下文 prefill 真正跑在 GPU 上专家并行MoonEP基于动态冗余专家的均衡通信库MoonshotAI/MoonEP解决超稀疏 MoE 的跨卡负载倾斜、动态形状与复制开销Agent 沙箱AgentENV面向长程智能体任务的可恢复 microVM 沙箱kvcache-ai/AgentENV支撑百万 token 轨迹中的暂停、恢复、分叉和快照部署适配vLLM、SGLang、TokenSpeed 的部署入口与配方各推理框架官方文档降低从权重到服务的接入成本这里有一个必须厘清的边界“关键 Infra 技术开放”不等于 K3 的整套训练平台全部开源。FlashKDA、MoonEP 和 AgentENV 有公开代码KDA Context Parallelism、统一激活管理、KDA 感知前缀缓存、集群调度等更多系统能力主要通过技术报告披露设计与实现细节。代码开放和设计公开是两个层级不能混为一谈。2.2 为什么要把三层内容同时交付只有权重社区能运行模型却很难知道模型为什么有效只有论文研究者能理解方法却无法验证真实权重只有 Infra工程团队能复用组件却无法观察它们在 3T 级模型中的整体效果。K3 开放日把三者拼在了一起┌──────────────────────────────────────────────────────────┐ │ Kimi K3 开放技术栈 │ ├──────────────────────────────────────────────────────────┤ │ 模型层2.8T MoE · 104B 激活 · 原生多模态 · 1M Context │ ├──────────────────────────────────────────────────────────┤ │ 方法层KDA · Gated MLA · AttnRes · Stable LatentMoE │ ├──────────────────────────────────────────────────────────┤ │ 系统层FlashKDA · MoonEP · AgentENV · Prefix Cache │ ├──────────────────────────────────────────────────────────┤ │ 部署层vLLM · SGLang · TokenSpeed · Kimi API │ └──────────────────────────────────────────────────────────┘这意味着社区第一次可以围绕 K3 做相对完整的纵向追踪从公式、权重到 GPU 内核再到推理框架和生产服务而不是只对着一张排行榜猜测模型内部发生了什么。三、模型权重2.8T 不是唯一值得看的数字3.1 模型卡披露的完整骨架维度Kimi K3 官方配置工程含义总参数量2.8T进入 3T 级开放权重模型区间单 token 激活参数104BMoE 将单次计算控制在总参数的一小部分网络层数93 层其中 1 个稠密层主体由稀疏专家层构成注意力组成69 层 KDA 24 层 Gated MLA以 3:1 比例混合线性注意力与全局注意力专家配置896 个路由专家每 token 选 16 个另有 2 个共享专家极端稀疏带来容量也放大负载均衡难题上下文长度1,048,576 token面向长代码库、研究和长程 Agent 轨迹视觉编码器MoonViT-V2401M 参数文本与图像进入同一模型主干量化MXFP4 权重 / MXFP8 激活后训练阶段即引入量化感知训练量化不是发布后压缩补丁而是训练方案的一部分Hugging Face 官方仓库将权重拆成96 个 Safetensors 分片模型仓库占用约1.56 TB。这组数字说明一个现实K3 虽然是开放权重模型却不是“下载到一张消费级显卡就能跑”的本地模型。官方建议在64 个或更多加速器组成的超节点上部署绝大多数个人开发者更适合使用 API权重开放的直接受益者首先是云厂商、大型企业和具备集群条件的研究机构。3.2 开放权重不等于无限制开源K3 采用自定义的Kimi K3 License允许使用、复制、修改、分发、部署、微调和创建衍生作品但包含两类重要商业条件场景许可证要求Model as a Service 业务主体及关联方连续 12 个月总收入超过 2000 万美元商业使用前需与月之暗面另行签署协议商业产品月活超过 1 亿或月收入超过 2000 万美元产品界面需显著展示“Kimi K3”内部使用或通过月之暗面官方产品及认证推理伙伴使用上述两项附加要求不适用因此更准确的说法是K3 是开放权重模型并配套高度开放但非标准宽松许可证。对研究、内部部署和大多数中小团队它给出的使用空间很大对大型 MaaS 平台和超级应用法务评估不能省略。四、技术报告K3 如何同时扩展长度、深度与宽度47 页技术报告把 K3 的主线概括得很清楚模型不只扩大参数量而是沿序列长度、网络深度和模型宽度三个方向同时改造信息流。4.1 序列长度KDA 与 Gated MLA 的 3:1 混合每个主干块由3 层 Kimi Delta AttentionKDA和 1 层 Gated MLA组成。KDA 用固定大小的递归状态替代随序列增长的完整 KV Cache负责高效处理长序列周期性插入的 Gated MLA 保留全局 token 交互能力弥补纯线性注意力在精确检索上的短板。这不是“线性注意力完全替代标准注意力”而是一种务实的混合路线让 KDA 承担大部分长序列计算让 MLA 定期做全局校准。4.2 网络深度AttnRes 不再只依赖上一层传统残差连接把前面所有层的信息不断压进当前隐藏状态网络越深信息越容易在逐层累积中被稀释。Attention ResidualsAttnRes让当前层可以选择性读取嵌入和前序块的表示相当于把“沿 token 的注意力”扩展成“沿网络深度的注意力”。K3 使用 Block AttnRes将 93 层划分为块级表示在保留跨层选择能力的同时把存储与通信成本从逐层规模压缩到逐块规模。4.3 模型宽度Stable LatentMoE 把稀疏做到 896 选 16K3 的 896 个路由专家并不是简单堆数量。Stable LatentMoE 先把完整隐藏表示投影到更窄的 latent space再交给路由专家处理从而降低专家通信和权重访存压力同时用三项机制稳定极端稀疏训练机制解决的问题RMSNorm抑制路由分支在上投影前的尺度波动SiTU-GLU对大激活做平滑封顶降低低精度训练中的溢出风险Quantile Balancing直接根据路由分数分位数调整专家偏置减少手工平衡超参数配合 Per-Head Muon、训练数据与后训练方案官方报告称 K3 相比 Kimi K2 获得约2.5 倍总体 Scaling Efficiency 提升。这里的 2.5 倍是架构、训练与数据共同作用的整体指标不应简化成“FlashKDA 单项加速 2.5 倍”。五、关键 Infra把论文结构变成可训练、可服务的系统5.1 FlashKDA为递归注意力定制 GPU 内核KDA 的固定状态节省了超长序列的缓存却带来新的矛盾状态更新有串行依赖而 GPU 最擅长大规模并行。FlashKDA 使用 CUTLASS 编写专用 chunkwise 内核把 chunk 内并行计算与跨 chunk 状态传播重叠起来覆盖训练和推理 prefill并可作为flash-linear-attention的自动分发后端。公开版本当前要求SM90 及以上 GPU、CUDA 12.9 及以上、PyTorch 2.4 及以上。这说明它面向的是 Hopper 及更新架构的生产级环境而不是通用消费卡兼容层。5.2 KDA Context Parallelism跨卡传状态而不是传整段 KVSoftmax Attention 做上下文并行时需要跨卡交换随序列长度增长的 KV 块KDA 的上下文由固定大小状态表示因此 KDA Context ParallelismKCP可以让每张卡先计算本地片段的状态转移再通过固定大小的 All-Gather 和前缀扫描恢复各段初始状态。它的关键收益是通信量不随上下文 token 数同步膨胀计算可以随设备数近线性扩展。对 100 万 token 上下文这不是局部优化而是架构能否跨设备落地的前提。5.3 MoonEP用动态冗余专家消除最慢那张卡MoE 训练的常见瓶颈不是总计算量而是路由不均部分 GPU 收到大量热门专家 token其他 GPU 等待整步训练速度由最慢的 rank 决定。MoonEP 在当前 micro-batch 和当前层上在线规划少量冗余专家使每个 rank 都恰好接收S × K个 token。MoonEP 设计带来的变化动态冗余专家将热门专家临时复制到空闲 rank消除跨卡负载差异GPU 在线规划规划开销接近可忽略同时保证存在可行方案Zero-copy permute/unpermutetoken 直接进入远端按专家分组的目标位置减少中间复制静态 Shape每层计算形状预先确定去掉逐层 host 同步工作量感知 GEMM 调度rank 内部仍有专家冷热差异时继续优化 SM 排程MoonEP 以 MIT License 发布并明确致谢 DeepEP、ECHO、UltraEP 和阿里 AcclEP。这也说明国产大模型 Infra 已经形成一条互相借鉴、快速迭代的开源链路而不是各家公司完全封闭地重复造轮子。5.4 百万 token Agentic RL状态管理比生成速度更难长程 Agent 强化学习可能包含数百到数千次工具调用。模型推理、KV Cache、沙箱文件系统和任务进度必须跨训练迭代存活否则每次中断都要从头重放。K3 的方案包括 partial rollout、外部 KV Cache 保留、自适应限流以及可恢复的 microVM 沙箱。AgentENV 基于 Firecracker支持 Pause/Resume、Fork 和 Snapshot。报告披露增量检查点与恢复延迟最低分别达到133 ms 和 49 msK3 训练与评测期间累计创建51,219,741 个沙箱、覆盖 1,505,678 个镜像。这组数字揭示了 Agent 训练的新现实大模型公司的核心 Infra 已从“管理 GPU”扩展到“同时管理数以万计的长期软件环境”。5.5 在线服务同时管理 KDA 状态与 MLA KV CacheK3 的混合注意力会产生两种完全不同的缓存KDA 是每个请求一份固定大小递归状态MLA KV Cache 则随 token 增长。官方将两者装进统一分页池并把前缀哈希粒度与物理块粒度解耦使请求可在细至512 token的边界复用前缀。在集群层系统再用缓存亲和调度把会话送回持有其前缀缓存的集群并通过预算式准入控制隔离短请求与百万 token 长请求。官方 API 披露编码工作负载的缓存命中率超过 90%。这套设计说明 K3 的成本优势不能只归因于 MoE 稀疏激活缓存、调度与请求分级同样决定最终 token 价格。六、横向对比K3 开放的是模型还是一套方法论维度Kimi K3DeepSeek 系列Qwen 系列GPT / Claude 闭源旗舰权重2.8T 完整权重自定义 K3 License多代 MoE/推理模型开放权重多尺寸、多模态权重常见 Apache 2.0 或系列许可证不开放技术报告47 页覆盖架构、训练、RL、Infra 与服务论文与技术报告较完整模型卡、论文和技术博客持续更新主要是系统卡与产品说明关键 InfraFlashKDA、MoonEP、AgentENV另披露缓存与调度设计DeepEP、FlashMLA 等形成成熟工程影响力深度适配 vLLM、SGLang 与阿里云生态内部 Infra 不公开路线重点3T 级规模 混合线性注意力 百万 token Agent训练和推理效率、低成本 MoE尺寸覆盖、开发者生态与广泛部署用封闭全栈维持能力和产品体验领先主要门槛约 1.56 TB 权重集群部署要求高旗舰模型仍需专业集群更容易找到适合本地部署的中小版本只能通过 API数据与成本受供应商控制K3 的做法并非凭空出现。DeepSeek 已经证明公开 DeepEP、FlashMLA 这类底层组件可以让一次模型发布产生超出权重本身的行业影响Qwen 则证明多尺寸权重与主流推理框架深度适配能快速形成开发者规模。K3 的差异在于把 3T 级模型、百万上下文 Agent 和配套系统设计集中到同一个开放日展示。它的短板也同样清晰没有中小版本承接普通本地用户完整部署门槛远高于多数开放模型许可证也不是 Apache 2.0 或 MIT 式的无附加商业条件。因而 K3 更像一套面向研究机构、云厂商和大型企业的“开放前沿样板”而不是一款人人都能本地运行的普惠模型。七、工程实践不同团队应该如何接入团队类型推荐路径不建议做的事个人开发者先用 Kimi API、Kimi Code 或聚合平台验证任务效果为体验模型直接下载 1.56 TB 权重Agent 应用团队按 OpenAI/Anthropic 兼容 API 接入保留完整reasoning_content与工具调用历史多轮调用时只回传最终content丢失保留思考历史Infra 研究者单独研究 FlashKDA、MoonEP并与 FLA、DeepEP 对照测试把论文总体 2.5 倍效率提升当作单个内核跑分有集群的企业用 vLLM、SGLang 或 TokenSpeed 官方配方做容量评估忽略权重常驻、专家并行通信和缓存命中率只按 104B 激活参数估算资源MaaS 与超级应用部署前审查 Kimi K3 License 的收入阈值与署名要求将“开放权重”理解为无条件商业许可对多数团队合理顺序是先用 API 验证 K3 在长程编程、知识工作和多模态 Agent 上的增益再决定是否值得承担私有部署成本。真正需要研究完整权重的团队则应把计算节点、权重存储、高带宽互联、推理引擎和缓存策略视作一个整体而不是只准备足够多的显存。八、总结维度核心要点权重开放2.8T 总参数、104B 激活参数96 个 Safetensors 分片仓库约 1.56 TB报告开放47 页技术报告完整覆盖架构、预训练、后训练、Infra、评测与案例架构主线KDA Gated MLA 处理长度AttnRes 扩展深度Stable LatentMoE 扩展宽度Infra 主线FlashKDA 解决内核效率MoonEP 解决专家并行AgentENV 支撑长程 Agent 状态开放边界部分 Infra 有代码部分以报告披露权重采用带商业条件的自定义许可证现实门槛官方建议 64 个以上加速器的超节点API 仍是多数开发者的首选行业意义开放竞争从“放一个权重文件”升级为模型、报告、内核与部署协同开放纵向看从 Kimi 的长上下文、K2 的万亿参数 MoE到 K3 的 3T 级模型与百万 token Agent月之暗面的技术主线始终围绕“让模型处理更长、更复杂的任务”展开。横向看K3 正在接续 DeepSeek 开创的全栈开放竞争真正能改变行业的不只是模型能力而是能否把支撑能力的论文、内核、通信库和部署方法一起交给社区。Kimi K3 开放日最值得记住的因此不是“2.8T 权重终于能下载了”而是一个更具体的信号前沿模型的开放标准正在提高。下一轮竞争社区会追问的不再只是“权重在哪里”还会追问“报告是否讲清楚、Infra 是否跑得起来、许可证是否真的允许我使用”。K3 已经给出了相当完整的答案但它也坦率暴露了 3T 级开放模型的现实——开放降低了知识门槛却没有消除算力门槛。参考资料Kimi K3 官方模型仓库 — MoonshotAI / GitHubKimi K3: Open Frontier Intelligence 技术报告 — MoonshotAI, 2026-07-28Kimi K3 模型权重与模型卡 — MoonshotAI / Hugging FaceKimi K3 Tech Blog: Open Frontier Intelligence — KimiFlashKDA高性能 Kimi Delta Attention 内核 — MoonshotAI / GitHubMoonEP基于动态冗余专家的均衡专家并行库 — MoonshotAI / GitHubAgentENV面向 Agentic AI 的 microVM 沙箱 — kvcache-ai / GitHubKimi K3 vLLM 部署配方 — vLLM RecipesKimi K3 SGLang 部署指南 — SGLang Documentation