正式环境模型部署框架全景从单模型服务到 LLM 推理平台前一阵子我给团队搭生产环境的模型服务发现很多人对“模型部署”的理解还停留在“用 Flask 起个接口”或者“docker run 一下 vLLM”的层面。等到真上了正式环境QPS 一压、显存一抖、日志一炸才知道部署这件事的水有多深。更麻烦的是现在还要面对 LLM 推理平台这种新物种——不只是把模型跑起来还要管并发、限流、知识库、Agent 编排、结果评测整个链路已经远超出“单模型服务”的范畴。这篇文章我想完整梳理一条从单模型服务走向 LLM 推理平台的路径先讲清楚单模型部署的核心思路和框架选型再展开 vLLM、Triton、TensorRT-LLM 这类高性能推理引擎的取舍然后聊 LLM 平台的网关、RAG、Agent 编排、评测这些上层设施最后把我在生产环境踩过的坑整理成一份排查手册。适合正在把模型往正式环境推的工程同学也想给已经上车的架构师一点参考。1. 内容整体设计与思路拆解模型部署为什么是个系统工程如果你只部署过一个聊天机器人 Demo你感受到的可能是“把模型怼进显存起个服务调一下 API”。但正式环境不一样背后至少叠加了四层要求第一层是资源管理。GPU 显存是刚性的模型权重、KV Cache、激活值、推理框架自身的内存开销都要算进去。第二层是性能指标。QPS、首 Token 延迟TTFT、每 Token 延迟TPOT、吞吐量不同业务有不同的侧重点。第三层是高可用。单点故障、滚动更新、优雅退出、健康检查这些在玩具环境里根本不会碰。第四层是 LLM 特有的东西显式批处理、模板拼装、结构化输出、安全过滤以及和 RAG、Agent 生态的耦合。即使只做单模型服务框架选型也直接决定了你后面能不能平滑走向推理平台。很多人一开始图省事直接用 FastAPI 手写接口等到并发上来了才发现动态批处理没法做最后只能推倒重来。我更建议一开始就把“请求入口、推理引擎、模型仓库、监控运维”四个部分分开设计这样后面接平台层不会伤筋动骨。1.1 从部署到推理平台的演进逻辑单模型部署的核心单元是“一个模型 一个服务”比如用 TorchServe 部署一个 YOLOv5或者用 FastAPI 包一个 BERT 分类器。它的特点是把模型当作一个独立的服务单元尽管理论上可以用多副本负载均衡但每个副本自己管自己的批处理无法在全局做调度。到了 LLM 阶段情况变了。LLM 是单卡装不下的模型常见 7B/14B/72B而且是自回归生成显存占用会随上下文动态变化。于是我们需要一个更聪明的推理引擎比如 vLLM 的 PagedAttention 和 Continuous Batching它能在请求级别做显存管理和批处理调度大幅提升吞吐。再往后同一个平台要承载几十个模型、多套 Agent 流程、几个业务线共用你就需要一个真正意义的推理平台模型网关、治理层、调度层、可观测性层都独立出来。这就是从“单模型服务”到“LLM 推理平台”的演进路径每个阶段各有痛点不要想着一步到位但也别等遇到瓶颈才回头。1.2 框架全景速览与选型建议我按自己的理解把现有框架分成三类一类是 Web 封装型比如 FastAPI、Flask或者 Java 侧的 Spring Boot / 若依框架。它适合原型、轻量场景但原生不支持动态批处理和显存优化LLM 场景下性能上限很低。第二类是专用推理引擎比如 vLLM、TGIHugging Face 出的、TensorRT-LLM、Triton Inference Server、ONNX Runtime。这一层负责把模型跑到接近硬件极限支持 PagedAttention、KV Cache 量化、Tensor Parallel是正式环境真正干活的层。第三类是编排平台层比如 Ollama Open WebUI 这种本地玩法的组合、GPUStack 这种集群管理工具、Dify / LangGraph 这类 Agent 编排框架以及各种 RAG 中间件。它们解决的是“如何组织模型服务”和“如何被业务消费”的问题。选型一般遵循这个思路如果只有一两个模型单卡能撑住vLLM 或 TGI 就够如果有多模型混布、跨卡调度、需要 C 级极致性能Triton 更合适如果拿到的是 ONNX 导出文件很多视觉、端侧模型就上 ONNX Runtime如果要快速在 k8s 里给业务团队提供服务还得在引擎上面加网关和统一鉴权。每类框架都不是万能的关键看你正在哪个阶段。2. 从单模型服务到高性能推理引擎核心细节与实操要点聊完框架全景我们回到最常被问到的实操问题单模型服务到底该怎么搭2.1 用 FastAPI 做模型服务快速起步但还是要注意坑一个典型的单模型服务就是一个 Python 进程加载模型进入显存对外暴露 HTTP 接口。我见过无数人用 FastAPI 写这种东西确实快写个 /predict 接口里面调 model()完事。但有几个细节很多人第一次都会漏掉第一个坑是模型加载时机。项目启动后再 load 模型会造成服务长时间无响应影响健康检查。正确的做法是定义一个全局的 lifespan在进程启动阶段把模型加载好期间让 /health 返回 503等加载完成再放流量进来。第二个坑是全局锁。如果你没有做批处理多个请求同时进来会争抢 GPU换来换去反而更慢。简单做法是给推理函数加线程锁保证单个进程同一时间只跑一次推理。但这样 QPS 就受限了因为 GPU 利用率做不上去。第三个坑是 batch 和队列。想要提升吞吐就要自己实现一个简单的请求队列攒够 N 个请求或 X 毫秒后一起推理这就是简易动态批处理。你可以用一个高性能异步消息服务来做队列或者直接在 Python 里用一个队列但效率都不如专用引擎的 Continuous Batching 好。所以如果你在正式环境跑 LLM我不建议用 FastAPI 手写推理循环直接用 vLLM 起步更现实。from fastapi import FastAPI, UploadFile from contextlib import asynccontextmanager import torch model_holder {} asynccontextmanager async def lifespan(app: FastAPI): # 启动时加载模型并锁定到当前设备 from transformers import AutoModel, AutoTokenizer model_holder[model] AutoModel.from_pretrained(your/local/path).to(cuda).eval() model_holder[tokenizer] AutoTokenizer.from_pretrained(your/local/path) yield model_holder.clear()这是我早期做 YOLOv5 边缘端部署时的经验树莓派 5 上跑 YOLOv5加载模型本身不算难难的是首次推理的 warmup 和算力分配。树莓派算力有限模型不能选太大输入分辨率要固定下来还要做去抖动、缓冲、帧处理这类业务融合。边缘端的模型部署强调“精简 确定性”跟云端 LLM 平台的设计思路完全不同但两者在“先定边界、再选框架、最后做调优”这件事上是殊途同归的。2.2 TorchServe 与 Triton 这类正式推理服务器多模型、多版本、动态加载如果你只有一个模型手写 FastAPI 可以接受。但当你需要同时部署多个模型、多个版本灰度、不断更新模型权重时就该用专门的推理服务器了。NVIDIA Triton Inference Server 是我合作过的团队用得最多的一个它支持多模型并发每个模型可以独立配置实例数它支持多种后端包括 PyTorch、TensorRT、ONNX Runtime它还能做模型版本管理灰度切换的时候不需要重启服务。Triton 有个关键概念叫 Model Repository一个目录一个模型里面包含若干版本文件夹每个版本下放 config.pbtxt 和模型文件。模型加载后Triton 自动为每个模型创建调度实例支持 Dynamic Batching也就是说你不需要自己写队列配置一下即可max_batch_size 设 8preferred_batch_size 设 [4, 8]就可以自动攒批。配置模型的同时还要把 instance_group 设成 GPU 实例数量。显存不够时顶多是把实例数调小让模型共享 GPU而不是让 Triton 自动把所有模型都塞进显存——它会做但性能会很差。TorchServe 在 PyTorch 生态里更顺手但它的核心设计为传统模型做了较多假设跑 LLM 时没有 Triton 那么灵活通常更适合视频、图片这类单轮推理。我的建议是如果你团队只有 PyTorch 一条技术栈TorchServe 起步没有问题如果后面要接 vLLM、TensorRT-LLM就直接上 Triton让 Triton 作为统一入口后端再去对接不同的推理引擎。2.3 高性能推理引擎详解vLLM、TensorRT-LLM、TGI、ONNX Runtime现在把目光放到 LLM 推理平台上最核心的一环——推理引擎。这个环节选错了后面的优化都要跟着返工。vLLM是当下最热门的选择核心是 PagedAttention。它把 KV Cache 切成固定大小的块page像操作系统管理内存一样按需分配解决了显存碎片问题。配合 Continuous Batching即在请求粒度上把新请求插入到正在生成的空隙里吞吐量能比 naive 部署高出数倍。vLLM 的配置项很多但正式环境里你至少要把几个参数搞明白tensor_parallel_size跨卡并行、max_num_seqs并发生成长度、gpu_memory_utilization显存利用率上限。我一开始把 gpu_memory_utilization 设成 0.95结果 KV Cache 太大服务启动后没跑满就报 OOM后来调成 0.85 才稳定。docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/qwen2.5-7b-instruct \ --served-model-name qwen7b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --max-num-seqs 64 \ --enforce-eager注意max-num-seqs 设太大会导致请求排队时显存瞬间爆掉设太小又把吞吐锁死。建议先按业务预估并发设置再用压测逐步调参。TensorRT-LLM是 NVIDIA 官方针对自家 GPU 做的极致优化引擎。它把模型编译成 TensorRT engine权重精度、层融合、KV Cache 内存分配都预先定死推理速度通常比 vLLM 还要快一点但灵活性差模型结构一改就要重新构建 engine。更麻烦的是TensorRT-LLM 更偏向工程集成写 C/Python 代码较多量化和内存分配如果不熟悉很容易把显存吃到黑屏。我的经验是如果只是 7B、13B 这种中档模型vLLM 完全够用如果是 70B 且对延迟极度敏感、还要追求极致性价比再考虑 TensorRT-LLM。TGIText Generation Inference是 Hugging Face 推出的推理服务底层支持 Flash Attention 和 Continuous Batching。它的 API 设计很简洁对 Hugging Face 生态兼容性好但性能调优能力略逊于 vLLM。实测下来相同条件下 vLLM 的吞吐往往比 TGI 高 20%~30%。TGI 更适合想快速部署、又不想折腾太多参数的团队。ONNX Runtime则更适合导出成 ONNX 格式的模型。这类模型业内叫 “ONNX 部署”典型场景是边缘设备或 C 服务。ONNX 的优势是部署形态轻、不依赖 Python 环境、跨平台劣势是 LLM 场景下的动态形状处理比较棘手而且量化工具链不如 GGUF 顺畅。2.4 GGUF / ONNX 模型格式与量化到底在解决什么问题提到 LLM 部署绕不开模型格式。很多人拿到 Hugging Face 的原生格式safetensors就直接跑这在服务端没什么问题但如果你要上 Ollama、llama.cpp、跑在 Windows 或者果机本地就需要 GGUF 格式。GGUF 是 llama.cpp 团队设计的格式核心特点是一体化打包权重、分词器、模板、超参还内嵌了量化后的权重常见 Q4_K_M / Q8_0。它解决的核心问题不是“压缩成最小”而是“跨平台可运行且内存可控”。把 7B 模型从 fp16 量化到 Q4_K_M内存大概从 14GB 降到 4~6GB本地跑完全没问题。我们在 Ollama 里部署 qwen1.5-0.5b-chat就是直接 ollama run qwen2.5:0.5b本地机器用起来非常顺滑。ONNX 走的是另一条路它主要解决“部署环境无关”。模型导成 ONNX 后可以在 ONNX Runtime 里跑也可以用 onnx-tensorrt 工具转到 TensorRT 后端。但注意ONNX 对 LLM 的支持一直比 GGUF 磨蹭因为 LLM 里有大量动态 shape、自回归循环等结构导出时容易遇到算子不支持的问题。所以 LLM 场景我建议优先考虑 GGUF/原生 PyTorchONNX 留给视觉模型和传统 CV 场景。# 把 safetensors 转成 GGUF如使用 llama.cpp 工具链 python convert_hf_to_gguf.py your_model_dir \ --outfile qwen2.5-7b-q4_k_m.gguf \ --outtype q4_k_m如果是对量化精度比较敏感的任务我不建议一上来就 Q4可以先跑 fp16 基准结果再对比 Q8 和 Q4看指标退化多少。有很多业务模型在 Q4 下损失不大但也有分类模型掉 2~3 个百分点的情况。正式上线前量化对比实验必须做。3. 实操过程与核心环节实现Docker、GPUStack、可视化与集群光有推理引擎还不够正式环境还要解决“怎么跑起来”“怎么管理多机”“怎么给业务团队可视化使用”的问题。3.1 通过 Docker 部署 vLLM镜像、网络、挂载与健康检查用 Docker 部署 vLLM 是最常见的入门路径。我给出一个可以直接照抄的流程第一步准备模型目录。如果你是用 Hugging Face 缓存的模型直接把${HF_HOME}/hub/models--org--model映射进容器或者单独复制一份权重到 /data/models 下。我不建议直接--model Qwen/Qwen2.5-7B让容器现场下载正式环境必须离线、固定版本。第二步选择镜像。官方镜像 vllm/vllm-openai 会跟着社区版本更新但生产上我习惯锁定 tag比如 vllm/vllm-openai:v0.8.4避免过两天功能漂移。第三步挂载与端口。GPU 卡用--gpus all反而不是最佳实践更可控的是按索引暴露比如--gpus device0,device1。容器内 8000 端口映射到宿主机做个反向代理即可。注意 vLLM 的 API 是 OpenAI 兼容的业务组可以直接用 openai SDK 连接不需要额外写适配层。第四步健康检查与优雅退出。vLLM 自带 /health但进程重启时如果是 kill -9 强杀显存状态可能残留造成后面容器启动失败。建议设置健康检查探针同时安排一个停止前的延迟关停让正在跑的 batch 有机会落盘。在 Kubernetes 里就用 preStop 钩子sleep 几秒再 SIGTERM。3.2 用 GPUStack 做 Windows 或小规模集群的模型管理GPUStack 这个工具很多人可能还比较陌生但它确实适合小团队、Windows 环境、混合架构场景。它把推理服务抽象成“模型部署实例”支持在 Windows/服务器上管理 GPU提供了统一 API 和一个轻量 Web 界面。它的定位类似“私有化的方式快速跑起多卡模型平台”适合不愿意一上来就搭 Kubernetes 的团队。我在一个内部项目里用 GPUStack 在 Windows 工作站上部署过几个小模型。体验是安装简单模型管理直观自带 token 鉴权还能看 GPU 占用对非专职运维团队相当友好。但它不适合超大规模集群调度策略没有 Kubernetes 那么灵活高级网络策略支持也弱。所以 GPUStack 更合适做“实验平台”正式的要紧业务我还是建议上 K8s。3.3 Ollama Open WebUI本地和开发环境的可视化推理体验提到可视化很多做过本地模型实验的人都会碰到一个问题Ollama 部署完模型后只有一个 API怎么搞个界面出来最常见的答案就是 Open WebUI。它把 Ollama 的本地模型包装成 ChatGPT 式的聊天页面除了好看还解决了几个实际问题多模型切换、会话历史持久化、知识库上传实验性的 RAG、角色设计。Open WebUI 是一个完整的 chat UI支持接入 Ollama和 OpenAI 兼容接口可以用 Docker 一键起服务。搭配关系是Ollama 负责拉取和运行 GGUF 模型Open WebUI 负责展示和交互两者通过 Ollama 的 /api 接口通信。很多团队在正式生产之前用它做内部试用和验收完全够用。3.4 Kubernetes 下的推理平台从单 Pod 到弹性资源池如果你最终要走向真正的 LLM 推理平台Kubernetes 是绕不开的一环。推理服务天然适合 Kubernetes 的滚动更新和资源调度。核心工作流是每个模型服务做成一个 DeploymentPod 内跑 vLLM / Triton 容器Pod 外挂 PVC存放模型权重Service 做负载均衡Ingress 暴露到公司内网。另外GPU 级联调度和 GPU 显存 oversubscription 需要借助设备插件来实现。在 Kubernetes 里跑 LLM 要特别注意两个东西一个是亲和性调度不要让两个大模型 Pod 落在同一张卡上这会直接 OOM另一个是完整的探针vLLM 的 /health 可以作为 livenessProbe但要再写一个 readinessProbe 专门检查模型是否已经加载完成防止流量砸到一个还在加载的副本。我见过太多团队因为 readiness 没配好新服务一上线就把部分请求打到正在初始化实例上造成大量超时。apiVersion: apps/v1 kind: Deployment metadata: name: vllm-llama3-8b spec: replicas: 3 template: spec: containers: - name: vllm image: vllm/vllm-openai:v0.8.4 args: [--model, /model, --served-model-name, llama3-8b, --gpu-memory-utilization, 0.85] readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 30 periodSeconds: 104. LLM 推理平台的完整组件RAG、Agent 编排、网关与评测单模型服务 推理引擎只能解决“模型能跑”的问题。真正常见的 LLM 推理平台还包括 RAG 知识库、Agent 编排、网关鉴权、评测这套完整链路。4.1 LLM Wiki 知识库、GraphRAG 与本体让模型带上业务上下文知识库有三个关键词一起出现是近期的趋势Wiki、GraphRAG、本体Ontology。传统 RAG 的流程文档切片、向量化、检索、拼 Prompt。它确实能解决一部分事实问答问题但单纯靠向量相似度召回在复杂关系问答上经常翻车。GraphRAG 的思路是先用 LLM 抽取实体和关系建知识图谱再通过图结构检索来回答。这么做的好处是模型可以顺着关系链跳到下一跳回答“某业务线和某团队之间的合作流程”这类跨段落问题。代价是构建成本高需要跑大量 LLM 抽取任务。而“本体”概念更进一步它给知识图谱加了一层模式层定义了类型、属性、关系约束。相当于让模型知道“谁是客户、谁是供应商、它们的资质要求有哪些约束”。你去看 LLM Wiki 这类知识库系统底层往往就是“本体 图谱 向量”的混合检索。实操上我建议不要一上来就 GraphRAG先在传统 RAG 基础上把分块策略和 top-k 选好再逐步加入图谱。很常见的错误是切片定得太短把关键事实拆散了或者是检索 Top-k 设得太小相关段落被滤掉。你至少要让检索召回 5 段左右再交给 LLM让它自己选。4.2 Agent 框架与编排LangGraph、Dify、Eino 的取舍LLM 推理平台上另一块核心是 Agent 编排。单纯的问答模型只能回答问题Agent 框架让模型可以调用工具、读数据库、执行动作是业务真正切入生产系统的门。LangGraph 是目前我在生产环境用得比较顺手的框架。它的核心思维是“图状态机”——把每一步 Agent 执行步骤建模成图里的节点节点之间有条件和数据流转。相比 LangChain 的链式调用LangGraph 更适合做需要循环、条件分支、人工介入的流程。另一个方向是 Dify偏 Low-Code业务同学可以在界面上拖拽搭 RAG 应用和 Agent 工作流底层再对接 vLLM 或 OpenAI 兼容服务。Eino 是字节跳动开源的一个新框架如果你在 Go 技术栈里值得关注。它主打高性能和可调度性适合把 Agent 流程嵌入到微服务架构中。选型逻辑很简单如果要快速交付且团队里没有太多算法同学Dify 会省很多事如果要做复杂状态机、多 Agents 协作、深度定制LangGraph 更稳如果性能要求极高且技术栈非 Python再看 Eino。from langgraph.graph import StateGraph, END class AgentState(dict): messages: list def call_llm(state: AgentState): response client.chat.completions.create( messagesstate[messages], modelqwen7b ) return {messages: [response.choices[0].message]} graph StateGraph(AgentState) graph.add_node(llm, call_llm) graph.set_entry_point(llm) graph.add_edge(llm, END) app graph.compile()注意Agent 框架不是“让模型自由发挥”。正式环境必须给 Agent 加工具白名单、调用超时、失败重试上限以及最重要的 conversation 隔离。如果你一种业务一个 Agent后面维护成本会迅速膨胀。4.3 模型网关LLM 网关、语义路由与限流当平台里同时存在好几个模型服务、好几个业务线共用时就需要一个 LLM 网关。它的职责包括统一入口与鉴权、模型路由、限流、灰度、可观测性、协议转换不同模型可能不是同一个 API 风格。做网关时“语义路由”这个概念现在很流行不是手动指定模型而是根据请求内容动态路由到不同模型。比如简单问题走小模型、复杂推理走大模型这样可以显著降低成本。我们内部实践下来语义路由要基于 Embedding 和分类模型去判断纯靠提示词很难稳定。另外网关层必须做限流不然某个业务线的突发流量可能把整个推理集群打爆。令牌桶算法依然是最可靠的方案。4.4 评测与可观测性从 DeepEval 到 Open LLM Leaderboard模型部署上线前一定要过评测这一关。否则你很难回答“这个新模型和老模型比到底好不好”的问题。现在有不少评测工具其中 DeepEval 是一个比较轻量、可接入 CI 的开源框架可以在部署流水线里跑回归评估。它的思路是定义一组测试用例起一个评测模型作为裁判用类似“G-Eval”的方法来打分做成了 pytest 风格直接和 pytest 框架无缝衔接。评测指标要分开看传统指标准确率、F1适合分类任务开放生成任务要用语义相似度、答案相关性、忠实度、毒性去衡量。还有一个方向是参照公开榜单比如 Open LLM Leaderboard它给了你一个相对基线你的模型在工业界处于什么位置。但注意公开榜单和你的业务场景往往不一样所以一定要搭建自己的离线评测集。部署以后可观测性又是另一层每轮请求的延迟、Token 生成速率、显存水位、队列长度都要监控。对外只看到“生成很慢”实际上可能是并发过大导致请求排队或者显存碎片不断累积。# DeepEval 实测示例 from deepeval import evaluate from deepeval.metrics.answer_relevancy import AnswerRelevancyMetric from deepeval.test_case import LLMTestCase test_case LLMTestCase(input..., actual_output..., expected_output...) metric AnswerRelevancyMetric(modellocal-llm) result evaluate([test_case], [metric])5. 常见问题与排查技巧实录最后分享我在正式环境里踩过的一些坑。这些坑大多不算复杂但每次都会让人痛苦一阵建议直接收藏对照。5.1 显存不足、模型加载失败、服务无法启动显存问题是模型部署里出现频率最高的问题。新手最容易犯的错误是在模型加载阶段没有做内存预估。7B 模型 fp16 大约 14GB 权重加上 KV Cache 至少 8GB如果 GPU 只有 24GB能余下的也就 2GB。此时如果把 gpu_memory_utilization 设成 0.95服务启动没问题一旦请求进来 KV Cache 分配立刻失败。正确做法是先留足权重空间再分配 KV Cache。另一个经验是最好安排一块专用显存而不是把训练和推理混在一张卡上否则训练一抖动推理直接挂掉。5.2 QPS 低、并发上不去QPS 低通常有三个原因。第一没有开 Continuous Batching或 max-num-seqs 太小。第二动态批处理的等待时间设得太短攒不到一个有效 batch。第三Token 生成的最大长度设得太长导致单个请求占用的 KV Cache 时间过久整体吞吐被拖慢。压测的时候要结合业务平均输入输出长度来调参不能拿最大长度去算容量。5.3 量化后效果变差量化不是白嫖它用少量精度换显存和速度。Q4_K_M 通常损失不大但如果模型比较小比如 0.5B量化后很可能明显变傻。遇到这种情况先跑基准对比 fp16 与 Q8、Q4 的输出量化前后差的度量指标逐项分析。如果是任务型模型抽取、分类尽量回到 fp16 或 Q8 试试宁可多占用点显存也不想效果掉点。5.4 服务报 schema/tool payload rejected用 OpenAI 兼容接口时经常遇到llm request failed: provider rejected the request schema or tool payload。这类错误一般是对齐问题后端 vLLM 版本较老不支持某些工具调用 schema或者工具参数里带了不符合 JSON Schema 规范的内容。先打开服务端日志看 reject 的具体原因把 tools payload 简化到最小可复现样例再逐步加字段。版本升级也是常用手段我一般喜欢把 vLLM 锁在最新稳定版避免因为功能不兼容被反复折磨。5.5 推理延迟抖动延迟抖动往往不是模型变慢而是队列积压、GPU 频率降频、显存带宽争抢导致。排查思路先看 P99 和平均延迟如果 P99 明显高于均值大概率是排队再看 GPU 利用率曲线如果利用率经常 100%说明并发策略太激进如果频繁抖动且 GPU 频率降低可能是散热或者电源限制。下边给一张排查速查表作为我实际排障时第一步要查的内容现象可能原因大概率处理办法启动时 OOM 或加载失败显存预留不足调低 gpu_memory_utilization 至 0.8~0.9QPS 上不去Continuous Batching 没生效检查 max-num-seqs、批处理等待窗口延迟抖动明显请求队列积压观察 P99、减少入口并发或增加副本模型加载慢从磁盘/网络读权重权重放本地 NVMe预拉取镜像工具调用报错Schema 不兼容简化 tools payload、升级推理引擎量化效果变差精度损失过大换成 Q8 或 fp16重新跑评测偶发超时探针或优雅退出没配好增加 readiness 探针、延长 preStop6. 我最后想说的几件事踩过这些坑之后我最大的体会是正式环境里的模型部署永远不只是“把模型跑起来”。它的成败取决于你是否在一开始就把路径想清楚是先跑一个单模型服务验证效果还是直接上高性能推理引擎再或者一步到位搭 LLM 推理平台。这三个阶段的复杂度差异是数量级的但也不是越高级越好。如果业务量不大、模型数量少一个 vLLM 服务加一个网关就已经是很扎实的正式环境如果多个团队共用 GPU、模型经常迭代、还要接一堆 Agent 和知识库场景那才值得投入精力去搭全平台。还有一个小建议任何模型上线之前一定先把“退出路径”想好。所谓退出路径就是新模型效果不行你怎么快速回滚到旧模型。模型网关的作用在这一刻体现得最充分——只改一个路由配置就能切回去。没有网关的话你就只能重新发布服务那个过程在正式环境里会非常煎熬。这个领域迭代速度极快框架日新月异但只要把资源管理、推理引擎、模型格式、网关编排、评测监控这几条主线抓住后面不管框架怎么换你都能快速上车。希望这篇全景梳理能帮你在正式环境的模型落地多避开几个坑。 从单模型服务到LLM推理平台：生产环境部署全景指南
正式环境模型部署框架全景从单模型服务到 LLM 推理平台前一阵子我给团队搭生产环境的模型服务发现很多人对“模型部署”的理解还停留在“用 Flask 起个接口”或者“docker run 一下 vLLM”的层面。等到真上了正式环境QPS 一压、显存一抖、日志一炸才知道部署这件事的水有多深。更麻烦的是现在还要面对 LLM 推理平台这种新物种——不只是把模型跑起来还要管并发、限流、知识库、Agent 编排、结果评测整个链路已经远超出“单模型服务”的范畴。这篇文章我想完整梳理一条从单模型服务走向 LLM 推理平台的路径先讲清楚单模型部署的核心思路和框架选型再展开 vLLM、Triton、TensorRT-LLM 这类高性能推理引擎的取舍然后聊 LLM 平台的网关、RAG、Agent 编排、评测这些上层设施最后把我在生产环境踩过的坑整理成一份排查手册。适合正在把模型往正式环境推的工程同学也想给已经上车的架构师一点参考。1. 内容整体设计与思路拆解模型部署为什么是个系统工程如果你只部署过一个聊天机器人 Demo你感受到的可能是“把模型怼进显存起个服务调一下 API”。但正式环境不一样背后至少叠加了四层要求第一层是资源管理。GPU 显存是刚性的模型权重、KV Cache、激活值、推理框架自身的内存开销都要算进去。第二层是性能指标。QPS、首 Token 延迟TTFT、每 Token 延迟TPOT、吞吐量不同业务有不同的侧重点。第三层是高可用。单点故障、滚动更新、优雅退出、健康检查这些在玩具环境里根本不会碰。第四层是 LLM 特有的东西显式批处理、模板拼装、结构化输出、安全过滤以及和 RAG、Agent 生态的耦合。即使只做单模型服务框架选型也直接决定了你后面能不能平滑走向推理平台。很多人一开始图省事直接用 FastAPI 手写接口等到并发上来了才发现动态批处理没法做最后只能推倒重来。我更建议一开始就把“请求入口、推理引擎、模型仓库、监控运维”四个部分分开设计这样后面接平台层不会伤筋动骨。1.1 从部署到推理平台的演进逻辑单模型部署的核心单元是“一个模型 一个服务”比如用 TorchServe 部署一个 YOLOv5或者用 FastAPI 包一个 BERT 分类器。它的特点是把模型当作一个独立的服务单元尽管理论上可以用多副本负载均衡但每个副本自己管自己的批处理无法在全局做调度。到了 LLM 阶段情况变了。LLM 是单卡装不下的模型常见 7B/14B/72B而且是自回归生成显存占用会随上下文动态变化。于是我们需要一个更聪明的推理引擎比如 vLLM 的 PagedAttention 和 Continuous Batching它能在请求级别做显存管理和批处理调度大幅提升吞吐。再往后同一个平台要承载几十个模型、多套 Agent 流程、几个业务线共用你就需要一个真正意义的推理平台模型网关、治理层、调度层、可观测性层都独立出来。这就是从“单模型服务”到“LLM 推理平台”的演进路径每个阶段各有痛点不要想着一步到位但也别等遇到瓶颈才回头。1.2 框架全景速览与选型建议我按自己的理解把现有框架分成三类一类是 Web 封装型比如 FastAPI、Flask或者 Java 侧的 Spring Boot / 若依框架。它适合原型、轻量场景但原生不支持动态批处理和显存优化LLM 场景下性能上限很低。第二类是专用推理引擎比如 vLLM、TGIHugging Face 出的、TensorRT-LLM、Triton Inference Server、ONNX Runtime。这一层负责把模型跑到接近硬件极限支持 PagedAttention、KV Cache 量化、Tensor Parallel是正式环境真正干活的层。第三类是编排平台层比如 Ollama Open WebUI 这种本地玩法的组合、GPUStack 这种集群管理工具、Dify / LangGraph 这类 Agent 编排框架以及各种 RAG 中间件。它们解决的是“如何组织模型服务”和“如何被业务消费”的问题。选型一般遵循这个思路如果只有一两个模型单卡能撑住vLLM 或 TGI 就够如果有多模型混布、跨卡调度、需要 C 级极致性能Triton 更合适如果拿到的是 ONNX 导出文件很多视觉、端侧模型就上 ONNX Runtime如果要快速在 k8s 里给业务团队提供服务还得在引擎上面加网关和统一鉴权。每类框架都不是万能的关键看你正在哪个阶段。2. 从单模型服务到高性能推理引擎核心细节与实操要点聊完框架全景我们回到最常被问到的实操问题单模型服务到底该怎么搭2.1 用 FastAPI 做模型服务快速起步但还是要注意坑一个典型的单模型服务就是一个 Python 进程加载模型进入显存对外暴露 HTTP 接口。我见过无数人用 FastAPI 写这种东西确实快写个 /predict 接口里面调 model()完事。但有几个细节很多人第一次都会漏掉第一个坑是模型加载时机。项目启动后再 load 模型会造成服务长时间无响应影响健康检查。正确的做法是定义一个全局的 lifespan在进程启动阶段把模型加载好期间让 /health 返回 503等加载完成再放流量进来。第二个坑是全局锁。如果你没有做批处理多个请求同时进来会争抢 GPU换来换去反而更慢。简单做法是给推理函数加线程锁保证单个进程同一时间只跑一次推理。但这样 QPS 就受限了因为 GPU 利用率做不上去。第三个坑是 batch 和队列。想要提升吞吐就要自己实现一个简单的请求队列攒够 N 个请求或 X 毫秒后一起推理这就是简易动态批处理。你可以用一个高性能异步消息服务来做队列或者直接在 Python 里用一个队列但效率都不如专用引擎的 Continuous Batching 好。所以如果你在正式环境跑 LLM我不建议用 FastAPI 手写推理循环直接用 vLLM 起步更现实。from fastapi import FastAPI, UploadFile from contextlib import asynccontextmanager import torch model_holder {} asynccontextmanager async def lifespan(app: FastAPI): # 启动时加载模型并锁定到当前设备 from transformers import AutoModel, AutoTokenizer model_holder[model] AutoModel.from_pretrained(your/local/path).to(cuda).eval() model_holder[tokenizer] AutoTokenizer.from_pretrained(your/local/path) yield model_holder.clear()这是我早期做 YOLOv5 边缘端部署时的经验树莓派 5 上跑 YOLOv5加载模型本身不算难难的是首次推理的 warmup 和算力分配。树莓派算力有限模型不能选太大输入分辨率要固定下来还要做去抖动、缓冲、帧处理这类业务融合。边缘端的模型部署强调“精简 确定性”跟云端 LLM 平台的设计思路完全不同但两者在“先定边界、再选框架、最后做调优”这件事上是殊途同归的。2.2 TorchServe 与 Triton 这类正式推理服务器多模型、多版本、动态加载如果你只有一个模型手写 FastAPI 可以接受。但当你需要同时部署多个模型、多个版本灰度、不断更新模型权重时就该用专门的推理服务器了。NVIDIA Triton Inference Server 是我合作过的团队用得最多的一个它支持多模型并发每个模型可以独立配置实例数它支持多种后端包括 PyTorch、TensorRT、ONNX Runtime它还能做模型版本管理灰度切换的时候不需要重启服务。Triton 有个关键概念叫 Model Repository一个目录一个模型里面包含若干版本文件夹每个版本下放 config.pbtxt 和模型文件。模型加载后Triton 自动为每个模型创建调度实例支持 Dynamic Batching也就是说你不需要自己写队列配置一下即可max_batch_size 设 8preferred_batch_size 设 [4, 8]就可以自动攒批。配置模型的同时还要把 instance_group 设成 GPU 实例数量。显存不够时顶多是把实例数调小让模型共享 GPU而不是让 Triton 自动把所有模型都塞进显存——它会做但性能会很差。TorchServe 在 PyTorch 生态里更顺手但它的核心设计为传统模型做了较多假设跑 LLM 时没有 Triton 那么灵活通常更适合视频、图片这类单轮推理。我的建议是如果你团队只有 PyTorch 一条技术栈TorchServe 起步没有问题如果后面要接 vLLM、TensorRT-LLM就直接上 Triton让 Triton 作为统一入口后端再去对接不同的推理引擎。2.3 高性能推理引擎详解vLLM、TensorRT-LLM、TGI、ONNX Runtime现在把目光放到 LLM 推理平台上最核心的一环——推理引擎。这个环节选错了后面的优化都要跟着返工。vLLM是当下最热门的选择核心是 PagedAttention。它把 KV Cache 切成固定大小的块page像操作系统管理内存一样按需分配解决了显存碎片问题。配合 Continuous Batching即在请求粒度上把新请求插入到正在生成的空隙里吞吐量能比 naive 部署高出数倍。vLLM 的配置项很多但正式环境里你至少要把几个参数搞明白tensor_parallel_size跨卡并行、max_num_seqs并发生成长度、gpu_memory_utilization显存利用率上限。我一开始把 gpu_memory_utilization 设成 0.95结果 KV Cache 太大服务启动后没跑满就报 OOM后来调成 0.85 才稳定。docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/qwen2.5-7b-instruct \ --served-model-name qwen7b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --max-num-seqs 64 \ --enforce-eager注意max-num-seqs 设太大会导致请求排队时显存瞬间爆掉设太小又把吞吐锁死。建议先按业务预估并发设置再用压测逐步调参。TensorRT-LLM是 NVIDIA 官方针对自家 GPU 做的极致优化引擎。它把模型编译成 TensorRT engine权重精度、层融合、KV Cache 内存分配都预先定死推理速度通常比 vLLM 还要快一点但灵活性差模型结构一改就要重新构建 engine。更麻烦的是TensorRT-LLM 更偏向工程集成写 C/Python 代码较多量化和内存分配如果不熟悉很容易把显存吃到黑屏。我的经验是如果只是 7B、13B 这种中档模型vLLM 完全够用如果是 70B 且对延迟极度敏感、还要追求极致性价比再考虑 TensorRT-LLM。TGIText Generation Inference是 Hugging Face 推出的推理服务底层支持 Flash Attention 和 Continuous Batching。它的 API 设计很简洁对 Hugging Face 生态兼容性好但性能调优能力略逊于 vLLM。实测下来相同条件下 vLLM 的吞吐往往比 TGI 高 20%~30%。TGI 更适合想快速部署、又不想折腾太多参数的团队。ONNX Runtime则更适合导出成 ONNX 格式的模型。这类模型业内叫 “ONNX 部署”典型场景是边缘设备或 C 服务。ONNX 的优势是部署形态轻、不依赖 Python 环境、跨平台劣势是 LLM 场景下的动态形状处理比较棘手而且量化工具链不如 GGUF 顺畅。2.4 GGUF / ONNX 模型格式与量化到底在解决什么问题提到 LLM 部署绕不开模型格式。很多人拿到 Hugging Face 的原生格式safetensors就直接跑这在服务端没什么问题但如果你要上 Ollama、llama.cpp、跑在 Windows 或者果机本地就需要 GGUF 格式。GGUF 是 llama.cpp 团队设计的格式核心特点是一体化打包权重、分词器、模板、超参还内嵌了量化后的权重常见 Q4_K_M / Q8_0。它解决的核心问题不是“压缩成最小”而是“跨平台可运行且内存可控”。把 7B 模型从 fp16 量化到 Q4_K_M内存大概从 14GB 降到 4~6GB本地跑完全没问题。我们在 Ollama 里部署 qwen1.5-0.5b-chat就是直接 ollama run qwen2.5:0.5b本地机器用起来非常顺滑。ONNX 走的是另一条路它主要解决“部署环境无关”。模型导成 ONNX 后可以在 ONNX Runtime 里跑也可以用 onnx-tensorrt 工具转到 TensorRT 后端。但注意ONNX 对 LLM 的支持一直比 GGUF 磨蹭因为 LLM 里有大量动态 shape、自回归循环等结构导出时容易遇到算子不支持的问题。所以 LLM 场景我建议优先考虑 GGUF/原生 PyTorchONNX 留给视觉模型和传统 CV 场景。# 把 safetensors 转成 GGUF如使用 llama.cpp 工具链 python convert_hf_to_gguf.py your_model_dir \ --outfile qwen2.5-7b-q4_k_m.gguf \ --outtype q4_k_m如果是对量化精度比较敏感的任务我不建议一上来就 Q4可以先跑 fp16 基准结果再对比 Q8 和 Q4看指标退化多少。有很多业务模型在 Q4 下损失不大但也有分类模型掉 2~3 个百分点的情况。正式上线前量化对比实验必须做。3. 实操过程与核心环节实现Docker、GPUStack、可视化与集群光有推理引擎还不够正式环境还要解决“怎么跑起来”“怎么管理多机”“怎么给业务团队可视化使用”的问题。3.1 通过 Docker 部署 vLLM镜像、网络、挂载与健康检查用 Docker 部署 vLLM 是最常见的入门路径。我给出一个可以直接照抄的流程第一步准备模型目录。如果你是用 Hugging Face 缓存的模型直接把${HF_HOME}/hub/models--org--model映射进容器或者单独复制一份权重到 /data/models 下。我不建议直接--model Qwen/Qwen2.5-7B让容器现场下载正式环境必须离线、固定版本。第二步选择镜像。官方镜像 vllm/vllm-openai 会跟着社区版本更新但生产上我习惯锁定 tag比如 vllm/vllm-openai:v0.8.4避免过两天功能漂移。第三步挂载与端口。GPU 卡用--gpus all反而不是最佳实践更可控的是按索引暴露比如--gpus device0,device1。容器内 8000 端口映射到宿主机做个反向代理即可。注意 vLLM 的 API 是 OpenAI 兼容的业务组可以直接用 openai SDK 连接不需要额外写适配层。第四步健康检查与优雅退出。vLLM 自带 /health但进程重启时如果是 kill -9 强杀显存状态可能残留造成后面容器启动失败。建议设置健康检查探针同时安排一个停止前的延迟关停让正在跑的 batch 有机会落盘。在 Kubernetes 里就用 preStop 钩子sleep 几秒再 SIGTERM。3.2 用 GPUStack 做 Windows 或小规模集群的模型管理GPUStack 这个工具很多人可能还比较陌生但它确实适合小团队、Windows 环境、混合架构场景。它把推理服务抽象成“模型部署实例”支持在 Windows/服务器上管理 GPU提供了统一 API 和一个轻量 Web 界面。它的定位类似“私有化的方式快速跑起多卡模型平台”适合不愿意一上来就搭 Kubernetes 的团队。我在一个内部项目里用 GPUStack 在 Windows 工作站上部署过几个小模型。体验是安装简单模型管理直观自带 token 鉴权还能看 GPU 占用对非专职运维团队相当友好。但它不适合超大规模集群调度策略没有 Kubernetes 那么灵活高级网络策略支持也弱。所以 GPUStack 更合适做“实验平台”正式的要紧业务我还是建议上 K8s。3.3 Ollama Open WebUI本地和开发环境的可视化推理体验提到可视化很多做过本地模型实验的人都会碰到一个问题Ollama 部署完模型后只有一个 API怎么搞个界面出来最常见的答案就是 Open WebUI。它把 Ollama 的本地模型包装成 ChatGPT 式的聊天页面除了好看还解决了几个实际问题多模型切换、会话历史持久化、知识库上传实验性的 RAG、角色设计。Open WebUI 是一个完整的 chat UI支持接入 Ollama和 OpenAI 兼容接口可以用 Docker 一键起服务。搭配关系是Ollama 负责拉取和运行 GGUF 模型Open WebUI 负责展示和交互两者通过 Ollama 的 /api 接口通信。很多团队在正式生产之前用它做内部试用和验收完全够用。3.4 Kubernetes 下的推理平台从单 Pod 到弹性资源池如果你最终要走向真正的 LLM 推理平台Kubernetes 是绕不开的一环。推理服务天然适合 Kubernetes 的滚动更新和资源调度。核心工作流是每个模型服务做成一个 DeploymentPod 内跑 vLLM / Triton 容器Pod 外挂 PVC存放模型权重Service 做负载均衡Ingress 暴露到公司内网。另外GPU 级联调度和 GPU 显存 oversubscription 需要借助设备插件来实现。在 Kubernetes 里跑 LLM 要特别注意两个东西一个是亲和性调度不要让两个大模型 Pod 落在同一张卡上这会直接 OOM另一个是完整的探针vLLM 的 /health 可以作为 livenessProbe但要再写一个 readinessProbe 专门检查模型是否已经加载完成防止流量砸到一个还在加载的副本。我见过太多团队因为 readiness 没配好新服务一上线就把部分请求打到正在初始化实例上造成大量超时。apiVersion: apps/v1 kind: Deployment metadata: name: vllm-llama3-8b spec: replicas: 3 template: spec: containers: - name: vllm image: vllm/vllm-openai:v0.8.4 args: [--model, /model, --served-model-name, llama3-8b, --gpu-memory-utilization, 0.85] readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 30 periodSeconds: 104. LLM 推理平台的完整组件RAG、Agent 编排、网关与评测单模型服务 推理引擎只能解决“模型能跑”的问题。真正常见的 LLM 推理平台还包括 RAG 知识库、Agent 编排、网关鉴权、评测这套完整链路。4.1 LLM Wiki 知识库、GraphRAG 与本体让模型带上业务上下文知识库有三个关键词一起出现是近期的趋势Wiki、GraphRAG、本体Ontology。传统 RAG 的流程文档切片、向量化、检索、拼 Prompt。它确实能解决一部分事实问答问题但单纯靠向量相似度召回在复杂关系问答上经常翻车。GraphRAG 的思路是先用 LLM 抽取实体和关系建知识图谱再通过图结构检索来回答。这么做的好处是模型可以顺着关系链跳到下一跳回答“某业务线和某团队之间的合作流程”这类跨段落问题。代价是构建成本高需要跑大量 LLM 抽取任务。而“本体”概念更进一步它给知识图谱加了一层模式层定义了类型、属性、关系约束。相当于让模型知道“谁是客户、谁是供应商、它们的资质要求有哪些约束”。你去看 LLM Wiki 这类知识库系统底层往往就是“本体 图谱 向量”的混合检索。实操上我建议不要一上来就 GraphRAG先在传统 RAG 基础上把分块策略和 top-k 选好再逐步加入图谱。很常见的错误是切片定得太短把关键事实拆散了或者是检索 Top-k 设得太小相关段落被滤掉。你至少要让检索召回 5 段左右再交给 LLM让它自己选。4.2 Agent 框架与编排LangGraph、Dify、Eino 的取舍LLM 推理平台上另一块核心是 Agent 编排。单纯的问答模型只能回答问题Agent 框架让模型可以调用工具、读数据库、执行动作是业务真正切入生产系统的门。LangGraph 是目前我在生产环境用得比较顺手的框架。它的核心思维是“图状态机”——把每一步 Agent 执行步骤建模成图里的节点节点之间有条件和数据流转。相比 LangChain 的链式调用LangGraph 更适合做需要循环、条件分支、人工介入的流程。另一个方向是 Dify偏 Low-Code业务同学可以在界面上拖拽搭 RAG 应用和 Agent 工作流底层再对接 vLLM 或 OpenAI 兼容服务。Eino 是字节跳动开源的一个新框架如果你在 Go 技术栈里值得关注。它主打高性能和可调度性适合把 Agent 流程嵌入到微服务架构中。选型逻辑很简单如果要快速交付且团队里没有太多算法同学Dify 会省很多事如果要做复杂状态机、多 Agents 协作、深度定制LangGraph 更稳如果性能要求极高且技术栈非 Python再看 Eino。from langgraph.graph import StateGraph, END class AgentState(dict): messages: list def call_llm(state: AgentState): response client.chat.completions.create( messagesstate[messages], modelqwen7b ) return {messages: [response.choices[0].message]} graph StateGraph(AgentState) graph.add_node(llm, call_llm) graph.set_entry_point(llm) graph.add_edge(llm, END) app graph.compile()注意Agent 框架不是“让模型自由发挥”。正式环境必须给 Agent 加工具白名单、调用超时、失败重试上限以及最重要的 conversation 隔离。如果你一种业务一个 Agent后面维护成本会迅速膨胀。4.3 模型网关LLM 网关、语义路由与限流当平台里同时存在好几个模型服务、好几个业务线共用时就需要一个 LLM 网关。它的职责包括统一入口与鉴权、模型路由、限流、灰度、可观测性、协议转换不同模型可能不是同一个 API 风格。做网关时“语义路由”这个概念现在很流行不是手动指定模型而是根据请求内容动态路由到不同模型。比如简单问题走小模型、复杂推理走大模型这样可以显著降低成本。我们内部实践下来语义路由要基于 Embedding 和分类模型去判断纯靠提示词很难稳定。另外网关层必须做限流不然某个业务线的突发流量可能把整个推理集群打爆。令牌桶算法依然是最可靠的方案。4.4 评测与可观测性从 DeepEval 到 Open LLM Leaderboard模型部署上线前一定要过评测这一关。否则你很难回答“这个新模型和老模型比到底好不好”的问题。现在有不少评测工具其中 DeepEval 是一个比较轻量、可接入 CI 的开源框架可以在部署流水线里跑回归评估。它的思路是定义一组测试用例起一个评测模型作为裁判用类似“G-Eval”的方法来打分做成了 pytest 风格直接和 pytest 框架无缝衔接。评测指标要分开看传统指标准确率、F1适合分类任务开放生成任务要用语义相似度、答案相关性、忠实度、毒性去衡量。还有一个方向是参照公开榜单比如 Open LLM Leaderboard它给了你一个相对基线你的模型在工业界处于什么位置。但注意公开榜单和你的业务场景往往不一样所以一定要搭建自己的离线评测集。部署以后可观测性又是另一层每轮请求的延迟、Token 生成速率、显存水位、队列长度都要监控。对外只看到“生成很慢”实际上可能是并发过大导致请求排队或者显存碎片不断累积。# DeepEval 实测示例 from deepeval import evaluate from deepeval.metrics.answer_relevancy import AnswerRelevancyMetric from deepeval.test_case import LLMTestCase test_case LLMTestCase(input..., actual_output..., expected_output...) metric AnswerRelevancyMetric(modellocal-llm) result evaluate([test_case], [metric])5. 常见问题与排查技巧实录最后分享我在正式环境里踩过的一些坑。这些坑大多不算复杂但每次都会让人痛苦一阵建议直接收藏对照。5.1 显存不足、模型加载失败、服务无法启动显存问题是模型部署里出现频率最高的问题。新手最容易犯的错误是在模型加载阶段没有做内存预估。7B 模型 fp16 大约 14GB 权重加上 KV Cache 至少 8GB如果 GPU 只有 24GB能余下的也就 2GB。此时如果把 gpu_memory_utilization 设成 0.95服务启动没问题一旦请求进来 KV Cache 分配立刻失败。正确做法是先留足权重空间再分配 KV Cache。另一个经验是最好安排一块专用显存而不是把训练和推理混在一张卡上否则训练一抖动推理直接挂掉。5.2 QPS 低、并发上不去QPS 低通常有三个原因。第一没有开 Continuous Batching或 max-num-seqs 太小。第二动态批处理的等待时间设得太短攒不到一个有效 batch。第三Token 生成的最大长度设得太长导致单个请求占用的 KV Cache 时间过久整体吞吐被拖慢。压测的时候要结合业务平均输入输出长度来调参不能拿最大长度去算容量。5.3 量化后效果变差量化不是白嫖它用少量精度换显存和速度。Q4_K_M 通常损失不大但如果模型比较小比如 0.5B量化后很可能明显变傻。遇到这种情况先跑基准对比 fp16 与 Q8、Q4 的输出量化前后差的度量指标逐项分析。如果是任务型模型抽取、分类尽量回到 fp16 或 Q8 试试宁可多占用点显存也不想效果掉点。5.4 服务报 schema/tool payload rejected用 OpenAI 兼容接口时经常遇到llm request failed: provider rejected the request schema or tool payload。这类错误一般是对齐问题后端 vLLM 版本较老不支持某些工具调用 schema或者工具参数里带了不符合 JSON Schema 规范的内容。先打开服务端日志看 reject 的具体原因把 tools payload 简化到最小可复现样例再逐步加字段。版本升级也是常用手段我一般喜欢把 vLLM 锁在最新稳定版避免因为功能不兼容被反复折磨。5.5 推理延迟抖动延迟抖动往往不是模型变慢而是队列积压、GPU 频率降频、显存带宽争抢导致。排查思路先看 P99 和平均延迟如果 P99 明显高于均值大概率是排队再看 GPU 利用率曲线如果利用率经常 100%说明并发策略太激进如果频繁抖动且 GPU 频率降低可能是散热或者电源限制。下边给一张排查速查表作为我实际排障时第一步要查的内容现象可能原因大概率处理办法启动时 OOM 或加载失败显存预留不足调低 gpu_memory_utilization 至 0.8~0.9QPS 上不去Continuous Batching 没生效检查 max-num-seqs、批处理等待窗口延迟抖动明显请求队列积压观察 P99、减少入口并发或增加副本模型加载慢从磁盘/网络读权重权重放本地 NVMe预拉取镜像工具调用报错Schema 不兼容简化 tools payload、升级推理引擎量化效果变差精度损失过大换成 Q8 或 fp16重新跑评测偶发超时探针或优雅退出没配好增加 readiness 探针、延长 preStop6. 我最后想说的几件事踩过这些坑之后我最大的体会是正式环境里的模型部署永远不只是“把模型跑起来”。它的成败取决于你是否在一开始就把路径想清楚是先跑一个单模型服务验证效果还是直接上高性能推理引擎再或者一步到位搭 LLM 推理平台。这三个阶段的复杂度差异是数量级的但也不是越高级越好。如果业务量不大、模型数量少一个 vLLM 服务加一个网关就已经是很扎实的正式环境如果多个团队共用 GPU、模型经常迭代、还要接一堆 Agent 和知识库场景那才值得投入精力去搭全平台。还有一个小建议任何模型上线之前一定先把“退出路径”想好。所谓退出路径就是新模型效果不行你怎么快速回滚到旧模型。模型网关的作用在这一刻体现得最充分——只改一个路由配置就能切回去。没有网关的话你就只能重新发布服务那个过程在正式环境里会非常煎熬。这个领域迭代速度极快框架日新月异但只要把资源管理、推理引擎、模型格式、网关编排、评测监控这几条主线抓住后面不管框架怎么换你都能快速上车。希望这篇全景梳理能帮你在正式环境的模型落地多避开几个坑。