我越来越确定，未来医疗 Agent 最难的工作，会发生在从 2.8T 缩回 32B 的路上：见过前沿模型的能力以后，能不能把它压缩成一套小模型也能遵守、系统能够验证、医院愿意承担责任的流程。

大家好，我是陆徐洲。

这两天 Kimi K3 正式开放了模型权重。

2.8 万亿总参数、1040 亿激活参数、原生多模态、100 万上下文。单看参数，“大模型”三个字都显得不够用了，它已经直接迈进 3T 级别。

但我看完发布信息，最强烈的感受却是：权重开放了，真正有能力在本地部署顶尖模型的机构，可能反而更少了。

它的权重仓库已经超过 1.5TB，vLLM 官方部署方案要求至少 8 张 GB300，生产流量还建议使用多节点。拿到权重只是起点，长期把它养起来才是门槛。

K3 同时更新了架构，并非只靠规模取胜。它每个 Token 只激活 896 个专家中的 16 个，官方称相对 K2 的 scaling 效率提升约 2.5 倍。MoE 可以降低每次推理的计算量，显存却仍要容纳海量专家权重。

从完整服务器、网络、存储，到高可用、机房改造和后续运维，大模型私有化的成本早已超出几张卡。不同吞吐、精度和国产化要求下，项目可能从数百万元一路走到数千万元。300 万和 5000 万都可能出现，但脱离并发、上下文和可用性谈一个固定报价，没有意义。

所以 Kimi K3 开放权重当然是一件大事，它首先把前沿能力交给了具备 AI 基础设施的公司和算力中心。距离每家医院都能直接搬进机房，中间还隔着一整套昂贵的工程系统。

01、DeepSeek 的部署热潮，后来发生了什么

2025 年初 DeepSeek-R1 开放权重以后，国内医院出现过一轮非常密集的本地部署热潮。

有一项覆盖 261 家公开宣布部署 DeepSeek-R1 医院的调查，三级医院占了 84%，但放到全国医疗机构里，覆盖率只有约 0.7%。在披露参数的三级医院中，671B、70B 和 32B 都有人用，比例分别是 45.2%、29.0% 和 25.8%。

这个数字和很多人的印象有些差异：早期既有 32B、70B 蒸馏版，也确实出现了不少“满血版”项目。

但我要提醒一句，这份数据统计的是 2025 年初的公开上线信息。它能说明当时的热度，不能证明一年以后这些系统仍在以同样的模型、并发和成本稳定运行。发布会上把 671B 跑起来，和让它每天接入电子病历、承受真实访问量，是两件完全不同的事。

我在实际项目里的体感是，真正进入持续应用以后，模型尺寸会明显往中间收敛。70B 曾经是一个很典型的能力档位，后来 30B 左右越来越常见。公开案例里，新医大一附院和福建省人民医院采用过 DeepSeek-R1 70B，武汉协和医院则部署了 32B；Qwen3-32B 也逐渐成为很多团队熟悉的基线。

今年选择更多了：Qwen3.6-27B、35B-A3B，以及更大一档的 Qwen3.5-122B-A10B。235B 当然也能部署，代价是跨入另一套硬件、并发和运维体系。这里的 A3B、A10B 描述的是每个 Token 的激活参数量，整套 35B、122B 权重依然需要加载。

Hugging Face 的下载数据也能看到这种倾向。截至 2026 年 7 月 29 日，Qwen3-32B 页面显示约 1010 万次下载，Qwen3.6 的 27B 和 35B-A3B 均在 600 万量级；Qwen3-235B-A22B 约 80 万，Qwen3.5-122B-A10B 约 130 万。刚发布的 Kimi K3 数据还在快速变化，暂时不适合横向比较。

当然，下载次数无法代表医院部署数。Hugging Face 统计的是特定文件的 HTTP 请求，也无法对应到独立用户。但它至少提醒我们：社区反复拿来测试和适配的模型，通常集中在“够强、放得下、跑得动”的区间。

