AI 蓝鲸汇 由多名资深 AI 从业者与投资人共同创建，以“小规模、高规格、深度交流”为核心，长期邀请一线 AI 从业者、技术专家、创业者与投资人，围绕真实产业议题展开坦诚对话，致力于发现与培育优质 AI 项目，帮助更多青年创业者在 AI 浪潮中找到真正可落地的方向。

⬆️关注 AI 蓝鲸汇

Kimi K3 最有趣的地方，绝不是「月之暗面又发了一个新模型」这么简单。

这类消息太多了。参数、榜单、Demo，大家早就看麻了。

K3 值得单独拿出来说，是因为它凑齐了过去很难同时出现的一组条件：

2.8T 参数，1M token 上下文，开源权重。

Kimi 官方给的技术定义是，K3 基于 Kimi Delta Attention 和 Attention Residuals 构建，原生支持视觉理解，主要面向 long-horizon coding、knowledge work 和 reasoning。完整模型权重会在 2026 年 7 月 27 日前发布。

对创业者来说，这件事的含义很直接。

Kimi K3 的目标场景已经很清楚：Agent、Code、Research 和 Enterprise Workflow。它要处理的是更长、更重、更难验收的任务。

当然，先泼点冷水。

Kimi 官方自己也承认，K3 的整体表现仍然落后于 Claude Fable 5 和 GPT 5.6 Sol 这两个最强闭源模型。它够不上「全面第一」。但 K3 确实把开源模型推到了一个新位置：有些任务还差一点，有些已经能跟最强闭源模型坐在同一张桌上比了。

真正值得问的是：

当一个 3T 级开源模型集齐了长任务、工具调用、视觉反馈、1M 上下文和 API 生产化能力，哪些 AI 产品会因此重新值得做一遍？

PART 01

开源模型又开始拼 Scale 了

过去一年，很多国产开源模型讲的是另一套故事：够用、便宜、好接入、对开发者友好。

Kimi K3 的气质不太一样。

它把规模这件事又搬回了台面。

几个数字先摆在这里：

  • 2.8T 参数

  • 1M token context window

  • KDA，Kimi Delta Attention

  • AttnRes，Attention Residuals

  • Stable LatentMoE

  • 896 个 experts 中激活 16 个

  • 相比 Kimi K2，整体 scaling efficiency 提升约 2.5 倍

  • 原生 multimodal，支持视觉理解

K3 把开源模型推向 2.8T 参数区间

月之暗面这次走的是大模型路线：把开源模型继续往 trillion-parameter frontier 推。只是走法得换，不能光靠传统 dense Transformer 硬堆。

KDA 和 AttnRes 听着技术味很重，核心问题却很简单：模型越大、序列越长，信息怎么稳定传下去？

KDA 处理的是长序列 attention 的效率问题。AttnRes 处理的是深层模型里的 representation 传递问题。

Stable LatentMoE 又解决了另一个麻烦：2.8T 参数不可能每次全激活。K3 的做法是在 896 个 experts 里激活 16 个，把模型规模和推理成本之间的账重新算了一遍。

*KDA、Attention Residuals 与 Stable LatentMoE，是这次技术叙事的核心

K3 真正想验证的是另一件事：3T 级模型能不能落在可训练、可推理、可部署的工程区间里。

参数多大本身不重要，能不能工程化才重要。

PART 02

榜单里真正该看的，是它强在哪些任务

看模型发布，人很容易被「领先」「最强」带着走。

但创业者选模型，不能这么干。

得看它强在哪、弱在哪，强的那块跟你的产品有没有关系。

Kimi 官方 Benchmark 表里，K3 在 coding、agentic、vision、knowledge work 这些任务上已经进入 frontier 区间。但它没有横扫闭源模型。

