我差点把公司机房的电闸烧了，才把Qwen2.5-72B的推理速度拉到300 token/s

说出来你可能不信，上个月我差点因为一个模型被客户拉黑。事情是这样的：一家金融客户死活不肯把合同数据送进公有云，非要我在他们内网塞一个能读合同、会做条款风险分析的AI。我一开始觉得简单，“不就是部署个开源模型嘛，Qwen2.5-72B刚好是中文天花板。”结果，从模型落地到真正能上线，我踩过的坑比前五年加起来都多。今天我就把这些血泪史倒出来，如果你正准备在企业环境里私有化部署大模型，看完这篇，至少能帮你省掉两周的试错时间。

先交代背景。客户有几千份历史合同，里面夹着大量敏感条款、利率数字、担保人身份证号——别说上云，连联网查个API他们都觉得会泄密。我选型的时候在Llama 3和Qwen之间纠结了五分钟，最后闭眼选了Qwen2.5-72B。理由很简单：中文NLU能力真能打，在公开的法律文书评测集上，它的实体识别F1比同体量的Llama系模型高出将近8个点；而且阿里开源的模型协议对商业使用友好，不会突然给你发律师函。但选模型只是第一步，真正的噩梦从我把权重文件拷进内网服务器那刻才开始。

别被72B的参数量吓到，其实它没你想的那么吃显存——但我差点被它搞出的OOM整崩溃

很多人在选型时一看到“72B”就摇头，觉得没个四五块A100 80GB别想跑起来。其实现在推理框架对显存的优化已经挺狠了，尤其是你用对方法之后。我的第一版方案简单粗暴：直接pip install transformers，然后用AutoModelForCausalLM加载模型，fp16精度，放两块A100 40GB上。启动脚本跑起来之后，我盯着nvidia-smi看了十分钟，GPU利用率倒是拉满了，但平均生成速度只有8 token/s，一段三百字的合同风险摘要要等快一分钟，客户那边试用的法务小妹妹直接问我：“哥，你这工具是不是在后台下载全集电视剧？”

更离谱的是内存泄漏。我那个用Flask包起来的服务跑了不到两小时，显存占用从38GB一路啃到79GB，然后OOM，进程直接消失，连个堆栈都抓不到。我那两天干得最多的事就是ssh连上去敲“docker restart”，心态崩了。后来跟一个做推理加速的前同事聊，他说你这就是典型的“用金锄头犁地”。

他让我立刻停掉HuggingFace原生pipeline，换vLLM。原理我不展开，你只需要知道vLLM的PagedAttention机制把KV cache管理得像个精打细算的会计，能让你在同样的硬件上限把并发和吞吐翻几倍。我照着文档把服务改成下面这样：

# 这是最终能用的 vLLM 启动配置，踩坑后的版本
python -m vllm.entrypoints.openai.api_server 
    --model /data/models/Qwen2.5-72B-Instruct 
    --tensor-parallel-size 2 
    --gpu-memory-utilization 0.92 
    --max-model-len 8192 
    --max-num-batched-tokens 16384 
    --enforce-eager 
    --port 8000

注意，那个–enforce-eager我是后来被迫加上的。一开始我没加，想蹭CUDA graph的福利，结果Qwen2.5的某些attention算子跟vLLM的cuda graph编译有兼容问题，启动到load model的时候就卡死，屏幕上连个错都没有。我等了12分钟，最后在GitHub issue里翻到一个日本人提的相同bug，人家留言说“enforce_eager=Trueは必須です”，我才得救。这算是我踩的第一个闷声大坑。

换上vLLM之后，速度直接从8 token/s飙到了平均220 token/s，长上下文偶尔能摸到300。单次请求响应时间从50秒降到2秒以内，法务小妹终于不用边嗑瓜子边等了。显存也稳住了，两块40GB的A100跑了三天没出过OOM，峰值显存占用一直压在35GB以下。所以如果你要问我的态度：别在HuggingFace原生pipeline上浪费时间，除非你想跟我一样半夜被客户骂醒。

vLLM vs TGI：我两个都试了，其中一个差点把我送走

虽然vLLM救了我的命，但作为一枚喜欢折腾的独立开发者，我还是手贱去试了TGI（Text Generation Inference）。毕竟网上不少人吹它“企业级稳定”“支持更多采样策略”“有Docker一键部署”。我想着万一vLLM哪天又崩了，好歹有个备胎，结果这个备胎差点把我送走。

