Kimi K2.5月底退役：第一代万亿参数全模态模型结束服务

月之暗面今天（2026 年 8 月 24 日）宣布，Kimi K2.5 将于本月底结束服役，平台正式下线时间为 8 月 31 日。Kimi K2.5 是月之暗面第一代万亿参数全模态模型，也是今年 1 月推出后，Kimi 在对话、代码、视觉理解和 Agent 任务上的主力版本。

这不是一次简单的模型改名，而是一次产品代际切换：K2.5 代表 Kimi 从“长文本助手”走向“通用多模态 Agent”的关键阶段；K3 则把模型规模、上下文长度和推理能力继续推向更高一档。对于普通用户，这意味着聊天入口会逐步切换到新模型；对于开发者，则意味着模型名称、上下文限制、输出行为和任务可靠性都需要重新验证。

Kimi K2.5 将在 8 月 31 日正式退出

Kimi K2.5 是一款拥有 1 万亿总参数、采用混合专家架构并原生支持文本与视觉输入的多模态模型。 根据月之暗面的公告，Kimi K2.5 本月底将结束服役，相关服务此后不再作为平台持续维护的主力模型。

K2.5 的“1 万亿参数”并不意味着每次生成都要同时计算全部参数。它采用 MoE（Mixture of Experts，混合专家）架构，即模型总参数规模很大，但每个 Token 只激活其中一部分专家。公开资料显示，Kimi K2.5 的总参数约为 1T，每个 Token 的激活参数约为 32B。简单理解，它更像是一家拥有 1 万名员工、但每个项目只调度 320 名专业人员的公司：模型容量很大，单次推理成本则由实际激活的专家数量决定。

K2.5 于 2026 年 1 月发布并开源。月之暗面当时将它定义为 Kimi 迄今最智能、最全能的模型，重点覆盖以下几类任务：

• 文本与视觉理解：支持图片、文档、页面截图等输入，不再局限于纯文本对话。
• 思考与非思考模式：简单任务可以快速回答，复杂问题则能够进入更长的推理过程。
• 代码与软件工程：面向代码生成、调试、项目理解和多文件修改等场景优化。
• Agent 任务：能够调用工具、拆解任务，并在较长流程中持续执行。
• 图像与视频理解：模型训练阶段加入视觉和视频数据，使其能够处理更接近真实世界的信息输入。

它最重要的变化，不是参数从几百亿增加到万亿，而是模型开始把“看懂内容”和“执行任务”放在同一套架构中。过去的多模态模型往往像是给语言模型外挂一个图像识别模块，K2.5 则试图让文本、图像和视频从训练阶段就进入同一个模型体系。

K2.5 为什么曾经重要

全模态模型是指能够在同一模型中原生处理文本、图像、视频等多种输入形式，并将理解结果用于对话、推理或行动的模型。 Kimi K2.5 的价值，主要体现在它把多模态能力从“识图问答”推进到了“基于视觉信息执行复杂任务”。

例如，用户不只是上传一张网页截图，让模型回答“这是什么”；还可以要求模型阅读一组产品原型图、整理页面结构、生成前端代码，再根据运行结果继续修改。对于 Agent 来说，图片和视频不是附加信息，而可能是任务状态本身：屏幕上的报错、浏览器中的按钮、工厂现场的设备状态，都需要被模型理解后转化为下一步行动。

K2.5 还引入了 Agent Swarm 思路。Agent Swarm 是一种让多个专用智能体并行分工、再由主智能体汇总结果的任务执行机制。 按公开介绍，K2.5 可以同时协调最多 100 个专用 AI Agent。它的目标不是让一个模型把所有事情从头做到尾，而是把复杂任务拆成搜索、分析、编码、验证等子任务，交给不同的“虚拟员工”并行完成。

这个设计对软件工程尤其有吸引力。一个较大的代码任务可以被拆成：一个 Agent 检查现有架构，一个 Agent 阅读相关文档，一个 Agent 编写测试，另一个 Agent 尝试实现功能，最后由主 Agent 统一合并和复核。相比单轮代码生成，这种方式更接近真实的软件开发流程。

不过，Agent Swarm 也有明显代价：任务调度、上下文同步、工具调用和结果验证都会带来额外延迟。多 Agent 并不等于能力简单相加，任何一个子 Agent 的误判，都可能在后续流程中被放大。因此，K2.5 的竞争力不只取决于模型本身会不会写代码，还取决于它能否在长流程中保持状态、正确调用工具，并在错误发生后自我修正。

从 K2.5 到 K3：月之暗面的路线已经改变