几个数字比较有代表性：

  • DeepSWE：Kimi K3 67.5，GPT 5.6 Sol 73.0，Claude Fable 5 70.0

  • Program Bench：Kimi K3 77.8，高于 GPT 5.6 Sol 的 77.6 和 Claude Fable 5 的 76.8

  • Terminal Bench 2.1：Kimi K3 88.3，接近 GPT 5.6 Sol 的 88.8

  • FrontierSWE：Kimi K3 81.2，低于 Claude Fable 5 的 86.6，高于 GPT 5.6 Sol 的 71.3

  • SWE Marathon：Kimi K3 42.0，高于表中其他模型

  • BrowseComp：Kimi K3 91.2，高于 Claude Fable 5 的 88.0 和 GPT 5.6 Sol 的 90.4

  • OmniDocBench：Kimi K3 91.1，高于 GPT 5.6 Sol 的 85.8 和 Claude Fable 5 的 89.8

K3 没有全面领先闭源模型，但在 coding、agentic、vision、knowledge work 等任务上已经进入 frontier 区间

这些数字来自 Kimi 官方博客，不是第三方独立评测。官方脚注里也提到，不同 Benchmark 使用了不同的 agentic harness，比如 KimiCode、Claude Code、Codex。

所以别急着判断「谁赢了」。

更现实的看法是：在 coding、agentic workflow、long-context knowledge work 这些高价值任务上，开源模型已经能被拿来和闭源模型放在同一张表里比较了。

对创业公司来说，这意味着你多了一个能用的选择。

真实产品里，你很少需要每个环节都用 absolute SOTA。更多时候，你需要的是某个任务上足够强，成本能算过来，接入不折腾，出了问题能替换。

K3 最值得进入评测池的，也正是这些位置。

PART 03

K3 最能打的地方，是长任务

Kimi K3 官方博客里，榜单反而没那么重要，值得细看的是 case。

case 会暴露一个模型到底想服务什么场景。

K3 的几个例子已经跳出了普通问答。这几个 case 看的其实是同一个能力：模型能不能在复杂环境里连续干活，自己试、自己改、自己验证。

第一个例子是 kernel optimization。

官方让模型在相同 sandbox 里独立工作，最多 24 小时，对 4 个任务进行 profiling、rewrite 和 benchmark。任务涉及 AttnRes、KDA、512-head-dimension MLA kernel，还跨了 NVIDIA H200 和另一类 GPGPU。

结果是，K3 接近 Claude Fable 5，明显超过 Opus 4.8、GPT 5.6 Sol 和 GPT 5.5。

K3 会写 CUDA 并不难，难的是它能在工程环境里待得住。跑测试，看结果，改实现，再验证——这个循环比单次代码补全难得多。

第二个例子是 MiniTriton。

K3 从零构建了一个类似 Triton 的 GPU compiler，包括 tile-level IR、MLIR 之上的 optimization passes、PTX code-generation pipeline。官方说，在支持的 roofline benchmarks 上，MiniTriton 和 Triton、torch.compile 表现相当，部分 workload 还超过 Triton。它还能支持 nanoGPT end-to-end training，并保持稳定收敛。

这已经不是一个好看的 Demo 了。

从 DSL frontend，到 IR passes，再到 PTX codegen 和 runtime，这是一条完整工程链路。模型要记住目标，理解系统，拆任务，跑 benchmark，修局部 bug，还不能把整个 pipeline 改坏。

K3 的价值在长时间、多轮验证的工程任务推进

很多 Agent 产品今天卡住的地方也在这里。

调用一次工具不难。难的是让模型在不确定的环境里，把一件麻烦事往前推进。

K3 这次想证明的就是这个。

它想证明的是「我能做多久，能不能做完」。至于「我能答什么」，那只是起点。

PART 04

1M 上下文的真正价值，是让任务不断档

Kimi 的长上下文一向是它的标签。

但到了 K3，1M token context window 不能再只理解为「可以读更长的 PDF」。

对 Agent 来说，上下文更像工作记忆。

很多 AI 产品做不深，第一轮回答其实不差，差的是任务一长就开始断：

  • 前面做过的决策忘了

  • 文件之间的关系断了

  • 工具调用结果没有沉淀

  • 中途报错后无法恢复

  • 代码库、文档、数据表、用户反馈放不到同一个任务空间里

1M context 当然能塞很多字，可光能塞字算不上价值。1M context 的价值，要看它能不能在长代码库、长文档、多轮工具调用里保住状态。状态不断，问答工具才可能变成 Workflow 的执行者。

