---
url: https://blog.hanfucn.com/posts/kimi-k31-kaiyuan.md
description: >-
  据公开报道，月之暗面 11 月 5 日开源 Kimi K3.1 Pro：总参数 2.8 万亿、激活参数约 104B，MoE 架构，支持 100 万
  token 上下文与图文多模态输入，并引入 Gated DSA 稀疏注意力优化长上下文效率；阿里云自研超节点已完成 Day 0 适配。同日百度开源 2800
  亿参数 MoE 模型文心 5.5 Flash Base。本文聊聊开源大模型走到这个规模，独立开发者真正该关心的三件事。
---

# 2.8 万亿参数、百万上下文，还开源：Kimi K3.1 Pro 发布，独立开发者该关心什么

![展开的开源模型网络](/posts/kimi-k31-kaiyuan/hero.jpg)

先给事实（均据公开报道）：11 月 5 日，月之暗面开源 Kimi K3.1 Pro——总参数 2.8 万亿、激活参数约 104B，MoE 架构，支持 100 万 token 上下文与图文多模态输入，并引入 Gated DSA 稀疏注意力以优化长上下文效率；阿里云自研超节点已完成对它的 Day 0 适配。同日，百度开源 2800 亿参数 MoE 模型文心 5.5 Flash Base。一句话概括这一天的行业信号：开源模型继续向闭源旗舰的规模区间推进。本篇选题出自[每日热门关键字排行榜](/hot-keywords)。

## 第一件该关心的事：开源改变的是成本结构，不只是「免费」

闭源 API 的计费方式是按 token 付租金，量越大、租越久，账越厚。开源权重的意义从来不是零成本，而是把选择权交回来：可以自部署把边际成本压成电费与机器折旧，可以在自己的数据上微调而不必把语料交给别人，可以在供应商涨价或下线时有退路。对独立开发者，开源旗舰每往前走一步，谈判桌上就多一张牌——哪怕你最终还是调 API，价格也是被开源逼下来的。

## 第二件：2.8 万亿是总参数，先看激活参数

MoE（混合专家）架构的数字要拆开看：2.8 万亿是全部专家的总和，决定容量上限；约 104B 的激活参数，才更接近每回答一个问题实际调用的计算量。发布稿爱用大数字，但做产品的人要算小账：延迟、并发、单次调用成本，看的都是激活侧。当然，即便只看激活侧，这个体量也不是个人显卡能招待的——它的正确打开方式是云端推理与平台托管，Day 0 适配的消息值得留意，正因为适配完成的速度决定了开发者多快能真正调上它。

## 第三件：百万上下文很美，但请先算三笔账

100 万 token 上下文意味着整本书、整个代码仓库可以一次塞进去。但长上下文有三笔隐形账：一是价格账，输入 token 再便宜，一百万乘上调用次数也不是小数；二是延迟账，上文越长，首字等待越久；三是注意力账，塞得进去不等于找得出来，关键信息埋在中段被忽略是已知现象。Gated DSA 这类稀疏注意力优化缓解的是第一、二笔账的一部分，第三笔还要靠自己的检索与分块设计。把上下文当仓库用的人，最后都会回到 RAG 的老路上来——区别只是仓库变大了。

## 顺带一提：开源与闭源不是二选一

也不必把这次开源读成「闭源已死」。更可能的格局是长期分层：闭源旗舰继续负责探索能力上限，开源旗舰负责把水位抬到所有人够得着的地方，两者之间的价格带会被反复挤压。对产品方的实际影响是：模型选型从「一次性下注」变成「可替换组件」——架构上给模型层留好抽象，比押中某一个模型重要得多。哪天某个模型涨价、限流或下线，能在一周内换掉它，才是小团队真正的护城河。

## 写在最后

同一天两家开源、规模再上一阶，趋势已经很清楚：旗舰能力正在从「某家独享」变成「行业水位」。对独立开发者的建议很朴素：别追着参数跑，拿你产品里最真实的十个任务，逐个模型实测一遍——谁的格式最稳、谁的幻觉最少、谁的总账最便宜，答案只在你自己的任务里。模型会继续变大，你的评测集不要变。