Kimi K3 是月之暗面于 2026 年 7 月开源的 2.8 万亿参数模型，原生支持视觉理解，并提供 100 万 Token 上下文窗口。 与 K2.5 相比，K3 的升级重点不再只是增加一个视觉输入接口，而是继续扩大模型容量、上下文范围和复杂推理能力。

K3 基于 KDA（Kimi Delta Attention，Kimi 增量注意力）混合线性注意力机制和 Attention Residuals（注意力残差）技术构建。传统 Transformer 的标准注意力机制在处理超长上下文时，计算和显存压力会快速增加；混合线性注意力的思路，则是让部分信息以更高效的状态形式持续传递，在长文本场景下减少对全部历史 Token 进行重复计算的需求。

100 万 Token 上下文窗口的意义，也不只是“能一次塞进更多文字”。按照中文内容的粗略换算，100 万 Token 足以覆盖大量代码仓库、数百份长文档，甚至一个中型项目的需求、设计、接口和测试资料。模型可以在更少的检索切片和更少的人工拼接下，直接理解跨文件、跨章节的关系。

但超长上下文并不自动等于超强记忆。上下文窗口解决的是“模型能不能看到”，并不保证模型一定能在百万 Token 中准确找到并使用关键信息。实际效果仍然取决于注意力分配、信息定位、推理能力和工具链设计。对于开发者来说，K3 的 1M 上下文更适合代码库分析、企业知识库、长周期研究和复杂项目管理，而不是把所有资料无差别塞进一次请求。

| 对比项 | Kimi K2.5 | Kimi K3 | |---|---:|---:| | 发布节点 | 2026 年 1 月 | 2026 年 7 月 | | 总参数规模 | 约 1 万亿 | 约 2.8 万亿 | | 架构特点 | MoE，多模态原生训练 | KDA 混合线性注意力、Attention Residuals | | 视觉能力 | 原生支持视觉与文本输入 | 原生支持视觉理解 | | 上下文窗口 | 256K Token | 100 万 Token | | 主要定位 | 通用对话、多模态、代码与 Agent | 软件工程、知识工作、深度推理与复杂 Agent | | 当前状态 | 2026 年 8 月 31 日结束服务 | Kimi 当前旗舰主线 |

从产品策略看，月之暗面正在把 Kimi 从“一个能力很强的聊天模型”改造成“覆盖知识工作和软件工程的基础智能平台”。K2.5 是这个方向的验证版本，K3 则是扩大规模后的正式版本。

对普通用户有什么影响

对普通用户而言，K2.5 退役的直接影响是：8 月 31 日之后，Kimi 产品和相关平台将不再把 K2.5 作为持续支持的模型。 用户不需要手动保存模型权重才能继续使用 Kimi，但此前针对 K2.5 调整出的提示词、工作流和回答预期，可能不会在新模型上完全复现。

如果你只是用 Kimi 进行搜索、总结、写作和日常问答，迁移成本相对较低。新模型通常会在推理、视觉理解和复杂任务上提供更强能力，旧对话也可以继续作为上下文参考。但如果你长期依赖 K2.5 的某种输出风格，例如固定格式的 JSON、特定代码模板或较短的回答长度，就需要重新测试提示词。

更值得注意的是，模型升级可能带来“能力变强但行为变化”的问题。新模型可能更倾向于展开推理、主动拆解任务或调用更多工具，也可能对边界条件和不确定信息给出不同处理方式。对于需要稳定输出的用户，不能只用一两个问题判断迁移是否成功，最好准备一组自己的测试样例。

建议至少覆盖以下场景：

1. 一组普通问答，观察回答长度、事实准确性和语气是否变化。
2. 一组图片或文档理解任务，验证表格、截图、版式和关键信息提取能力。
3. 一组代码任务，检查生成代码能否通过测试，而不是只看代码是否“像对的”。
4. 一组长文本任务，确认模型能否找到埋在文档中间的关键条件。
5. 一组多步骤任务，观察模型是否会遗漏子任务、重复执行或错误调用工具。

对开发者和 Agent 工作流的影响更大

对开发者来说，模型下线意味着一次兼容性迁移，而不只是更换模型字符串。 K2.5 的调用方需要检查模型名称是否被硬编码在应用、工作流编排器、评测脚本和部署配置中，同时确认新模型是否仍然支持原有的视觉输入格式、工具调用协议、思考模式和上下文长度。

尤其是 Agent 应用，迁移时要重点检查四个方面。

第一，工具调用格式

不同模型对工具参数的生成习惯可能不同。即使工具定义没有变化，新模型也可能更严格地遵循 JSON Schema，或者在缺少字段时采取不同策略。原本依赖模型“自己补全”的工具调用逻辑，迁移后可能直接失败。

第二，停止条件与循环控制

