32B多模态医疗大模型预训练工程化实战：数据、并行与稳定性

去年我们团队接手了一个任务：从零预训练一个32B参数规模的多模态医疗大模型。刚立项时，很多人都以为最难的是模型结构设计，真跑起来才发现，真正决定项目生死的是端到端工程化。原始数据要洗、显存要算、并行要切、训练要盯、评测要自建，任何一个环节掉链子，前面几个月的算力和人力就全白烧了。

这篇文章就是把我们大半年踩过的坑和沉淀下来的经验完整复盘一遍，重点围绕32B多模态医疗大模型预训练这条主线，讲清楚数据怎么配比、并行怎么选、显存怎么算、训练怎么稳、评测怎么建，以及从预训练到最终可用的收尾链路。如果你也准备做类似规模的模型，或者正在给团队搭训练基础设施，这篇应该能帮你省掉不少试错成本。

1. 32B医疗大模型预训练：项目整体设计与工程化目标

先说结论：医疗大模型项目里，模型结构反而是最不紧张的部分。Transformer系架构加上视觉编码器，大家都熟。真正的难点在于，医疗场景的数据形态复杂、质量参差、合规要求高，预训练过程又长又贵，稍有不慎就是几周算力打水漂。所以这个项目从第一天就定了一个原则：所有环节都必须工程化、可复现、可回滚。

1.1 为什么偏偏选择32B这个尺寸

很多团队一上来就想上70B甚至更大，但实际推演之后会发现，在医疗领域32B是一个性价比非常高的甜点值。

7B、13B这类模型在小规模通用文本上表现尚可，但对医疗这种长尾知识密集的领域，常识推理、跨模态对齐能力都偏弱。比如让模型结合影像报告判断用药合理性，小模型经常给出看似通顺但医学逻辑不通的回答。70B以上则是另一个极端：单复本就要跨多机部署，训练时通信和稳定性成本指数级上升，后续推理部署也困难，上线要养几十张卡。

32B则刚好卡在中间。它在多模态融合能力上足够支撑影像特征与文本语义的对齐，token利用率也比大模型更经济。更实际的一点是，以80GB显存的主流训练卡来看，32B参数配合张量并行和流水线并行，单节点8卡就能放下一个训练复本，这对集群调度和容错都友好得多。

还有一个常被忽略的点：医疗领域的高质量数据量远小于通用互联网。32B已经能充分吸收现有的医学教材、临床指南、脱敏病历和影像报告，数据不足时盲目上大模型反而更容易过拟合，或者把预训练变成无效的算力消耗。用做餐厅来类比，7B是街边小馆，家常菜没问题；70B是五星级酒店，菜品多但成本巨高；32B是特色中餐厅，规模适中，既能稳住出品质量，又不用养一个庞大的后勤团队。

1.2 "端到端工程化"到底包含哪些环节

端到端这三个字，说起来容易，做起来其实是一整套闭环。训练脚本只是冰山一角，真正端到端意味着从原始数据进入系统的那一刻起，到评估结果出来、再反馈回训练配置，全链路都跑得通、可追踪、可迭代。

具体拆成六个环节：数据采集与清洗、语料配比与采样、并行训练框架、稳定性监控、评测体系、对齐与部署回馈。每个环节都需要有明确的输入输出和校验关卡。医疗场景还额外增加两条硬约束：隐私脱敏必须滴水不漏，医学答案必须可控可解释。模型不能一本正经地给患者下一个错误诊断，所以评测环节里必须有医学背景的标注团队参与人工审核。

我们当时在组织协作上也踩了不少坑。最开始的配置是算法工程师主导一切，结果算法同学一周有三天在帮数据处理脚本debug。后来重新调整了团队结构：数据工程师管清洗管道，算法工程师管模型和并行策略，SRE管训练稳定性和告警，医学标注团队管评测集构建。各司其职之后，整体迭代速度才真正起来。这也是做大规模预训练的一个核心建议：别让算法工程师包打天下。

2. 多模态医疗数据准备：清洗流水线如何搭

很多团队把预训练当成一个纯算力游戏，觉得只要卡多就能赢。但医疗大模型的数据复杂度远超通用语料。一份影像报告可能是扫描件转的PDF，一份病历可能混合了半结构化文本和医生手写风格的口语表达，一张CT影像又需要和相同时段内的报告文本做精准对齐。数据环节要是没打好底子，后面所有的训练都是空中楼阁。

