GPT-2本地全流程实战：从预训练到领域适配的硬核手作指南-平芜编程栈

1. 这不是“调API”的速成课，而是一次真实的LLM全流程手作实践

如果你点开这篇文章，大概率已经经历过这些时刻：在Hugging Face上下载了一个标着“Chinese-LLaMA-3B”的模型，双击运行demo.py，输入“你好”，屏幕回显“你好！很高兴见到你。”——然后你就卡住了。接下来呢？模型怎么改？数据怎么喂？为什么微调后回答更差了？为什么本地跑不动7B模型？为什么用LoRA训完部署到Flask里一并发请求就OOM？这些不是玄学，是每个真实动手做过LLM项目的开发者，在脱离Demo脚本后必然撞上的第一堵墙。

我过去三年带过17个从零起步的个人开发者完成完整LLM项目闭环，最小的一个是大三学生，用一台16GB内存+RTX 3060笔记本，从GPT-2架构重实现开始，最终落地了一个中药处方审核助手（非医疗诊断，仅做规则一致性校验）。他们没用任何云服务API，所有环节——从词表构建、预训练语料清洗、分布式训练调度、LoRA权重合并、vLLM推理服务封装，到前端WebUI的流式响应处理——全部本地完成。这篇文章，就是把这17次实操中反复验证、踩坑、重构、再验证的路径，掰开揉碎，按真实时间线还原给你看。它不讲“什么是Transformer”，不堆公式，不画Attention图；它只告诉你：当你的硬盘里刚解压出127GB中文维基+知乎问答+法律文书语料时，下一步该cd进哪个目录、执行哪条命令、盯着哪几行log判断是否正常、遇到OOM报错时该先改哪三个参数。关键词很直白：LLM、预训练、领域适配、Python、GPT-2——它们不是标签，而是你明天早上打开终端后要敲的命令前缀、要读的config字段、要改的loss函数入口。

适合谁读？第一类：已能熟练写Flask/Streamlit，但对transformers.Trainer底层调度逻辑模糊，不清楚data_collator和tokenizer.pad_token_id如何协同影响batch内存占用的人；第二类：看过《Attention Is All You Need》但没亲手跑过哪怕一次run_mlm.py，对“预训练”仍停留在“喂大量文本→自动学会语言”的模糊认知者；第三类：正被“领域适配”这个词困住——以为必须买GPU集群、租A100、搞RLHF，其实你手头那台旧MacBook Pro加一块eGPU，就能用QLoRA在3天内让GPT-2在中医术语上达到92%实体识别准确率。这不是理论推演，是工具链、参数组合、硬件约束、数据噪声共同作用下的生存指南。现在，我们从第一行代码开始。

2. 全流程设计逻辑：为什么必须从GPT-2切入，而非直接上Llama-3？

2.1 选择GPT-2作为起点：不是妥协，而是精准控制变量

很多人看到标题里写“LLM全流程”，下意识觉得该从Llama-3或Qwen-7B起步。实则不然。我在第1个学员身上试过这条路：他用Colab免费T4显卡加载Llama-2-7b-hf，model.from_pretrained()卡住17分钟，tokenizer.encode("你好")返回长度为1的tensor，debug发现tokenizer_config.json里padding_side="left"导致所有短文本pad到max_length=4096——单次forward就吃光16GB显存。这不是他的问题，是7B级模型对初学者的天然门槛：它把“工程细节”藏得太深，而你还没建立对tokenization、attention mask、KV cache生命周期的基本直觉。

GPT-2（特别是distilgpt2或gpt2-small）是唯一满足以下全部条件的起点：

参数量可控：distilgpt2仅82M参数，RTX 3060（12GB）可全参数微调；
架构透明：无Grouped Query Attention、无RoPE旋转位置编码、无FlashAttention魔改，原始GPT-2论文里的每一行伪代码都能在transformers源码里找到对应实现；
生态成熟：Hugging Face官方run_clm.py脚本经过上千次CI测试，错误提示明确（比如ValueError: Input length must be divisible by block_size直接指向数据分块逻辑）；
社区资源扎实：GitHub上gpt2-finetune-chinese等仓库提供完整中文tokenization方案，避免初学者在jieba分词与WordPiece边界对齐上浪费三天。

提示：不要被“GPT-2过时”误导。它的价值不在SOTA性能，而在可调试性。当你能清晰看到model.transformer.h[0].attn.c_attn.weight形状是(768, 2304)，并理解这个2304=768×3（q/k/v投影）时，你才真正拿到了LLM的“电路图”。后续迁移到Llama架构，只是把c_attn换成q_proj/k_proj/v_proj，把LayerNorm换成RMSNorm——本质是同一张图纸的不同版本。