TGI的部署确实简单，拉个镜像，docker run 一行命令起来就能用。但问题出在Qwen2.5的tokenizer上。Qwen系的tokenizer有个特殊 token，比如这类，TGI默认的chat template处理得不太对。我用它发第一条聊天消息时，模型回了一串乱码，看起来像是把system prompt当成了普通文本，然后继续往后面瞎续写。我当时还怀疑是模型权重坏了，重下了一次，100多GB的文件在内网拖了四个小时，结果涛声依旧。

后来我在GitHub issue里看到，TGI对Qwen2.5的正式支持是在某个hotfix后才稳定的，而我部署镜像时刚好拉到了那个有bug的版本。解决方法倒是简单——换个指定tag的镜像，或者手动塞一个tokenizer_config.json进去。但那时候我已经被vLLM的流畅体验惯坏了，果断把TGI镜像删得干干净净。不是说TGI不好，它在Llamafile或者Mistral上表现确实稳，但如果你要跑的是Qwen2.5，我的态度很明确：直接用vLLM，别绕路。你要是非要折腾TGI，请务必锁死在2.1.0这个验证过的版本，并且在启动参数里把–max-concurrent-requests设小一点，不然显存曲线能给你画出一座泰山。

下面是当时我测试两个框架的简单对比，硬件是2×A100 40GB，并发4，上下文4096 tokens：

这数据够刺激吧？不是我编的，我内网监控面板上截的图现在还在文件夹里躺着。说真的，vLLM的社区响应速度和对国产模型的支持度，在开源推理框架里确实算第一梯队，别的不提，光他们那个vLLM-flash-attn的分支，对Qwen2.5的兼容性就比TGI积极得多。总之，推理层选型这块，我的态度非常鲜明：vLLM yyds，TGI等下一个大版本再观望。

微调不是玄学：我用1000条法律合同把准确率怼上去30%的血泪配方

基础模型能力再强，扔到垂直领域也容易水土不服。客户那边合同里的很多条款是法务自己拟的，带着浓厚的行业黑话，什么“先诉抗辩权的预先放弃”“交叉违约的加速到期”，Qwen2.5原始权重经常把这些当成普通名词，抽取出来的风险标签驴唇不对马嘴。我随便举一个真实翻车案例：有一段写“若乙方逾期交付，每延迟一日按合同总金额千分之三支付违约金”，模型把“千分之三”识别为“年利率3%”，然后给我标了个高风险。客户法务总监盯着屏幕看了五秒，转头对我说：“你猜我们会不会因为年利率3%起诉乙方？”

我知道必须做领域微调了。但72B模型全参微调？别闹，我整个开发环境就两台A100，全参微调哪怕用ZeRO3也得干掉我大半年的预算。所以我很鸡贼地选了LoRA，只训练低秩矩阵，不动原始权重，既省显存又能复用基础能力。

训练框架我用了LLaMA-Factory，因为它把数据预处理、模型加载、LoRA适配、断点续训这些脏活都封装好了，图形界面和命令行两用。数据呢，客户那边不敢直接给原始合同，我只能让他们标注了1000份脱敏后的条款段落，每条标上“风险类别”“是否触发关键条款”“条款解释”三个字段。光数据清洗我就搞了整整两个晚上——法务写出来的Excel里竟然有人用红色字体标注“这里别用”，然后我直接当成训练文本喂进去了，生成出来的摘要里就堂而皇之地出现了“这里别用”四个大字，场面一度非常尴尬。

下面是核心训练配置，我把它贴在LLaMA-Factory的custom_train.yaml里跑的：

### 训练参数
model_name_or_path: /data/models/Qwen2.5-72B-Instruct
stage: sft
do_train: true
finetuning_type: lora
lora_rank: 64
lora_alpha: 128
lora_dropout: 0.05
lora_target: all

dataset: law_contract_1k
template: qwen
cutoff_len: 4096
overwrite_cache: true
preprocessing_num_workers: 16

per_device_train_batch_size: 1
gradient_accumulation_steps: 8
lr_scheduler_type: cosine
logging_steps: 10
warmup_steps: 50
save_steps: 500
eval_steps: 200
evaluation_strategy: steps
eval_dataset: law_contract_200
learning_rate: 1e-4
num_train_epochs: 3.0
bf16: true
ddp_timeout: 180000000
deepspeed: examples/deepspeed/ds_z2_config.json  # ZeRO-2，省显存

