1. 一套开源权重和一套能用的服务之间差的不是模型而是流程最近我经常被问到一类问题开源大模型已经满天飞下载一个权重就能跑起来为什么实际做项目时还要花时间讨论训练、微调和推理框架很多人把“会用 Transformers 库”和“能把大模型放到业务里”混为一谈结果模型加载成功了到了高并发、长文本、任务定制这些环节就全露馅。我的理解是这样大模型的落地本质上不是“模型”问题而是“流程”问题。一条完整的项目链路可以粗略分成预训练、微调、推理三个阶段每个阶段有完全不同的瓶颈、成本结构和工程方法论。预训练是在海量文本上学习语言和知识决定模型的上限微调是把模型的普适能力校准到你的业务分布上决定模型有没有用推理部署则是把参数转化为每秒几十次的在线服务决定体验能不能成立。三个词放在一起说叫“全流程”但它们的优化目标几乎不共享。训练追求吞吐量微调追求参数效率和方向校准推理追求延迟和显存利用。这篇文章面向两种人一种是从算法转向工程的开发者手里拿过开源模型想系统理解框架怎么选、资源怎么算另一种是已经开始用大模型做产品但总觉得训练、微调、部署之间缺少一条方法论主线。我尽力把底层逻辑和工程落地的关键决策讲清楚也会给可以直接抄作业的配置和命令。2. 训练阶段的本质把模型拆开塞进显存然后让所有 GPU 假装成一个整体2.1 为什么单卡跑 7B 全参训练这么尴尬先做一个显存估算。一个 7B 参数规模的模型如果只用 FP16 做前向和反向权重本身就要 14GB这个数看起来不大但训练不等于只存权重。常用 AdamW 优化器配混合精度时没有做任何显存优化的情况下每个参数至少要占 16 到 20 字节FP16 权重占 2 字节、FP32 的 master weight 占 4 字节、Adam 的 momentum 和 variance 分别占 4 字节、梯度再占 2 到 4 字节。按一个参数 16 字节粗略算7B 模型光“参数、梯度、优化器状态”就要 112GB 上下这还没算中间激活和临时缓冲区。所以你会看到一个很常见的现象拿 A100 80G 跑 7B 全参微调只要序列长度稍微拉长、batch 稍微调大显存就直接爆掉。市面上大多数训练框架核心工作其实就两件事一是把这块巨大的状态切成很多份二是设计高效的通信方案让切出去的碎片在逻辑上仍然保持一致。如果你对显存和并行没有一个基本概念拿到 DeepSpeed、Megatron、FSDP 这些框架时会很难受因为它们解决的正是同一个问题的不同切法。2.2 并行方案那么多到底在切什么要理解并行先要分清模型训练时哪些东西可以切。最常见的是数据并行每个 GPU 放一份完整的模型副本各自处理不同的 batch训练完同步梯度。一个 7B 模型用 16 张卡做 DDP显存需求仍然是单份全参训练的大小只是吞吐量上去了所以它省不了显存。ZeRO 把 DDP 里的冗余给去掉了。Stage 1 只切分优化器状态Stage 2 在 Stage 1 基础上连梯度也开始切分Stage 3 更进一步把模型参数本身也分片存储。我用得最多的是 Stage 2 和 Stage 3。Stage 2 适合单机多卡、模型放得下一份完整参数的场景通信开销可控Stage 3 适合模型大到单卡完全塞不下的场景但每个 Transformer 层的前向反向都要做 all-gather 和 reduce-scatter通信压力明显更大多机场景尤其明显。张量并行和流水线并行是另一条路。张量并行把 Transformer 一层的权重按 row 或 column 切到多卡比如 QKV 矩阵让不同 GPU 各算一部分适合单机内 NVLink 带宽高的环境因为每算一个小步骤都要同步。流水线并行则是按层切GPU 0 算第 1 到第 8 层GPU 1 算第 9 到第 16 层数据是一段一段往下“流”的通信频率低一些但会留下流水线气泡。理解这点你想选型时就不会被名词绕晕数据并行是各算各的然后同步梯度张量并行是把一次计算拆开一起做流水线并行是把计算切到不同阶段轮流做ZeRO 是把状态分散到各卡之后仍然“拼成”一个完整模型。2.3 DeepSpeed、Megatron、FSDP 分别适合什么场景这里我给一个非常主观但实用的对比。DeepSpeed 的核心优势是 ZeRO 和 offload对 PyTorch 生态的改动小命令行接入方式成熟绝大多数想用十几张卡跑微调或继续预训练的团队第一选择就是它。Megatron-LM 擅长 3D 并行把数据并行、张量并行、流水线并行组合到一起适合从头预训练或超大模型场景但代码改动成本也更高。PyTorch 原生 FSDP 和 DeepSpeed Stage 3 思路接近好处是不引入额外框架版本兼容风险小PyTorch 2.x 项目里我用得更顺。框架主要切分思路上手成本最合适的场景DeepSpeedZeRO-1/2/3 offload中低中大规模微调、继续预训练Megatron-LM张量并行 流水线并行 数据并行高百亿以上模型预训练、NVLink 高带宽集群PyTorch FSDP参数/梯度/优化器状态分片低想少引依赖直接用 PyTorch 原生生态我的个人建议是你连分布式训练都是刚上手我建议先别碰 Megatron。用 DeepSpeed Stage 2 就能覆盖大多数 7B 到 13B 的微调场景实在要预训练超大模型自然会遇到瓶颈那时候再切 Megatron 也不迟。不要一开始就把自己的系统复杂度拉满通信 bug 排查起来比模型算法问题痛苦得多。2.4 一份能直接跑的 DeepSpeed 配置长什么样以 7B 模型全参微调或者继续预训练为例我用过一个比较稳的 DeepSpeed 配置deepspeed --num_gpus8 train.py \ --model_name_or_path Qwen/Qwen2.5-7B \ --deepspeed ds_config.jsonds_config.json关键字段大概是这样{ train_batch_size: auto, train_micro_batch_size_per_gpu: 2, gradient_accumulation_steps: auto, zero_optimization: { stage: 2, offload_optimizer: { device: cpu, pin_memory: true } }, optimizer: { type: AdamW, params: { lr: auto, betas: auto, eps: auto, weight_decay: auto } }, scheduler: { type: WarmupCosineLR, params: { warmup_min_lr: auto, warmup_max_lr: auto, warmup_num_steps: auto } } }几个字段慢慢解释。train_batch_size是整个任务期待达到的全局 batchtrain_micro_batch_size_per_gpu是每张卡前向反向一次的真实 batch size两者之间由gradient_accumulation_steps连接。举个例子如果全局 batch 是 648 张卡每卡 micro batch 是 2那一次梯度更新前需要累积 64 ÷ (8 × 2) 4 步。用auto后框架会自动帮你推但你必须保证传入的训练脚本里的 per_device_train_batch_size 和配置里能对应上。offload optimizer 到 CPU 是我在显存紧张时很喜欢开的选项。它的代价是 CPU 内存换了一些训练速度但数据并行下配合 gradient accumulation训练吞吐下降通常能接受。如果连 Stage 2 都塞不下再考虑 Stage 3 加参数 offload。我开始分布式训练时踩过的最大坑是学习率没有重新调原来单卡 batch 8 用 2e-5换到 8 卡 global batch 32 后还保持 2e-5结果 loss 飞得很高。线性缩放学习率有一些实际争议但保守做法是当 global batch 明显变大时先把学习率略微下调再用一小段训练做验证。3. 微调是“定向培养”不是把整个语言模型推倒重来3.1 先判断这个问题到底该用提示词、RAG还是微调很多人一上来就说“我要微调模型把业务做掉”。我得泼一盆冷水很多 NLP 场景根本不需要微调用提示词工程加检索增强就够了。什么时候该微调我给你一个判断顺序。如果你的任务把 prompt 调好就能做到七八成那就先别动模型。比如翻译、改写、通用问答这些能力大模型已经很熟了。如果你的任务需要依赖私有知识、实时数据或者用户问题是开放式的那先考虑检索增强生成把文档切片、向量化、召回后拼进 prompt。检索增强的主要好处是不改权重资料更新只需要换库出现错误也不用重新训练。只有当任务存在稳定的输入输出格式、特定领域术语、非常独特的行为偏好并且通过提示词很难稳定约束时微调才真正值得做。一个典型例子售后工单的总结必须输出固定字段还要区分退款原因、情绪倾向、责任方这时候微调比写一堆 prompt 规则可靠得多。我的经验是微调前的数据准备至少要占整个项目的一半时间。你说你要做“领域指令微调”但数据格式是否统一、坏样本是否清理过、指令是否覆盖真实场景这些决定最终效果的下限。框架只是把数据送进模型的手段数据质量差再牛的框架也救不回来。3.2 全量微调、Freeze 微调和 LoRA到底怎么选全量微调会更新模型所有参数适合目标数据分布和原始分布有明显差异的情况或者你要把模型重新培养成一个完全不同风格的助手。代价是显存和算力门槛都很高7B 全参微调用我之前算过的账单卡基本跑不动。Freeze 微调的意思是冻结大部分层只训练最后几层或者某些模块。这个策略的优点是在不损失太多效果的前提下显著减少可训练参数但缺点是你需要提前判断到底该解冻哪些层这个判断经常不准。早期很多人微调 Bert 时习惯只调顶层分类头但对生成式大模型而言“表达风格”并不只在最后一层这种行为调整往往很浅。LoRA 是目前我默认的选择。它不是冻结整个模型而是在线性层旁边添加一个小型低秩旁路只训练旁路参数。它最大的优势是无需为 7B 的每个参数保存优化器状态训练参数的量级可能只有原来的百分之一甚至更少显存压力大幅下降。我的基本策略是任务陌生、数据量大于几万条、且要求效果极限优先考虑全量微调如果只是想改变输出风格、套用一个领域术语体系、或者让模型学会特定 JSON 格式LoRA 通常是性价比最高且效果最稳的选择。方案可训练参数7B 单卡显存压力稳定风险点推荐场景全量微调全部很高普遍需要多卡并行数据噪声会被完整记住过拟合风险大大规模领域继续预训练、数据充分、算力充足Freeze 微调部分层中解冻层选择依赖经验容易欠拟合或过拟合少量参数适配浅层格式LoRA/QLoRA低秩旁路低到中rank 设置不合理可能欠拟合大部分业务定制、指令微调、格式学习3.3 LoRA 的“低秩”到底是什么意思LoRA 的核心思想可以用一句话解释微调阶段的大模型并不需要那么高的参数量去改变行为权重更新矩阵可以近似成一个很低秩的矩阵。假设某个线性层的权重是 W0维度是 d × dLoRA 会冻结 W0同时引入两个小矩阵 A 和 B让新增的更新量等于 B × A其中 A 的维度是 r × dB 的维度是 d × rr 往往只有 8、16、32。这样实际参与更新的参数从 d×d 降到了 2×d×r。当 d 是 4096r 是 16 时可训练参数量直接缩小了三个数量级以上。为什么这么小的参数改动可以不明显损害模型能力因为微调的理想状态不是彻底改变预训练学到的语言能力而是在原有语义空间里往目标任务方向“拨动”一个子空间方向。底层语义大多数时候是共享的真正需要的变化没那么复杂。LoRA 论文特别强调一个实际工程价值因为 W0 被冻结你可以同时维护多个任务对应的低秩旁路推理时选不同旁路合并而不是每个任务保存一个完整副本。在 LlamaFactory 这类工具里你只需要设置lora_rank16、lora_alpha32即可。lora_alpha可以理解为对低秩更新施加的缩放系数常见的经验是 alpha 取 rank 的 2 倍左右。不是 rank 越大越好我在小数据集上经常发现 r64 的 LoRA 反而比 r16 更容易过拟合。因为低秩更新本身是一种正则化设置过大的秩相当于削弱了这个正则效应。3.4 实操用 LlamaFactory 微调 Qwen2.5-7B 的思路很多团队不用从零写训练循环LlamaFactory 已经封装得比较完善。它把 SFT、LoRA、DPO 这些常见流程都预置好了还支持 Web UI 和命令行。我的习惯是在命令行里操作这样便于版本管理和重复执行。数据准备阶段LlamaFactory 会把数据集配置放在data/dataset_info.json里指向一份 JSON 文件。以指令微调样本为例理想格式是[ { instruction: 请把下面的售后记录转成结构化工单原因、责任方、建议动作。, input: 用户反映收到货后外包装破损产品屏幕碎裂要求换货。, output: 原因物流运输导致外包装破损责任方物流方建议动作补发一台新机并联系物流赔付。 } ]然后执行 SFT 的命令大致是llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B \ --stage sft \ --finetuning_type lora \ --dataset my_scene_data \ --template qwen \ --lora_rank 16 \ --lora_alpha 32 \ --output_dir output/my_lora \ --num_train_epochs 3 \ --learning_rate 1e-4 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --max_length 2048 \ --lr_scheduler_type cosine \ --warmup_ratio 0.1这套参数里的细节很多。per_device_train_batch_size2配合gradient_accumulation_steps8意味着更新一次梯度实际看了 16 条样本这个量对 7B 来说非常常见。learning_rate1e-4是 LoRA 类训练中常见的范围如果做全量微调通常要降到 1e-5 甚至更低。max_length设为 2048 意味着超过长度的样本会被截断如果你的业务文档普遍偏长这里要谨慎调因为长度越长显存和训练时间越长不是所有任务都需要完整保留长上下文。微调完成后要进行 LoRA 权重合并。在 LlamaFactory 里有对应命令本质是把 W0 scale × B × A 算回去并保存成完整权重。这一步千万不能省尤其当你把模型交给推理框架加载时如果推理框架不支持 PEFT adapter直接加载原始权重加 LoRA 权重文件很可能会得到错误输出。3.5 微调训练的几个“危险信号”和排查方法我最常看到的失败模式是 loss 一路下降看起来训练很顺利但真实业务测试一塌糊涂。出现这种问题大概率是训练时数据分布和推理时任务分布不一致或者模型只是背下了训练集里的格式而不是真正学会了任务推理。排查时不要只盯训练 loss。我会把训练集拿去随机抽 10 条看模型输出如果连训练集都复述不出正确内容说明欠拟合考虑调大 epoch、调低学习率、检查数据截断如果训练集输出完美但测试集输出崩坏第一反应是过拟合优先减少 epoch、增强数据多样性、降低 LoRA rank。还要警惕“格式记忆”问题模型学会了输出 JSON 外壳但里面的字段靠模仿训练集模板而不是真正理解这种情况通常是因为训练样本的同质化太严重需要加入更多反例和边界样本以及多样化的指令表达。4. 推理框架的账本显存复用、吞吐优化和量化带来的边界4.1 推理的性能逻辑为什么和训练不一样很多从训练切到推理的工程师一开始会不适应。训练阶段你可以接受一次前向反向跑几秒甚至几分钟因为目标是最大化单位时间能处理的 token 数推理阶段每一次请求都对应真实用户的等待首 token 延迟、单 token 生成速度、吞吐上限都会直接影响产品体验。还有一个本质差异训练时大量矩阵乘法能充分利用 GPU 算力推理时模型权重是固定的一个请求从 prompt 输入到逐个 token 输出每一步都需要扫一遍权重加计算注意力但实际新增的计算量很小所以推理很多时候是“访存密集”而不是“计算密集”。模型权重在显存里的读取带宽往往比 GPU 核心的 FLOPS 更早触顶。这就解释了为什么同一个 GPU训练时跑得挺快推理时却经常发现 GPU 利用率不高。很多新手看到 GPU 利用率只有 30% 就怀疑服务有问题其实对自回归推理来说低利用率不一定异常你需要关注的是并发压力和显存复用是否到位。推理框架解决的核心问题就是如何在多用户并发下尽量复用已经读进显存的数据、减少空闲等待、提高整体吞吐量。4.2 KV Cache 和 PagedAttention模型每一次生成都要掂量这笔账大模型推理的每个请求都会维护一个不断增长的键值缓存叫 KV Cache。每生成一个新 token都要把此前所有 token 的 Key 和 Value 记录缓存下来避免重复计算但这也导致显存占用随序列长度和并发数线性增长。我按 Qwen2.5-7B 的参数感性地算一笔账它有 28 层4 个 KV 头每个头的维度是 128FP16 精度下每个 token 的 KV Cache 大约要 56KB。如果并发 32 个请求、每个请求的上下文长度 4096那光 KV Cache 就要占 7GB 左右这还不算显存里还要放权重和激活。所以推理框架早就不像我们想的那样只负责把模型加载进去然后 forward 一次。vLLM 这样的框架提出了 PagedAttention 来管理 KV Cache思路非常像操作系统对物理内存的分页管理把 KV Cache 切分成固定大小的块按需分配减少显存碎片同时让多个请求可以共享相同前缀的 KV Cache。这部分设计对长上下文和 high 并发场景的提升是决定性的。OpenAI 兼容接口普及之后vLLM 很容易接入现有链路本地起的服务看起来就是一个标准的chat/completions接口。在显存紧张时我的第一反应不是换小模型而是先检查 KV Cache 的分配策略。模型能支持的并发数不完全由参数量决定还跟 max-model-len、每请求平均长度、量化方式有关。调低max-model-len能够直接释放 KV Cache 空间当产品场景本身不需要 32K 上下文时一个 8K 上限通常可以换到更多并发能力。4.3 量化不是免费午餐要看你的下游任务吃不吃得下推理阶段量化几乎成了标配。GPTQ 和 AWQ 都是在离线阶段把 FP16 权重压缩到 INT4 或 INT8然后推理框架加载压缩后的权重。AWQ 的做法是根据激活值统计找到对模型输出更重要的权重通道在量化时给予更多保护因此在小模型和敏感任务上表现往往更稳。GGUF 则是从 llama.cpp 生态流行起来的格式Ollama 这类工具大量使用它好处是可以灵活选不同量化等级CPU 和消费级 GPU 都能跑。这里必须强调一个容易被忽视的事实量化损失不是均匀分布的。如果你只是做通用对话模型说不定能承受一定的量化损失但当任务涉及代码生成、严格 JSON 输出、函数调用或者抽取实体边界时4bit 量化经常会出现字段缺失、括号配平错误、甚至凭空多出一个参数的问题。我自己做过的项目中用 AWQ 4bit 跑普通客服问答没什么问题但跑工单结构化抽取时错误率明显比 FP16 高。所以推理方案的确定千万别只在几个样例上判断行不行最好准备一组带严格比对的测试集把 FP16 和不同量化等级放在同一批请求上跑对比。4.4 vLLM、TGI、SGLang、Ollama、llama.cpp选型参照现在市面上的推理框架非常多我列出使用场景上差异最明显的几个。vLLM 是目前在线服务场景最主流的选择吞吐量优化好OpenAI 兼容接口完善社区资料多遇到问题基本能搜到答案。Hugging Face 的 TGI 也很成熟与 Transformers 生态衔接天然但实际表现上 vLLM 的优化更激进。SGLang 引入了 RadixAttention对共享前缀的 prompt 缓存特别有利如果你们的请求里有很多相同系统提示词或者固定前缀可以重点试它。Ollama 和 llama.cpp 更适合本地开发、个人电脑、小并发场景它们强在安装简单、量化灵活不适合做高并发在线服务。TensorRT-LLM 是 NVIDIA 系的深度优化方案能做图融合、运行时优化、动态 shape 等适合极致的线上吞吐要求但开发和维护成本也高通常用于搜推广这类流量极大的业务。目标检测、图像类任务里会看到很多 TensorRT engine 的概念和本文说的 LLM 推理框架不是一回事类似yolo engine常指的是 TensorRT 序列化后的加速模型千万别混用。框架所属生态并发优化最典型使用场景vLLM开源社区连续批处理 PagedAttention高并发服务、OpenAI 兼容 APITGIHugging Face连续批处理Transformers 生态快速部署SGLang开源社区RadixAttention、结构化输出优化大量共享前缀、Agent 场景TensorRT-LLMNVIDIA图优化、kernel 级优化极致吞吐、生产环境高优化需求Ollama / llama.cpp本地生态简单并发控制开发调试、离线单机运行我用 vLLM 启动在线服务的命令大致是vllm serve Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --max-num-seqs 32 \ --dtype autogpu-memory-utilization 0.85表示让 vLLM 尽量使用 85% 的显存作为 KV Cache 和运行缓冲剩下 15% 留给一些动态显存需求。max-num-seqs控制并发请求上限调得太高容易导致排队或者 OOM调得太低又无法压满吞吐。比较务实的做法是先按最大并发 16 到 32 起压测后看首 token 延迟和 P99 延迟再上下调整。4.5 吞吐、时延和显存真的能同时兼顾吗推理优化的核心其实是在三个维度上找平衡你想服务更多并发请求就可能让每个请求排队更长TTFT首 token 时间上升你想降低单个请求延迟就要给更多并发资源可能降低吞吐你想提升并发上限KV Cache 就要吃更多显存。不可能三角的味道弥漫在每一步决策里。所以接受现实不是所有场景都需要最低延迟。离线批处理任务更看重吞吐可以让 batch 尽量大、最大并发尽量高在线客服场景更看重 P95/P99 延迟需要限制并发请求数来保护单请求体验。没有一套参数适合所有服务部署上线前最好根据自己真实流量做一次压测用脚本模拟不同并发和提示词长度记录 TTFT、单 token 生成速度和错误率。相比训练阶段可以慢慢调推理阶段每一次修改都能很快用压测验证值得多花时间。5. 端到端闭环里那些容易被忽略的“脏活累活”5.1 从实际业务问题到微调数据的完整路线我建议把项目切成六个环节业务问题定义、数据准备、实验管理、模型微调、服务部署、线上观测。大多数人会把精力放在训练和部署上但我越来越相信数据准备和业务问题定义才是决定成败的地方。先明确你希望模型在什么输入下做出什么输出。比如客服文本分类任务你要收集真实会话记录把这些记录拆成“问题描述”和“期望回复”的对子。数据不是越多越好质量差的大规模数据可能反而让模型学到错误模式几千条精心挑选的样本往往效果会比十万条冗余样本更好。清洗时我会做几件事去掉重复、去掉明显的 OCR 乱码、去掉格式极端不合理的数据、把答案里直接复制原文的情况标记出来否则模型会学成“抄写员”。实验管理也值得从一开始就做。每个版本至少要在训练目录里保存数据集版本、数据文件 hash、微调参数、训练日志、验证集表现。我有一次微调效果回退排查半天发现是同事改了训练集里一个字段的映射方式但没人记录。后来我强行把版本信息写进 checkpoint 文件名比如qwen7b_lora_v3_data20240601_r16_ep3再也不靠记忆追溯了。5.2 模型微调完上线前的评估不能只看 loss评估分两层一层是通用能力回归另一层是业务场景回归。通用能力可以选开源评测集看模型有没有“变笨”业务场景回归必须自己构造。我的做法是从真实用户问题里挑出 30 到 100 条作为冒烟集每条给出预期行为描述比如“必须识别收货地址”“不得把退款原因归结为用户”“输出必须是合法 JSON”。每次训练完用固定 Prompt 和固定温度让模型跑一遍这批数据人工或脚本跑分。一个很容易被忽略的细节是温度参数对评估的影响。评估时如果把 temperature 调得过高同一个输入可能输出差异很大难以对比不同 checkpoint 的稳定表现。我一般用 temperature0 或接近 0 来测确定性任务用 temperature 偏高来测创造性任务。上线前还要重点做一次“拒绝类样本”验证看看模型会不会在它不该回答的问题上也强答比如不在业务范围内的闲聊这时你希望它明确说不知道而不是编一个答案。5.3 部署之后还有几条容易踩的路第一Transformer 的模板一致性。微调阶段用的 chat template 和推理阶段必须完全一致如果你训练时用了 Qwen 模板上线时却直接拼了一句 “System: …” 而没有走 tokenizer 的 chat template模型很可能会出现极其别扭的格式。解决方法是训练和推理都统一走模版函数别自己在外面拼。第二LoRA 合并后不能把测试建立在 adapter 加载这种临时方案上。我之前偷懒在推理脚本里动态挂 LoRA adapter 做测试模型输出看着没问题后来换到正式的合并权重方案结果出现了明显差异。原因可能是注意力层排序或者缩放倍数实现不完全一致所以请在上线前以合并完的完整权重路径做一次端到端回归。第三用 OpenAI 兼容客户端接入时base URL、model name 和 API key 看起来简单但很容易配错。vLLM 启动时--served-model-name决定客户端请求里 model 字段如果默认的模型名和客户端配置不一致服务端会返回 model not found。这个小问题在框架升级后尤其容易出现。第四服务的超时和重试策略要设计。大模型推理天然比普通接口慢一个长请求可能超过 30 秒网关层的 read timeout 如果设得比模型最大生成时间还短用户就会莫名收到超时错误。我处理过的线上故障里有很大比例不是模型变笨了而是 batch 内的慢请求拖垮了 P99然后网关误报为模型异常。5.4 我现在的固定操作习惯给后来者少走弯路做了几年大模型项目我的固定心法是默认先上 LoRA而不是全参默认先收集 100 条真实业务样本做冒烟集而不是急着把训练集扩到几十万默认评估脚本和训练脚本一起提交而不是评估代码单独放在某个人的笔记本里推理阶段优先用 vLLM 的 OpenAI 兼容接口能少写一层 Web 封装。如果产品需求还在频繁变化就别过早做全量微调和量化优化先用 prompt 工程和 RAG 扛住变化等到交互形态稳定下来再固化到模型权重里。从训练、微调到推理每个环节都存在可以深挖的优化空间但优秀工程实践一定是在正确优先级上分配有限资源。需要先跑通最简单闭环随后你自然会遇到该优化的地方。个人觉得最值得做的提前量