DeepSeek医疗本地化部署：环境、数据脱敏与微调训练闭环

简介：这份 PDF 文档面向医疗信息化从业者、算法工程师以及需要处理敏感病历数据的技术团队，聚焦 DeepSeek 本地化部署与医疗数据私有化训练，回应数据隐私合规和深度学习模型落地之间的平衡问题。内容从医疗行业私有化部署背景切入，涵盖服务器与图形处理器选型、操作系统和深度学习环境配置、病历数据收集清洗与标注，以及模型选择、数据划分、模型加载和训练实施等环节，同时提醒数据合规与访问权限控制等安全要点，并穿插可参照的命令与代码片段。压缩包内共 1 个 PDF 文件，约 228KB，篇幅精炼，便于按硬件准备、软件配置、数据处理和训练流程分层查阅。当前已有 1347 人学习，适合希望借助 DeepSeek 与 PyTorch 搭建本地医疗数据训练环境、梳理合规边界与工程流程，并快速定位关键配置与实施重点的读者参考。

1. 从一台不能出网的机器说起：DeepSeek 本地化部署到底在解决什么

上个月陪某医疗机构的信息科梳理一个病历辅助诊断试点，会开到第二十分钟就卡住了：患者数据不能出院内网，模型调用不能走外部接口，连日志里出现一个真实姓名都算事故。到这个份上，DeepSeek 本地化部署不再是「可选项」，而是唯一能往下走的路。

真正拖住进度的从来不是模型权重——权重拷进内网半天就完事——而是 PyTorch 与 CUDA 的版本对齐、80GB 显存到底能塞下多大的 batch、医疗数据的清洗口径、脱敏边界划在哪，以及训练指标好看但临床不敢用这几件事。这套方案适合手里已经有院内病历数据、至少有一张 80GB 显存卡、并且愿意把工程细节做扎实的团队；如果只是想调个接口看看效果，那确实没必要折腾本地化。下面按「环境基线 → 数据进模型 → 训练闭环 → 翻车现场 → 上线前最后一公里」的顺序拆。

2. 硬件与软件基线：把训练环境钉死在可复现的版本上

私有化训练最怕的不是模型不会调，而是「昨天能跑今天不能跑」。医疗项目周期长、验收严，环境必须可复现：哪个驱动、哪个 CUDA、哪个 torch、哪个 Python，全都要能写进交付文档。这一章先把机器配明白，再把环境钉死。

2.1 算力与存储的选型账：显存、内存、RAID 怎么配

一份常见的实训配置清单长这样，我把它拆成「为什么这么选」和「砍预算时先砍哪里」两列来看：

显存这块必须算清楚，否则机器到手第一天就会翻车。以 fp16 全参微调为例，显存占用大致是「权重 + 梯度 + 优化器状态」三份，Adam 的优化器状态还要再乘 2：

四张卡合计 320GB，7B 全参用 ZeRO-3 切分理论上跑得动，但通信开销和调试成本会吃掉大部分收益。医疗场景的数据量通常在几千到几万条病历量级，LoRA 微调加一个重新初始化的分类头，效果和成本的比例更划算。我一般会先跑 LoRA 拿到基线，再判断有没有必要上全参。

2.2 从裸机到可训练环境：系统、Conda、PyTorch 与数据库

RAID 是在装机阶段配好的，操作系统看到的已经是逻辑盘，所以软件层不用管 RAID，只要把数据盘挂到独立目录就行。训练产物、原始病历、模型权重全部放/data，系统盘只放系统和环境，这条规矩能救命——checkpoint 写满根分区导致系统起不来的事故，我见过不止一次。

# 1. 系统基线：先更新，再装编译和数据盘工具 sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential git vim htop nvtop unzip # 2. 数据盘挂到 /data（/dev/sdb1 只是示例，用 lsblk 确认实际盘符） sudo mkfs.ext4 /dev/sdb1 sudo mkdir -p /data sudo mount /dev/sdb1 /data echo '/dev/sdb1 /data ext4 defaults 0 2' | sudo tee -a /etc/fstab

上面的挂载步骤里，lsblk确认盘符是最容易被跳过的一步，写错盘符就是格式化系统盘。/etc/fstab里加defaults 0 2是为了重启后自动挂载，漏了这行，机器一重启训练脚本就会因为找不到/data直接退出。

