32B多模态医疗大模型训练实践：从数据工程到效果评测

1. 为什么是32B：这个规模到底解决了什么问题

1.1 医疗场景的真实痛点

先聊一个反直觉的现象：很多人以为医疗模型难在"专业知识的深度"，实际做下来你会发现，难在"多模态信息的对齐"和"输出形式的规范性"。

放射科医生看一张胸部CT片子，脑子里同时在做三件事：识别病灶区域、对照患者病史、按结构化报告模板组织语言。通用大模型做第一件事勉强凑合，第二件事基本靠猜，第三件事——让模型输出一份符合放射科书写规范的诊断报告——几乎必翻车。不是模型不够聪明，而是通用模型压根没见过几万份"图像-报告"配对数据。

我这次的目标很明确：做一个能接受医学影像输入、输出结构化诊断描述的多模态模型。输入是图，输出是文本，中间跨越的是视觉特征和医学语义之间的鸿沟。这个鸿沟，7B模型填不平，70B模型填得起但跑不动，32B是一个经过成本、效果、工程复杂度三方权衡后的选择。

1.2 7B、32B、70B的取舍逻辑

这个选择不是拍脑袋定的。我列一个实际训练中会遇到的资源账单，你就明白为什么32B是甜点区：

• 7B模型（约140亿参数）：bf16权重占14GB，LoRA训练单卡A100 40G就能跑，甚至消费级显卡勉强能玩。但实际测试下来，7B在多模态医疗场景的短板很明显——复杂推理能力弱，面对"多个病灶并存""影像征象与病史关联"这类需要多步推理的问题，经常给出答非所问的结论。
• 32B模型（约640亿参数）：bf16权重占64GB，LoRA训练需要4卡A100 80G起步，全参微调需要8卡甚至更多。这个规模跑到什么水平？恰好是"能进行多步推理、能理解复杂指令、能记住大量医学知识"的门槛。最关键的，32B开源社区生态成熟，基座模型选择多。
• 70B模型：效果当然更好，但显存需求直接翻倍，训练和推理成本指数上升。对大多数团队来说，不是技术不行，是账单不行。

我最后选定了Qwen2.5-32B-Instruct作为语言基座。原因有三：其一，它的中文能力和指令跟随能力在开源模型里属于第一梯队，医疗场景对中文术语的理解要求极高；其二，32B这个尺寸的上下文窗口和推理能力足够支撑"图文交错输入"这种复杂任务；其三，社区生态活跃，踩坑有人陪，出了问题能找到讨论。

1.3 视觉编码器与连接器的选型

多模态模型的结构，说白了就是三部分：视觉编码器负责"看图"，语言模型负责"说话"，连接器负责"翻译"。前两者是成熟组件，真正决定上限的往往是连接器。

视觉编码器我用了SigLIP-SO400M，不是CLIP。原因很简单：SigLIP在图文对齐上用了更稳定的损失函数，视觉特征的判别力更强。医学影像有个特点——病灶区域往往只占整张图像的极小比例，编码器必须能捕捉细粒度特征。SigLIP的patch-level特征保留做得比CLIP好，这对后续的细粒度识别至关重要。

连接器走的是**两层MLP（多层感知机）**路线，不是Q-Former也不是Resampler。MLP结构简单、参数少、训练稳定，对医疗这种数据量不算海量的领域更友好。Q-Former那套交叉注意力机制理论上能压缩更多视觉token，但在医学影像上容易丢失高分辨率细节，我实测下来性价比不高。

连接器输出维度是4096，和Qwen2.5的hidden size对齐，这样喂进去的语言模型无需改动内部结构，只用标准的attention机制处理视觉token和文本token的拼接序列。

2. 数据工程：一块显卡换不回一条坏数据

2.1 医疗数据的来源与合规审查

这是整个项目里最耗时、也最不能省的一环。模型训练领域有句老话叫"垃圾进，垃圾出"，在医疗场景要再加一句："违规进，凉凉出"。数据合规不是法务部门的事，是训练工程师的第一道生死线。

我这次的数据来源主要有三类：

• 公开学术数据集：如PubMed上的图文配对数据、公开的胸部X光数据集、皮肤镜图像数据集等，这些数据集的授权协议要逐条核对，有些只允许科研用途，商用需要单独申请。
• 医院合作脱敏数据：通过正规合作渠道获取的脱敏影像与报告，所有患者身份信息（姓名、病历号、人脸区域）必须经过不可逆脱敏处理，且无法反推。
• 合成数据与大模型生成数据：用已有报告模板和影像描述，结合GPT-4等通用大模型生成多样化的报告文本，再与脱敏影像配对。这类数据占比控制在20%以内，防止模型学到"AI味"。

合规审查的流程是这样的：所有原始数据先经过脱敏工具扫描，再人工抽检10%确认无隐私泄露风险，最后登记数据来源、用途、有效期，建立完整的溯源台账。

2.2 从原始图文到干净样本的清洗流程

数据清洗听起来土，实际上是决定模型上限的隐形王牌。我写了一个多级过滤pipeline