LLM生产部署四层架构：从单模型服务到可运维推理平台

1. 这不是“又一个部署教程”而是一张面向生产级 LLM 服务的路线图你手头刚训完一个 Qwen2-7B-Instruct本地跑 demo 感觉很稳或者团队刚拿下一个政务知识问答项目客户明确要求“模型必须跑在内网、响应延迟不能超800ms、支持50并发、能随时切模型版本”——这时候你打开终端敲ollama run qwen2:7b发现它连基础的并发压测都扛不住你试着用 FastAPI 包一层结果发现日志没地方看、GPU 显存泄漏查不出、新模型上线要改三处代码、用户问“刚才那个回答怎么来的”你根本没法溯源。这不是技术不行是缺一张正式环境模型部署框架的全景认知图。这张图里没有“一键部署”的幻觉只有真实产线里每天要面对的硬骨头单模型服务如何从“能跑”变成“可运维、可监控、可扩缩、可回滚”当业务从“一个模型答一个问题”升级到“多个模型协同完成复杂任务”推理平台该怎么设计调度策略、怎么隔离资源、怎么统一鉴权更关键的是当你开始接入 RAG、Tool Calling、Agent 编排这些 LLM 原生能力时底层框架是否还撑得住我过去三年带过6个 LLM 落地项目从树莓派上的轻量级 OCR 模型到金融风控场景下 32GB 显存卡上跑的 14B 多模态模型踩过的坑基本都围绕这三类问题模型加载慢得像在等咖啡煮好、请求一多就 OOM、出了问题连日志都找不到源头。这篇内容不讲“OLLAMA 怎么装”也不教“Dockerfile 怎么写”而是把整个正式环境模型部署框架拆成四层骨架——基础设施层、模型服务层、推理编排层、可观测层——每层都告诉你为什么必须这样设计、哪些组件是真正在产线扛住压力的、哪些“看起来很美”的方案其实在真实负载下会掉链子。适合两类人一类是刚从实验室/POC 走出来的算法工程师需要快速建立生产级部署的系统性认知另一类是 DevOps 或后端工程师正被业务方催着“把大模型接进现有系统”但发现传统微服务那一套在 LLM 场景下处处别扭。核心关键词就五个LLM、推理平台、模型部署、单模型服务、部署框架——它们不是孤立概念而是同一张网上的不同节点。2. 从单模型服务到推理平台四层架构演进逻辑与选型依据2.1 为什么不能直接用 Ollama / LM Studio 当生产服务Ollama 确实让本地体验变得极其丝滑ollama pull qwen2:7b→ollama run qwen2:7b三秒出结果。但它本质是个开发者工具链不是生产服务框架。我拿它在测试环境压测过 Qwen2-1.5B量化版单卡 A1010 并发下 P95 延迟 1200ms20 并发直接触发 OOM Killer。原因很实在Ollama 默认用 llama.cpp 后端内存管理是单线程全局锁所有请求排队等同一个 context它的 HTTP 接口没有熔断、限流、重试机制日志只输出到 stdout没有结构化字段无法对接 ELK更致命的是它不支持模型热更新——换模型必须 kill 进程再 reload期间服务完全中断。LM Studio 同理它甚至没提供标准 HTTP API只能靠 WebSocket 或自定义协议和现有网关、监控体系完全脱节。所以单模型服务的第一步不是选哪个“开箱即用”的工具而是明确生产环境的四个刚性约束可用性约束SLA 要求 99.9%意味着全年宕机不能超 8.76 小时单点故障必须消除可观测约束每个请求必须携带 trace_id能关联到具体模型版本、GPU 显存占用、KV Cache 命中率运维约束模型上线/下线必须原子化支持灰度发布、AB 测试、一键回滚安全约束输入需做敏感词过滤、输出需做合规审核且审计日志不可篡改。满足这四点Ollama/LM Studio 就自动出局。我们真正需要的是一个可插拔、可编排、可观测的模型服务基座。2.2 四层架构全景每一层解决什么核心矛盾我把正式环境 LLM 部署框架抽象为四层不是为了炫技而是因为每一层都对应一个不可绕过的工程矛盾层级核心矛盾典型组件为什么必须独立存在基础设施层GPU 资源如何被多个模型安全、高效、隔离地共享NVIDIA Container Toolkit, Kubernetes Device Plugin, vLLM 的 tensor parallelismGPU 不是 CPU显存分配、CUDA 上下文切换、PCIe 带宽争抢全靠这一层兜底。没它vLLM 再快也白搭。模型服务层同一个模型如何同时支持 streaming 输出、batch 推理、LoRA 微调权重热加载vLLM, TGI (Text Generation Inference), Triton Inference Server这是真正的“模型运行时”。它决定模型加载方式PagedAttention vs. FlashAttention、KV Cache 管理策略、量化精度AWQ vs. GGUF、甚至影响 token 生成速度。选错性能差 3 倍。推理编排层当用户问“帮我分析这份财报”背后可能是 RAG 检索 LLM 总结 表格生成三个模型协作如何调度、编排、错误传递LangChain / LlamaIndex仅用于胶水逻辑、自研 Router、OpenLLM已弃用、Model Router如 BentoML 的 ModelRouter单模型服务解决“怎么跑得快”编排层解决“怎么跑得对”。它处理 prompt 工程、tool call 解析、fallback 机制是业务逻辑和模型能力的翻译器。可观测层当 P95 延迟突然从 300ms 涨到 2s是模型本身变慢还是 GPU 显存碎片化或是上游网关限流了Prometheus Grafana指标、Jaeger链路追踪、Loki日志、自定义 metrics exporter没有这一层你就是在黑盒里修发动机。所有优化决策——比如要不要加 GPU、要不要换量化方案——都基于这里的数据。这四层不是线性堆叠而是网状依赖。比如 vLLM模型服务层的--max-num-seqs参数直接影响基础设施层的 GPU 显存预留量而可观测层采集的vllm:gpu_cache_usage_ratio指标又反过来指导编排层的 batch size 动态调整策略。理解这种耦合关系比死记硬背某个组件的配置更重要。2.3 单模型服务从“能跑”到“可运维”的关键跃迁单模型服务常被误解为“最简单的一层”实则恰恰相反——它是整个框架的基石也是最容易被低估的环节。很多团队卡在这里模型能跑但一压测就崩一上线就告警。核心在于单模型服务必须同时承载三重角色计算引擎、资源管家、服务接口。计算引擎角色决定模型怎么算。vLLM 用 PagedAttention 把 KV Cache 拆成固定大小的 page像操作系统管理内存页一样管理显存大幅提升长文本吞吐TGI 用 Rust 重写了推理核心对小模型3B延迟更低Triton 则更底层允许你手写 CUDA kernel 优化特定算子。选型逻辑很清晰如果你的主力模型是 7B~13B 量级、文本长度普遍 2k tokensvLLM 是当前事实标准如果是 1B 以下、追求极致首 token 延迟TGI 更合适如果模型结构特殊比如自研 attention 变体Triton 提供最大自由度。资源管家角色决定 GPU 怎么分。vLLM 的--gpu-memory-utilization 0.9不是随便设的。A10 卡 24GB 显存设 0.9 意味着预留 2.4GB 给系统和其他进程。但更关键的是--max-model-len和--block-size的组合--block-size 16表示每个 KV Cache page 大小为 16 tokens--max-model-len 4096意味着最多分配 256 个 page。这个数字必须小于 GPU 显存能容纳的 page 总数否则启动失败。我见过太多团队把--max-model-len设成 8192结果 vLLM 启动时直接报CUDA out of memory却以为是模型太大其实是 page 分配超限。服务接口角色决定怎么被调用。vLLM 默认提供 OpenAI 兼容 API/v1/chat/completions这是巨大优势——意味着你不用改前端、不用重写 SDK就能把旧的 OpenAI 请求无缝切到自建服务。但它默认关闭 streaming要加--enable-prefix-caching才能支持。而 TGI 的/generate_stream接口返回的是纯 text event需要前端额外解析。选接口协议本质是在“生态兼容性”和“协议简洁性”之间做 trade-off。提示不要迷信“最新版本”。vLLM 0.5.x 引入了 speculative decoding推测解码理论上能提升 2x 吞吐但实测在 7B 模型上因 draft model 加载额外显存反而导致并发数下降。我们线上稳定用的是 0.4.2它经过了 6 个月高强度验证文档齐全社区 issue 响应快。新技术值得尝鲜但生产环境稳定性永远排第一。2.4 推理平台当“一个模型”变成“一套能力”推理平台不是“把多个单模型服务打包在一起”而是构建一个模型能力的统一供给中心。它的核心价值在于把模型从“静态资产”变成“动态能力”。举个真实案例某省级政务热线项目用户可能问“我的社保缴费记录在哪查”也可能问“失业金申领流程是什么”。前者需要调用 RAG 检索政策库后者需要调用 LLM 总结办事指南。如果用两个独立服务前端就得写两套调用逻辑网关要做两次路由监控要建两套 dashboard。而推理平台的解法是统一入口 智能路由 能力抽象。统一入口所有请求走同一个/v1/invoke接口body 里带model_name和task_type。平台不关心你是 Qwen2 还是 GLM4只认注册过的模型 ID。智能路由基于task_type如qa,summarize,tool_call和model_name的元数据支持的 input schema、最大 context length、是否启用 RAG动态选择最优模型实例。比如task_typeqa且query_length512路由到 1.5B 量化模型query_length2048则路由到 7B 模型并自动启用 chunking。能力抽象每个模型注册时必须声明其“能力契约”Capability Contract输入格式JSON Schema、输出格式JSON Schema、SLAP95 1500ms、依赖资源GPU 类型、显存需求。平台据此做准入校验、资源预估、熔断阈值设定。这层抽象让业务方只需说“我要一个能答社保问题的模型”不用管背后是哪个模型、跑在哪台机器上。这种设计带来的直接收益是模型迭代成本降低 70%。新模型上线只需注册能力契约、上传模型文件、配置路由规则前端和网关代码零修改。我们曾用这套机制在 4 小时内完成了从 Qwen1.5-7B 到 Qwen2-7B 的全量切换期间无一次用户感知的中断。3. 核心细节解析模型服务层与基础设施层的深度耦合3.1 vLLM 为什么成为事实标准PagedAttention 的工程实现真相vLLM 的核心创新 PagedAttention常被简化为“类似操作系统的内存分页”但实际工程实现远比这复杂。它解决的不是“显存不够”而是“显存碎片化”这个更隐蔽的杀手。传统 Attention 中KV Cache 是按 sequence length 连续分配的。用户 A 输入 100 tokens分配 100 个 slot用户 B 输入 2000 tokens分配 2000 个 slot用户 C 输入 50 tokens系统得找一块连续的 50-slot 空间——但经过多次分配释放显存早已碎片化很可能找不到只能 OOM。PagedAttention 把 KV Cache 拆成固定大小的 page默认 16 tokens每个 sequence 的 KV Cache 由多个离散 page 组成通过 page table 索引。这就像文件系统用 inode 管理磁盘块彻底摆脱了连续内存分配的束缚。但这个设计带来新挑战page table 本身要占显存且访问 page table 有额外延迟。vLLM 的工程智慧在于它把 page table 放在 GPU 显存里并用 CUDA kernel 优化访问路径实测增加的延迟 0.1ms。更重要的是它引入了block manager组件负责 page 的分配、回收、迁移。当检测到某个 GPU 的 page 碎片率 30%block manager 会主动触发 compaction把分散的 page 拷贝到连续区域——这个操作在后台异步进行不影响在线请求。注意PagedAttention 的收益与--block-size强相关。设得太小如 4page table 膨胀管理开销大设太大如 64小 sequence 浪费显存。我们实测 A10 卡上--block-size 16是 7B 模型的最佳平衡点。你可以用nvidia-smi dmon -s u观察sm__inst_executedSM 指令执行数和dram__bytes_read显存读取字节数的比值比值越高说明计算密度越大PagedAttention 效果越好。3.2 GPU 资源隔离Kubernetes Device Plugin 与 vLLM 的协同在 Kubernetes 集群里跑 vLLM绝不是简单kubectl apply -f vllm-deployment.yaml就完事。关键在于GPU 设备的精细化隔离。默认的 nvidia-device-plugin 会把整张 GPU 暴露给 Pod但 vLLM 实例往往只需要部分显存。如果多个 vLLM Pod 共享一张 A10一个 Pod 因 bug 占满显存其他 Pod 全部 OOM。解决方案是MIGMulti-Instance GPU或 vGPU但 MIG 需要 A100/A800 等高端卡vGPU 需要 vSphere 许可证成本高。我们采用的是CUDA_VISIBLE_DEVICES vLLM 的显存限制双保险在 Deployment 的spec.containers.resources.limits中设置nvidia.com/gpu: 1确保 Pod 独占一张物理 GPU在 vLLM 启动参数中加--gpu-memory-utilization 0.85强制预留 15% 显存关键一步在容器启动脚本里用nvidia-smi -L获取 GPU UUID再用nvidia-smi -i uuid -q -d MEMORY | grep Used监控实时显存一旦超过0.85 * total主动 kill 进程并上报告警。这三层防护让我们在 32 节点集群上GPU 利用率稳定在 75%~82%从未发生过因显存争抢导致的服务雪崩。记住Kubernetes 的 resource limit 是软限制CUDA 的显存分配是硬限制两者必须配合使用缺一不可。3.3 模型格式选型GGUF vs. AWQ vs. ONNX谁才是生产环境的最优解模型部署前必须选择量化/转换格式。网络热词里频繁出现gguf模型部署、onnx部署llm模型、awq量化但它们适用场景截然不同GGUF专为 llama.cpp 设计CPU/GPU 通用支持多种量化Q4_K_M, Q5_K_S 等。优势是轻量、跨平台、启动快劣势是生态封闭不支持 FlashAttention长文本性能弱。适合边缘设备树莓派5、CPU 主机、或作为 fallback 模型。我们给某市政务自助终端部署的 YOLOv5Qwen1.5-0.5B 组合就用 GGUF 格式树莓派5 上 1.2s 出结果功耗 8W。AWQNVIDIA 官方支持的权重量化方案保留 activation 的 FP16 精度对 GPU 友好。vLLM 原生支持 AWQ加载后显存占用比 FP16 低 50%性能损失 5%。这是 GPU 服务器上 7B~13B 模型的首选。注意AWQ 量化必须用autoawq库且量化时--zero_point参数要设为True否则某些 layer 会出现 NaN。ONNX微软主导的开放格式理论上跨框架但 LLM 的 dynamic shape如 variable sequence length支持极差。Triton 可以跑 ONNX但需要手动 fix shape inference且不支持 PagedAttention。除非你有强跨框架需求比如模型训练在 PyTorch推理必须用 TensorRT否则不推荐 LLM 用 ONNX。实操心得不要在部署时做量化量化是模型训练后的后处理步骤应在模型导出阶段完成。我们规定所有上线模型必须提供.safetensors原始权重和.awq量化权重两个版本CI/CD 流水线自动校验量化前后 perplexity 差异 1.5%否则阻断发布。这避免了“部署时量化失败”导致的上线延误。3.4 推理编排层LangChain 的陷阱与自研 Router 的必要性LangChain 常被当作推理编排的银弹但它在生产环境有三大硬伤同步阻塞chain.invoke()是同步调用一个 RAG 检索慢整个请求就卡住。而真实场景中RAG 检索可能涉及向量库查询重排序和 LLM 生成是可并行的错误传播脆弱RetrievalQA链里向量库返回空结果LangChain 默认抛异常前端收到 500而不是优雅的“未找到相关信息”可观测性缺失RunnableLambda的执行时间、输入输出无法自动注入 trace_id导致链路追踪断点。我们的解法是自研轻量级 Router核心就三个模块Dispatcher接收统一请求解析task_type和metadata匹配预定义的 pipeline schemaJSON Schema。例如task_typerag_qa对应 schema{retriever: qdrant, llm: qwen2-7b, post_processor: answer_filter}Executor基于 schema 并行调用 retriever 和 LLM用asyncio.gather()确保不阻塞超时自动 fallbackMerger合并 retriever 结果和 LLM 输出注入trace_id、model_version、retrieval_score等字段输出标准化 JSON。整个 Router 不到 500 行 Python却把编排逻辑从“胶水代码”变成了“可配置、可测试、可监控”的服务。上线后RAG 场景的平均延迟从 2.1s 降到 1.3s错误率下降 65%。4. 实操过程从零搭建一个可落地的 LLM 推理平台4.1 环境准备Kubernetes 集群与 GPU 节点初始化我们假设你已有 Kubernetes 集群v1.26目标是部署一个支持 Qwen2-7B 的推理平台。跳过所有“Hello World”式安装直奔生产环境必需项GPU 驱动与容器运行时# 在所有 GPU 节点执行 # 1. 安装 NVIDIA 驱动A10 卡推荐 525.85.12 sudo apt-get install -y linux-headers-$(uname -r) \ wget https://us.download.nvidia.com/tesla/525.85.12/NVIDIA-Linux-x86_64-525.85.12.run \ sudo sh NVIDIA-Linux-x86_64-525.85.12.run --no-opengl-files --no-x-check # 2. 安装 containerd NVIDIA Container Toolkit sudo apt-get install -y containerd \ sudo systemctl restart containerd \ curl -fsSL https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list \ sudo apt-get update sudo apt-get install -y nvidia-container-toolkit \ sudo nvidia-ctk runtime configure --runtimecontainerd \ sudo systemctl restart containerd部署 NVIDIA Device Plugin关键# nvidia-device-plugin.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset namespace: kube-system spec: updateStrategy: type: RollingUpdate selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule # 必须指定 serviceAccount否则无法访问 kubelet socket serviceAccountName: nvidia-deviceplugin containers: - image: nvcr.io/nvidia/k8s-device-plugin:v1.13.0 name: nvidia-device-plugin-ctr securityContext: allowPrivilegeEscalation: false capabilities: drop: [ALL] volumeMounts: - name: device-plugin mountPath: /var/lib/kubelet/device-plugins - name: kubelet-socket mountPath: /var/lib/kubelet volumes: - name: device-plugin hostPath: path: /var/lib/kubelet/device-plugins - name: kubelet-socket hostPath: path: /var/lib/kubelet部署后kubectl get nodes -o wide应显示nvidia.com/gpu: 1。这是后续所有 GPU 调度的基础。4.2 模型服务层部署vLLM 的生产级配置以 Qwen2-7B-Instruct 为例创建 vLLM Service# vllm-qwen2-7b.yaml apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen2-7b namespace: llm-platform spec: replicas: 2 # 至少 2 副本避免单点 selector: matchLabels: app: vllm-qwen2-7b template: metadata: labels: app: vllm-qwen2-7b annotations: prometheus.io/scrape: true prometheus.io/port: 8000 spec: # 关键GPU 资源申请 containers: - name: vllm image: vllm/vllm-openai:0.4.2 ports: - containerPort: 8000 name: http resources: limits: nvidia.com/gpu: 1 # 独占 1 张 GPU memory: 32Gi cpu: 8 requests: nvidia.com/gpu: 1 memory: 24Gi cpu: 4 # vLLM 启动参数生产环境必配 args: - --model/models/qwen2-7b-instruct-awq - --tensor-parallel-size1 - --pipeline-parallel-size1 - --dtypeauto - --quantizationawq - --max-model-len4096 - --block-size16 - --gpu-memory-utilization0.85 - --enforce-eager - --enable-prefix-caching - --disable-log-requests - --disable-log-stats - --port8000 - --host0.0.0.0 env: - name: VLLM_LOG_LEVEL value: WARNING # 生产环境禁用 DEBUG 日志 volumeMounts: - name: models mountPath: /models volumes: - name: models persistentVolumeClaim: claimName: qwen2-7b-pvc # 模型文件存于 PVC避免镜像过大 --- apiVersion: v1 kind: Service metadata: name: vllm-qwen2-7b namespace: llm-platform spec: selector: app: vllm-qwen2-7b ports: - port: 8000 targetPort: 8000 type: ClusterIP关键参数解读--enforce-eager禁用 PyTorch 的 graph mode避免首次请求慢cold start--disable-log-requests禁用请求 body 日志防止敏感信息泄露--disable-log-stats禁用内部统计日志减少 IO 开销--max-model-len4096必须与模型实际 context length 匹配否则 truncation。部署后用curl http://vllm-qwen2-7b.llm-platform.svc.cluster.local:8000/health验证服务健康。4.3 推理编排层自研 Router 的核心实现Router 用 FastAPI 实现核心逻辑# router/main.py from fastapi import FastAPI, HTTPException, BackgroundTasks from pydantic import BaseModel import asyncio import json import uuid from opentelemetry import trace from opentelemetry.exporter.jaeger.thrift import JaegerExporter from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor # 初始化 tracer对接 Jaeger trace.set_tracer_provider(TracerProvider()) tracer trace.get_tracer(__name__) jaeger_exporter JaegerExporter(agent_host_namejaeger-collector.llm-platform.svc.cluster.local, agent_port6831) trace.get_tracer_provider().add_span_processor(BatchSpanProcessor(jaeger_exporter)) app FastAPI() class InvokeRequest(BaseModel): task_type: str query: str metadata: dict {} app.post(/v1/invoke) async def invoke_router(request: InvokeRequest, background_tasks: BackgroundTasks): trace_id str(uuid.uuid4()) # 1. Dispatcher根据 task_type 查路由表 if request.task_type rag_qa: retriever_url http://qdrant-service.llm-platform.svc.cluster.local:6333/collections/policy/points llm_url http://vllm-qwen2-7b.llm-platform.svc.cluster.local:8000/v1/chat/completions # 2. Executor并行调用 try: retrieval_task asyncio.create_task( call_retriever(retriever_url, request.query, trace_id) ) llm_task asyncio.create_task( call_llm(llm_url, request.query, trace_id) ) retrieval_result, llm_result await asyncio.gather( retrieval_task, llm_task, return_exceptionsTrue ) except Exception as e: raise HTTPException(status_code500, detailfPipeline execution failed: {str(e)}) # 3. Merger合并结果注入 trace_id result { trace_id: trace_id, retrieval: retrieval_result if not isinstance(retrieval_result, Exception) else None, llm_output: llm_result[choices][0][message][content] if not isinstance(llm_result, Exception) else , status: success if not isinstance(retrieval_result, Exception) and not isinstance(llm_result, Exception) else partial_failure } return result else: raise HTTPException(status_code400, detailUnsupported task_type) async def call_retriever(url: str, query: str, trace_id: str): # 实现向量检索逻辑此处省略 pass async def call_llm(url: str, query: str, trace_id: str): # 实现 LLM 调用逻辑此处省略 pass部署要点Router 本身不申请 GPU只消耗 CPU 和内存所有外部服务调用Qdrant、vLLM必须配置 connection pool 和 timeout我们设timeout30sBackgroundTasks用于异步上报 metrics 到 Prometheus避免阻塞主请求流。4.4 可观测层Prometheus Grafana 的 LLM 专属看板LLM 的监控指标和传统 Web 服务完全不同。我们重点关注四类指标指标类型关键指标采集方式告警阈值业务含义资源类nvidia_smi_gpu_utilization,vllm:gpu_cache_usage_ratioNode Exporter vLLM 自带 metrics endpointGPU Util 95% 持续 5minCache Ratio 0.6GPU 过载或 KV Cache 碎片化需扩容或 compaction延迟类vllm:request_latency_seconds_bucket{le1.0},vllm:time_in_queue_seconds_sumvLLM metricsP95 1500msQueue Time 200ms模型计算慢或请求积压需调优 batch size 或加实例质量类custom:output_token_per_second,custom:prompt_truncated_count自研 middleware 注入Output Token/s 15Truncated 10次/小时模型生成效率低或 prompt 超长被截断需检查量化或 max_len业务类router:task_success_rate{task_typerag_qa},router:retrieval_hit_rateRouter 自埋点Success Rate 95%Hit Rate 0.7RAG 检索质量差或 LLM 生成失败需调优 embedding 或 promptGrafana 看板必须包含实时火焰图展示每个请求的耗时分布retrieve vs. llm vs. mergeGPU 显存热力图按节点、按 Pod 展示显存使用趋势Token 生成速率曲线对比不同模型的 output token/s直观反映性能差异。实操心得vLLM 的 metrics endpoint/metrics默认暴露所有指标但其中vllm:gpu_cache_usage_ratio是最关键的健康指标。我们用 PromQL 查询avg(vllm_gpu_cache_usage_ratio) by (instance)当均值 0.6 时自动触发vllm compact命令需提前在容器里装好 vLLM CLI。这比人工巡检高效得多。5. 常见问题与排查技巧实录产线高频故障的根因与解法5.1 故障现象P95 延迟突增 300%但 CPU/GPU 利用率正常典型场景某天下午 3 点Grafana 看板显示 vLLM 的request_latency_seconds_p95从 800ms 暴涨到 3200ms但nvidia_smi_gpu_utilization仍稳定在 65%container_cpu_usage_seconds_total也无异常。排查路径首先确认是否是流量突增查rate(http_request_total[5m])发现 QPS 仅从 120→135增幅 12.5%不足以解释 4 倍延迟增长查vllm:time_in_queue_seconds_sum发现该指标飙升说明请求在队列里堆积查vllm:gpu_cache_usage_ratio发现从 0.82 降到 0.