1. 从训练到落地为什么微调之后才是真正的硬仗很多人第一次接触大模型脑子里想的都是“我要训练一个自己的模型”。折腾了几周数据清洗、租了GPU、跑完LoRA微调看着loss曲线一路往下掉心里美滋滋。结果一到实际用的时候傻眼了——模型是训好了权重文件躺在磁盘里然后呢怎么让业务系统调它怎么扛住并发怎么控制成本怎么保证输出稳定这就是我常说的微调只是上半场工程化落地才是决定项目生死的那一脚。你去看那些真正把大模型跑进生产环境的团队他们在推理部署和API封装上花的时间往往比训练本身还多。原因很简单训练是一次性的活儿而API服务是7×24小时要扛住的活儿。这篇文章我想聊的就是从“模型微调完成”到“业务方稳定调用API”这条链路上到底有哪些坑、哪些关键决策点、哪些能直接抄作业的方案。适合已经跑过至少一次微调、准备把模型推上线的开发者也适合正在做技术选型、纠结要不要自建推理服务的团队负责人。核心关键词就三个模型微调、推理部署、API工程化。我会把每一步的“为什么这么选”讲清楚而不是只丢一个结论给你。先说一个基本认知微调产出的模型权重本质上只是一个“静态文件”。它不会自己变成服务不会自己处理并发更不会自己省钱。从权重到API之间至少隔着推理引擎选型、量化策略、服务框架、并发调度、监控告警这五道关。每一道关都有它的脾气选错了轻则成本翻倍重则线上直接雪崩。我见过太多团队在微调阶段投入了大量精力结果部署时随便找了个demo脚本套上Flask就上线QPS一上来直接OOM。也见过有人盲目追求“大而全”的推理框架配置复杂到自己都维护不动。所以接下来的内容我会按照真实的落地顺序一层一层拆开讲。2. 推理引擎选型别一上来就上最重的方案2.1 主流推理引擎的能力边界对比微调完成后第一件事是决定用什么推理引擎来加载权重。这一步的选择会直接影响后面所有的工程决策包括显存占用、吞吐量、支持的量化格式、API封装难度。我先把几个主流方案的核心差异摆出来这些都是我在实际项目里踩过或者验证过的。推理引擎核心优势主要限制适合场景原生Transformers兼容性最好任何微调权重都能直接加载显存占用大吞吐低无连续批处理验证阶段、单次推理、调试vLLMPagedAttention显存管理吞吐极高支持连续批处理对部分自定义模型结构支持需要适配高并发在线服务TGI部署简单内置量化HuggingFace生态无缝定制化能力相对弱快速上线、标准模型llama.cppCPU也能跑量化极致资源占用低高并发场景吞吐不如GPU方案边缘设备、低并发、成本敏感TensorRT-LLM极致性能算子融合深度优化编译流程复杂模型转换成本高追求极致延迟的大规模服务这张表不是让你背的而是让你在选型时有个判断依据。我的经验是如果你还在验证微调效果就用原生Transformers别折腾如果准备上生产且并发量在几十以上直接上vLLM如果团队运维能力弱、想快速上线TGI是稳妥选择如果预算极紧或者要跑在CPU上llama.cpp。2.2 为什么vLLM成了当前在线服务的主流选择重点说一下vLLM因为这两年它在在线推理场景里几乎是默认选项。核心原因是它解决了大模型推理里最要命的一个问题KV Cache的显存浪费。传统推理方式下每个请求的KV Cache要预分配一整块连续显存按最大长度来分。你请求可能只用了200个token但显存按2048预分配了剩下的全浪费。并发一上来显存瞬间被吃光。vLLM的PagedAttention把KV Cache切成固定大小的块按需分配类似操作系统的虚拟内存分页。这个改动让显存利用率从原来的可能30%提升到80%以上吞吐量直接翻几倍。我实测过一个7B模型在单张24G显存卡上原生Transformers大概能扛8到10个并发换成vLLM之后稳定跑到40以上。这个差距在真实业务里就是“要不要加卡”的区别。注意vLLM对模型结构的支持不是100%全覆盖。如果你微调时改了模型结构比如自定义了attention层加载时可能报错。这种情况要么改回标准结构要么用原生方案先跑通再考虑优化。2.3 量化策略省显存和保效果之间的平衡术选完引擎紧接着要决定量化方案。量化说白了就是用更低的精度存权重和算矩阵代价是可能损失一点效果。常见的几档FP16/BF16不量化效果最好显存占用最大。7B模型大概要14G权重显存。INT8显存减半效果损失通常很小适合大多数场景。INT4显存再减半7B模型权重只要4G左右效果损失开始可感知但很多任务还能接受。GPTQ/AWQ训练后量化方法INT4下效果比朴素量化好不少是当前主流选择。我的建议很直接如果显存够优先BF16别为了省一点显存牺牲效果如果显存紧张用AWQ的INT4它在多数任务上比GPTQ更稳INT8是折中方案适合对效果敏感又需要一定压缩的场景。量化不是免费的午餐。我做过一个文本分类的微调任务BF16下准确率92%INT4量化后掉到88%。这4个点在某些业务里是致命的。所以量化后一定要用你的验证集重新跑一遍评估别想当然。3. 从权重到服务API工程化的核心环节3.1 服务框架的选型逻辑推理引擎负责“算得快”服务框架负责“管得好”。这两件事要分开看。很多人把vLLM自带的OpenAI兼容API直接暴露出去就完事了小规模可以但生产环境不够。服务框架要解决的核心问题包括请求队列管理、超时控制、限流、鉴权、日志、多模型路由、优雅重启。这些用原生推理引擎自带的server很难做全。常见的组合是FastAPI 推理引擎灵活自己写控制逻辑适合定制需求多的团队。Ray Serve适合多模型、多副本的复杂编排自动扩缩容。Triton Inference Server工业级支持多框架多模型但配置复杂。推理引擎自带server 网关最省事前面加一层网关做限流鉴权。我个人的偏好是中小规模用FastAPI自己封装控制力最强出问题好排查规模大了再考虑Ray Serve或者Triton。别一上来就上Triton那个学习曲线会让你怀疑人生。3.2 请求队列与并发控制的关键参数这是最容易出事的环节。大模型推理是计算密集型一个请求可能要跑几秒。如果没有队列管理请求一多直接把GPU打满后面的请求全部超时。核心要控制的参数有这么几个最大并发数max_concurrent_requests同时处理的请求上限。设太高会OOM设太低吞吐上不去。经验值是从GPU显存反推留20%余量。队列长度queue_size排队等待的请求上限。超过就快速失败返回别让用户干等。单请求超时request_timeout防止某个长请求拖垮整个服务。批处理窗口batch_windowvLLM这类引擎会自动做连续批处理但你可以控制等待新请求加入批次的时间窗口。我踩过的一个坑早期没设队列上限结果流量高峰时请求全堆在内存里最后OOM把服务搞挂了。后来加了队列长度限制和快速失败机制虽然会拒绝一部分请求但至少服务是活的。宁可拒绝不可雪崩这是生产环境的基本原则。3.3 流式输出的实现与坑点大模型API如果不做流式输出用户体验会很差。用户等5秒才看到第一个字体感上比等3秒看到全部还难受。流式输出用SSEServer-Sent Events实现推理引擎逐token返回服务端逐块推给客户端。实现上有几个坑首token延迟流式的价值在于首token快如果首token就要等3秒流式意义不大。这跟推理引擎的prefill速度有关量化能改善。中断处理用户可能中途关闭连接服务端要能感知并停止推理否则白烧算力。缓冲策略逐token推太碎网络开销大攒一批推延迟高。一般攒几个token或者按时间窗口推。# FastAPI流式输出核心逻辑示意 from fastapi.responses import StreamingResponse async def stream_generate(prompt): async def event_generator(): async for token in engine.generate_stream(prompt): yield fdata: {token}\n\n yield data: [DONE]\n\n return StreamingResponse(event_generator(), media_typetext/event-stream)这段代码看着简单但生产环境要加上超时、异常捕获、连接断开检测。别小看这些少一个都可能在高峰期出问题。4. 性能调优与成本控制让每一分算力都花在刀刃上4.1 批处理大小的计算与调优批处理是提升吞吐最直接的手段。同样一批请求逐个跑和攒成一批跑GPU利用率天差地别。但批处理大小不是越大越好它受显存限制。计算逻辑是这样的显存总量减去模型权重占用剩下的给KV Cache。每个请求的KV Cache大小跟序列长度、层数、隐藏维度有关。假设模型权重占10G显存24G剩14G给KV Cache。如果每个请求平均占0.5G那理论上能批28个。但实际要留余量设20个比较稳。调优方法是从保守值开始逐步加压观察显存和延迟。找到那个“吞吐最高且延迟可接受”的平衡点。我一般会做一个压测脚本模拟真实请求分布跑出不同批大小下的QPS和P99延迟曲线然后选拐点。提示批处理大小和延迟是矛盾的。批越大吞吐越高但单个请求的等待时间也越长。要结合业务对延迟的容忍度来定。实时对话场景批大小要小离线批量处理可以大。4.2 显存优化的几个实用手段除了量化还有几个手段能省显存KV Cache量化把KV Cache也用INT8存能再省一半显存效果损失很小。PagedAttention前面提过vLLM默认开启显存利用率大幅提升。梯度检查点这是训练用的推理用不上别搞混。模型并行单卡放不下就多卡切分但会引入通信开销延迟会上升。我实际项目里的组合拳是AWQ INT4量化权重 KV Cache INT8 PagedAttention。一套下来一个13B模型能在单张24G卡上跑得飞起成本比不优化低了一半以上。4.3 成本核算自建和调用的账怎么算这是很多团队纠结的问题到底自建推理服务还是直接调用外部API我算过一笔账逻辑是这样的。自建的成本包括GPU租用或采购、运维人力、电费、闲置浪费。调用外部API的成本就是按token计费。关键变量是你的请求量和稳定性。请求量小且波动大调API划算不用养机器。请求量大且稳定自建划算单位成本低。数据敏感必须自建没得选。需要深度定制自建外部API给不了你微调后的模型。我见过一个团队日均请求量不大但非要自建结果GPU利用率长期低于10%纯浪费。也见过请求量巨大的团队一直调API账单高得吓人。算账要算总拥有成本不是只看单价。5. 线上稳定性保障监控、告警与故障排查5.1 必须监控的核心指标服务上线不是终点是起点。没有监控的线上服务等于裸奔。大模型API服务要盯的指标分几类性能类首token延迟TTFT用户感知最直接每token输出延迟TPOT影响整体响应时间QPS和并发数容量规划依据批处理利用率批处理是否跑满资源类GPU利用率低于50%说明浪费长期100%说明要扩容显存占用接近上限就要警惕OOMCPU和内存服务框架本身的健康度业务类请求成功率低于99%就要查超时率突增说明有异常队列等待时间反映容量是否够这些指标用Prometheus采集Grafana展示是标准组合。别自己造轮子。5.2 常见故障与排查思路我把实际遇到过的问题整理成一张速查表现象可能原因排查方向解决手段服务突然OOM并发超限、显存泄漏、批太大看显存曲线和并发数降批大小、加队列限制、重启延迟突然飙升GPU被占满、请求堆积看GPU利用率和队列长度限流、扩容、优化批处理输出乱码或截断量化损失、tokenizer问题对比BF16和量化输出换量化方案、检查tokenizer部分请求超时长请求拖累、调度不均看请求长度分布设单请求超时、长度限制服务启动失败权重格式不兼容、显存不足看启动日志换引擎、降量化精度这张表是我踩坑踩出来的每一条背后都是真实的深夜排查。遇到问题先看监控别瞎猜。大部分故障在指标上都有预兆。5.3 灰度发布与回滚机制模型更新不能一把梭。新版本微调模型上线前一定要做灰度。流程是新模型部署成独立副本切一小部分流量过去对比新旧版本的效果和性能指标。没问题再逐步放量有问题立即回滚。回滚要能做到秒级。这意味着旧版本的权重和服务要保留着别一上线就把旧的删了。我见过有人更新模型后发现问题结果旧权重没留只能干等重新部署业务停了半小时。注意灰度不只是看技术指标还要看业务指标。新模型可能延迟更低但输出质量变差了这种问题只有业务侧能发现。所以灰度期间要拉上业务方一起看。6. 工程化落地的完整路径复盘把整条链路串起来一个标准的落地路径是这样的微调完成产出权重文件用原生Transformers验证效果确认微调有效。量化转换根据显存和效果要求选AWQ或GPTQ转换后重新评估。推理引擎部署选vLLM或TGI加载量化权重压测确定批处理参数。服务框架封装用FastAPI或Ray Serve包一层加队列、限流、鉴权、流式输出。监控接入Prometheus采集指标Grafana看板设告警阈值。灰度上线小流量验证对比新旧版本逐步放量。持续调优根据线上数据调整批大小、量化策略、扩容缩容。这条路径不是线性的中间会反复。比如压测发现延迟高可能要回去换量化方案灰度发现效果差可能要重新微调。这很正常工程化本来就是迭代的过程。我在实际项目里最大的体会是别追求一步到位先跑通再优化。很多团队卡在选型阶段纠结vLLM还是TGI纠结INT4还是INT8结果一个月过去了服务还没上线。正确的做法是先用最稳妥的方案跑通全链路哪怕性能不是最优然后再针对性优化。跑通的价值远大于选型完美。另外一个体会是文档和配置要版本化。推理引擎的参数、量化配置、服务框架的配置全部进Git。线上出问题时能快速定位是哪个版本、哪个配置导致的。我吃过亏改了个参数没记录出问题后排查了半天才发现是那个改动。最后分享一个小技巧压测要用真实数据分布。很多人压测用固定长度的短请求结果线上全是长请求表现完全不一样。压测数据要从真实日志里采样长度分布、并发模式都要贴近实际。这样压出来的结果才有参考价值。这条链路我走过好几遍每次都有新坑但每次跑通后的那种踏实感是实打实的。模型微调是技术活工程化落地是手艺活两者都做好了大模型才能真正变成业务能用的东西。 
长河君 · 2026/10/12 23:40:53 · 阅读 1.2k 大模型微调后如何工程化落地：推理部署与API服务实战指南
1. 从训练到落地为什么微调之后才是真正的硬仗很多人第一次接触大模型脑子里想的都是“我要训练一个自己的模型”。折腾了几周数据清洗、租了GPU、跑完LoRA微调看着loss曲线一路往下掉心里美滋滋。结果一到实际用的时候傻眼了——模型是训好了权重文件躺在磁盘里然后呢怎么让业务系统调它怎么扛住并发怎么控制成本怎么保证输出稳定这就是我常说的微调只是上半场工程化落地才是决定项目生死的那一脚。你去看那些真正把大模型跑进生产环境的团队他们在推理部署和API封装上花的时间往往比训练本身还多。原因很简单训练是一次性的活儿而API服务是7×24小时要扛住的活儿。这篇文章我想聊的就是从“模型微调完成”到“业务方稳定调用API”这条链路上到底有哪些坑、哪些关键决策点、哪些能直接抄作业的方案。适合已经跑过至少一次微调、准备把模型推上线的开发者也适合正在做技术选型、纠结要不要自建推理服务的团队负责人。核心关键词就三个模型微调、推理部署、API工程化。我会把每一步的“为什么这么选”讲清楚而不是只丢一个结论给你。先说一个基本认知微调产出的模型权重本质上只是一个“静态文件”。它不会自己变成服务不会自己处理并发更不会自己省钱。从权重到API之间至少隔着推理引擎选型、量化策略、服务框架、并发调度、监控告警这五道关。每一道关都有它的脾气选错了轻则成本翻倍重则线上直接雪崩。我见过太多团队在微调阶段投入了大量精力结果部署时随便找了个demo脚本套上Flask就上线QPS一上来直接OOM。也见过有人盲目追求“大而全”的推理框架配置复杂到自己都维护不动。所以接下来的内容我会按照真实的落地顺序一层一层拆开讲。2. 推理引擎选型别一上来就上最重的方案2.1 主流推理引擎的能力边界对比微调完成后第一件事是决定用什么推理引擎来加载权重。这一步的选择会直接影响后面所有的工程决策包括显存占用、吞吐量、支持的量化格式、API封装难度。我先把几个主流方案的核心差异摆出来这些都是我在实际项目里踩过或者验证过的。推理引擎核心优势主要限制适合场景原生Transformers兼容性最好任何微调权重都能直接加载显存占用大吞吐低无连续批处理验证阶段、单次推理、调试vLLMPagedAttention显存管理吞吐极高支持连续批处理对部分自定义模型结构支持需要适配高并发在线服务TGI部署简单内置量化HuggingFace生态无缝定制化能力相对弱快速上线、标准模型llama.cppCPU也能跑量化极致资源占用低高并发场景吞吐不如GPU方案边缘设备、低并发、成本敏感TensorRT-LLM极致性能算子融合深度优化编译流程复杂模型转换成本高追求极致延迟的大规模服务这张表不是让你背的而是让你在选型时有个判断依据。我的经验是如果你还在验证微调效果就用原生Transformers别折腾如果准备上生产且并发量在几十以上直接上vLLM如果团队运维能力弱、想快速上线TGI是稳妥选择如果预算极紧或者要跑在CPU上llama.cpp。2.2 为什么vLLM成了当前在线服务的主流选择重点说一下vLLM因为这两年它在在线推理场景里几乎是默认选项。核心原因是它解决了大模型推理里最要命的一个问题KV Cache的显存浪费。传统推理方式下每个请求的KV Cache要预分配一整块连续显存按最大长度来分。你请求可能只用了200个token但显存按2048预分配了剩下的全浪费。并发一上来显存瞬间被吃光。vLLM的PagedAttention把KV Cache切成固定大小的块按需分配类似操作系统的虚拟内存分页。这个改动让显存利用率从原来的可能30%提升到80%以上吞吐量直接翻几倍。我实测过一个7B模型在单张24G显存卡上原生Transformers大概能扛8到10个并发换成vLLM之后稳定跑到40以上。这个差距在真实业务里就是“要不要加卡”的区别。注意vLLM对模型结构的支持不是100%全覆盖。如果你微调时改了模型结构比如自定义了attention层加载时可能报错。这种情况要么改回标准结构要么用原生方案先跑通再考虑优化。2.3 量化策略省显存和保效果之间的平衡术选完引擎紧接着要决定量化方案。量化说白了就是用更低的精度存权重和算矩阵代价是可能损失一点效果。常见的几档FP16/BF16不量化效果最好显存占用最大。7B模型大概要14G权重显存。INT8显存减半效果损失通常很小适合大多数场景。INT4显存再减半7B模型权重只要4G左右效果损失开始可感知但很多任务还能接受。GPTQ/AWQ训练后量化方法INT4下效果比朴素量化好不少是当前主流选择。我的建议很直接如果显存够优先BF16别为了省一点显存牺牲效果如果显存紧张用AWQ的INT4它在多数任务上比GPTQ更稳INT8是折中方案适合对效果敏感又需要一定压缩的场景。量化不是免费的午餐。我做过一个文本分类的微调任务BF16下准确率92%INT4量化后掉到88%。这4个点在某些业务里是致命的。所以量化后一定要用你的验证集重新跑一遍评估别想当然。3. 从权重到服务API工程化的核心环节3.1 服务框架的选型逻辑推理引擎负责“算得快”服务框架负责“管得好”。这两件事要分开看。很多人把vLLM自带的OpenAI兼容API直接暴露出去就完事了小规模可以但生产环境不够。服务框架要解决的核心问题包括请求队列管理、超时控制、限流、鉴权、日志、多模型路由、优雅重启。这些用原生推理引擎自带的server很难做全。常见的组合是FastAPI 推理引擎灵活自己写控制逻辑适合定制需求多的团队。Ray Serve适合多模型、多副本的复杂编排自动扩缩容。Triton Inference Server工业级支持多框架多模型但配置复杂。推理引擎自带server 网关最省事前面加一层网关做限流鉴权。我个人的偏好是中小规模用FastAPI自己封装控制力最强出问题好排查规模大了再考虑Ray Serve或者Triton。别一上来就上Triton那个学习曲线会让你怀疑人生。3.2 请求队列与并发控制的关键参数这是最容易出事的环节。大模型推理是计算密集型一个请求可能要跑几秒。如果没有队列管理请求一多直接把GPU打满后面的请求全部超时。核心要控制的参数有这么几个最大并发数max_concurrent_requests同时处理的请求上限。设太高会OOM设太低吞吐上不去。经验值是从GPU显存反推留20%余量。队列长度queue_size排队等待的请求上限。超过就快速失败返回别让用户干等。单请求超时request_timeout防止某个长请求拖垮整个服务。批处理窗口batch_windowvLLM这类引擎会自动做连续批处理但你可以控制等待新请求加入批次的时间窗口。我踩过的一个坑早期没设队列上限结果流量高峰时请求全堆在内存里最后OOM把服务搞挂了。后来加了队列长度限制和快速失败机制虽然会拒绝一部分请求但至少服务是活的。宁可拒绝不可雪崩这是生产环境的基本原则。3.3 流式输出的实现与坑点大模型API如果不做流式输出用户体验会很差。用户等5秒才看到第一个字体感上比等3秒看到全部还难受。流式输出用SSEServer-Sent Events实现推理引擎逐token返回服务端逐块推给客户端。实现上有几个坑首token延迟流式的价值在于首token快如果首token就要等3秒流式意义不大。这跟推理引擎的prefill速度有关量化能改善。中断处理用户可能中途关闭连接服务端要能感知并停止推理否则白烧算力。缓冲策略逐token推太碎网络开销大攒一批推延迟高。一般攒几个token或者按时间窗口推。# FastAPI流式输出核心逻辑示意 from fastapi.responses import StreamingResponse async def stream_generate(prompt): async def event_generator(): async for token in engine.generate_stream(prompt): yield fdata: {token}\n\n yield data: [DONE]\n\n return StreamingResponse(event_generator(), media_typetext/event-stream)这段代码看着简单但生产环境要加上超时、异常捕获、连接断开检测。别小看这些少一个都可能在高峰期出问题。4. 性能调优与成本控制让每一分算力都花在刀刃上4.1 批处理大小的计算与调优批处理是提升吞吐最直接的手段。同样一批请求逐个跑和攒成一批跑GPU利用率天差地别。但批处理大小不是越大越好它受显存限制。计算逻辑是这样的显存总量减去模型权重占用剩下的给KV Cache。每个请求的KV Cache大小跟序列长度、层数、隐藏维度有关。假设模型权重占10G显存24G剩14G给KV Cache。如果每个请求平均占0.5G那理论上能批28个。但实际要留余量设20个比较稳。调优方法是从保守值开始逐步加压观察显存和延迟。找到那个“吞吐最高且延迟可接受”的平衡点。我一般会做一个压测脚本模拟真实请求分布跑出不同批大小下的QPS和P99延迟曲线然后选拐点。提示批处理大小和延迟是矛盾的。批越大吞吐越高但单个请求的等待时间也越长。要结合业务对延迟的容忍度来定。实时对话场景批大小要小离线批量处理可以大。4.2 显存优化的几个实用手段除了量化还有几个手段能省显存KV Cache量化把KV Cache也用INT8存能再省一半显存效果损失很小。PagedAttention前面提过vLLM默认开启显存利用率大幅提升。梯度检查点这是训练用的推理用不上别搞混。模型并行单卡放不下就多卡切分但会引入通信开销延迟会上升。我实际项目里的组合拳是AWQ INT4量化权重 KV Cache INT8 PagedAttention。一套下来一个13B模型能在单张24G卡上跑得飞起成本比不优化低了一半以上。4.3 成本核算自建和调用的账怎么算这是很多团队纠结的问题到底自建推理服务还是直接调用外部API我算过一笔账逻辑是这样的。自建的成本包括GPU租用或采购、运维人力、电费、闲置浪费。调用外部API的成本就是按token计费。关键变量是你的请求量和稳定性。请求量小且波动大调API划算不用养机器。请求量大且稳定自建划算单位成本低。数据敏感必须自建没得选。需要深度定制自建外部API给不了你微调后的模型。我见过一个团队日均请求量不大但非要自建结果GPU利用率长期低于10%纯浪费。也见过请求量巨大的团队一直调API账单高得吓人。算账要算总拥有成本不是只看单价。5. 线上稳定性保障监控、告警与故障排查5.1 必须监控的核心指标服务上线不是终点是起点。没有监控的线上服务等于裸奔。大模型API服务要盯的指标分几类性能类首token延迟TTFT用户感知最直接每token输出延迟TPOT影响整体响应时间QPS和并发数容量规划依据批处理利用率批处理是否跑满资源类GPU利用率低于50%说明浪费长期100%说明要扩容显存占用接近上限就要警惕OOMCPU和内存服务框架本身的健康度业务类请求成功率低于99%就要查超时率突增说明有异常队列等待时间反映容量是否够这些指标用Prometheus采集Grafana展示是标准组合。别自己造轮子。5.2 常见故障与排查思路我把实际遇到过的问题整理成一张速查表现象可能原因排查方向解决手段服务突然OOM并发超限、显存泄漏、批太大看显存曲线和并发数降批大小、加队列限制、重启延迟突然飙升GPU被占满、请求堆积看GPU利用率和队列长度限流、扩容、优化批处理输出乱码或截断量化损失、tokenizer问题对比BF16和量化输出换量化方案、检查tokenizer部分请求超时长请求拖累、调度不均看请求长度分布设单请求超时、长度限制服务启动失败权重格式不兼容、显存不足看启动日志换引擎、降量化精度这张表是我踩坑踩出来的每一条背后都是真实的深夜排查。遇到问题先看监控别瞎猜。大部分故障在指标上都有预兆。5.3 灰度发布与回滚机制模型更新不能一把梭。新版本微调模型上线前一定要做灰度。流程是新模型部署成独立副本切一小部分流量过去对比新旧版本的效果和性能指标。没问题再逐步放量有问题立即回滚。回滚要能做到秒级。这意味着旧版本的权重和服务要保留着别一上线就把旧的删了。我见过有人更新模型后发现问题结果旧权重没留只能干等重新部署业务停了半小时。注意灰度不只是看技术指标还要看业务指标。新模型可能延迟更低但输出质量变差了这种问题只有业务侧能发现。所以灰度期间要拉上业务方一起看。6. 工程化落地的完整路径复盘把整条链路串起来一个标准的落地路径是这样的微调完成产出权重文件用原生Transformers验证效果确认微调有效。量化转换根据显存和效果要求选AWQ或GPTQ转换后重新评估。推理引擎部署选vLLM或TGI加载量化权重压测确定批处理参数。服务框架封装用FastAPI或Ray Serve包一层加队列、限流、鉴权、流式输出。监控接入Prometheus采集指标Grafana看板设告警阈值。灰度上线小流量验证对比新旧版本逐步放量。持续调优根据线上数据调整批大小、量化策略、扩容缩容。这条路径不是线性的中间会反复。比如压测发现延迟高可能要回去换量化方案灰度发现效果差可能要重新微调。这很正常工程化本来就是迭代的过程。我在实际项目里最大的体会是别追求一步到位先跑通再优化。很多团队卡在选型阶段纠结vLLM还是TGI纠结INT4还是INT8结果一个月过去了服务还没上线。正确的做法是先用最稳妥的方案跑通全链路哪怕性能不是最优然后再针对性优化。跑通的价值远大于选型完美。另外一个体会是文档和配置要版本化。推理引擎的参数、量化配置、服务框架的配置全部进Git。线上出问题时能快速定位是哪个版本、哪个配置导致的。我吃过亏改了个参数没记录出问题后排查了半天才发现是那个改动。最后分享一个小技巧压测要用真实数据分布。很多人压测用固定长度的短请求结果线上全是长请求表现完全不一样。压测数据要从真实日志里采样长度分布、并发模式都要贴近实际。这样压出来的结果才有参考价值。这条链路我走过好几遍每次都有新坑但每次跑通后的那种踏实感是实打实的。模型微调是技术活工程化落地是手艺活两者都做好了大模型才能真正变成业务能用的东西。