2.1 数据构成与配比：我们最终怎么组织语料

多模态模型的数据配比直接决定模型的能力偏向。我们最终采用的数据主要由五个来源构成，每个来源的配比都经过了几轮消融实验才定下来。

这里特别说下合成问答对的部分。医疗数据的天然形态是叙述性的病历报告，而不是问答题，但模型在落地时最需要的是问答能力。我们当时用经过筛选的医学文本作为语料，让强模型生成候选问题，再让医学标注团队以双人背靠背方式审核并修正答案。这套流程成本不低，但回报也很明显，预训练中后期混入这些指令数据后，模型在下游任务上的表现提升非常显著。

关于配比，踩过一个坑：最开始我们把影像报告配比提到了40%，结果模型对图像特征的编码能力确实增强了，但纯文本的医学推理能力出现了下降。后来把配比调回25%左右，同时在图文对中随机mask一部分文本，强制模型从图像本身学习特征，平衡才算找回来。

2.2 清洗链路：过滤、去重、图文对齐的关键细节

清洗链路我们做得比较重，核心分五个阶段，每个阶段都有独立的校验点。

第一阶段是格式解析与文本抽取。这个阶段最大的坑是PDF扫描件。很多医学教材和指南是图片型PDF，直接抽出来全是乱码。我们的做法是接入OCR引擎并做了医学词表增强，同时保留版面信息，让"标题-正文-表格"的结构能被后续流程感知。

第二阶段是敏感信息识别与脱敏。不是简单地把姓名身份证号删掉就结束，而是要识别间接标识符，比如年龄、职业、地域组合起来可能定位到具体个人。脱敏规则是合规团队和医学团队一起定的，每一条规则都有正反例和边界说明。这一步做不好，后面模型就算训出来了也无法上线，所以宁可慢也绝不能跳。

第三阶段是质量过滤。我们维护了一个多层级过滤器，先做重复率检测，再做低质量文本分类。有一类特别隐蔽的坏数据是"看似通顺实则无意义"的文本，比如自动生成的摘要、机器翻译的烂稿，它们语法完全正常但语义稀碎。我们专门训练了一个小模型来识别这类数据，实测可以把清洗后的有效token率提升至少10个百分点。

第四阶段是是图文配对。影像报告和影像文件常常散落在不同文件夹，文件名规则也不统一。我们为每条样本生成了一个全局唯一ID，并通过影像检查号、检查日期、报告唯一码三个字段做交叉匹配，不满足任何一个都直接丢弃。这个规则让图文对齐的准确率从最初的约90%提升到了99.5%以上。

第五阶段是采样和人机共检。每天随机抽取一定比例的清洗结果，由医学背景的兼职人员做复核，抽检不合格率超过阈值的批次直接回退重洗。这套机制帮助我们很快发现过几次批量性的数据污染事件：某段时间的电子病历文本里混入了系统自动生成的无意义占位符，如果没有人工抽检，这些垃圾数据会直接进入训练集。

提示：清洗管道一定要做成幂等的。每条样本有唯一ID和清洗状态字段，任务失败后可以从断点恢复，重新跑不会重复处理也不会漏处理。我们最开始用简单的定时脚本，结果一次网络故障导致数据重复写入，白白浪费了两天的训练迭代。

3. 预训练基础设施选型：并行策略与显存压榨

32B参数的多模态模型，显存和通信是绕不开的两座山。选择什么样的并行策略，不只是一个技术偏好，而是对集群拓扑、模型结构、训练成本三者的综合权衡。这一部分我会详细讲清楚我们如何设计并行方案，并把显存计算过程一并列出来。

3.1 并行策略怎么选：一张表看懂主流方案

当前主流的训练并行方案有很多，每种方案切的对象不同，适用的场景也不同。先看一张对比表。

实际项目中我们采用的是混合并行。数据并行负责扩大Batch Size，张量并行负责把单层的大矩阵切到多张卡上计算，流水线并行负责把整个模型切到多阶段上。三者的比例需要根据集群实际拓扑来定。

我们遇到的真实场景是：每个节点8张80GB显存加速卡，节点内部NVLink带宽高，跨节点走以太网。这种情况下，张量并行跨节点做会非常亏，因为每层矩阵乘法的AllReduce通信量极大。所以我们把张量并行限制在节点内部，也就是tensor_parallel_size设为4或8，流水线并行则用来跨节点切分。