Agent 通常需要判断任务何时完成。如果新模型更积极地调用工具，或者在工具结果不完整时继续追问，原有的最大轮次、超时和预算控制就可能不再合适。开发者需要重新设置最大工具调用次数、单任务 Token 上限和异常退出条件。

第三，视觉输入处理

K2.5 的多模态能力可能被用于网页截图、扫描文档、流程图和 UI 自动化。迁移至 K3 后，图片分辨率、视频帧采样、图文混排顺序和视觉 Token 计算方式都值得重新验证。视觉任务不能只拿文本基准测试结果代替，必须使用真实业务样本。

第四，长上下文成本

K3 支持 100 万 Token 上下文，但这不代表所有请求都应该使用百万级上下文。更长的上下文通常意味着更高的输入成本、更长的首 Token 延迟和更复杂的上下文管理。实际工程中，结构化检索、摘要压缩和分层记忆仍然有价值。

开源模型退役，意味着什么

K2.5 的特殊之处在于，它曾经以开源模型的身份进入开发者生态。模型权重、推理框架和社区部署让开发者可以在自己的基础设施上运行或评估它。服务结束与权重消失是两件不同的事：官方托管服务可以下线，但已经公开的模型权重、社区量化版本和推理适配仍可能继续存在。

这给开发者留下了两条路线：

• 继续保留 K2.5：适合已经完成微调、提示词适配或本地部署的团队，但需要自行承担硬件、推理框架、安全更新和故障排查成本。
• 迁移到 K3 或其他新模型：适合希望获得官方持续支持、更新能力和更长上下文的团队，但需要重新做评测、成本核算和业务适配。

运行 1T 级别 MoE 模型并不轻松。完整精度部署通常需要多张高端 GPU，量化虽然能够降低显存占用，但会牺牲速度、精度或多模态能力。更现实的做法不是简单问“本地能不能跑”，而是计算每个任务的总拥有成本：模型加载占用多少显存，单用户并发是多少，首 Token 延迟能否接受，视觉编码器是否支持当前推理框架，以及升级后谁负责维护。

从这个角度看，K2.5 退役也提醒了开源模型用户：开源权重带来控制权，但不等于拥有完整产品生命周期。模型服务、文档、推理适配、漏洞修复和版本兼容，仍然需要厂商或社区持续投入。

K2.5 的退场，是快速迭代的另一面

月之暗面在一年多时间里连续推进 K2、K2.5 和 K3，从 1T 参数基础模型、思考模型，到原生多模态模型，再到 2.8T 参数和百万 Token 上下文，节奏明显快于传统软件产品的版本周期。

这种速度有好处：用户能更快获得更强的推理、代码和 Agent 能力，开发者也能接触到更激进的模型架构。但代价同样明确：模型生命周期变短，兼容性压力增加，围绕某个版本构建的工作流可能在几个月后就要迁移。

我的判断是，K2.5 退役并不代表它失败。相反，它完成了两个重要任务：一是验证了万亿参数 MoE 模型在开源和多模态方向上的可行性；二是把 Agent Swarm、视觉理解和工具调用带进了更广泛的开发者视野。问题在于，模型能力迭代已经快到“产品稳定性”追不上“模型升级速度”的阶段。

对于使用 Kimi 的团队，最稳妥的做法不是等到 8 月 31 日之后再处理，而是现在就完成一次迁移演练：冻结一批真实任务，分别用 K2.5 和 K3 跑出结果，记录准确率、延迟、Token 消耗、工具调用成功率和人工修订时间，再决定是全面切换还是保留本地版本。

Kimi K2.5 的时代即将结束，但它留下的判断标准仍然有效：一个模型是否真正有用，不只看参数规模和榜单排名，还要看它能否稳定理解真实输入、完成多步骤任务，并以可控的成本接入生产环境。对 K3 来说，接下来真正的考验，正是把纸面上的 2.8 万亿参数和 100 万 Token 上下文，转化成开发者每天都愿意依赖的生产力工具。

参考来源

1. IT之家：月之暗面第一代万亿参数多模态模型 Kimi K2.5 官宣月底结束服役 —— 2026 年 8 月 24 日报道，介绍 Kimi 官方关于 K2.5 结束服务的公告及模型背景。
2. IT之家：月之暗面 Kimi K2.5 模型发布并开源 —— 介绍 K2.5 的发布、原生多模态架构和 Agent 能力。
3. IT之家：月之暗面开源 Kimi K3 模型，2.8 万亿参数 —— 介绍 K3 的参数规模、KDA 混合线性注意力、Attention Residuals 和百万 Token 上下文窗口。
4. Hugging Face：Kimi K2.5 模型页面 —— 提供 K2.5 开源模型权重及相关模型信息，具体许可和使用说明以页面最新内容为准。