# 3. 环境隔离：一个项目一个 conda 环境，绝不在 base 里装 torch conda create -n deepseek_medical python=3.10 -y conda activate deepseek_medical # 4. 按驱动支持的 CUDA 版本装 PyTorch，cu118 对应驱动 520 以上 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

装完必须验证，而且要验证到「几张卡、每张多少显存」这个粒度：

import torch print("torch:", torch.__version__, "cuda:", torch.version.cuda) print("available:", torch.cuda.is_available(), "count:", torch.cuda.device_count()) for i in range(torch.cuda.device_count()): p = torch.cuda.get_device_properties(i) print(f"GPU {i}: {p.name}, {p.total_memory / 1024**3:.1f} GB, sm_{p.major}{p.minor}")

这段输出的关键信息有三个：torch.version.cuda要和驱动匹配，device_count()要等于物理卡数，total_memory要接近 80GB。只看到一张卡的情况我遇到过两次，一次是卡没插到位，一次是CUDA_VISIBLE_DEVICES在某个 shell 配置文件里被写死了。看到显存只有 79GB 出头是正常的，驱动会预留一小块。

数据库这块，病历结构化字段存 MySQL 就够了，重点是字符集和权限：

sudo apt install -y mysql-server sudo mysql_secure_installation # 病历里有生僻字和特殊符号，字符集必须是 utf8mb4 sudo mysql -e "CREATE DATABASE medical_data CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" # 应用账号只给增删改查，不给 DROP 和 GRANT sudo mysql -e "CREATE USER 'med_app'@'localhost' IDENTIFIED BY 'REPLACE_WITH_ENV';" sudo mysql -e "GRANT SELECT, INSERT, UPDATE ON medical_data.* TO 'med_app'@'localhost'; FLUSH PRIVILEGES;"

密码不要写死在脚本里，走环境变量或者配置中心读取。权限只给 DML 是有意为之：训练脚本只需要读数据、写推理结果，给它建表删表的权限，等于把误操作的口子留着。字符集用utf8mb4而不是utf8，是因为后者在 MySQL 里实际只存 3 字节，病历里的罕见字会变成问号，而这种损坏在训练阶段是查不出来的。

提示：驱动、CUDA、torch 三个版本号在环境搭好后立刻写进项目 README，并且用pip freeze > requirements-lock.txt锁住。半年后回来复现实验，靠记忆是复现不出来的。

3. 医疗数据进模型之前：清洗、脱敏与数据集切分

模型效果的上限由数据决定，这句话在医疗文本上体现得特别明显。院内导出的病历表通常长这样：主诉、现病史、检查报告、诊断结论四类自由文本，加年龄、性别、就诊科室几个结构化字段。脏数据不是「有几个空值」这么简单，而是同一个症状有五六种写法、同一次就诊被导出成三行、诊断名称在不同科室叫法不一致。

3.1 病历文本的清洗：缺失值、重复值和单位混乱

很多教程上来就是一行dropna()，在医疗数据上这是灾难。罕见病样本本来就少，全表 dropna 会把「检查报告为空但诊断明确」的样本整条删掉，模型直接学不到这类病。

import pandas as pd import re raw = pd.read_csv('/data/raw/medical_records.csv', dtype=str) # 只取建模需要的列，导出时多带的字段不进内存 cols = ['patient_id', 'visit_time', 'chief_complaint', 'present_illness', 'exam_report', 'diagnosis'] df = raw[cols].copy() # 主诉和现病史同时为空的，基本是导出占位行，这类才丢 df = df.dropna(subset=['chief_complaint', 'present_illness'], how='all') # 去重键用「患者 + 就诊时间 + 主诉」，整行去重会误删补录的检查报告 df = df.drop_duplicates(subset=['patient_id', 'visit_time', 'chief_complaint']) def norm_text(s: str) -> str: if not isinstance(s, str): return '' s = s.replace('\u3000', ' ').strip() # 全角空格 s = re.sub(r'\s+', ' ', s) # 连续空白压成一个 s = s.replace('ｃｍ', 'cm').replace('ｍｍ', 'mm') # 全角单位统一 return s for c in ['chief_complaint', 'present_illness', 'exam_report']: df[c] = df[c].map(norm_text) df.to_parquet('/data/clean/records_clean.parquet', index=False)

