Kimi K3 正式发布：参数干到了2.8T，国产开源模型再上新台阶，最新鲜自测来了

用户11563501

发布于 2026-07-17 21:33:40

360

上周还在群里刷到有人猜"Kimi 下一个模型会不会破万亿"，没想到 K3 直接把参数干到了 2.8T，它将国产开源模型又带到了一个新高度。

外媒惊呼，过去中国模型落后6个月的说法已经结束。

最后一次顶尖开源模型？

这次发布的 Kimi K3 总参数 2.8T，原生支持视觉理解，1M Token 上下文窗口。过去12个月里有9个月，Kimi 系列模型都保持着开源模型尺寸的上限，K2 是中国第一个交付出万亿尺寸的开源模型，K2.5 是中国第一个开源全模态模型，K3 这次把开源模型的尺寸上限，推到了全球范围内都屈指可数的位置，放眼全球，能做到 1T 以上、且真正有竞争力的模型，目前也不过寥寥几家。

如果做横向参考，目前值得放在一起比的应该是 K3、Fable 5、Opus 4.8、Sol、Grok 4.5、GPT-5.5、GLM 5.2 这几家。

Kimi K3 在 DeepSWE、FrontierSWE、Terminal Bench 2.1、Program Bench、SWE Marathon 等编程基准，以及 GDPval-AA v2、Automation Bench、JobBench、SpreadsheetBench 2、BrowseComp 等 Agent 基准中达到开源模型 SOTA，整体性能超过 Claude Opus 4.8、GPT-5.5 ，但仍落后于 Claude Fable 5 和 GPT-5.6 Sol；在部分工程任务中接近 Fable 5，并超过 GPT-5.6 Sol。

价格上，国产模型仍旧实惠，命中cache情况下每百万token仅2元，未命中条件下20元，输出价格为 100 元。官方称编程场景缓存率超过 90%。与之对标，Claude Opus 4.8的加强高达25美元。

为什么"更大"没那么简单

把参数堆到 2.8T 这个量级，难点从来不是”堆”，而是堆完了还能跑得动、跑得稳，让"更大"真正转化成开发者能用上的能力，而不应是一个只能刷榜的巨兽。K3 换了一套底层架构，官方正式名称是 Kimi Delta Attention（KDA），搭配 Attention Residuals（AttnRes，注意力残差），这两个架构改动一起解决”信息怎么在超长序列和更深的模型层数之间流动”这个问题。

配合架构改动，K3 还把 MoE 稀疏度做得更激进：896个专家里只激活16个，搭配一套叫 Stable LatentMoE 的框架。目的是让模型在复杂推理、多轮对话、长上下文任务里更稳，不容易聊着聊着就跑偏。通过这一整套架构+训练配方的改动，相比 K2 带来了大约 2.5倍的整体scaling效率提升。也就是说，同样的算力，K3 能换来更多的智能，而不是简单地把模型body撑大。

惊艳的效果

这一系列的创新带来的是惊艳的效果。

用 K3 改进 K3 自己的模型架构。 基于 Attention Residuals 的实现代码和历史实验记录，K3 能分析性能瓶颈、提出优化方向、修改代码并运行对比实验；实验失败后，还能检查日志和 profiling 结果，继续调整方向。这不是"帮人写代码"的层面，而是开始参与真实的 AI 研究流程，协同代码、系统和实验，推进模型架构本身的迭代。

科学研究场景的复现能力。 包括在广义相对论框架下复现致密星的 I-Love-Q 普适关系、GWTC-5 引力波数据分析、脉冲星计时与种群分析。这几个案例说明 K3 的能力已经不只停留在"写业务代码"，在需要严谨数理推导和数据处理的科研场景里同样能用。

此外网络上还放出了一批 3D/游戏向的案例，比如从零构建接近 3A 品质的游戏 demo，视觉效果不错。

真实体感

笔者第一时间体验，拿前两天自进化智能体的例子（Andrej Karpathy：AI写代码，只需要问自己这一个问题）做了验证，一方面算力充足没人抢，另一方面，这样的Case更能够说明一个模型的综合能力。