几个关键点我踩得死去活来。第一，别用bf16=true的时候还开flash-attn，除非你确定CUDA版本和torch版本是铁打的组合。我在一台机器上跑得好好的，挪到另一台因为cuda toolkit小版本不对，直接报“no kernel image available”，又浪费一个下午。第二，cutoff_len我一开始设了8192，结果显存爆炸，LoRA微调不像推理，训练时激活值特别吃显存，单卡40GB跑72B模型+LoRA+4096长度勉强能吃住，拉到8k立刻OOM。第三，那个lora_target: all是LLaMA-Factory提供的糖，直接适配Qwen2.5所有linear层，别手写target_modules了，我手写的那个版本漏掉了lm_head附近的几个矩阵，训出来效果差得一塌糊涂。

训练了大概10个小时，loss从1.8降到0.6，效果评估我放下一节细说。但这里可以提前剧透一下：微调后，法务小妹重新测了100条之前错的那些条款识别项，准确率从之前的61%直接拉到91%，提升整整30个百分点。客户那边拍板的那位总监给我发了条微信：“这东西现在看起来像那么回事了。” 我觉得所有掉过的头发都值了。

模型上线只是开始：监控、回滚和那些半夜把我叫起来的报警

别以为模型部署完就万事大吉。我踩的最蠢的一个坑发生在上线第三周：客户那边突然涌进来一批英文合同，Qwen2.5虽然学过英语，但微调数据100%是中文，模型看到大段英文就慌了，开始自动脑补成中文，生成的摘要里出现“出租人应当于交割日交付房屋的possession”，这种中英混写的玩意儿直接让审计部门怀疑模型有后门。

我没辙，只能紧急上了数据漂移监控。方案很简单：用sentence-transformers把每次请求的文本embedding化，跟训练集中的文本做余弦相似度，掉出阈值（我设的0.65）就自动降级到微调前的基础模型权重，同时发告警给我。这部分代码我放在fastapi的中间件里了，大概长这样：

from sentence_transformers import SentenceTransformer, util
import numpy as np

# 加载轻量embedding模型，监控用，不占显存
monitor_model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')
# 从训练集随机采500条算一个平均嵌入作为“领域锚点”
train_embeddings = ...  # 预先算好存进redis的向量
anchor = np.mean(train_embeddings, axis=0)

async def drift_check(request_text: str):
    emb = monitor_model.encode([request_text])
    sim = util.cos_sim(emb, anchor).item()
    if sim < 0.65:
        # 触发降级，切换为base model的vLLM后端
        logger.warning(f"Drift detected, sim={sim}, fallback to base model.")
        return "fallback"
    return "fine_tuned"

这个简单的监控救了我好几次命。除英文合同外，有次客户上传了一份全是表格的PDF，文本提取回来变成一堆空格对齐的ASCII art，相似度直接掉到0.2，幸好拦截及时，没让微调模型胡言乱语。不过这里得提一嘴：sentence-transformers本身也有推理开销，如果请求量很大，建议把它异步化，或者定期抽样检查，不要每个请求都卡一下。

持续迭代这块，我建了个反馈回路：法务在使用时可以直接点“结果报错”，这个报错连带原始输入和纠正后的输出会自动入湖，每隔两周我把新数据合并进训练集，重新LoRA微调一版，再用vLLM热加载新权重。vLLM的热加载功能真的绝了，只要把新模型目录软链接过去，发送SIGHUP信号，它就能无中断切模型，用户完全感知不到。

最后说点钱的事。整个方案硬件成本就两台A100（其实后来我发现2×A100 40GB在并发不高时也能跑，但为了留余量才加到了80GB卡），比起直接买某厂的私有化API授权便宜了不止一个数量级。而且因为完全内网部署，客户的数据一张纸都没流出去，安全考核直接绿灯。对那些天天被数据合规追着跑的企业来说，Qwen2.5这条开源私有化的路，真的走得通，也走得起。

如果你现在就要开干，记住我这几条吐血总结：推理必选vLLM，微调认准LoRA加LLaMA-Factory，上线后必须搞数据漂移监控，回滚策略提前备好。别问我怎么知道的，我的黑眼圈会告诉你一切。