参数上值得说的是dropna的how='all'：只有两列同时为空才删，单列为空保留，让模型自己学「信息不全」这个信号。去重键选「患者 + 时间 + 主诉」而不是整行，是因为同一次就诊的检查报告可能是后补的，整行比对会把它当成新样本，导致同一份病历在训练集里出现两次。文本规整里全角转半角看着琐碎，但 tokenizer 会把ｃｍ和cm切成不同的 token，模型要多花很多样本才能学会这俩是一回事。

落盘用 Parquet 不用 CSV，一是保留列类型，二是体积小、读取快，几万条病历的差别不明显，但到了几十万条就能省下每次训练前几分钟的加载时间。

3.2 脱敏与切分：为什么按患者切而不是按行切

脱敏必须在数据落盘之前做，不能等到训练时再处理。这一条是硬性要求，也是「数据不出域」之外的第二道闸。常用的做法是正则兜住格式化信息，再抽检自由文本：

import re PATTERNS = { 'ID_CARD': r'\b\d{17}[\dXx]\b', 'PHONE': r'\b1[3-9]\d{9}\b', 'MRN': r'(住院号|病历号|门诊号)[:：]?\s*[A-Za-z0-9]{6,}', 'NAME': r'(患者|姓名)[:：]\s*[\u4e00-\u9fa5]{2,4}', } def deidentify(text: str) -> str: if not isinstance(text, str): return '' for tag, pat in PATTERNS.items(): text = re.sub(pat, f'[{tag}]', text) return text for c in ['chief_complaint', 'present_illness', 'exam_report']: df[c] = df[c].map(deidentify)

正则只能覆盖「有固定格式」的部分，自由文本里「老王说他这个月又疼了」这种口语化称呼，正则抓不住，只能靠人工抽检。我一般会随机抽 200 条逐条看，抽检记录留档，这在验收时是要交的材料。

切分是这一章最容易埋雷的地方，先说结论：必须按患者切，不能按行切。

from sklearn.model_selection import GroupShuffleSplit # 先切 20% 做测试集，保证同一患者不出现在两边 gss_test = GroupShuffleSplit(n_splits=1, test_size=0.2, random_state=42) train_val_idx, test_idx = next(gss_test.split(df, groups=df['patient_id'])) df_tv = df.iloc[train_val_idx].reset_index(drop=True) df_test = df.iloc[test_idx].reset_index(drop=True) # 再从剩下的 80% 里切 12.5%，换算下来正好是总体的 10% 验证集 gss_val = GroupShuffleSplit(n_splits=1, test_size=0.125, random_state=42) tr_idx, val_idx = next(gss_val.split(df_tv, groups=df_tv['patient_id'])) df_train = df_tv.iloc[tr_idx].reset_index(drop=True) df_val = df_tv.iloc[val_idx].reset_index(drop=True) print(len(df_train), len(df_val), len(df_test)) print('患者重叠:', set(df_train.patient_id) & set(df_test.patient_id))

7:1:2的比例是通过两次切分凑出来的：先切 20% 做测试，再在 80% 里切 12.5%，得到总体的 10%。用GroupShuffleSplit而不是train_test_split，是因为后者的random_state只保证行的随机性，同一个糖尿病患者的五次复诊会被随机分到训练集和测试集里，模型等于提前见过答案。这种泄漏不会报错，只会让验证集指标虚高十几个点，然后上线时被打回原形——这是我在项目里踩过最贵的一个坑。

3.3 分词编码与 Dataset 封装：max_length 怎么定

病历文本拼接方式直接影响模型能读到什么。我一般按「主诉 → 现病史 → 检查报告」的顺序拼，因为诊断结论往往藏在现病史末尾，而 tokenizer 的截断是从尾部砍的：