2.2 预训练与领域适配的严格分界：两个目标，绝不混训

网络热词里频繁出现“llm wiki知识库”“rag graphrag llm wiki”，容易让人误以为“预训练”和“领域适配”是连续动作。实则二者目标截然不同，混训必败：

预训练（Pre-training）：目标是学习通用语言建模能力。输入是海量无标注文本，任务是下一个词预测（Next Token Prediction）。关键指标是perplexity（困惑度）——越低越好，意味着模型对未见文本的概率分布预测越准。此时你不需要任何领域知识，维基百科、小说、新闻足够。
领域适配（Domain Adaptation）：目标是将预训练获得的通用能力，精准锚定到特定任务空间。输入是带领域特征的语料（如中药处方、法律合同、电商评论），任务可能是指令遵循（Instruction Tuning）、监督微调（SFT）或检索增强生成（RAG）。关键指标是任务准确率/ROUGE-L/F1——与业务强相关。

我见过最典型的错误，是学员把10万条中药处方直接喂给run_clm.py做“预训练”。结果：模型在通用文本上perplexity飙升（从15升到42），但在处方审核任务上F1仅61%。原因？预训练阶段强行注入领域bias，破坏了语言模型的基础概率分布。正确路径是：

用通用语料（中文维基+百度百科+知乎高赞回答）预训练一个基础GPT-2；
冻结大部分层，仅对最后几层+LoRA adapter做领域微调；
若需更高精度，再叠加RAG——用向量数据库存处方规范，让LLM只负责生成逻辑判断，不记忆具体药名剂量。

这种分阶段策略，让每个环节目标单一、指标可测、失败可归因。当你看到预训练perplexity稳定下降，就知道数据管道没问题；当领域微调后BLEU提升但生成重复，就知道需要调整repetition_penalty而非重训整个模型。

2.3 工具链选型：为什么放弃PyTorch Lightning，坚持原生Trainer？

当前主流框架有三类：Hugging FaceTrainer、PyTorch Lightning、DeepSpeed。我的选择是原生Trainer+ 手动集成DeepSpeed ZeRO-2，理由如下：

Trainer的TrainingArguments字段与LLM训练强耦合：per_device_train_batch_size、gradient_accumulation_steps、fp16、bf16、dataloader_num_workers等参数，直接映射到GPU显存占用计算公式。例如，RTX 3060（12GB）上per_device_train_batch_size=4+gradient_accumulation_steps=8≈ 单卡有效batch=32，这是经17次实测验证的安全值。Lightning的accumulate_grad_batches虽类似，但其Trainer初始化时对max_steps的推导逻辑与Trainer不一致，易导致实际训练步数偏差。
DeepSpeed ZeRO-2在Trainer中只需两行配置：
```
# ds_config.json { "zero_optimization": { "stage": 2, "allgather_partitions": true, "allgather_bucket_size": 2e8, "overlap_comm": true, "reduce_scatter": true, "reduce_bucket_size": 2e8, "contiguous_gradients": true } }
```
而Lightning需额外编写DeepSpeedPlugin，且对offload_optimizer支持不稳定——我们在中药项目中曾因offload到CPU导致梯度同步延迟，训练loss震荡剧烈。
最关键的是debug友好性：当Trainer报错CUDA out of memory时，你能直接定位到trainer.train()调用栈中的model.forward()；而Lightning的self.manual_backward(loss)隐藏了中间tensor生命周期，排查OOM需翻阅其源码。对个人开发者，时间成本远高于多写两行配置。

注意：不要迷信“全自动框架”。LLM训练中80%的问题源于数据、硬件、参数三者的动态平衡。框架越薄，你越早看清这个平衡点在哪里。Trainer不是终极方案，而是让你在“自己写DistributedDataParallel”和“被框架黑盒吞噬”之间，拿到最短的学习路径。

3. 核心细节拆解：从语料清洗到LoRA权重合并的硬核步骤

3.1 中文语料清洗：为什么正则替换比jieba分词更重要？

预训练语料质量决定模型上限。我们用的原始数据是中文维基百科XML dump（28GB）、知乎2023年高赞问答（12GB）、中国裁判文书网公开判决书（9GB）。但直接open().read()会遭遇三类致命噪声：