问题是这样的，我让KIMI学习上篇文章，构造提示词，为我生成一个自动化技能挖掘系统，让他自己不断从GitHub学习相关文本生成视频的项目，持续学习，沉淀优化SKILL。正好这也是loop工程的很好示例，它为我生成的Prompt是这样的：

/goal "构建一个名为 Skill Miner 的自动化技能挖掘系统，用于持续发现、提炼、并沉淀'输入一个链接，自动生成一支完整短视频'相关的可复用AI工作流，最终验证这套技能是否真的能产出可用的视频。

═══════════════════════════════════
【第一部分：前置配置】
═══════════════════════════════════

目标领域：只关注'输入一个URL/链接，自动生成一支完整短视频'相关的开源项目与工作流，
具体包括但不限于：网页/文章内容抓取与提炼、脚本/分镜生成、TTS配音、字幕动画、
素材/转场自动匹配、背景音乐适配、竖屏短视频渲染与合成的开源仓库

挖掘目的：沉淀一套'一个链接 → 一支利于传播的短视频'的完整技能包，
补充到我自己的 skills 目录，之后拿真实文章/链接直接调用生成短视频

验证方式：技能包挖出来后，实际用它处理以下3个不同类型的真实链接，生成3支视频，
并对每支视频做独立质量评分，判断是否比手动/零散调用方式更省事、产出是否可直接使用：
1. https://mp.weixin.qq.com/s/yEWfTLs9W3-QblvPbrGUPQ
2. https://mp.weixin.qq.com/s/TI1PhbO1xm455-WEOBGi2Q
3. https://mp.weixin.qq.com/s/Nra1BerW5kSDZEipJcS6ow

你自己维护的技能库仓库路径：[待补]

═══════════════════════════════════
【第二部分：技能挖掘流水线，共8个独立阶段】
═══════════════════════════════════
每个阶段只做一件事，输出结构化JSON传给下一阶段。

1. Scout：按【目标领域】监控 GitHub Trending 和关键词搜索
   （如 'text-to-video' 'article to video' 'auto video generation' 'content to reels' 等）
   - 搜索条件：stars > 100，最近3个月有更新
   - 只输出候选仓库列表（name/stars/language/last_updated），不做判断

2. Filter：用确定性规则（非LLM）过滤掉明显不符合'链接生成视频'领域的仓库
   （如纯视频剪辑工具但不涉及内容提炼、纯TTS库但不涉及完整流程）
   - 输出 KEEP/REJECT + 理由

3. Reader：按 README → docs/ → examples/ → 源码 的顺序增量读取
   - 前面信息足够时不再往下走，记录 context_loaded 和是否读了源码

4. Workflow Extractor：从上下文中提炼'链接→视频'相关的可复用工作流，标准化为
   {skill_name, goal, inputs, steps, outputs, failure_modes} 结构，
   并标注这个技能对应链路里的哪一步（内容提炼/脚本生成/配音/字幕/转场/合成）
   - 不符合领域或提炼不出来的直接淘汰

5. Skill Score：用固定规则（非LLM）打分，检查项至少包括：
   有README依据、有示例、步骤数达标、可复用、非仓库专属逻辑、
   确实能拼进'链接→视频'完整链路；任一必选项不过直接拒绝

6. Skill Generator：转成标准化技能包，目录结构：
   skill-name/SKILL.md, examples.md, commands.md, metadata.json, tests.md

7. Reviewer：独立于Generator的审核agent，只回答
   '这个技能能否不做修改直接拼进链接生成视频的流程里使用'，YES/NO + 一段理由

8. Publisher：审核通过后，在【技能库仓库路径】创建分支、提交技能包、准备PR说明
   （不自动合并，等待人工审批；不允许对第三方仓库发起任何写操作或PR）