3.2 显存估算与训练配置：32B模型如何在80GB卡上稳定跑起来

很多团队第一步就栽在OOM上，因为低估了优化器状态占用的空间。我们以32B模型、全参数训练、混合精度来算一笔账。

模型权重以FP16存储，32B参数每个占2字节，总共约64GB。梯度同样以FP16存储，又是约64GB。优化器状态这里最容易被忽略：AdamW需要为每个参数保存一阶动量FP32和二阶动量FP32，各占4字节，两个状态合计每个参数8字节，于是32B参数就是256GB。三者相加，单复本至少需要384GB的显存，这还没算激活值和通信缓冲。

用80GB的卡来算，8张卡总共640GB，去掉384GB后还剩256GB给激活和通信，看似够用。但如果开了很大的全量激活，一个4096长度样本的激活值可能轻松吃掉几十GB，微Batch再大一点就爆了。所以我们压显存的几个手段是：开启激活重计算，用时间换空间；张量并行维度设为4，流水线维度设为2，这样单复本正好放在8卡节点内；微Batch设为1，通过梯度累积来凑大Batch。

一个可参考的训练配置如下：

model: name: multimodal_medical_32b text_config: architecture: decoder_only hidden_size: 4096 layers: 48 attention_heads: 32 vision_config: encoder_type: vit_large output_projection: mlp data: seq_length: 4096 total_batch_size: 128 micro_batch_size: 1 accumulation_steps: 16 parallelism: tensor_parallel_size: 4 pipeline_parallel_size: 2 data_parallel_size: 8 zero_stage: 1 optimizer: lr: 1.0e-4 min_lr: 1.0e-5 warmup_steps: 2000 weight_decay: 0.1 grad_clip: 1.0

说下为什么TP取4而不是8。TP=8时矩阵切得更碎，单卡显存压力确实更小，但每层计算多了一次8卡全互联的AllReduce，通信开销明显增大，实测吞吐反而下降。TP=4加PP=2的组合在8卡节点上最平衡，每个Transformer层的计算量主要落在4张卡上，通信可控，显存也不吃紧。

流水线并行维度我们设得比较保守，只设了2，因为PP会带来流水线气泡。医疗模型不像通用大模型那样有一望无际的预训练数据量，训练步数有限，每一分算力都很宝贵，所以宁可让单卡多放一些参数，也不愿意用大量PP去牺牲有效吞吐。

Data Parallel Size设为8，意味着同时有8个复本在跑，配合total_batch_size=128，每个复本每步实际消费16条样本。梯度累积步数就是16，这个数值不是拍脑袋定的，而是模型收敛效果和集群吞吐交叉验证后的结果。累积步数太大会导致梯度更新滞后，模型收敛变慢；太小则Batch Size上不去，训练不稳定。

注意：如果你用的是多模态模型，视觉编码器的参数规模一定要单独计算。我们最初估算时只算了文本侧32B，忽略了视觉塔的额外开销，导致实际初始化和预期不符。视觉塔哪怕只有几亿参数，叠加到优化器状态上也是一笔不小的显存开销。

4. 训练稳定与调优：那些不能只看Loss的细节

预训练跑到第10天开始，训练曲线逐渐平稳，但真正的考验也在这个阶段开始。模型规模大、训练周期长，各种偶发问题会接踵而来。毫不夸张地说，稳定训练前线值班同学的日常，就是和loss spike、通信超时、数据管道阻塞打交道。

4.1 监控体系：我如何第一时间发现训练异常

我们的监控体系分三层：指标层、日志层、告警层。

指标层关注的是训练吞吐和数值稳定性。吞吐指标主要是每秒钟处理的token数和GPU利用率。数值稳定性指标则是loss、梯度范数、学习率、loss缩放因子。梯度范数是特别重要的一个信号，如果梯度范数突然变成几千甚至上万，尽管还没出现NaN，模型内部其实已经开始震荡了。我们的经验是，梯度范数一旦超过初始值的三倍，就要触发告警并临时降低学习率。

日志层则记录每个全局步的样本元信息复现能力。训练进程崩溃之后，我们从最后的checkpoint恢复，同时需要确认崩溃前最后几步到底喂了什么数据。所以训练主循环每处理一个Batch都会输出该Batch的样本ID列表到日志，这样即使分布式训练出现奇怪的复现问题，也能通过样本ID回查。