import torch from transformers import AutoTokenizer MODEL_DIR = '/data/models/deepseek-med-base' # 内网权重目录，按实际替换 label2id = {name: i for i, name in enumerate(sorted(df_train['diagnosis'].unique()))} id2label = {i: n for n, i in label2id.items()} tokenizer = AutoTokenizer.from_pretrained(MODEL_DIR, use_fast=True) if tokenizer.pad_token is None: tokenizer.pad_token = tokenizer.eos_token # 分类任务必须有 pad_token def build_text(r): return (f"主诉：{r['chief_complaint']} " f"现病史：{r['present_illness']} " f"检查：{r['exam_report']}") MAX_LEN = 512 train_enc = tokenizer([build_text(r) for _, r in df_train.iterrows()], truncation=True, max_length=MAX_LEN, padding='max_length') val_enc = tokenizer([build_text(r) for _, r in df_val.iterrows()], truncation=True, max_length=MAX_LEN, padding='max_length')

label2id用sorted排序是为了让标签顺序固定，否则换台机器跑，类别 ID 可能整体错位，模型加载后预测全乱。pad_token为空是很多中文权重目录的通病，不设置的话 padding 阶段直接抛异常，或者更隐蔽地拿unk去填充，把噪声喂进注意力。

MAX_LEN=512是个取舍：中文病历普遍在 600 到 2000 字之间，512 个 token 大概覆盖 400 到 500 字，长病历的结论段会被截掉。我的处理是先统计文本长度分布，如果 90 分位在 800 token 以内，就整体提到 768；如果长尾特别长，就改成「头部 400 token + 尾部 200 token」拼接，保证主诉和结论都在。直接把max_length拉到 2048 是最省事的做法，但显存占用随长度平方增长，4 张卡也未必扛得住。

class MedicalDataset(torch.utils.data.Dataset): def __init__(self, encodings, labels): self.encodings = encodings self.labels = labels def __getitem__(self, idx): item = {k: torch.tensor(v[idx]) for k, v in self.encodings.items()} item['labels'] = torch.tensor(self.labels[idx], dtype=torch.long) return item def __len__(self): return len(self.labels) train_ds = MedicalDataset(train_enc, [label2id[x] for x in df_train['diagnosis']]) val_ds = MedicalDataset(val_enc, [label2id[x] for x in df_val['diagnosis']])

自定义 Dataset 这么写的原因是padding='max_length'已经把序列补齐到等长，不需要再写动态 padding 的 collate 函数。如果为了省显存改成padding=True批内补齐，就必须自己实现DataCollatorWithPadding，否则同一个 batch 里张量长度不一致会直接崩。

4. DeepSeek 模型加载与训练闭环：从 Transformers 到 Trainer

环境有了、数据干净了，接下来是训练闭环。这块看着代码量不大，但参数设错一个，可能白跑一整天。我的习惯是先拿 500 条样本跑通 3 个 step，确认显存、loss、保存路径都正常，再全量跑。

4.1 模型与分词器加载：标签顺序和分类头

