我越来越确定未来医疗 Agent 最难的工作会发生在从 2.8T 缩回 32B 的路上见过前沿模型的能力以后能不能把它压缩成一套小模型也能遵守、系统能够验证、医院愿意承担责任的流程。大家好我是陆徐洲。这两天 Kimi K3 正式开放了模型权重。2.8 万亿总参数、1040 亿激活参数、原生多模态、100 万上下文。单看参数“大模型”三个字都显得不够用了它已经直接迈进 3T 级别。但我看完发布信息最强烈的感受却是权重开放了真正有能力在本地部署顶尖模型的机构可能反而更少了。它的权重仓库已经超过 1.5TBvLLM 官方部署方案要求至少 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武汉协和医院则部署了 32BQwen3-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 决定这中间的距离能不能被工程填平。