告警层我们就用了常见的时间序列监控方案，设定多级阈值，比如30分钟loss没有下降超过0.5%触发Warning，梯度范数异常触发Critical。告警规则不要设太敏感，否则值班同学一天会被震几十次，最后就麻木了。我们调了一周才找到一个合适的阈值区间。

有一次印象特别深，训练跑到第14天，loss突然一夜之间从1.8涨到2.1，而且持续不降。排查了很久，最后定位到是数据采样管道的问题。当时采样进程的Buffer在并发写入时出现了竞态条件，导致一批重复样本被反复送进训练管道，模型被迫反复咀嚼同一批数据，自然就开始过拟合飙升。快速修复后，靠的是我们给每条样本做的唯一ID校验，直接对比最近1000步的样本ID分布，才发现重复率异常。

4.2 超参数配置与医疗场景调优：Loss下降不等于能力提升

医疗大模型的超参数设置，心法上和通用模型有区别也有相通的地方。下表是我们最终稳定使用的一组核心参数。

在医疗场景里，最需要提醒的一点是：不要迷信预训练loss的漂亮曲线。loss下降只能说明模型在拟合数据分布，不能说明模型学会了医学推理。我们曾经有一个版本loss降得非常顺畅，模型却在内部评测集的用药合理性维度上惨败。原因是数据分布里常见病案例太多，模型学会了把常见病用药方案背下来，遇到需要鉴别诊断的复杂病例就无法组织出合理的推理链。

解决方法是把评测提前介入训练迭代。从第5万步开始，每5000步就跑一次内部评测集，看关键维度的通过率。通过率不是单纯看生成文本的BLEU或ROUGE分数，而是看结构化抽取的医学实体、推荐药物、禁忌症判断是否准确。把评测反馈和训练超参数关联起来，才是真正的调优闭环。

数据配比也要用工程手段来调。我们有意识地构造了一批覆盖罕见病和疑难病例的重复采样样本，并让这批样本以一定概率在训练数据中出现，为的是平衡高频常见病和低频罕见病之间的学习差距。单纯靠调整文本配比太粗粒度，这类难例挖掘式的采样，效果要明显得多。

5. 医疗场景评估与落地：从预训练到可用的闭环

预训练模型不是终点，可用的医疗模型才是终点。训练结束后我们面对的关键问题是：这个32B多模态模型，到底能不能在真实的医疗场景里被信任、被使用？这需要一套严谨且贴近实际业务的自建评测体系。医疗场景的评测和通用NLP评测有着明显的差别，通用评测看选择题正确率就够了，医疗评测必须要看模型给出的推理链条是否医学合理、是否存在危险建议。

5.1 自建医疗评测集：不看Benchmark，看真实任务

公开的医疗问答基准集虽然方便，但存在两个隐患。一是可能有数据泄漏，如果这些基准集本身混入了预训练语料，评测分数虚高，毫无参考价值。二是基准集的任务形态与真实医疗场景不匹配，比如很多公开集都是偏诊断分类的选择题，而真实产品需要的是开放式的多轮问诊支撑。

所以我们必须自建评测集。具体包括以下几类任务方向：

• 疾病分诊与鉴别诊断：给定主诉和检查结果，要求模型列出可能的疾病范围，排序并说明依据。
• 影像报告理解：输入CT或MRI的影像特征描述，结合文本报告，考察模型能否理解病变位置和性质。
• 用药合理性判断：给定患者基本信息、诊断和当前用药，要求模型给出是否存在药物相互作用风险。
• 多轮问诊对话：考察模型能否在连续追问中保持上下文一致，并且不给出超出证据范围的确定性诊断。
• 证据引用与不确定性表达：模型输出必须能指明依据来源，对不确定项要明确说"无法判断"或"建议进一步检查"。

评测流程我们采用的是双盲加多专家审核。每条模型输出，由至少两位医学背景标注员独立打分，分歧较大的案例进入争议评审。打分维度包括医学正确性、证据完整性、表达安全性、交互自然度四类。这个流程成本不低，但能换来对模型能力的真实判断。

有一个很典型的案例：某版本模型在标准评测集上的分诊准确率达到了90%，但在自建的多轮问诊评测里，遇到一位患者连续三次追问"会不会是癌症"时，模型为了安抚患者给出了过度乐观的排除性结论，这在医疗安全上是不可接受的。这种问题，只有通过贴近真实场景的评测才能暴露出来。

5.2 从预训练到对齐与部署的衔接：工程上如何收尾