import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification tokenizer = AutoTokenizer.from_pretrained(MODEL_DIR, use_fast=True) if tokenizer.pad_token is None: tokenizer.pad_token = tokenizer.eos_token model = AutoModelForSequenceClassification.from_pretrained( MODEL_DIR, num_labels=len(label2id), id2label=id2label, label2id=label2id, torch_dtype=torch.bfloat16, # 训练精度，和 bf16=True 对应 ignore_mismatched_sizes=True, # 分类头尺寸和预训练权重不一致，允许重建 ) model.config.pad_token_id = tokenizer.pad_token_id model.gradient_checkpointing_enable() # 显存紧张时先开这个

三个参数必须一起给：num_labels、id2label、label2id。只给num_labels的话，模型会按数字顺序输出，等你把预测结果映射回诊断名的时候才发现对不上。ignore_mismatched_sizes=True是因为加载的是基础模型，原来没有分类头，或者分类头的类别数和现在不同，不加这个会报尺寸不匹配直接退出。pad_token_id写进 config 是为了推理时不再传一遍，也避免推理端漏设导致 padding 位置参与注意力计算。

需要注意的是，分类头是随机初始化的，训练初期 loss 会从 2.3 左右（类别数少的话从 0.69）开始往下掉，这是正常的。如果 loss 一直在原地打转，先查学习率是不是大了，再查标签是不是全映射成了同一个 ID。

4.2 训练参数与显存预算：batch、梯度累积、bf16

from transformers import TrainingArguments, Trainer import numpy as np from sklearn.metrics import accuracy_score, f1_score def compute_metrics(eval_pred): logits, labels = eval_pred preds = np.argmax(logits, axis=-1) return { 'accuracy': accuracy_score(labels, preds), 'macro_f1': f1_score(labels, preds, average='macro'), 'weighted_f1': f1_score(labels, preds, average='weighted'), } args = TrainingArguments( output_dir='/data/runs/deepseek-med-cls-v1', num_train_epochs=3, per_device_train_batch_size=8, per_device_eval_batch_size=32, gradient_accumulation_steps=4, # 等效 batch = 8 * 4 * 卡数 learning_rate=1e-5, warmup_ratio=0.1, weight_decay=0.01, bf16=True, logging_steps=10, eval_strategy='epoch', save_strategy='epoch', save_total_limit=2, load_best_model_at_end=True, metric_for_best_model='macro_f1', greater_is_better=True, report_to='none', )

参数表比代码更值得看，我把几个关键项的取值依据列出来：

显存不够时的降级顺序是有讲究的，别一上来就量化：先降per_device_train_batch_size到 4，同时gradient_accumulation_steps翻倍保持等效 batch；还不行就开gradient_checkpointing，代价是慢 20% 到 30%；再不行才考虑 LoRA 替换全参；量化放在训练里是最后手段，因为量化训练的收敛行为很难调。

metric_for_best_model='macro_f1'配合load_best_model_at_end=True，训练结束会自动加载验证集 macro-F1 最高的那个 checkpoint。这个组合在类别不平衡的医疗数据上特别重要，具体原因在第 5 章展开。

4.3 启动训练与断点续训

trainer = Trainer( model=model, args=args, train_dataset=train_ds, eval_dataset=val_ds, compute_metrics=compute_metrics, ) trainer.train(resume_from_checkpoint=True) # 首次运行会自动忽略 trainer.save_model('/data/runs/deepseek-med-cls-v1/best') tokenizer.save_pretrained('/data/runs/deepseek-med-cls-v1/best')

resume_from_checkpoint=True会去output_dir里找最新的 checkpoint，没有就正常从头开始，所以本地调脚本时不用改来改去。长时间训练建议用nohup或 tmux 挂后台，日志重定向到文件，因为 SSH 断线把训练杀掉的情况太常见了：

nohup python train_cls.py > /data/runs/train_$(date +%m%d_%H%M).log 2>&1 & tail -f /data/runs/train_*.log | grep -E "loss|f1|epoch"

日志里重点盯三个东西：loss 是不是单调下降（允许小幅波动）、eval 的 macro_f1 是不是还在涨、显存有没有缓慢爬升。显存缓慢爬升通常是某处把计算图挂在了列表里没释放，跑几个 epoch 后 OOM，这种要靠torch.cuda.memory_allocated()定时打印来定位。

5. 避坑与排查：六个翻车现场

这一章全是发生过的事。每一条都按「现象 → 原因 → 解决」写，能对号入座的基本上能省一天到两天。

5.1 六个高频翻车现场

第一坑：验证集 F1 高到 0.97，上线后惨不忍睹。现象是训练集和验证集指标都漂亮，测试集一跑就掉到 0.6 附近。原因是切分时用了train_test_split按行随机分，同一患者的多次复诊横跨训练和测试，模型实际上是在做「患者识别」而不是「疾病分类」。解决方法是改成GroupShuffleSplit，groups传patient_id，切完打印一次患者 ID 交集，结果必须是空集。这个检查我后来写进了脚本里，跑之前自动断言。

第二坑：昨天能跑，今天一启动就 OOM。现象是代码一行没改，CUDA out of memory。原因有三种：上一条命令的进程没退干净，显存还占着；max_length被改大了，或者某批数据异常长；显存碎片导致虽然总量够但分配不出来。排查顺序是先nvidia-smi看有没有残留进程，有就kill -9；再看日志里当批的序列长度；最后才考虑设PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True缓解碎片。养成习惯：每次启动训练前先跑一遍nvidia-smi。

第三坑：量化之后模型体积小了，召回率掉了八个点。现象是做了动态量化，torch.quantization.quantize_dynamic(model, {torch.nn.Linear}, dtype=torch.qint8)，推理快了、模型小了，但少数类别的召回断崖式下跌。原因是动态量化对分类头这种小矩阵影响很大，且它主要针对 CPU 推理路径，在 GPU 上收益有限。解决方法是量化只用于推理侧，训练保持 bf16；量化后必须把完整测试集重跑一遍，按类别看召回，而不是只看总体准确率；如果掉得厉害，就把分类头排除在量化范围外。

第四坑：准确率 0.92，罕见病一个都没预测对。现象是总体 accuracy 很高，混淆矩阵里罕见病那一行全是 0。原因是数据极度不平衡，模型学会了「全猜常见病」这个偷懒策略，而用 accuracy 做模型选择等于奖励这种行为。解决方法有三层：模型选择指标换成 macro-F1；训练时给类别权重或者用重采样；评估必须按类别输出召回率。这一条在医疗场景里是红线，总体准确率再高，漏诊就是事故。

第五坑：长病历的结论被截没了。现象是模型对「检查报告很长但诊断明确」的样本预测置信度很低。原因是max_length=512从尾部截断，而诊断结论恰好写在现病史末尾。解决方法是先统计 token 长度分布，把max_length提到 768 或 1024；或者改拼接策略，取「主诉 + 现病史前 300 字 + 现病史后 200 字」，保证首尾信息都在。改完要重新评估，因为输入分布变了。

第六坑：脱敏做完了，抽检还是抽出了姓名。现象是结构化字段干净，但自由文本里还有「患者张某」这样的表述。原因是正则只匹配了「患者：xxx」这种带冒号的格式，没覆盖自然语言里的称呼。解决方法是正则加宽到姓名[:：]?\s*之外，再补一条中文姓氏 + 「某」的模式；更重要的是建立抽检流程，每批数据随机抽 200 条人工过一遍，抽检记录留档。脱敏这件事没有「做完」，只有「做够」。

5.2 排查路径：从显存到指标的固定顺序

出问题时最忌讳东一榔头西一棒子。我固定按这个顺序走，基本十分钟内能定位到方向：

前两步解决环境问题，中间两步解决训练问题，后两步解决评估问题。顺序颠倒的话，很容易在环境有问题的状态下分析指标，得出的结论全是错的。

注意：所有排查动作都要留记录。同一台机器上第二个人接手时，能查到「上一次 OOM 是因为某进程没退」比什么都值钱。

6. 上线前的最后一公里：加密、权限与小流量回放

训练跑完、指标达标，很多团队就在这一步直接接进业务系统，然后出问题。我的做法是先过三道关，最后才谈灰度。

第一道是静态加密。病历落盘必须加密，cryptography的 Fernet 够用，密钥单独存，不进代码库：

from cryptography.fernet import Fernet import os # 密钥只在首次生成，之后从密钥管理服务或环境变量读取，绝不硬编码 key = os.environ.get("MED_DATA_KEY") or Fernet.generate_key() cipher = Fernet(key) token = cipher.encrypt(b"patient_id=xxx;diagnosis=xxx") plain = cipher.decrypt(token).decode()

这里强调两点：密钥和密文不能放在同一个目录，否则加密形同虚设；训练时读取的是解密后的内存数据，临时文件要落在tmpfs上，避免明文出现在磁盘。

第二道是最小权限。数据库账号只给SELECT/INSERT/UPDATE，模型目录只读，训练输出目录只对训练账号可写，推理服务用单独的账号。权限这件事在验收时是要逐条核对的，我一般会写一张自检表：

第三道是小流量回放。不接实时业务，先拿 200 份历史病历走一遍完整链路：解密 → 清洗 → 编码 → 推理 → 结果落库，人工对比模型输出和当时的真实诊断。这一步能暴露的问题比测试集多得多，比如某类病历的字段是空的、某个时间段的编码格式不一样、推理服务的 batch 拼装把长文本截断了。回放通过之后再按 1% 的流量灰度两周，每天看一次误判样本。

从那以后我每次交付医疗类模型，都强制走一遍「回放 200 份历史病历 + 抽检 200 条脱敏结果」这个组合，少一步都不签字。这两个数字不大，但足够把大部分低级错误挡在上线之前。希望帮到你。

本文还有配套的精品资源，点击获取