K3 的重点落在端到端 knowledge workflow

官方 API 文档里有一个细节很实用：上下文缓存对普通模型请求自动启用，不需要 cache ID、TTL 或额外参数。只要长前缀保持不变，后续请求会自动尝试命中缓存。

这个功能看起来小，放到产品里却很实在。

一个代码库 Agent，不能每次都从零读项目。一个企业知识库助手，也不能每次都重新吞完整文档。一个投研 Agent，如果每轮都重新处理材料，延迟和成本都扛不住。

PART 05

API 细节里，藏着 K3 的产品取向

很多模型发布喜欢堆参数、晒榜单、放 Demo。

K3 的 quickstart 反而值得多看几眼。API 文档里藏着它的产品取向。

K3 可以通过 OpenAI SDK 调用，base_url 是 https://api.moonshot.cn/v1，模型名是 kimi-k3。对已经搭了 OpenAI-style 工程栈的团队来说，这意味着接入层不用推倒重写。

K3 始终开启 thinking mode。目前 reasoning_effort 只支持 max，后续会有其他档位。流式输出里，推理增量和最终答案增量分开，分别是 reasoning_content 和 content。

这说明 K3 不是轻量聊天模型。

它更偏 reasoning-heavy。复杂任务能力可能更强，但代价也很明显：延迟、成本、可控性都得重新评估。

K3 支持严格 JSON Schema 的结构化输出，也支持 Partial Mode。

这两个能力落到生产系统里很实用。JSON Schema 让模型输出能解析、能入库、能传给下游系统。Partial Mode 可以让模型从指定前缀继续生成，适合模板化文档、固定格式报告、代码补全和受控生成。

工具调用里有个坑，官方专门提醒了：多轮对话和工具调用时，必须把 API 返回的完整 assistant message 原样加入下一次请求，不能只保留 content。

很多团队自己封装 LLM gateway 时，最容易犯这个错。只存文本，丢掉 tool_calls、reasoning、metadata。到了复杂 Agent Loop 里，状态就断了。

K3 支持动态加载工具。你可以把完整工具定义放进不含 content 的 system message，从该位置开始加载工具。后续请求仍然要带上这个 message，服务端不会替你保存声明。

这个设计对多工具 Agent 很实在。现实业务里，模型不该每次都面对全部工具。按阶段、按角色、按任务上下文注入工具，才更像一个能跑的系统。

还有价格。

Kimi 官方博客披露的 API 价格是：cache-hit input 0.30 美元 / MTok，cache-miss input 3.00 美元 / MTok，output 15.00 美元 / MTok。

这个价格结构说明，K3 的长上下文商业化，不能只靠 1M token 这个能力本身。真正要算得过账，得靠 cache hit 把重复上下文的调用成本打下来。

所以 K3 更适合有稳定前缀、反复调用、多轮推进的工作流。

比如代码库、企业知识库、研究材料库。一次性长文本问答反而没那么能体现它的价格结构优势。

把这些细节放在一起看，K3 的产品取向就很清楚了：它想进 Agent Pipeline。

但它不是拿来就能无脑上生产的。

官方文档里的限制要认真看：

  • reasoning_effort 当前仅支持 max

  • max_completion_tokens 默认 131072，最大 1048576

  • temperature=1.0、top_p=0.95 等采样参数固定，建议不要显式传入

  • 多轮对话和工具调用必须原样回传完整 assistant message

  • 视觉输入不支持公网图片 URL，只支持 base64 或 ms://<file-id>

  • 联网搜索正在更新，近期不建议用于生产流程

所以我的建议很简单：K3 应该进入复杂 Agent、代码、研究、长文档和多模态工作流的评测池，但别默认所有任务都用它。

它还需要 routing。

PART 06

创业者该问的，不是 K3 强不强

AI 创业团队现在很容易把模型选型聊成站队。

用 GPT，Claude，Kimi，还是 Qwen？

这个问题太粗了。

你真正要拆的是：

  • 产品里有几类任务？

  • 每类任务需要什么模型特征？

  • 哪些环节要最强模型，哪些环节只要便宜稳定，哪些环节必须可控可替换？

