从单模型服务到LLM推理平台：部署架构、引擎选型与生产实践

模型部署这件事这几年变化得实在太快。几年前我还在为一个训练好的分类模型写 Flask 接口纠结要不要上 uWSGI 还是 Gunicorn现在手里已经要同时管着几十个大模型服务、几个不同的推理引擎、还有一套带网关和观测的 LLM 推理平台。如果你也正处在“单模型服务能跑但一上正式环境就各种翻车”的阶段或者已经在评估 vLLM、TensorRT-LLM、SGLang 这些推理框架那么这篇从单模型服务讲到 LLM 推理平台的文章应该能帮你在选型和架构上少走不少弯路。模型部署不是把模型文件往服务器上一丢就完事。正式环境里有并发、有延迟、有显存、有监控还有数不清的兼容性问题。本文不聊训练只聊部署我会把单模型服务、LLM 推理引擎、量化选型、GPU 适配、推理平台架构、边缘部署、自动化测试和排错经验按生产落地的主线一路拆开讲适合做后端的老手、算法工程师转型模型部署的同行也适合刚准备把模型推到线上的团队参考。1. 从单模型服务到推理平台部署架构演进的核心逻辑1.1 单模型服务为什么扛不住正式环境先说个很典型的场景。你训练了一个文本分类模型导出成 ONNX 或者 TorchScript然后用 FastAPI 写个/predict接口Uvicorn 一拉单机部署模型加载进内存推理一次几十毫秒。本地压测没问题接口响应也稳定看起来挺美。可一旦上了正式环境事情就开始变味。第一波并发上来Uvicorn 的异步模型和 CUDA 推理的同步调用之间的协调就开始出问题GPU 利用率忽高忽低显存时不时涨一点请求稍微多一点延迟就飙到几秒。更麻烦的是你要部署的不止一个模型。公司业务一扩张分类模型、实体识别、相似度匹配、摘要生成各个团队各自为战每人一套 FastAPI 服务端口乱成一锅粥监控指标没有人统一看模型版本没人统一管出了问题谁也说不清是哪儿挂了。这就是单模型服务架构的天花板它适合“跑起来”不适合“运营”。正式环境要的是可观测、可治理、可扩展、可容错。单个服务本身再轻快也没法回答“你今天为什么 GPU 显存又满了”“昨天上线的模型为什么回流准确率掉了 3 个点”这种平台层面的问题。1.2 推理平台的核心诉求与分层设计思路当我们谈模型推理平台不是简单地做一个“把模型打包部署的工具”而是要给模型服务提供一个标准化、平台化的运行环境。我拆过很多需求总结下来正式环境的推理平台基本要覆盖四层第一层是模型服务层解决“模型怎么跑”的问题。例如用 vLLM 跑 LLM、用 Triton 跑多模型、用 ONNX Runtime 跑中小模型这一层要管理推理引擎、模型版本、量化精度和显存占用。第二层是网关接入层解决“流量怎么进”的问题。统一入口、路由分发、限流熔断、鉴权审计这些不是业务方各自能搞定的。我们做平台时要让业务方尽量少感知模型背后的部署细节他们只需要调用一个统一的 API。第三层是调度资源层解决“算力怎么分”的问题。多模型共享 GPU、自动扩缩容、队列管理、多副本负载均衡本质上和微服务架构里的服务编排是一个套路只不过把 CPU 换成了 GPU 显存。第四层是观测治理层解决“出了事怎么查”的问题。指标、日志、链路追踪、模型质量回放这四样一样都不能少。模型推理和普通服务不一样光看 P99 延迟不够还得看 token 级吞吐、显存水位、量化损失和上下文长度这些模型专属指标。把架构拆成这四层你会发现很多技术选型的争论其实是在不同层面打架。你拿 FastAPI 和 vLLM 比这不对等FastAPI 是应用框架vLLM 是服务化推理引擎它们在平台里的位置截然不同。先有分层思维再去选型才不会越选越乱。2. 单模型服务层的框架选型对比与实操要点2.1 FastAPI ONNX Runtime轻量推理服务的最小可行方案先补充一段我很常用的底线方案。正式环境里中小模型的部署量非常大不可能每个模型都上重型推理平台。一个干净、可控、可基准测试的 FastAPI 服务配上 ONNX Runtime依然是目前最稳妥的组合。FastAPI 的优势在于原生异步、Pydantic 校验、OpenAPI 文档自动生成这对后端团队接手非常友好。ONNX Runtime 的优势在于跨框架、跨硬件训练时用 PyTorch导出 ONNX 后不管是 CPU 还是 GPU 都能用同一套推理代码。实操上我建议模型加载必须放到应用启动事件里做不要放在请求处理函数里。否则第一个请求要做十几秒的模型加载接口直接超时。更细一点的技巧是ONNX Runtime 的 session 要按 GPU 设备建不要每个请求都建同时设置 intra_op_num_threads 和 inter_op_num_threads否则多线程并发时 CPU 资源会被白白浪费。再加两个生产上的细节第一请求输入要做长度截断和预检查尤其文本模型你不可能让用户一传几 MB 的文本直接进模型。第二输出要做后处理和结构化包装我习惯统一返回{code: 0, data: ..., trace_id: ...}的格式这样后续接网关时做字段映射会非常省事。2.2 Docker Ollama本地大模型部署的最快路径大模型流行起来以后本地化部署的诉求也突然多了。很多团队没精力自己搭 vLLM 集群只需要在局域网里跑一个开源模型支持 API 调用比如 Qwen、Llama 的 7B、14B 版本。这种情况下 Docker Ollama 是我见过效率最高的路径。Ollama 把模型下载、量化、服务化、API 暴露全部封装好了。你用ollama pull qwen2.5:7b拉模型docker run -d -v /data/ollama:/root/.ollama -p 11434:11434 ollama/ollama起服务然后curl http://localhost:11434/v1/chat/completions就能拿到 OpenAI 风格的响应。整个过程十几分钟几乎没有任何学习成本。但这里我要强调几点。Ollama 默认加载模型是有内存和显存控制的如果你的机器是 24G 显存跑 7B 量化模型没有问题但想同时加载两个模型就可能会出现 OOM 或者反复换入换出。操作上可以用OLLAMA_MAX_LOADED_MODELS1控制并发加载模型数用OLLAMA_NUM_PARALLEL控制单模型并行请求数这两个参数在生产环境必须提前调好。Docker 部署还有一个容易被忽略的点容器里的 CUDA 运行时版本要和宿主机驱动兼容。常见坑是宿主机驱动太老容器里拉的新版 PyTorch 镜像跑不起来。先执行nvidia-smi确认驱动版本再选合适的基础镜像这是最省心的顺序。2.3 模型服务封装预加载、批处理、超时与并发控制不管用什么框架部署单模型有几个通用点我建议形成自己的模板别每次都临时写。一是预加载。模型、分词器、专用处理器全部在进程启动时加载启动完成后等待一个 ready 信号再对外提供服务。配合 K8s 的 readinessProbe 就很好用。二是批处理。对于小模型动态 batching 可以把吞吐提升好几倍。实现思路不复杂请求进来先不立刻推理放进队列积累一定请求数或等待一小段窗口时间再统一拼成 batch 送入 GPU。vLLM 的 continuous batching 是在引擎层做了类似的事我们自己写小模型服务时也可以借鉴这套思想。三是超时与并发控制。推理服务最怕慢查询拖死进程。我通常在服务里用信号量控制并发上限超过上限直接返回 429 或排队同时给每个推理请求设一个硬超时时间GPU 推理线程没有在规定时间返回就直接丢弃。说到底单模型服务的核心目标是“跑得稳”不是“功能多”。把有限的功能做成可复用模板你才有精力去做真正的平台。3. LLM推理引擎、量化方案与GPU适配实战3.1 GGUF、GPTQ、AWQ 几种量化该怎么选到了 LLM 这里模型部署的技术栈和传统模型完全不一样。最典型的差异就是量化方案。现在开源模型动辄 70B不做量化基本没法在单卡上跑。你一定会遇到 GGUF、GPTQ、AWQ 这些词我一个个说。GGUF 是 llama.cpp 生态的格式它把模型权重和超参数打包进一个文件可以配合 CPU 和 GPU 混合推理。对我来说 GGUF 最大的价值是通用性极强支持 llama.cpp、Ollama、LM Studio 这类工具你不用装 PyTorch 就能跑模型。适合个人工作站、边缘设备、以及 CPU 推理场景。GPTQ 是面向 GPU 的量化格式主要在 AutoGPTQ 生态里使用。它通过二阶信息做逐层量化补偿量化到 4bit 后显存占用能压到原来的四分之一左右但保留较好的生成质量。如果你确定模型只跑 GPUGPTQ 是我比较推荐的。AWQ 的思路不同它不是单纯量化权重而是根据激活值分布保护重要权重通道量化后质量通常比 GPTQ 更稳一点推理时还有激活感知特性和 TensorRT-LLM、vLLM 配合都不错。我的建议很简单跑在 Ollama、llama.cpp 场景选 GGUF跑在 GPU 集群、要极致吞吐选 AWQ要兼容旧生态、用 transformers 直接加载选 GPTQ。没有绝对优劣关键是看推理引擎支持和团队熟悉度。3.2 vLLM / TensorRT-LLM / SGLang 的取舍在正式环境部署 LLM API 服务vLLM 是我见过出场率最高的推理框架。它的核心技术是 PagedAttention把 KV Cache 分成物理块管理大幅降低了显存碎片浪费吞吐和并发能力很突出。安装简单pip install vllm之后一行命令就能启动 OpenAI 兼容服务部署体验非常顺滑。TensorRT-LLM 的定位不一样它是基于 TensorRT 深度优化的推理引擎适合把模型编译成高度优化的引擎文件配合 NVIDIA 显卡能压出更强的单卡性能。代价是构建流程相对复杂模型格式需要通过 trtllm-build 编译和 Hugging Face 生态的适配没有 vLLM 顺手。它更偏生产级调优适合已经确定要长期运行同一批模型的场景。SGLang 是后起之秀主打的亮点是更高效的前后端处理在长文本、多轮对话和高并发场景下表现很猛RadixAttention 可以复用公共前缀的 KV Cache多轮对话场景优势明显。我的取舍经验是这样的想快速上线且团队资源有限直接上 vLLM成熟稳定踩坑资料多跑在 NVIDIA 系列卡上、追求极限性能和低延迟、且能投入人力的团队考虑 TensorRT-LLM如果你的应用场景有大量多轮对话和长文档试试 SGLang它的前缀缓存优化会让你惊喜。值得提醒的是框架版本迭代非常快别盲目追新先跑通一版再评估升级。3.3 GPU显存估算方法以L20为例选卡和选模型永远分不开。热词里频繁出现的 L20 显卡很多人在问它适合部署什么模型。L20 是 48G 显存的 NVIDIA 数据中心级显卡显存大、功耗适中、支持 BF16 和 Tensor Core对于主流开源 LLM 的部署相对友好。我通常按这个公式估算模型需要的显存参数量(GB) 模型参数量(B) × 每个参数的字节数。FP16/BF16 下每参数约 2 字节所以 7B 模型全精度权重约 14GB。INT8 量化约 7GBINT4 量化约 3.5GB。再额外加上 KV Cache 和推理过程中的激活值一般预留 30%-50% 的余量。举例来说在 L20 48G 显存上部署一个 14B 模型BF16 权重约 28GB还剩 20GB 给 KV Cache 和激活值足以应付比较长的上下文。如果想同时部署两个 7B 模型走 INT8 量化后每个约 7-8GB两个加上 KV Cache48G 也能装下但就要用前面的 Ollama 参数限制并发加载数避免显存抖动。这套估算方法不复杂但能帮你在采购之前快速判断能不能跑。我的建议是至少留 40% 余量别把显存算到 95% 再去跑一旦上下文长度升高或并发请求增多OOM 会来得非常突然。4. 从单机走向推理平台网关、调度与观测4.1 网关层设计路由、限流和模型多版本管理当你手里有多个模型服务后第一件事不是写调度器而是先把网关立起来。网关要解决的三个问题是请求往哪走、流量怎么控、模型版本怎么切。模型路由的维度很多。可以按模型名路由也可以按业务类型路由还可以按输入规模路由。例如短文本走小模型超长文本走大模型或者同一个线上请求默认走加速版小模型检测到置信度低再转发大模型。这块我建议直接用一层独立的网关服务做不要塞进每个模型服务里。Spring Boot 生态里很多人会直接把网关和业务管理后台合并其实逻辑可以放一起但边界要清晰。限流和熔断也不能省。LLM 推理是典型的高成本慢请求如果上游业务方写了个 bug 疯狂刷接口几秒钟就能把 GPU 打满。我习惯在网关层做两层限流第一层按调用方 AppKey 做 QPS 配额限制第二层按模型维度做全局并发限制。超出的请求直接返回 429返回体里带重试时间和排队建议。多版本管理同样重要。线上模型 A/B 测试和灰度发布本质就是网关层流量切分。你在网关里配置model_version: v1 → v2的权重比例然后观察回流数据和推理质量再逐步切到 v2。这个能力如果没有每个模型版本更新都意味着业务方改代码这是不可接受的。4.2 弹性扩缩容与真正的健康检查正式环境里GPU 服务扩缩容和普通 Web 服务不太一样。难点在于模型加载本身就有几秒到几十秒的时间副本扩容不能指望秒级完成GPU 资源是稀缺资源不能像 CPU 服务那样随便铺一堆副本。我在生产里推荐的方案是结合请求队列长度和 GPU 显存使用率做指标。例如当某模型的排队请求数持续超过某个阈值、且 GPU 利用率已超过 85% 时触发扩容。扩容时不要直接拉新副本先把模型镜像准备好再用预热接口加载模型等 readiness 探针通过后再接入流量。健康检查也有讲究。LLM 服务如果只是返回 200不代表推理功能正常。我见过最典型的例子是某个 vLLM 进程已经卡死但 HTTP 端口还在响应K8s 认为副本健康流量继续打进来直到客户端大量超时才暴露。正确的健康检查要做两件事一是检查模型推理是否真的在正常响应例如每 30 秒往服务发一个极短的请求二是检查推理引擎内部的 state 是否健康比如 vLLM 的is_server_ready接口。好的探针才能让扩缩容有意义。4.3 统一接入OpenAI兼容接口与观测体系推理平台做到后面你会发现统一的 API 协议是重中之重。为什么大家都要做 OpenAI 兼容接口因为它既是事实标准又方便团队内外部直接复用生态。vLLM、Ollama、LM Studio、TGI 都支持 OpenAI 风格接口这让平台接入成本大幅降低。技能方面模型服务可以暴露原生/v1/chat/completions但平台层一定要在更上面的地方做协议统一。我们通常在网关层做鉴权、用量计量和审计业务方拿到的每一个api_key都能对应到具体的配额和账单。这样做还有个额外好处以后底层换引擎业务方代码一行都不用改。观测体系建设是模型平台最重要的投入之一。指标上至少要有QPS、延迟TTFT 首 token 延迟和 TBT 每 token 延迟要分开看、GPU 利用率、显存占用、KV Cache 使用率、排队长度。日志上要带 trace_id、model_id、prompt_tokens、completion_tokens。模型层级还有一个特殊的观测维度是生成质量定期把线上请求抽样保存做评估和回归这就是 LLM as Judge 或离线评测要做的事。没有这套体系平台离“能运营”还有很远的距离。5. 边缘部署与全链路质检验收5.1 树莓派5跑YOLOv5的真实体验不只是数据中心需要部署模型边缘设备同样是模型部署的重头戏。热词里有一条是“树莓派5上部署自己训练的YOLOv5模型”这个场景我实测过可以给点参考。树莓派5的 CPU 比前代强很多但也没有强到能跑大模型的地步。YOLOv5 的 s 和 n 版本经过优化后在树莓派上推理是可以接受的。我的做法是这样训练完 YOLOv5 后导出为 ONNX再用 ONNX Runtime 在树莓派上运行。先pip install onnxruntime,然后把导出好的 best.onnx 配合 cmark export 后处理代码跑起来。没有 GPU 的情况下关键是推理尺寸输入图片 resize 到 640 或 320检测速度完全两码事。实战里的坑也很多。树莓派的内存是共享的CPU 和 GPU 共用一块 LPDDR 内存YOLO 后处理里的 numpy 操作如果写得不优化内存分配会非常频繁。建议把后处理里的循环尽量向量化避免逐框 for 循环。另外树莓派供电不足会导致 CPU 降频推理速度骤降这个不是代码问题是硬件问题换一个足功率电源能解决。如果实在想跑得快一点可以通过 Hailo-8、Coral TPU 或 RKNN NPU 之类的方案做硬件加速但工程复杂度会上一个台阶。对多数做原型验证的团队来说ONNX Runtime 在树莓派 5 上跑 YOLOv5n 已经够用了。5.2 本地视频模型部署的三个关键点“本地部署视频模型”也上过热词。视频模型和图像模型不一样数据量是爆发式的一秒钟 30 帧模型稍微慢一点就处理不过来。这类部署的关键点有三个。第一是解码与推理分离用 OpenCV 或 PyAV 解码线程专做视频取帧推理线程专做模型预测中间用带长度上限的队列缓冲避免解码过快撑爆内存。第二是帧抽样策略不是所有视频都需要逐帧推理先做运动检测画面变化大的帧才送模型这种优化在安防和质检场景能省几十倍的算力。第三是推理结果的时序后处理视频模型输出一般要做平滑或去抖例如检测目标连续几帧出现才确认否则画面闪烁会让业务方直接投诉。本地视频模型部署还有个更基础的问题别把处理和存储放在同一个机械硬盘上因为视频文件非常大的情况下 I/O 会成为瓶颈。先确认读帧速率能不能跑满推理消耗再考虑优化模型否则你优化的方向就错了。5.3 pytest搭建模型回归测试模型部署上了正式环境后最怕的不是推理慢而是“悄悄变坏”。模型更新、量化参数调整、推理引擎升级都可能让结果劣化。我强烈建议你在部署流程里接入基于 pytest 的模型回归测试。这套测试做起来不复杂核心是准备一套固定的评测样本集和阈值。每个样本包含输入、期望输出或评测标准例如分类任务的 label、生成任务的参考答案、相似度任务的标准分值。然后写 pytest 用例在预发布环境里对候选模型执行推理计算准确率、F1、BLEU、语义相似度等指标只要比基线低于设定阈值就直接 fail阻断发布。你会发现 pytest 做模型回归有个额外好处它能和 CI/CD 流程天然整合。你可以在每个模型版本推送到镜像仓库前自动触发一次回归测试测试通过才允许打正式标签。这个测试跑一次可能只要几分钟但能挡住大量质量事故。别忘了测试样本集要定期更新把线上新出现的异常 case 吸收进去否则时间一长就会回归盲区。也可以用类似思路做 LLM 的评测举个例子需要自动化评估摘要质量时可以调用一个更强大的模型当裁判也就是 LLM as Judge把这个裁判模型的打分结果和人工抽检结果做对比保证评测口径可信。这一套我做下来模型上线的安全感是完全不一样的。6. 生产环境常见问题与排错记录6.1 LLM请求失败的典型原因先说一个我在实际部署中反复见过的报错llm request failed: provider rejected the request schema or tool payload.这个报错的意思很直白上游 LLM 服务拒绝了请求的结构或工具调用格式。大多数情况下不是模型本身坏了而是客户端发出的请求不符合服务端 JSON Schema 的限制。排查思路很简单先把请求抓出来看 messages 里 system、user、assistant 角色是否符合要求tools 或 functions 的声明有没有多余字段。有些服务端对 tool 名有字符限制有些对参数对象里的 null 值敏感。我遇到最多的原因是客户端用了新版本 SDK 增加了字段但服务端还是老版本的协议。解决方案是固定 SDK 版本同时在网关层做一次协议格式化把非标准字段剥掉。类似的请求失败还有很多种比如 context length exceeded、bad prompt、unsupported parameters。处理这些问题的根本思路是在网关层做好统一错误码映射和回滚机制。因为你不可能让业务方直接面对 vLLM 或者 OpenAI SDK 的原始报错那不是生产环境的体验。6.2 显存泄漏与并发踩坑正式环境跑 LLM显存问题几乎每天都在上演。最常见的是显存缓慢爬升跑几天后 OOM。先别急着怀疑模型代码检查推理引擎版本vLLM 不同版本之间的显存回收行为差异很大升级到 0.4.x 之后的版本多数问题都有修复。我踩过最郁闷的一次坑是服务里的日志模块把推理结果全量缓存了一部分导致显存只增不减最后靠 dump trace 才发现。并发和显存的相互作用也容易出问题。max_num_seqs、max_model_len、gpu_memory_utilization这三个参数是调节的关键。显存利用率可以设 0.9 也可以设 0.7但太高了容易在长文本请求时 OOM,太低了 GPU 利用率又上不去。我习惯先设一个保守值把线上流量观测两周再逐步调高。另外就是别忽略 CUDA 的 context 占用。一个进程内如果多次初始化不同推理引擎CUDA context 可能被重复创建每份都是几百 MB 的量级。我做平台层时规定一个进程只使用一个统一的推理后端避免混用多个引擎导致显存暴涨。6.3 框架选型的常见误区最后聊聊热词里出现的各种框架和选型误区。这些热搜词里夹杂着 Spring Boot、若依、Nuxt、Flutter、Qt MVVM 这些词乍一看和模型部署无关但仔细想想它们其实都在回答同一个问题模型服务的上层应用怎么做。常见误区是想用一个框架解决所有问题。比如有人想直接用若依来做模型管理后台确实能快速出界面但若依的权限和代码生成思路适合普通业务管理模型服务的 GPU 调度和推理编排并不在它的视野里。反之有人想用 Flutter 或 Nuxt 做一个很炫的模型调用前端这当然可以但前端再炫网关层和后端的稳定性才是真正的壁垒。另外一个误区是照搬网上博客的推荐不评估团队能力。vLLM 相比 TensorRT-LLM 更容易上手但如果你团队里没有懂 CUDA 的人非要去搞 TensorRT 优化项目大概率会延期。选框架的标准应该是团队能不能在遇到问题时维护它而不是谁名气大用谁。框架本身只是工具生产环境拼的是运维体系、观测能力和团队对工具的理解深度。还有一类热词比如 agent 框架、智能体框架、co-star 框架这类恰恰说明 LLM 部署之后还有一层是应用编排。平台能力稳定之后你可以在平台上跑多智能体、跑 RAG、跑工具调用但前提是底层的推理服务有足够的并发和延迟保障。别本末倒置先把模型服务打稳再谈上层智能。6.4 实战排错速查表我把日常高频问题和排查方向整理成一个速查表有需要可以直接对号入座。症状优先排查方向常见解决手段请求报 schema rejected网关协议格式、SDK 版本固定协议版本网关层做字段剥离首 token 延迟高模型太长、排队、网关转发慢调短 max_model_len提高并发上限GPU 利用率低动态 batching 未生效、请求太稀疏开启 continuous batching合并请求显存缓慢增长引擎版本、日志缓存、context 泄漏升级版本排查缓存引用限制并发模型服务虚假健康探针只检查端口未检查推理配备推理级健康检查请求量化后效果暴跌量化方式与模型不匹配切换 AWQ/GPTQ/GGUF用回归测试验证树莓派推理变慢供电降频、内存不足换电源减小输入尺寸优化后处理这张表的每一行背后都是我踩过的实际案例。如果你也有类似问题对照着做基本能省一半排查时间。7. 最后再分享几个我自己的体会做到现在我最深的感受是模型部署这件事的难度不在单个技术点上而在怎么把几十个环节串成一条可靠的链路。单模型服务用 FastAPI 能跑大模型用 vLLM 能跑但真正让业务方放心使用、让团队能长期维护的是网关、观测、测试、资源调度这些容易被忽视的周边设施。我个人更建议团队从单模型服务开始哪怕慢一点先把一个模型的部署做扎实沉淀出可复用的模板和观测指标再逐步扩展成平台。不要一开始就想搭一个巨大的推理平台那样大概率会陷入框架的海洋里出不来。先跑通、再优化、最后再做平台化治理这个顺序几乎不会错。最后分享一个小技巧任何模型上线前至少准备好三份东西——一份模型卡记录模型版本、量化方案、显存占用、延迟指标、一份回归测试集能自动跑出质量对比报告、一份回滚方案能快速切回旧版本。这三点看着不起眼但真到出事的时候它们能救整个团队于水火。