预训练跑完之后，还需要经过一个精收尾阶段，再进入部署推理。我们采用的做法是在预训练的最后1%到2%的数据量内，故意混入高质量的指令微调数据。为什么要在预训练阶段做这件事，而不是预训练完成后才单独做标准的指令微调？因为直接接着预训练做，模型的分布转移会更小，遗忘现象显著减少。

我实测下来的对比结果很有说服力：同样一批指令数据，放在预训练最后阶段混入，训练完后的下游任务平均分比单独做指令微调高出约5个百分点。这个操作在工程上也很简单，只需要在数据采样器里调整一下最后阶段的数据混合比例即可。

对齐之后是部署环节。32B模型直接部署推理显存压力不低。我们用了4bit量化加推理加速框架，单张80GB卡可以稳定跑起来，延迟控制在可接受范围内。医疗场景还有额外要求，模型输出的置信度必须低门槛触发安全话术，即当解码时的置信度较低，或者模型判断问题超出自身知识范围时，应当输出"建议尽快到线下医疗机构就诊"，而不是强行给结论。

从产品角度来看，还需要把模型的推理过程显式化出来。也就是输出"判断依据"和"参考来源"，让医生或患者可以追溯。我们做了简单的证据收集模块，从输入病历中抽取相关实体，并在输出文本中标注对应的文本片段。这个功能在内部试用时反馈很好，显著提升了模型的可信度。

6. 高频故障速查与医疗场景特有经验

最后这一部分，把我们实际运行中踩过的高频故障和特定于医疗模型的经验陷阱整理出来，相当于一份速查手册。团队里每个值班同学桌上都贴着一张类似的表，遇到问题先查表定位，省去大量试错时间。

6.1 高频故障排查速查表：从报错到根因

有一个排查经验特别有价值：任何在训练中出现的反常行为，第一件事永远是查数据，而不是查模型。因为预训练模型的结构相对成熟，超参数也是验证过的，真正容易出问题的地方往往是数据管道。我们处理过几次诡异问题，比如训练平稳跑了一天但无效token比例异常高，排查后发现是某个上游系统改了字段分隔符，导致解析器把大量正文内容当成了元数据丢弃。

6.2 医疗模型独有的坑：数据偏斜、隐私清洗与能力损伤

医疗模型和通用模型相比，有几个特有的坑一定要单独拿出来说。

数据偏斜问题。医院的真实数据分布是严重失衡的，常见病占大头，罕见病样本稀缺。如果不干预，模型就会变成"常见病专家"，遇到罕见病病例时倾向于把它误判成某种常见病，这在医疗场景是致命的。我们的解决思路是难例挖掘加过采样，专门构建一批罕见病和疑难病例的数据子集，用更高倍率的采样权重混入训练管道。

隐私清洗过度导致能力损伤。这个问题非常隐蔽，但实际发生的频率不低。最初为了保证隐私合规，我们把病历里的年龄、性别、地域、职业全部抹掉了，结果发现模型在评测时对性别相关的疾病判断出现了系统性偏差，比如某些只在特定性别高发的疾病，模型完全无法利用上下文信息。后来和合规团队重新梳理了字段级别的脱敏规则，保留对医学推理有意义的间接标识符，同时对权限和访问做严格管控，才在合规与能力之间找到平衡。

还有一个很容易被忽略的问题是评测集污染。内部评测集如果长期不更新，模型在多次迭代过程中会逐渐过拟合到评测集上，表现分越来越好看，但真实场景表现跟不上。我们的做法是每个月用最新的实际业务数据重新标注一批评测样本，并且从评测集合里定期淘汰那些被模型反复见过的题目。

最后再分享一个个人感受：做医疗大模型和做通用大模型的最大不同，是你在每个环节都要多问一句"这个方案如果真的让模型学会了，放到患者面前是否安全"。工程上的每个取舍，最终都会被这条底线重新检验。所以团队里最好从一开始就有医学背景的人参与数据规则制定和评测体系设计，而不是等模型训出来再临时找医生来点评，那样返工成本太高了。

这个项目做完之后，我们内部最大的收获并不是跑通了一个32B模型，而是建立了一套从数据到训练再到评测的自动化闭环。后续无论模型升到更大规模，还是迁移到其他垂直领域，这套工程底座都能直接复用。如果你也在做类似方向，建议从第一天就把数据版本、清洗规则版本、评测集版本全部纳入版本管理，这是一笔看起来不起眼但回报极高的投资。