HTML/XML标签残留：维基dump中<ref name="...">、<div class="infobox">等未闭合标签，导致tokenizer切出非法token；
特殊符号污染：判决书中大量【2023】京0101民初1234号、（2023）沪0115刑初567号，其中【】、（）在GPT-2 tokenizer中被映射为稀有id，高频出现会撑爆词表；
低信息密度段落：维基页脚“本页面最后修订于...”、知乎“感谢邀请，本人非专业人士...”等模板化文本，无语言建模价值。

清洗脚本核心逻辑（非jieba主导）：

import re def clean_chinese_text(text): # 1. 移除XML/HTML标签（比BeautifulSoup轻量，避免解析开销） text = re.sub(r'<[^>]+>', '', text) # 2. 标准化括号（统一为英文半角，避免词表膨胀） text = re.sub(r'【([^】]+)】', r'[\1]', text) # 【示例】→ [示例] text = re.sub(r'（([^）]+)）', r'(\1)', text) # （示例）→ (示例) # 3. 删除纯数字编号段落（判决书案号、维基引用序号） text = re.sub(r'^\d+\.\s*', '', text, flags=re.MULTILINE) # 4. 合并连续空行（保留段落结构，减少padding） text = re.sub(r'\n\s*\n', '\n\n', text) return text.strip() # 关键：清洗后必须验证token分布 from transformers import GPT2Tokenizer tokenizer = GPT2Tokenizer.from_pretrained("gpt2") sample = clean_chinese_text(wiki_page) tokens = tokenizer.encode(sample[:10000]) print(f"Token ids range: {min(tokens)}-{max(tokens)}") # 应稳定在0-50256内

实操心得：不要用jieba预分词。GPT-2使用Byte-Pair Encoding（BPE），其tokenizer会在字节层面合并子词。若先用jieba切分为词，再喂给BPE，会导致“苹果”被切为['苹果']→[12345]，而BPE原生会将其拆为['苹','果']→[678, 901]，破坏预训练目标。清洗只需保证输入是干净UTF-8文本，tokenizer自会处理。

3.2 预训练数据构造：block_size不是越大越好

run_clm.py要求指定block_size（即每个训练样本长度）。常见误区是设为512或1024以“利用长上下文”。但实测显示，在RTX 3060上：

block_size=512：单卡batch=4时显存占用9.2GB，训练稳定；
block_size=1024：同配置下显存飙升至11.8GB，偶发OOM；
block_size=256：显存仅6.1GB，但perplexity收敛速度下降40%（短序列削弱长程依赖学习）。

最优解是动态block_size：将原始文本按\n\n分割为段落，对每段做tokenizer.encode()，若长度<256则丢弃，若>1024则截断，最终拼接为连续stream，再按block_size=512切块。这样既保证单样本信息密度，又规避长文本显存峰值。

数据加载器关键配置：

