1. 大模型训练师到底在做什么先把一个常见的误解掰开大模型训练师不是“给模型喂数据的人”也不是“标注工人”换个高级名字。这个岗位真正在做的事是把一个通用的、什么都懂一点但什么都不精的基座模型通过一系列工程手段变成在特定业务场景下“能干活、干得稳、成本可控”的生产力工具。它横跨了数据处理、分布式训练、微调策略、效果评估、推理部署这几条线任何一条断了最终交付的东西都是半成品。我见过太多团队踩同一个坑算法同学在实验室里用单卡把 loss 调得很漂亮一上生产环境就崩——吞吐上不去、显存爆掉、并发一高延迟飙到十几秒。问题不在模型本身而在于没人从“训练师”的全局视角去统筹这件事。大模型训练师的核心价值恰恰是填补“论文里的模型”和“线上跑得动的服务”之间那条巨大的鸿沟。这个岗位适合谁如果你是算法工程师想从传统 CV/NLP 往大模型方向转这是最自然的路径如果你是后端或运维出身对分布式系统和资源调度有感觉补上微调和评估的知识也能切入如果你是刚入行的学生跟着一条完整的“环境配置 → 数据准备 → 微调 → 部署 → 评估”链路走一遍比零散看十篇论文都管用。下面我按实际项目推进的顺序把每个环节的坑和门道讲透。2. 训练前的整体设计与方案选型2.1 先想清楚全量训练、微调还是提示工程动手写第一行代码之前最该问自己的问题是这个需求到底需不需要“训练”。很多人一上来就想微调结果发现用精心设计的提示词加少量示例就能解决白白烧了几十张卡的机时。我的判断顺序是这样的提示工程优先任务规则清晰、输出格式固定、领域知识不深先用 few-shot 提示跑一批测试集。成本几乎为零一天内能出结论。微调Fine-tuning其次任务需要模型掌握特定风格、特定领域术语、特定输出结构且提示工程效果不稳定时上微调。全量预训练最后只有当你手里有海量领域语料几十 GB 起步、且通用模型完全不具备该领域能力时才考虑继续预训练。绝大多数业务场景根本用不到这一步。这里有个经验数据在垂直行业法律、医疗、金融的问答任务上一个 7B 级别的模型做 LoRA 微调效果往往能逼近甚至超过直接调用更大的通用模型而推理成本只有后者的几分之一。这就是微调的价值所在。2.2 基座模型怎么选不是越大越好选基座模型是训练师最关键的决策之一直接决定后续所有工作的成本上限。我的选型维度有这么几个维度考量点常见取舍参数量7B / 13B / 70B7B 适合单卡或双卡微调70B 需要多卡并行中文能力词表覆盖、语料占比国产开源模型中文通常更稳许可证商用是否受限商用项目必须确认 license生态工具是否被主流框架支持影响微调和部署的便利度显存占用FP16 / INT8 / INT4决定你能用什么硬件举个具体的账一个 7B 模型FP16 精度下光权重就要占约 14GB 显存加上优化器状态、梯度、激活值全量微调轻松突破 60GB单张消费级卡根本放不下。而用 LoRA 只训练低秩适配矩阵可训练参数降到原来的百分之几显存需求直接砍到 10GB 出头一张 24GB 的卡就能跑起来。这就是为什么现在个人和小团队做微调几乎默认从 LoRA 起步。提示选模型时别只看榜单分数。榜单高的模型未必适合你的任务一定要拿自己的真实数据做小样本对比测试跑个几十条看输出质量比看任何排行榜都靠谱。2.3 硬件与并行策略的匹配硬件决定了你能用什么并行策略这是绕不开的物理约束。常见的几种并行方式我按适用场景排一下数据并行DP每张卡放一份完整模型数据切分。适合模型能塞进单卡的情况实现最简单。张量并行TP把单层内的矩阵运算切开分到多卡。适合单层就很大的模型但卡间通信量大对带宽要求高。流水线并行PP把不同层分到不同卡。适合层数多的深层模型但会有流水线气泡利用率受影响。ZeRO 系列本质是优化器状态、梯度、参数的分片DeepSpeed 的核心贡献能在数据并行基础上大幅省显存。实际项目里7B 模型微调通常一张或两张卡用 LoRA 就够了13B 可能需要 ZeRO-2 或 ZeRO-370B 级别才需要 TPPP 组合。别一上来就搞最复杂的并行方案先用最简单的跑通遇到显存瓶颈再逐级加码这是最省时间的路径。3. 数据准备决定成败的隐形战场3.1 数据质量比数量重要一百倍我做过一个对比实验同样一个 7B 模型用 5000 条精挑细选的高质量指令数据微调效果明显好过用 5 万条从网上爬来的脏数据。原因很简单大模型微调阶段学的是“模式和风格”脏数据里的错误、矛盾、低质表达会被模型照单全收。什么样的数据算高质量我的标准是三条指令清晰无歧义、回答准确且完整、格式统一规范。尤其是格式微调数据里如果一会儿用 JSON、一会儿用自然语言、一会儿又混着 markdown模型学出来的输出会非常不稳定。数据格式上指令微调最通用的是这种结构{ instruction: 把下面这段话翻译成英文, input: 今天天气很好, output: The weather is nice today. }如果是多轮对话就改成 messages 数组的形式每条带 role 字段system / user / assistant。这个结构几乎所有主流微调框架都认省得你来回转换。3.2 数据清洗的实操清单清洗这一步没有捷径但有一套可复用的流程。我通常按这个顺序过一遍去重完全重复的直接删近似重复的用编辑距离或语义相似度筛。重复数据会让模型过拟合到特定表达。长度过滤太短的比如少于 5 个 token通常是噪声太长的超过模型上下文窗口要截断或拆分。格式校验检查每条数据字段是否齐全JSON 是否能正常解析有没有缺 output 的残缺样本。敏感与违规内容筛查这一步必须做用关键词加分类模型双重过滤避免把不合规内容喂进模型。质量抽检随机抽 100 条人工看一遍这一步能发现自动化脚本漏掉的大量问题。注意数据清洗脚本一定要保留原始数据的备份和清洗日志。我踩过的坑是清洗规则写错把一批好数据误删了结果没有备份只能重来。清洗过程要可追溯、可回滚。3.3 数据配比与采样策略如果你的微调数据来自多个来源比如既有客服对话又有产品文档问答配比就很重要。我的经验是核心业务场景的数据占比不低于 60%其余用通用数据补充防止模型在微调后“忘记”通用能力也就是所谓的灾难性遗忘。采样时还要注意类别均衡。如果某个意图的样本特别多模型会偏向输出这一类。可以对少数类做上采样或对多数类做下采样让各类别大致均衡。具体比例没有定论跑一版评估看混淆矩阵再调比拍脑袋定比例靠谱。4. 微调实操从环境到跑通第一个模型4.1 环境配置的避坑要点环境配置是新手最容易卡住的地方CUDA 版本、PyTorch 版本、驱动版本三者不匹配报错能让你怀疑人生。我的建议是优先用官方提供的 Docker 镜像或 conda 环境文件别自己一个个 pip install 去凑。一个典型的微调环境需要这些组件CUDA Toolkit版本要和显卡驱动兼容PyTorch要和 CUDA 版本对应transformers、peft、datasets、accelerate 等 HuggingFace 生态库训练框架要么用 HuggingFace Trainer要么用 LLaMA-Factory 这类集成工具如果你只是想快速跑通我强烈推荐 LLaMA-Factory 或类似的一站式工具它把数据加载、LoRA 配置、训练、导出都封装好了改个配置文件就能跑。想深入理解原理再去看 HuggingFace 的原生写法。4.2 LoRA 微调的关键参数怎么定LoRA 有几个核心参数定得好不好直接决定效果和成本rank秩控制适配矩阵的大小。常用 8、16、32、64。任务越复杂、数据越多rank 可以适当调大。我一般从 16 起步效果不够再加。alpha缩放系数通常设为 rank 的 1 到 2 倍。alpha/rank 的比值影响适配强度。target_modules决定给哪些层加适配器。常见做法是给注意力层的 q、k、v、o 投影都加上效果比只加 q、v 更稳。dropout防过拟合小数据集上设 0.05 到 0.1。学习率方面LoRA 通常比全量微调大一些1e-4 到 3e-4 是常见区间。batch size 受显存限制可以用梯度累积来等效放大。比如单卡只能放 batch size 2设梯度累积 8 步等效 batch size 就是 16。4.3 训练过程的监控与早停训练不是设好参数就撒手不管。要盯几个关键指标loss 曲线训练 loss 稳定下降是好事但如果验证 loss 开始上升说明过拟合了该停。学习率调度通常用 cosine 或 linear 衰减warmup 阶段占总步数的 3% 到 10%。梯度范数如果梯度爆炸说明学习率太高或数据有问题需要调低学习率或加梯度裁剪。早停策略很实用每隔一定步数在验证集上评估一次连续几次没提升就停。这样既省机时又能拿到泛化最好的那个 checkpoint而不是训练到最后过拟合的版本。# 一个典型的 LoRA 微调启动命令示意 python train.py \ --model_name_or_path ./base_model \ --data_path ./data/train.json \ --lora_rank 16 \ --lora_alpha 32 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --output_dir ./output5. 效果评估别只看 loss5.1 自动评估与人工评估结合loss 降了不代表模型好用。我见过 loss 很低但输出全是套话的模型因为训练数据里套话太多模型学会了“安全但无用”的回答模式。所以评估必须多维度自动指标BLEU、ROUGE 适合有标准答案的任务但对开放式生成参考价值有限。模型打分用一个更强的模型给输出打分成本低、速度快适合大批量粗筛。人工评估抽一批样本人工看重点看准确性、流畅度、是否遵循指令。这是最终标准。评估集要独立于训练集且覆盖各类典型场景和边界情况。我一般会专门构造一批“刁钻”样本比如模糊指令、多意图混合、需要拒答的问题看模型怎么应对。5.2 常见的效果问题与归因模型效果不好先别急着调参按这个顺序排查现象可能原因排查方向输出格式乱训练数据格式不统一检查数据格式一致性答非所问指令数据质量差抽检训练样本重复啰嗦训练轮数过多减少 epoch 或早停通用能力下降灾难性遗忘混入通用数据特定场景差该场景数据不足补充针对性数据这个表我基本每次项目都会过一遍能快速定位大部分问题。6. 部署上线让模型真正跑起来6.1 推理框架的选择训练完的模型要部署成服务推理框架的选择直接影响吞吐和延迟。几个主流方案vLLM吞吐高支持 PagedAttention适合高并发场景是目前生产环境的主流选择。llama.cpp支持量化能在 CPU 或低显存设备上跑适合边缘部署和个人使用。Ollama封装度高一条命令拉起模型适合快速验证和本地开发。TGIHuggingFace 出品和生态集成好。选哪个取决于你的场景要高并发上 vLLM要低资源上 llama.cpp 量化版要快速验证上 Ollama。6.2 量化与显存优化部署阶段最大的约束还是显存。量化是最有效的手段INT8精度损失小显存减半大多数场景够用。INT4显存降到四分之一精度有一定损失但很多任务上感知不明显。一个 7B 模型 FP16 要 14GBINT4 量化后只要 4GB 左右一张普通显卡就能跑。代价是推理质量可能略降需要在自己的评估集上验证是否可接受。6.3 流式输出与并发处理用户体验上流式输出几乎是标配。用户不想等模型把整段话生成完才看到结果而是希望字一个个蹦出来。实现上用 SSEServer-Sent Events把生成的 token 逐步推给前端配合前端的 abort 机制用户还能中途取消。并发方面vLLM 的连续批处理能把多个请求动态合并大幅提升 GPU 利用率。实测下来同样的硬件用连续批处理比逐个请求处理的吞吐能高好几倍。7. 常见问题与排查实录7.1 显存不够怎么办这是最高频的问题。排查顺序先看是不是 batch size 太大调小或加梯度累积再看是不是用了全量微调换成 LoRA还不行就上量化或 ZeRO 优化最后才考虑换更大显存的卡。绝大多数情况在前两步就能解决。7.2 训练 loss 不下降先确认数据格式对不对标签有没有错位。然后检查学习率是不是太小或太大。如果用的是 LoRA确认 target_modules 有没有配对。我遇到过一次 loss 死活不降最后发现是数据里 output 字段全是空的白白浪费了半天。7.3 部署后延迟高先看是不是没用量化FP16 推理本身就慢。再看并发处理有没有开逐个请求处理会浪费大量 GPU 空闲时间。最后检查是不是 prompt 太长长上下文会显著增加首 token 延迟。7.4 模型输出不稳定多半是训练数据格式不统一或者推理时的 prompt 模板和训练时不一致。训练和推理的模板必须严格对齐这是很多人忽略的细节。训练时用什么格式推理时就得用什么格式差一个标点都可能影响输出。8. 我个人的一些实操体会做了一段时间大模型训练最大的感受是这活儿七分靠数据两分靠调参一分靠运气。很多人把精力全花在调参上却不肯在数据清洗上多花时间结果就是反复训练反复不满意。我现在的习惯是数据准备阶段花的时间至少占整个项目的一半剩下的才是训练和部署。另一个体会是别追求一步到位。先用小数据、小模型、LoRA 快速跑通全流程拿到一个能用的基线再逐步加数据、换大模型、调参数。这样每一步都有对比知道是什么带来了提升。一上来就憋大招往往连问题出在哪都找不到。最后分享一个容易被忽略的点保留完整的实验记录。每次训练的配置、数据版本、评估结果都记下来用表格管理。不然跑了几十次之后你根本记不清哪个 checkpoint 是用什么配置训出来的。这个习惯在需要复现或回滚时能救命。 大模型训练师实战指南：从微调、LoRA到部署全流程
1. 大模型训练师到底在做什么先把一个常见的误解掰开大模型训练师不是“给模型喂数据的人”也不是“标注工人”换个高级名字。这个岗位真正在做的事是把一个通用的、什么都懂一点但什么都不精的基座模型通过一系列工程手段变成在特定业务场景下“能干活、干得稳、成本可控”的生产力工具。它横跨了数据处理、分布式训练、微调策略、效果评估、推理部署这几条线任何一条断了最终交付的东西都是半成品。我见过太多团队踩同一个坑算法同学在实验室里用单卡把 loss 调得很漂亮一上生产环境就崩——吞吐上不去、显存爆掉、并发一高延迟飙到十几秒。问题不在模型本身而在于没人从“训练师”的全局视角去统筹这件事。大模型训练师的核心价值恰恰是填补“论文里的模型”和“线上跑得动的服务”之间那条巨大的鸿沟。这个岗位适合谁如果你是算法工程师想从传统 CV/NLP 往大模型方向转这是最自然的路径如果你是后端或运维出身对分布式系统和资源调度有感觉补上微调和评估的知识也能切入如果你是刚入行的学生跟着一条完整的“环境配置 → 数据准备 → 微调 → 部署 → 评估”链路走一遍比零散看十篇论文都管用。下面我按实际项目推进的顺序把每个环节的坑和门道讲透。2. 训练前的整体设计与方案选型2.1 先想清楚全量训练、微调还是提示工程动手写第一行代码之前最该问自己的问题是这个需求到底需不需要“训练”。很多人一上来就想微调结果发现用精心设计的提示词加少量示例就能解决白白烧了几十张卡的机时。我的判断顺序是这样的提示工程优先任务规则清晰、输出格式固定、领域知识不深先用 few-shot 提示跑一批测试集。成本几乎为零一天内能出结论。微调Fine-tuning其次任务需要模型掌握特定风格、特定领域术语、特定输出结构且提示工程效果不稳定时上微调。全量预训练最后只有当你手里有海量领域语料几十 GB 起步、且通用模型完全不具备该领域能力时才考虑继续预训练。绝大多数业务场景根本用不到这一步。这里有个经验数据在垂直行业法律、医疗、金融的问答任务上一个 7B 级别的模型做 LoRA 微调效果往往能逼近甚至超过直接调用更大的通用模型而推理成本只有后者的几分之一。这就是微调的价值所在。2.2 基座模型怎么选不是越大越好选基座模型是训练师最关键的决策之一直接决定后续所有工作的成本上限。我的选型维度有这么几个维度考量点常见取舍参数量7B / 13B / 70B7B 适合单卡或双卡微调70B 需要多卡并行中文能力词表覆盖、语料占比国产开源模型中文通常更稳许可证商用是否受限商用项目必须确认 license生态工具是否被主流框架支持影响微调和部署的便利度显存占用FP16 / INT8 / INT4决定你能用什么硬件举个具体的账一个 7B 模型FP16 精度下光权重就要占约 14GB 显存加上优化器状态、梯度、激活值全量微调轻松突破 60GB单张消费级卡根本放不下。而用 LoRA 只训练低秩适配矩阵可训练参数降到原来的百分之几显存需求直接砍到 10GB 出头一张 24GB 的卡就能跑起来。这就是为什么现在个人和小团队做微调几乎默认从 LoRA 起步。提示选模型时别只看榜单分数。榜单高的模型未必适合你的任务一定要拿自己的真实数据做小样本对比测试跑个几十条看输出质量比看任何排行榜都靠谱。2.3 硬件与并行策略的匹配硬件决定了你能用什么并行策略这是绕不开的物理约束。常见的几种并行方式我按适用场景排一下数据并行DP每张卡放一份完整模型数据切分。适合模型能塞进单卡的情况实现最简单。张量并行TP把单层内的矩阵运算切开分到多卡。适合单层就很大的模型但卡间通信量大对带宽要求高。流水线并行PP把不同层分到不同卡。适合层数多的深层模型但会有流水线气泡利用率受影响。ZeRO 系列本质是优化器状态、梯度、参数的分片DeepSpeed 的核心贡献能在数据并行基础上大幅省显存。实际项目里7B 模型微调通常一张或两张卡用 LoRA 就够了13B 可能需要 ZeRO-2 或 ZeRO-370B 级别才需要 TPPP 组合。别一上来就搞最复杂的并行方案先用最简单的跑通遇到显存瓶颈再逐级加码这是最省时间的路径。3. 数据准备决定成败的隐形战场3.1 数据质量比数量重要一百倍我做过一个对比实验同样一个 7B 模型用 5000 条精挑细选的高质量指令数据微调效果明显好过用 5 万条从网上爬来的脏数据。原因很简单大模型微调阶段学的是“模式和风格”脏数据里的错误、矛盾、低质表达会被模型照单全收。什么样的数据算高质量我的标准是三条指令清晰无歧义、回答准确且完整、格式统一规范。尤其是格式微调数据里如果一会儿用 JSON、一会儿用自然语言、一会儿又混着 markdown模型学出来的输出会非常不稳定。数据格式上指令微调最通用的是这种结构{ instruction: 把下面这段话翻译成英文, input: 今天天气很好, output: The weather is nice today. }如果是多轮对话就改成 messages 数组的形式每条带 role 字段system / user / assistant。这个结构几乎所有主流微调框架都认省得你来回转换。3.2 数据清洗的实操清单清洗这一步没有捷径但有一套可复用的流程。我通常按这个顺序过一遍去重完全重复的直接删近似重复的用编辑距离或语义相似度筛。重复数据会让模型过拟合到特定表达。长度过滤太短的比如少于 5 个 token通常是噪声太长的超过模型上下文窗口要截断或拆分。格式校验检查每条数据字段是否齐全JSON 是否能正常解析有没有缺 output 的残缺样本。敏感与违规内容筛查这一步必须做用关键词加分类模型双重过滤避免把不合规内容喂进模型。质量抽检随机抽 100 条人工看一遍这一步能发现自动化脚本漏掉的大量问题。注意数据清洗脚本一定要保留原始数据的备份和清洗日志。我踩过的坑是清洗规则写错把一批好数据误删了结果没有备份只能重来。清洗过程要可追溯、可回滚。3.3 数据配比与采样策略如果你的微调数据来自多个来源比如既有客服对话又有产品文档问答配比就很重要。我的经验是核心业务场景的数据占比不低于 60%其余用通用数据补充防止模型在微调后“忘记”通用能力也就是所谓的灾难性遗忘。采样时还要注意类别均衡。如果某个意图的样本特别多模型会偏向输出这一类。可以对少数类做上采样或对多数类做下采样让各类别大致均衡。具体比例没有定论跑一版评估看混淆矩阵再调比拍脑袋定比例靠谱。4. 微调实操从环境到跑通第一个模型4.1 环境配置的避坑要点环境配置是新手最容易卡住的地方CUDA 版本、PyTorch 版本、驱动版本三者不匹配报错能让你怀疑人生。我的建议是优先用官方提供的 Docker 镜像或 conda 环境文件别自己一个个 pip install 去凑。一个典型的微调环境需要这些组件CUDA Toolkit版本要和显卡驱动兼容PyTorch要和 CUDA 版本对应transformers、peft、datasets、accelerate 等 HuggingFace 生态库训练框架要么用 HuggingFace Trainer要么用 LLaMA-Factory 这类集成工具如果你只是想快速跑通我强烈推荐 LLaMA-Factory 或类似的一站式工具它把数据加载、LoRA 配置、训练、导出都封装好了改个配置文件就能跑。想深入理解原理再去看 HuggingFace 的原生写法。4.2 LoRA 微调的关键参数怎么定LoRA 有几个核心参数定得好不好直接决定效果和成本rank秩控制适配矩阵的大小。常用 8、16、32、64。任务越复杂、数据越多rank 可以适当调大。我一般从 16 起步效果不够再加。alpha缩放系数通常设为 rank 的 1 到 2 倍。alpha/rank 的比值影响适配强度。target_modules决定给哪些层加适配器。常见做法是给注意力层的 q、k、v、o 投影都加上效果比只加 q、v 更稳。dropout防过拟合小数据集上设 0.05 到 0.1。学习率方面LoRA 通常比全量微调大一些1e-4 到 3e-4 是常见区间。batch size 受显存限制可以用梯度累积来等效放大。比如单卡只能放 batch size 2设梯度累积 8 步等效 batch size 就是 16。4.3 训练过程的监控与早停训练不是设好参数就撒手不管。要盯几个关键指标loss 曲线训练 loss 稳定下降是好事但如果验证 loss 开始上升说明过拟合了该停。学习率调度通常用 cosine 或 linear 衰减warmup 阶段占总步数的 3% 到 10%。梯度范数如果梯度爆炸说明学习率太高或数据有问题需要调低学习率或加梯度裁剪。早停策略很实用每隔一定步数在验证集上评估一次连续几次没提升就停。这样既省机时又能拿到泛化最好的那个 checkpoint而不是训练到最后过拟合的版本。# 一个典型的 LoRA 微调启动命令示意 python train.py \ --model_name_or_path ./base_model \ --data_path ./data/train.json \ --lora_rank 16 \ --lora_alpha 32 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --output_dir ./output5. 效果评估别只看 loss5.1 自动评估与人工评估结合loss 降了不代表模型好用。我见过 loss 很低但输出全是套话的模型因为训练数据里套话太多模型学会了“安全但无用”的回答模式。所以评估必须多维度自动指标BLEU、ROUGE 适合有标准答案的任务但对开放式生成参考价值有限。模型打分用一个更强的模型给输出打分成本低、速度快适合大批量粗筛。人工评估抽一批样本人工看重点看准确性、流畅度、是否遵循指令。这是最终标准。评估集要独立于训练集且覆盖各类典型场景和边界情况。我一般会专门构造一批“刁钻”样本比如模糊指令、多意图混合、需要拒答的问题看模型怎么应对。5.2 常见的效果问题与归因模型效果不好先别急着调参按这个顺序排查现象可能原因排查方向输出格式乱训练数据格式不统一检查数据格式一致性答非所问指令数据质量差抽检训练样本重复啰嗦训练轮数过多减少 epoch 或早停通用能力下降灾难性遗忘混入通用数据特定场景差该场景数据不足补充针对性数据这个表我基本每次项目都会过一遍能快速定位大部分问题。6. 部署上线让模型真正跑起来6.1 推理框架的选择训练完的模型要部署成服务推理框架的选择直接影响吞吐和延迟。几个主流方案vLLM吞吐高支持 PagedAttention适合高并发场景是目前生产环境的主流选择。llama.cpp支持量化能在 CPU 或低显存设备上跑适合边缘部署和个人使用。Ollama封装度高一条命令拉起模型适合快速验证和本地开发。TGIHuggingFace 出品和生态集成好。选哪个取决于你的场景要高并发上 vLLM要低资源上 llama.cpp 量化版要快速验证上 Ollama。6.2 量化与显存优化部署阶段最大的约束还是显存。量化是最有效的手段INT8精度损失小显存减半大多数场景够用。INT4显存降到四分之一精度有一定损失但很多任务上感知不明显。一个 7B 模型 FP16 要 14GBINT4 量化后只要 4GB 左右一张普通显卡就能跑。代价是推理质量可能略降需要在自己的评估集上验证是否可接受。6.3 流式输出与并发处理用户体验上流式输出几乎是标配。用户不想等模型把整段话生成完才看到结果而是希望字一个个蹦出来。实现上用 SSEServer-Sent Events把生成的 token 逐步推给前端配合前端的 abort 机制用户还能中途取消。并发方面vLLM 的连续批处理能把多个请求动态合并大幅提升 GPU 利用率。实测下来同样的硬件用连续批处理比逐个请求处理的吞吐能高好几倍。7. 常见问题与排查实录7.1 显存不够怎么办这是最高频的问题。排查顺序先看是不是 batch size 太大调小或加梯度累积再看是不是用了全量微调换成 LoRA还不行就上量化或 ZeRO 优化最后才考虑换更大显存的卡。绝大多数情况在前两步就能解决。7.2 训练 loss 不下降先确认数据格式对不对标签有没有错位。然后检查学习率是不是太小或太大。如果用的是 LoRA确认 target_modules 有没有配对。我遇到过一次 loss 死活不降最后发现是数据里 output 字段全是空的白白浪费了半天。7.3 部署后延迟高先看是不是没用量化FP16 推理本身就慢。再看并发处理有没有开逐个请求处理会浪费大量 GPU 空闲时间。最后检查是不是 prompt 太长长上下文会显著增加首 token 延迟。7.4 模型输出不稳定多半是训练数据格式不统一或者推理时的 prompt 模板和训练时不一致。训练和推理的模板必须严格对齐这是很多人忽略的细节。训练时用什么格式推理时就得用什么格式差一个标点都可能影响输出。8. 我个人的一些实操体会做了一段时间大模型训练最大的感受是这活儿七分靠数据两分靠调参一分靠运气。很多人把精力全花在调参上却不肯在数据清洗上多花时间结果就是反复训练反复不满意。我现在的习惯是数据准备阶段花的时间至少占整个项目的一半剩下的才是训练和部署。另一个体会是别追求一步到位。先用小数据、小模型、LoRA 快速跑通全流程拿到一个能用的基线再逐步加数据、换大模型、调参数。这样每一步都有对比知道是什么带来了提升。一上来就憋大招往往连问题出在哪都找不到。最后分享一个容易被忽略的点保留完整的实验记录。每次训练的配置、数据版本、评估结果都记下来用表格管理。不然跑了几十次之后你根本记不清哪个 checkpoint 是用什么配置训出来的。这个习惯在需要复现或回滚时能救命。