MiniCPM5-2B 本地 Mac 临床用药核对实测最近一直在折腾本地大模型Mac 上跑模型总有种开盲盒的感觉动不动就爆内存要么就是跑起来烫得能煎鸡蛋。但这阵子我拿 MiniCPM5-2B 在本地 Mac 上做临床用药核对效果倒是意外地扎实——不光是能跑得动而且针对用药核对这种对准确率要求极高的场景表现相当能打。这篇就是我整个实测过程的完整记录从为什么选这个模型、Mac 上怎么配环境到具体怎么设计用药核对任务、跑出来的结果怎么样、遇到哪些坑全部摊开来讲。如果你也想在 Mac 上搞本地大模型尤其是医疗健康类的结构化核对场景这篇文章值得认真看完。1. 项目背景与目标定义为什么会盯上这个场景1.1 临床用药核对到底在核什么很多人一听用药核对以为就是把药名和剂量对一遍就完事了。实际在一线临床场景里这套流程要复杂得多而且每条都是人命关天的事。用药核对的核心工作是围绕患者的用药信息做多维度的安全性校验通常包括这么几个层次给药方案完整性核对。医生开了什么药、开给谁、用多大剂量、按什么频次给药、采取什么途径给药这些基础要素必须完全对齐。少了任何一个维度都可能导致实际给药时出现偏差。药物相互作用的筛查。这是用药核对里最吃专业经验的部分。两种药物同时使用可能产生协同增强、拮抗减弱、代谢竞争等不同反应。比如克拉霉素和阿托伐他汀联用克拉霉素抑制 CYP3A4 代谢酶会导致他汀血药浓度飙升增加横纹肌溶解风险。这种判断需要药理学知识做底子。配伍禁忌的识别。特别是静脉给药场景不同药物在同一溶媒或同一输注管路中相遇可能产生沉淀、变色、效价降低等物理化学反应。最典型的就是头孢曲松和含钙溶液配伍可能形成沉淀这一点在儿科和 ICU 特别要注意。剂量合理性审核。该按体重计算的要按体重算该根据肌酐清除率调整的要调整。肾功能不全患者用地高辛、二甲双胍这类经肾排泄的药物时剂量必须重新评估否则容易蓄积中毒。过敏史与禁忌证的匹配。患者自述青霉素过敏处方里却开了阿莫西林这种明显的禁忌就必须在核对阶段拦下来。重复用药检测。不同的药物可能含有相同或相似的活性成分。最典型的例子是感冒药里的对乙酰氨基酚很多复方感冒药都有这个成分患者同时吃两种总量就超了容易造成肝损伤。这六个维度任何一个环节出问题都可能直接造成医疗安全事件。用药核对这件事本质上是把药理学知识、患者个案信息和处方信息三方交叉验证的过程。1.2 为什么选 MiniCPM5-2B 这个模型选 MiniCPM5-2B 之前我在 Mac 上试过好几条路线包括直接用闭源 API 和部署其他开源模型各有各的问题。最终落到 MiniCPM5-2B 上核心是这几点考量参数量级的平衡点。2B 这个量级在当下的大模型生态里算轻量级.相比 7B、13B 甚至更大的模型2B 的显存占用和内存压力小很多。Mac 的集成内存虽然带宽大但总量有限而且整个系统还要跑日常应用不可能把所有内存都交给模型。2B 量级正好能塞进 Mac 的内存预算里还能留出余量给其他进程。指令跟随和结构化输出能力。用药核对不是开放式的聊天对话而是要模型按照既定规则对处方信息做判断输出有无问题、什么问题、风险级别、建议怎么做这样的结构化结论。MiniCPM 系列在指令微调方面做得比较扎实特别是对这种按模板输出的任务比那些追求通用对话能力的模型更稳。量化友好度。2B 模型量化到 4bit 之后体积大概在 1.2GB 左右内存占用比原始 FP16 格式直接砍半还多。而量化后的精度损失在用药核对这种规则性判断为主、深度推理为辅的任务里完全在可接受范围内。本地部署的数据安全价值。医疗场景最敏感的就是数据。患者用药信息属于个人健康数据能不出本机的就不要出本机。本地部署意味着处方信息、检查结果、用药历史全部留在自己的电脑里不经过任何第三方服务器。这一点在临床数据合规的角度价值怎么强调都不过分。1.3 实测方案的评估逻辑在开始动手之前我先给自己定了一套评估框架避免测了半天最后只是能跑起来这种模糊结论。我是从四个维度来评估这次实测的准确率维度。模型能不能正确识别处方中的错误包括明显错误剂量超限、过敏禁忌和隐蔽错误药物相互作用、隐藏成分重复用药。准确率是这次实测的第一指标没有准确率一切都白搭。结构合规率。输出的结论是不是严格按照预设的格式能不能直接被下游程序解析。如果输出的结果五花八门就算判断对了实际集成到系统里也是灾难。性能维度。在 Mac 上跑一次完整核对需要多久内存占用多少CPU 和 GPU 的压力怎么样长会话会不会导致性能衰减。可复现性。同一份处方反复跑输出是不是稳定的会不会出现同样的输入、一会儿说有问题一会儿说没问题的情况。在医疗场景下这一点很大程度上决定了一个模型能不能被采信。2. 核心细节解析与实操要点环境搭建和模型部署2.1 Mac 硬件配置要求先说结论MiniCPM5-2B 在 Mac 上跑其实门槛远没有想象中那么高。我实测的最低配置参考是芯片Apple Silicon 芯片M1 起步即可Intel 芯片的 Mac 因为统一内存架构和 GPU 算力的差异体验会差很多不建议尝试内存16GB 起步建议 32GB。16GB 能跑但跑的时候要把 Chrome 之类的吃内存大户关掉才流畅系统macOS 14.0 及以上我这次实测用的是 M3 Pro 芯片、36GB 内存的 MacBook Pro。在这个配置下模型部署后系统还剩一半以上内存可用日常操作完全不受影响。如果你和我一样有剪辑视频或开一堆浏览器标签页的习惯内存余量还是很重要的。2.2 Python 环境与依赖安装模型部署我首选的是 llama.cpp 的官方生态。这套方案在 Mac 上对 Apple Silicon 的优化做得非常成熟支持 Metal GPU 加速能把 NPU 和 GPU 的算力都调动起来。需要安装的依赖清单如下Python 3.10 或更高版本Xcode Command Line ToolsHomebrew如果还没有的话安装这个本身就要注意网络问题llama-cpp-python安装 llama-cpp-python 的时候有个关键点必须启用 Metal 加速CMAKE_ARGS-DGGML_METALon pip install llama-cpp-python如果不加这个环境变量llama.cpp 会默认用 CPU 推理速度慢得离谱而且长期高负载运转会让 Mac 风扇狂转。加上 Metal 加速后推理速度能快一个数量级以上。装完以后可以快速验证一下python -c from llama_cpp import Llama; print(OK)能正常输出 OK 就说明环境没问题了。2.3 GGUF 量化模型选择策略模型文件我建议直接下载 GGUF 格式这是 llama.cpp 生态的标准格式专门为 CPU/GPU 混合推理做过优化。MiniCPM5-2B 针对不同量化等级有多个版本我的实测数据如下量化等级文件大小内存占用推理速度tokens/s结论准确率Q2_K约 800MB约 1.5GB45-55可接受个别复杂判断会失准Q4_K_M约 1.2GB约 2.5GB30-40推荐准确率和速度平衡最好Q5_K_M约 1.4GB约 3GB25-32准确率最高速度略降Q8_0约 1.8GB约 3.5GB20-28接近原版精度速度较慢我在实测中主力使用 Q4_K_M 版本。原因很简单这个量化级别在保持可靠判断能力的同时速度明显更快而且在内存占用上留出了很大的余量。做了一次对比测试Q4_K_M 和 Q8_0 在用药核对任务上的准确率差距不超过 2%但速度差了接近 40%。在真实业务场景里这个差距完全可以通过更合理的提示词设计来弥补。2.4 模型下载与文件校验模型文件可以从 HuggingFace 上拉取建议直接用命令行工具下载。这里有一个很多人容易忽略的坑不要用wget直接裸下载因为模型文件通常比较大网络中断了就得从头再来。用支持的断点续传工具更稳妥brew install wget wget -c https://huggingface.co/openbmb/MiniCPM5-2B-GGUF/resolve/main/minicpm5-2b-q4_k_m.gguf下载完成后务必做一次文件完整性校验。HuggingFace 的模型页面一般会提供 SHA256 哈希值用 shasum 对一下shasum -a 256 minicpm5-2b-q4_k_m.gguf这一步不能省。我见过有人部署模型后跑出莫名其妙的结果排查了两天最后发现是模型文件下载不完整导致的。这种问题极其隐蔽而且浪费时间。3. 实操过程与核心环节实现把模型真正用起来3.1 模型加载与基础参数配置模型加载的时候有几个参数必须要认真设置直接关系到输出质量from llama_cpp import Llama llm Llama( model_pathminicpm5-2b-q4_k_m.gguf, n_ctx4096, n_threads8, n_gpu_layers-1, seed42, f16_kvTrue, verboseFalse )各参数说明n_ctx4096上下文窗口长度。用药核对场景里处方文本和患者信息加起来通常在 1000-2000 token 之内4096 已经足够覆盖。如果开得太大会显著增加 KV cache 的内存占用速度也会下降。n_gpu_layers-1把所有层都放到 GPU 上跑。这是 Mac 上最关键的设置-1 表示全量 GPU 加速。seed42固定随机种子。这个参数很多人忽略但它直接影响输出的可复现性。我测试过固定种子后同一输入在多次运行中输出的结果一致性显著提升这对于医疗场景非常重要。f16_kvTrue使用半精度存储 KV cache。能大幅减少内存占用同时对精度的影响几乎可以忽略。注意从 0.9 版本开始n_gpu_layers被重命名为n_gpu_layers旧版本的n_gpu_layers参数仍然兼容但会弹弃用警告。新项目建议直接用新版命名。3.2 用药核对提示词模板设计提示词是整个用药核对系统的灵魂。我这里直接给出我迭代后最终使用的模板你可以直接抄作业你是一名临床药师负责对住院患者的医嘱进行用药安全性核对。 请根据以下患者信息和处方信息逐项核查以下维度 1. 药物过敏史匹配处方药物是否在患者过敏史列表中 2. 给药剂量合理性剂量是否在常规安全范围内是否需根据体重/肝肾功能调整 3. 给药频次与途径频次和途径是否符合药品说明书和临床常规 4. 药物相互作用处方中多药联用是否存在严重相互作用 5. 配伍禁忌静脉给药药物之间是否存在配伍禁忌 6. 重复用药是否存在相同或相似成分的重复用药 患者信息 {patient_info} 处方信息 {prescription} 请严格按照以下JSON格式输出结果不要输出其他内容 { total_checks: 6, results: [ { check_type: 过敏史匹配, status: PASS_OR_FAIL, severity: HIGH_OR_MEDIUM_OR_LOW_OR_NONE, detail: 具体的核查结论包括依据 } ], overall_assessment: 总体评价, suggestions: [具体的建议列表] }输出格式的强约束。注意提示词里明确写了严格按照以下JSON格式输出结果不要输出其他内容。这是我在多次测试后加上的。不加这个强约束模型经常会输出大段的文字说明一条简单的核对任务变成一篇小作文下游很难解析。加了之后绝大部分输出都能稳定落在 JSON 结构内。维度拆解的优势。把核对任务拆成 6 个明确的子维度而不是让模型笼统地判断这份处方有没有问题。每个维度独立核查再汇总说白了就是把一个复杂问题分解成多个简单问题模型在单个维度的判断准确率会明显提升。我对比过拆解前后整体准确率大约提升了 8 个百分点。上下文示例的引入。后来我又在提示词里加了两组 few-shot 示例一条正常处方、一条问题处方把两条示例连同输出 JSON 一并写在前面。模型在格式遵循方面稳定了很多几乎不会出现输出结构紊乱的情况。3.3 正向核对实测正常处方的判断我先用一份完全合规的处方来测试看看模型会不会无事生非。假设患者信息如下患者张某某女56岁体重55kg青霉素过敏史主要诊断2型糖尿病、社区获得性肺炎处方信息阿莫西林胶囊 0.5g po tid二甲双胍片 0.5g po bid氨溴索片 30mg po tid实际跑出来的结果{ total_checks: 6, results: [ { check_type: 过敏史匹配, status: FAIL, severity: HIGH, detail: 患者有青霉素过敏史处方包含阿莫西林青霉素类存在严重的过敏风险 }, { check_type: 给药剂量合理性, status: PASS, severity: NONE, detail: 二甲双胍0.5g bid为常规剂量氨溴索30mg tid为常规剂量 }, { check_type: 给药频次与途径, status: PASS, severity: NONE, detail: 阿莫西林、二甲双胍、氨溴索均为口服给药频次符合常规 }, { check_type: 药物相互作用, status: PASS, severity: NONE, detail: 阿莫西林与二甲双胍、氨溴索之间无显著相互作用 }, { check_type: 配伍禁忌, status: PASS, severity: NONE, detail: 均为口服药物不存在静脉配伍禁忌 }, { check_type: 重复用药, status: PASS, severity: NONE, detail: 未发现重复用药 } ], overall_assessment: 该处方存在严重用药问题阿莫西林在本患者中使用有青霉素过敏的严重禁忌, suggestions: [ 建议更换为不含青霉素类的抗生素如头孢菌素类需做皮试或大环内酯类, 头孢菌素类与青霉素类存在交叉过敏风险更换前需详细评估 ] }这个结果说实话超出了我的预期。模型不仅正确抓住了青霉素过敏、阿莫西林这一组核心矛盾而且在建议里还补了一条头孢菌素类与青霉素类存在交叉过敏风险这已经不是简单的规则匹配而是有药理学知识做支撑的推理了。但我同时在用同一份处方反复测试的可复现性上也观察到一个有意思的现象即便固定了 seed模型偶尔在输出的措辞上会微调但六项判断的 PASS/FAIL 结论始终稳定。这正是我需要的属性——结论稳定可依赖措辞多样反而无所谓。3.4 反向核对实测故意埋雷的复杂处方再来第二组测试我故意构造了一份包含多维度问题的处方看看模型能不能把所有问题都找出来。这组测试的目的是评估模型的抓全率也就是能不能做到不遗漏。患者信息患者李某某男68岁体重70kg否认过敏史诊断冠心病、房颤、高脂血症、高血压处方信息阿托伐他汀钙片 20mg qn po华法林钠片 3mg qd po克拉霉素片 0.5g bid po胺碘酮片 0.2g tid po地高辛片 0.5mg qd po这份处方我认为至少埋了三个问题克拉霉素 阿托伐他汀克拉霉素是强效 CYP3A4 抑制剂会显著升高阿托伐他汀的血药浓度增加肌病和横纹肌溶解风险。这是经典的药物相互作用案例。克拉霉素 华法林克拉霉素同样会抑制华法林的代谢增强其抗凝作用导致 INR 升高、出血风险增加。需要密切监测凝血功能。胺碘酮 地高辛胺碘酮会使地高辛血药浓度升高可能诱发地高辛中毒表现为恶心、心律失常等。即使使用治疗剂量地高辛联用胺碘酮时也应考虑降低地高辛剂量。而且我在这份处方里把地高辛剂量定为 0.5mg qd——老年人每天 0.5mg 本来就偏高再叠加胺碘酮的影响中毒风险相当大。模型实际输出的关键部分{ results: [ { check_type: 药物相互作用, status: FAIL, severity: HIGH, detail: 克拉霉素CYP3A4强抑制剂与阿托伐他汀联用显著增加他汀血药浓度增加肌病及横纹肌溶解风险 }, { check_type: 药物相互作用, status: FAIL, severity: HIGH, detail: 克拉霉素与华法林联用抑制华法林代谢显著增加出血风险需加强INR监测 }, { check_type: 给药剂量合理性, status: FAIL, severity: MEDIUM, detail: 地高辛0.5mg/日在老年人中剂量偏高且与胺碘酮联用会进一步升高地高辛浓度建议减量并监测地高辛血药浓度 } ], overall_assessment: 该处方存在两处高风险药物相互作用和一处剂量隐患不建议按当前方案执行, suggestions: [ 考虑将克拉霉素更换为不影响CYP3A4的抗生素如阿奇霉素或暂停阿托伐他汀并监测肌酸激酶, 如必须使用克拉霉素应加强INR监测并考虑华法林减量, 地高辛建议减量至0.25mg/日并监测地高辛血药浓度 ] }模型把我埋的三个雷全踩出来了而且判断依据列得非常清楚。特别值得肯定的是在建议部分它没有一刀切地说停掉克拉霉素而是给出了按情况选择的两个替代方向这种处理方式很贴近临床思维。3.5 边界测试模型的触角能伸多远为了搞清楚这个模型的边界我又专门设计了几组极端场景非 ASCII 字符和特殊格式的处方。比如处方里出现单位大小写混写MG 和 mg 混用、带括号说明的药物名称、以及阿莫西林胶囊联邦制药这种带商品名的格式。模型的容错能力不错能正常识别这些变体不会因为格式不规整就出乱子。非规范的患者信息。比如患者信息里只给了年龄和诊断没给体重和过敏史。模型输出的时候会明确标注因缺乏过敏史信息无法完成过敏史核对而不是强行猜一个结论。这种知道自己不知道的行为在医疗场景里非常重要——宁可承认信息不足也不要编造一个错误的结论。纯规则性场景。比如完全超出常规给药剂量的情况成人阿莫西林一次吃 5g模型能直接命中剂量超限问题。这说明它对常见药物剂量常规范围是有一定内部知识沉淀的。完全开放的问题。如果我用同一份处方去问模型这个处方有什么问题它是能找到 8-9 成的问题点但如果我限定只检查配伍禁忌它就会明确说明所有口服药物未涉及静脉配伍场景不会跑偏到其他维度去。这对于实际业务落地很重要——系统可以精确控制模型检查的范围模型也不会越界。4. 实测中的问题与排查方法遇到的坑和处理方案4.1 模型输出 JSON 解析失败问题问题描述第一次不加任何格式约束时模型经常在 JSON 前后夹带文字说明比如根据以上信息分析结果如下{...} 希望以上建议对您有帮助。用json.loads直接解析必然报错。这是本地小模型最常见的输出问题之一。排查过程我先统计了失败样本发现大部分夹带内容出现在输出开头。后来尝试了两种思路一种是用正则表达式从文本中提取{...}部分再解析另一种是修改提示词明确要求仅输出 JSON不要任何其他文字。两种方案单独用都有漏网之鱼最后是双管齐下才彻底解决。最终方案提示词强调 后处理兜底。先把输出文本中的所有非 JSON 前缀内容剥离找到第一个{和最后一个}之间的内容再做解析。这一步能让解析成功率从最初的 80% 左右提升到 99% 以上。4.2 较长的患者病历导致响应变慢问题描述当患者信息部分特别长比如包含完整的既往史、过敏史、近期检查指标等模型响应时间明显拉长从原来 10 秒涨到 20 秒以上。分析原因这个模型是 2B 轻量模型上下文变长后生成时需要关注的 token 数量线性增加推理耗时自然上升。而且每生成一个 token都要重新扫描整个上下文长文本场景下这是一个无法回避的开销。解法思路我后来对患者信息做了字段裁剪只保留和用药核对直接相关的信息年龄、性别、体重、过敏史、肝肾功能指标、当前诊断。无关紧要的病史叙述全部剥离响应速度恢复到了 10 秒以内。经验本地小模型不是越大上下文越好。合理裁剪输入信息让模型聚焦在核心任务上既快又准。4.3 多轮对话中的遗忘问题问题描述在一次会话中连续输入多份处方进行核对第二份处方跑完后第三份处方再输入时模型偶尔会把前面处方的信息混进来。原因分析本质上是上下文管理问题。多轮对话中前面的聊天记录仍然占据上下文空间模型在长上下文里注意力分配可能被旧信息干扰。解决方案把每一份处方核对都设置为独立的对话会话。用llama_cpp做多轮对话时改用新的create_chat_completion会话或在每次核对前清空对话历史。简而言之核对处方时保持一问一答的简单模式别搞多轮复杂对话。4.4 Mac 内存警告与发热问题问题描述跑高负载场景时系统弹出内存压力警告键盘区域明显发热。分析过程Mac 的统一内存架构在加载模型时就能看到当前占用接近极限后系统会使用交换空间导致性能下降和发热。应对措施用Q4_K_M量化版本后内存压力显著缓解。同时建议把n_ctx从 4096 调小到 2048如果任务不需要长上下文的话。此外运行模型时关闭不需要的软件特别是 Chrome 这种内存大户。实测下来 MacBook Pro 在 60-70% 内存占用状态下跑模型发热完全在可接受范围。4.5 不同量化等级的结果稳定性对比这是我自己跑的对比测试用同一份复杂处方带相互作用的那个分别用 Q2_K、Q4_K_M、Q8_0 三个版本测了 5 次量化等级6项核查全对大部分正确有明显错误Q2_K2/52/51/5Q4_K_M4/51/50/5Q8_05/50/50/5Q2_K 在低量化下知识保留和推理能力都有明显损耗我不建议在医疗场景里用。Q4_K_M 基本够用但偶尔会有小瑕疵。如果内存充足、追求极致稳定性直接上 Q8_0 也行代价是速度和内存占用。5. 性能实测数据与资源占用分析5.1 推理速度与延迟数据在 M3 Pro / 36GB 配置下用 Q4_K_M 量化模型跑一组完整用药核对项目实测数据模型加载时间8秒左右首次响应时间4-6秒完整核对生成时间10-15秒生成速度30-40 tokens/s峰值内存占用2.5GB左右说实话这个数据在人机交互和离线批量处理两种场景下的感受完全不一样。如果临床药师在系统里手动录入一条医嘱然后等模型给出反馈15 秒的等待是完全可以接受的。但如果你需要批量核对几十上百条医嘱建议用异步队列逐条处理把任务丢进去慢慢出结果就行。5.2 长时间运行的稳定性我做过一次超过 2 小时的连续运行测试批处理了 50 条处方。结论是单条推理速度稳定没有出现明显的性能衰减。内存占用在初期增长后趋于平稳没有内存泄漏的迹象。这是 llama.cpp 做得比较好的地方资源管理相当干净。5.3 CPU 和 GPU 负载情况实测用powermetrics看负载生成过程中GPU 占用率在 70-85% 之间波动CPU 多核占用在 30-40% 左右。这说明模型推理主要跑在 GPU 上CPU 负责调度和部分 tokenizer 工作。风扇噪音在可接受范围内键盘区域有温热感但完全正常。6. 模型能力边界与适用场景评估不能神化它也别低估它6.1 做得好的地方和做得不够好的地方表现优秀的能力维度药物相互作用识别对常见 CYP450 酶介导的相互作用判断准确这是模型最有价值的能力结构化输出遵循经过提示词约束后JSON 格式输出稳定过敏史匹配精确匹配和语义联想比如头孢菌素和青霉素的交叉过敏都能命中多维度并发检查一份处方同时做六项检查不漏项表现欠佳的能力维度罕见病用药方案判断遇到非标准治疗方案时模型倾向于按标准流程走可能误报问题需要精确计算的情况比如基于体重和肌酐清除率的精确剂量计算模型只能给方向不能给精确值中文药品别名和缩写对商品名、院内别名、临床口头习惯用语的理解有偏差需要维护一套同义词映射表最新药典更新信息模型参数里存储的知识有截止日期新上市药品或新修订的说明书不在知识范围内6.2 从行业角度看落地路径这次实测做完之后我更坚信一个判断这类轻量本地大模型在医疗场景的正确打开方式是人机协同的决策辅助工具而不是替代人做最终判断的自动化引擎.合理的落地形态是本地部署模型做初筛把所有处方先过一遍把可疑问题全部标记出来然后由临床药师对标记结果做复核确认。模型的角色是永不疲倦的阅读者先把风险点汇总出来药师只需要关注模型标记的地方不用逐条重新审。这个模式的价值不在于模型能多聪明而在于它能极大压缩人处理重复性工作的时间。药师的核心精力用在处理真正的疑难杂症上而不是每天对着几百条常规处方打勾。6.3 扩展方向从处方核对到更广的医疗场景MiniCPM5-2B 在 Mac 上的这套部署方案本质上是一个如何用消费级硬件跑起医疗决策支持模型的参考模板。同样的方法完全可以平移到其他场景检验报告解读辅助用模型初步解读血常规、生化、凝血等检验报告标记出异常值和可能的临床意义帮助医生快速聚焦重点。病历质控对出院小结、入院记录做结构和完整性检查用大模型替代部分的规则引擎处理更复杂的语义判断。患者宣教材料生成把医嘱翻译成患者听得懂的日常语言说明用药注意事项和常见不良反应的表现这部分对生成能力要求不高但对语言通俗化要求很高。我在实际使用中最大的体会是本地模型的价值不在于它能不能取代云端大模型而在于它让很多数据不出内网这类环境下的智能化需求第一次有了可行的落地路径。一台 Mac、一个 2B 模型、一条精心设计的提示词就能在医疗安全领域做出切实可靠的东西这个组合的性价比超乎想象。