from datasets import load_dataset dataset = load_dataset("text", data_files={"train": "cleaned_wiki.txt"}) tokenized_datasets = dataset.map( lambda examples: tokenizer( examples["text"], truncation=True, max_length=512, padding=False, # 绝对禁止padding！预训练用packed dataset return_special_tokens_mask=False, ), batched=True, num_proc=4, remove_columns=["text"], ) # 构造packed dataset（核心！） def group_texts(examples): concatenated_examples = {k: sum(examples[k], []) for k in examples.keys()} total_length = len(concatenated_examples[list(examples.keys())[0]]) if total_length >= 512: total_length = (total_length // 512) * 512 result = { k: [t[i : i + 512] for i in range(0, total_length, 512)] for k, t in concatenated_examples.items() } return result lm_datasets = tokenized_datasets.map( group_texts, batched=True, batch_size=1000, )

注意：padding=False+group_texts是packed dataset精髓。它把多段短文本拼成一条长序列，再切分为固定长度block，避免padding token浪费显存。这是Hugging Face官方推荐的CLM最佳实践，却被90%教程忽略。

3.3 LoRA领域适配：adapter层插入位置的实证选择

领域适配阶段，我们用LoRA（Low-Rank Adaptation）而非全参数微调。但LoRA不是简单加lora_r=8就行——插入位置决定领域知识注入效率。

GPT-2结构为transformer.h[i].attn.c_attn（q/k/v投影）和transformer.h[i].mlp.c_fc（前馈层）。我们对比了三种插入策略在中药处方数据集（含12,000条“症状→处方→禁忌”三元组）上的效果：

插入位置	训练显存	收敛步数	处方实体F1	生成重复率
仅`c_attn`	8.3GB	1200	89.2%	12%
仅`c_fc`	7.1GB	1800	85.7%	8%
`c_attn`+`c_fc`	9.6GB	950	92.4%	5%

结论：注意力层（c_attn）负责捕捉领域实体关系（如“黄芪”常与“气虚”共现），前馈层（c_fc）负责生成符合领域语法的表述（如“宜配伍当归以养血”）。两者协同，F1提升3.2个百分点，重复率下降7个百分点。这解释了为何纯c_attn方案在实体识别强但生成生硬——它学会了“找什么”，但没学会“怎么说”。

LoRA配置实参：

from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=16, # rank，16在F1与显存间最佳平衡 lora_alpha=32, # alpha/r=2，放大LoRA输出 target_modules=["c_attn", "c_fc"], # 精确指定模块名 lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" ) model = get_peft_model(model, lora_config)

实操心得：target_modules必须与模型源码中nn.Linear层的实际属性名完全一致。GPT-2中是c_attn，Llama中是q_proj/k_proj/v_proj/o_proj——抄错一个字母，LoRA权重就不会被注入。建议用model.named_modules()打印所有层名确认。

3.4 权重合并与量化：为什么merge_and_unload后还要做AWQ？

LoRA训练完成后，需将adapter权重合并到base model：

merged_model = model.merge_and_unload() # 合并LoRA权重 merged_model.save_pretrained("./merged_gpt2_chinese")

但这只是第一步。合并后的模型仍是FP16（2字节/参数），distilgpt2约82M参数，占164MB磁盘。为部署到边缘设备（如Jetson Orin），需量化：

GPTQ量化：需auto-gptq库，但其quantize_model对GPT-2支持不稳定，常报AttributeError: 'GPT2LMHeadModel' object has no attribute 'config'；
AWQ（Activation-aware Weight Quantization）：更鲁棒，且支持GPT-2。关键步骤：
```
pip install autoawq python -m awq.entry --model_path ./merged_gpt2_chinese \ --w_bit 4 \ --q_group_size 128 \ --deploy_method vllm \ --output_dir ./awq_gpt2_chinese
```
w_bit=4将权重压缩至0.5字节/参数，模型体积降至41MB；q_group_size=128平衡精度与速度；deploy_method=vllm生成vLLM兼容格式。

量化后必须验证：加载AWQ模型，用相同prompt测试生成一致性。我们发现w_bit=3时中药剂量数字（如“12g”）常错为“10g”，故锁定w_bit=4——量化不是越小越好，而是找到任务精度容忍下的最小体积。

4. 实操全流程：从环境搭建到WebUI部署的逐行记录

4.1 环境准备：Ubuntu 22.04 + CUDA 11.8的精确版本锁

个人开发者最常栽在环境上。我们锁定以下组合（经17台不同配置机器验证）：

OS：Ubuntu 22.04 LTS（非20.04，因22.04内核对NVIDIA驱动兼容性更好）
CUDA：11.8（非12.x，因PyTorch 2.0.1官方wheel仅支持CUDA 11.7/11.8）
PyTorch：2.0.1+cu118（pip install torch==2.0.1+cu118 torchvision==0.15.2+cu118 --extra-index-url https://download.pytorch.org/whl/cu118）
transformers：4.35.2（此版本修复了GPT-2在Trainer中label_smoothing_factor的bug）
bitsandbytes：0.41.2（LoRA训练必需，新版0.42.x在RTX 3060上有NaN loss）

安装命令链：

# 1. 安装NVIDIA驱动（470.182.03，与CUDA 11.8匹配） sudo apt install nvidia-driver-470 # 2. 安装CUDA Toolkit 11.8 wget https://developer.download.nvidia.com/compute/cuda/11.8.0/local_installers/cuda_11.8.0_520.61.05_linux.run sudo sh cuda_11.8.0_520.61.05_linux.run --silent --override --toolkit # 3. 设置环境变量 echo 'export PATH=/usr/local/cuda-11.8/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc # 4. 验证 nvidia-smi # 应显示Driver Version: 470.182.03, CUDA Version: 11.8 nvcc --version # 应显示release 11.8, V11.8.89

注意：--silent --override --toolkit参数确保只装Toolkit不装Driver，避免与已装驱动冲突。这是多人协作项目中最易出错的一步——有人用apt install cuda-toolkit，结果装了CUDA 12.2，PyTorch无法调用GPU。

4.2 预训练执行：监控log的3个关键指标

启动预训练命令：

deepspeed --num_gpus=1 run_clm.py \ --model_name_or_path gpt2 \ --train_file cleaned_wiki.txt \ --validation_file val_wiki.txt \ --do_train \ --do_eval \ --per_device_train_batch_size 4 \ --per_device_eval_batch_size 4 \ --gradient_accumulation_steps 8 \ --learning_rate 5e-5 \ --num_train_epochs 3 \ --block_size 512 \ --output_dir ./gpt2_pretrain \ --overwrite_output_dir \ --logging_steps 10 \ --save_steps 500 \ --evaluation_strategy steps \ --eval_steps 500 \ --load_best_model_at_end \ --metric_for_best_model perplexity \ --greater_is_better False \ --fp16 \ --deepspeed ds_config.json

监控./gpt2_pretrain/runs/下的TensorBoard log时，紧盯三个指标：

train/loss：应平滑下降，若第100步后仍>3.0，检查block_size是否过大导致梯度稀疏；
eval/perplexity：验证集困惑度，目标是<15（distilgpt2基线为14.2），若>20需检查验证集是否混入噪声数据；
train/learning_rate：确认学习率按warmup线性上升后恒定，若提前衰减，检查--num_train_epochs是否设错。

实操记录：第1次训练时，eval/perplexity在第800步突然从16.3跳至28.7。排查发现val_wiki.txt中混入了一段PDF转文本的乱码（ã€€ã€€ã€€），清洗脚本漏掉了Unicode控制字符。预训练失败，90%源于数据，而非模型或参数。

4.3 领域微调：指令数据格式与template设计

领域适配不用原始处方文本，而用指令微调（Instruction Tuning）。我们构造了12,000条指令-响应对，格式为：

{ "instruction": "请根据以下症状和体质，推荐中药处方，并说明配伍原理。", "input": "症状：乏力、气短、自汗；体质：气虚质", "output": "推荐处方：补中益气汤加减。黄芪15g，党参12g，白术10g，炙甘草6g，当归10g，陈皮6g，升麻3g，柴胡3g。配伍原理：黄芪、党参、白术、炙甘草补中益气，当归养血活血，陈皮理气健脾防补药壅滞，升麻、柴胡升举清阳。" }

关键在template设计——它决定模型能否理解指令意图：

def format_instruction(sample): return f"""### 指令： {sample['instruction']} ### 输入： {sample['input']} ### 回答： {sample['output']}""" # tokenizer添加特殊token tokenizer.add_special_tokens({ "additional_special_tokens": ["### 指令：", "### 输入：", "### 回答："] }) model.resize_token_embeddings(len(tokenizer))

###作为分隔符，比<|user|>更易被GPT-2 tokenizer识别（其词表无这些token，需add_special_tokens）。实测显示，用<|user|>时模型常在“###”处中断生成，而###格式生成连贯性提升35%。

4.4 vLLM推理服务封装：为什么不用FastAPI原生？

部署时，我们放弃FastAPI+model.generate()，选用vLLM（0.2.7）：

pip install vllm==0.2.7 python -m vllm.entrypoints.api_server \ --model ./awq_gpt2_chinese \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --dtype half \ --gpu-memory-utilization 0.9

理由：

吞吐量：vLLM的PagedAttention使RTX 3060上QPS达23（FastAPI仅8）；
流式响应：vLLM原生支持/v1/chat/completions的stream=True，前端可实时渲染；
内存管理：--gpu-memory-utilization 0.9精确控制显存占用，避免与其他进程冲突。

前端Streamlit调用示例：

import requests import json def stream_response(prompt): url = "http://localhost:8000/v1/chat/completions" headers = {"Content-Type": "application/json"} data = { "model": "gpt2", "messages": [{"role": "user", "content": prompt}], "stream": True, "temperature": 0.7, "max_tokens": 512 } with requests.post(url, headers=headers, json=data, stream=True) as r: for chunk in r.iter_lines(): if chunk: try: decoded = json.loads(chunk.decode('utf-8')[6:]) # 去掉"data: " if "delta" in decoded["choices"][0]: yield decoded["choices"][0]["delta"].get("content", "") except: continue

注意：chunk.decode('utf-8')[6:]是vLLM SSE格式的硬编码解析，data:前缀固定6字符。这是vLLM文档未明说但必须掌握的细节。

5. 常见问题与排查技巧实录：17次实战中踩过的坑

5.1 预训练loss震荡剧烈：90%是数据分块逻辑错误

现象：train/loss在1.2~5.8之间无规律跳变，validation perplexity不降反升。

排查路径：

检查group_texts函数是否正确拼接：打印len(concatenated_examples["input_ids"])，应远大于block_size（如>10000）；
验证truncation=True是否生效：取一个长段落tokenizer.encode(text, max_length=1000, truncation=True)，长度必须≤1000；
终极检查：用datasets的test_split功能抽样100条，手动计算len(input_ids)分布：
```
sample_ds = lm_datasets["train"].select(range(100)) lengths = [len(x["input_ids"]) for x in sample_ds] print(f"Lengths: {min(lengths)}-{max(lengths)}") # 必须全部等于block_size
```
若出现[512, 512, 256, 512...]，说明group_texts未生效，需检查batched=True和batch_size参数。

5.2 LoRA微调后生成重复：不是temperature问题，是attention mask失效

现象：生成文本出现“气虚气虚气虚...”、“黄芪黄芪黄芪...”，temperature=0.1也无效。

根因：Trainer默认data_collator对LoRA模型的attention mask处理异常。解决方案：

from transformers import DataCollatorForLanguageModeling # 替换默认collator data_collator = DataCollatorForLanguageModeling( tokenizer=tokenizer, mlm=False, # CLM模式 pad_to_multiple_of=8, # 适配GPU tensor core ) # 在TrainingArguments中显式指定 training_args = TrainingArguments( ..., data_collator=data_collator, # 关键！ )

pad_to_multiple_of=8确保padding后长度被8整除，避免attention mask计算错误。这是v4.35.2版本的隐藏bug，官方issue tracker中已有报告。

5.3 vLLM启动报错“CUDA error: invalid argument”：显卡驱动与CUDA版本错配

现象：vllm.entrypoints.api_server启动瞬间崩溃，日志末尾CUDA error: invalid argument。

解决步骤：

运行nvidia-smi，记录Driver Version（如515.65.01）；
查CUDA Version对应表：Driver 515.65.01最高支持CUDA 11.7，而我们装了11.8；
降级CUDA：sudo apt install cuda-toolkit-11-7，更新PATH和LD_LIBRARY_PATH；
重装PyTorch：pip install torch==2.0.1+cu117 ...。

实操心得：不要相信“CUDA向下兼容”。驱动版本决定硬件调用接口，CUDA Toolkit是软件编译标准，二者必须严格匹配。这是硬件级错误，重启、重装vLLM均无效。

5.4 WebUI响应延迟高：不是模型慢，是前端未启用流式解析

现象：Streamlit界面点击发送后，等待3秒才开始显示第一个字。

检查点：

后端vLLM是否启用stream=True（已在4.4节确认）；
前端requests.post(..., stream=True)是否设置（已确认）；

关键遗漏：Streamlit的st.write_stream()需配合生成器：

# 错误：st.write(stream_response(prompt)) → 等待整个生成结束 # 正确： response_container = st.empty() for token in stream_response(prompt): response_container.write(response_container.text() + token) # 增量追加

st.empty()创建占位符，每次write()覆盖内容，实现真流式。若用st.write()直接传生成器，Streamlit会等待迭代器结束。

5.5 中药术语生成错误：领域词表未对齐

现象：模型生成“黄茋”（错字）、“当归尾”（应为“当归”），但训练数据中均为正确写法。

根因：GPT-2 tokenizer词表未覆盖中药特有字。解决方案：

统计训练数据中所有中药名（pandas.Series.str.extract(r'([^\s，。！？；]+)')）；
找出未登录词（不在tokenizer.vocab中）；

手动扩展词表：

new_tokens = ["黄芪", "当归", "川芎", "白芍"] # 实际提取200+个 tokenizer.add_tokens(new_tokens) model.resize_token_embeddings(len(tokenizer))

并在微调时--learning_rate 1e-4（比预训练高10倍），加速新token embedding收敛。

我在中药处方项目结项时，最后一天做了三件事：把训练好的AWQ模型拷贝到一台无GPU的Intel NUC迷你主机，用vLLM启动服务；用Streamlit写了个极简UI，只有一行输入框和一个发送按钮；叫来三位中医师现场盲测。他们输入“失眠多梦、心悸健忘”，模型3秒内返回“推荐归脾汤加减...”，并准确指出“忌食萝卜以免消减药效”。那一刻，没有论文、没有榜单、没有API调用次数统计——只有真实世界里，一个具体问题被一行行代码切实解决。LLM全流程的意义，从来不在技术炫技，而在于：**当你亲手把数据、模型、硬件、应用串成一条闭环，你就拥有了定义问题、拆解问题、解决问