02、我们正在被最强模型惯坏

这件事对做 Agent 的人还有一个不太容易察觉的影响。

我们个人使用 Codex、Claude、Kimi 或各种聚合平台时，已经习惯随时调用最强模型。上下文不够就加，推理不够就切到最高档，工具调用失败再重试几次。时间久了，很容易把模型提供的能力误认为是自己系统的能力。

但医疗场景不会给你这么宽松的条件。

病历、检验结果和影像报告属于敏感个人信息。医疗卫生机构还要承担数据全生命周期安全、权限、审批、日志和第三方管理责任。“信息不出院”有时是技术方案，有时也是项目在风险、效率和审批成本之间做出的现实选择。

初期探索时，我们可以在完成合规手续后，用少量、必要的数据和最强模型把业务链路跑通：到底要解决什么问题，医生如何验收，哪些步骤必须人工确认，哪些错误绝对不能发生。

但原型跑通只是第一步。后面更费时间的工作，往往是把这套 Agent 从宽松环境迁回院内：模型变小了，上下文变短了，工具调用格式变了，推理方式也变了。

换一个 API 地址远远不够，整个系统都要重新校准。

03、模型每缩小一层，Harness 就要补上一层

我把这个过程叫作“能力预算收紧”。

最开始，模型可以自己读一大段病历，判断该查什么知识，再组织出结果。换成小模型以后，这一串动作可能同时退化。最差的做法，是继续往 system prompt 里塞要求，期待模型突然变聪明。

真正有效的补偿，往往是把原来藏在模型里的工作拆出来：

输入先由程序完成结构化；专业知识交给可追溯的 RAG；评分量表和用药规则交给确定性计算；复杂任务拆成短步骤；工具参数使用严格 Schema；输出经过规则、第二模型和医生分层验证；失败时允许重试、降级或者直接阻断。

这就是 Harness 的补偿面：少给小模型写几句鼓励，多把确定性要求从模型内部搬到模型外部。

但补偿也有上限。小模型本身遵循复杂指令的能力更弱，工具过多、规则互相冲突、上下文塞得太满，反而更容易把它压垮。每换一代模型，Prompt、上下文模板、工具描述、解析器、重试条件和人工审核点都要重新做回归测试。

同一个 Harness 并不会天然适配所有模型。LangChain 曾公开过一个很典型的实验：固定模型，只调整 Harness，就把 Terminal Bench 2.0 的成绩从 52.8% 提升到 66.5%；但把同一套早期 Harness 换到另一种模型，效果又会下降。Harness 能补能力，也会和模型产生耦合。

所以真正的迁移路线应该是：用最强模型探索上限，用评测集冻结任务契约，再逐级缩小模型，观察能力从哪里开始断，然后只在断点上增加约束、工具和验证。

正确的顺序应该从能力断点出发，再决定增加哪一层工程结构。

04、医疗 Agent 的护城河，不会是部署了哪个模型

绕回 Kimi K3。

顶尖开放权重继续向万亿、甚至数万亿参数扩张，一定会推动整个行业的能力上限。但医院更关心另一张成绩单：系统能否在有限显存、有限预算和严格数据边界里长期运行。

对个人也是一样。如果我们所有原型都只在最强模型上开发，会越来越擅长展示 AI 的上限，却越来越不擅长在现实约束里交付。

实际上我们研发时也会保留两套环境：一套用最强模型快速探索；另一套尽早切到 27B、32B 或目标院内模型做回归。模型能力的差值，不应该留到上线前才发现，而应该从第一天就变成评测数据和 Harness 设计的一部分。

我越来越确定，未来医疗 Agent 最难的工作，会发生在从 2.8T 缩回 32B 的路上：见过前沿模型的能力以后，能不能把它压缩成一套小模型也能遵守、系统能够验证、医院愿意承担责任的流程。

大模型负责探索上限，小模型决定应用下限，Harness 决定这中间的距离能不能被工程填平。