按 K3 的能力画像，它最值得优先测试三个位置。

第一，代码库级 Agent

K3 官方重点强调的是 long-horizon coding、massive repositories、terminal tools。它在 SWE Marathon、Terminal Bench、FrontierSWE 这些任务上的表现也不错。

可以重点测这些场景：

  • 老项目理解

  • 自动修 bug

  • 代码迁移

  • 性能优化

  • 前端视觉反馈迭代

  • 工程 pipeline 搭建

如果你的场景只是简单代码补全，K3 可能太重。

第二，长文档和复杂知识库问答

1M context 加 automatic cache，适合长前缀、多轮追问、固定知识库反复调用。

可以测：

  • 投研材料库

  • 法律合同库

  • 企业制度库

  • SaaS 帮助文档

  • 行业研究资料库

这里最怕的是幻觉和权限问题。切片、引用、证据链、权限控制，一个都不能省。

第三，研究型 Agent

K3 官方案例里最亮的部分，是把论文、数据、代码、图表、dashboard 串起来。

官方提到一个计算天体物理案例：K3 为复现 I-Love-Q universal relations，阅读和交叉验证 20+ 篇论文，实现完整数值 pipeline，评估 300+ 个 equations of state，发现已发表公式中的不一致，生成 3000+ 行 Python 代码，并做出交互式 HTML dashboard。官方称，这个任务 K3 大约 2 小时完成，通常需要有经验研究者 1 到 2 周。

另一个 42 年 AI ASIC 行业研究网站案例，涉及 120+ 轮 recursive self-improvement、2.8k+ web searches/fetches、1.1k+ terminal data pulls、11k+ pages、87 份 quarterly reports 和 99 个 original PDFs。

这类 case 不是让你看一份报告就完事的。它要把 research、coding、visualization、dashboard、data pulling 串成一个端到端的 Workflow。

知识工作 SaaS 接下来真正值得做的，可能是把一组不结构化材料变成可更新、可交互、可追溯、可复用的工作系统。

///

END

K3 是一个分水岭，但别把模型能力误读成创业机会

开源模型正在摆脱便宜替代品的定位。2.8T 参数、1M 上下文、MoE 稀疏激活、原生视觉、long-horizon coding，这些能力组合已经开始冲击 frontier intelligence。

复杂 Agent 的模型底座多了一个选择。过去做 coding、research、knowledge work、多模态 workflow，很容易默认只看最强闭源模型。K3 出来之后，评测池里应该给它留个位置。

模型厂商的竞争正在从单轮回答转向端到端工作系统。Kimi Work 里的 Widgets、Dashboard，Kimi Code 里的 terminal/IDE，API 里的工具调用、动态加载工具、结构化输出和 cache，都指向同一个方向：模型开始组织工作，输出文本只是基础。

但创业者要冷静。

模型能力变强，创业机会并不会自动跟着成立。

K3 不会自动帮你找客户，不会替你搞定交付，不会让企业主动掏钱，数据治理、权限控制、结果校验、销售闭环，这些它一样帮不上。

这些问题，才是蓝鲸汇更关心的部分。

下一阶段的模型竞争，会更多写进 Agent 产品的日志里：cache hit rate、工具调用失败率、人工复核比例、客户续费率、毛利率。

Kimi K3 把开源模型带到了这张牌桌上。

接下来，就看创业者能不能把它用成业务，而不是只当一则新闻听听。

资料来源

Kimi K3 Tech Blog: Open Frontier Intelligence

Kimi K3 Quickstart 官方文档

关于 AI 蓝鲸汇

由多名资深的 AI 从业者和投资人一同创建，致力于发掘与培育优质 AI 项目，助力优秀青年投身 AI 创业。我们以小规模、高规格、深度交流为核心，长期邀请一线 AI 从业者、技术专家与创业者，围绕真实议题展开坦诚对话，共同提升 Al 认知与实践视野。同时，AI 蓝鲸汇 通过免费 Token、算力支持、投融资对接等资源，为青年创业者搭建成长通道，让真正有潜力的 AI 人才脱颖而出。