【流水线验收标准，跑完逐条核对】
1. Scout 发现候选仓库 ≥30 个
2. Filter 明确记录 KEEP/REJECT 数量及理由分布
3. Reader 至少 60% 的仓库无需读源码即可判断（记录具体比例）
4. Workflow Extractor 提炼出候选工作流 ≥5 个，且全部标注对应链路环节
5. Skill Score 每个工作流给出完整 checks 明细，不能只给最终分数
6. Skill Generator 完整生成 ≥2 个技能包（5个文件齐全）
7. Reviewer 审核与 Generator 独立执行，每个技能包有独立 YES/NO + 理由
8. Publisher 至少 1 个技能包通过审核，生成完整 PR 草稿并创建本地分支

【额外交付】
SKILL_PIPELINE.md：说明挖到的技能包应按什么顺序拼接成完整'链接→视频'流水线，
哪些环节还缺技能（没挖到覆盖的步骤），需要下次继续补

═══════════════════════════════════
【第三部分：技能应用 + 视频质量QA】
═══════════════════════════════════
用第二部分挖到、且通过审核的技能包，按 SKILL_PIPELINE.md 里的顺序拼装，
实际处理前面【验证方式】里给出的3个真实链接，各生成一支视频。

生成规格：9:16竖屏、60秒左右、每支视频需注明使用了哪几个技能包完成。

Video QA（必须由独立于生成流程的agent执行，不能自我评分）：
对每支视频，按以下7个维度打分，每项0-2分，满分14分：
1. 内容准确性：视频要点是否都能在原文中找到依据，有无编造或曲解原文
2. 信息密度：60秒内是否讲清3-5个核心要点，而非1个点车轱辘话说满
3. 开头钩子：前3秒是否有具体数字/悬念/冲突，而非泛泛开场
4. 字幕可读性：每条字幕停留时长是否≥字数/4.5秒，有无一闪而过
5. 音画同步：旁白、字幕、画面切换是否对齐，有无明显错位
6. 结尾收束：是否有明确总结或行动指引，而非戛然而止
7. 技术可用性：能否正常播放、比例是否为9:16、有无花屏/黑屏/音频丢失

判定标准：
- 总分 ≥12分：PASS，可直接使用
- 总分 8-11分：CONDITIONAL，需人工修改，须列出具体修改点
- 总分 <8分：FAIL，须定位是哪个技能包导致的问题（脚本提炼/配音/字幕/渲染等）

每支视频输出：
{
  "video_id": "xxx",
  "source_link": "xxx",
  "skills_used": ["xxx", "xxx"],
  "scores": {7项打分},
  "total": 分数,
  "verdict": "PASS/CONDITIONAL/FAIL",
  "issues": [具体问题，须能追溯到某个技能包]
}

═══════════════════════════════════
【第四部分：强制交付 report.html】
═══════════════════════════════════
必须包含以下内容，合并为一份可视化报告：

A. 技能挖掘漏斗图：8阶段输入→输出数量（条形图或漏斗图）
B. 技能明细表：每个通过评分的工作流名称、评分、对应链路环节、检查项详情
C. 流水线耗时统计：各阶段耗时 + 总耗时
D. 8条流水线验收标准逐条 PASS/FAIL
E. 3支视频的 Video QA 结果表：source_link / skills_used / 7项得分 / 总分 / verdict
F. 3支视频可直接预览或下载的链接/嵌入播放器

═══════════════════════════════════
【执行注意事项】
═══════════════════════════════════
- 分阶段输出过程进度，每阶段结束后简要说明做了什么、筛掉/通过了多少
- 中途遇到GitHub API限流、仓库读取失败、视频渲染失败等问题，自主定位并调整策略继续推进，不要卡住
- 使用合适的SKILL完成相关任务，避免重复造轮子
- Publisher阶段严禁对Scout/Reader读取的任何第三方仓库发起写操作或PR

【输出格式】
分阶段输出过程进度
最终输出：完整代码 + 技能包文件 + SKILL_PIPELINE.md + 3支生成的视频 + report.html + PR草稿内容" --max-iterations 100 --completion-promise "DONE"

可以看到，它满足了Loop的核心要素，有清晰的验收工作。