1. 从单模型服务到 LLM 推理平台思路得先转过来这两年只要往模型部署方向走几步就会发现市面上能选的方案已经从单模型 API 服务一路铺到了LLM 推理平台。很多人一开始都觉得奇怪我不就是把模型 load 起来写个接口让业务方来调吗有必要上一套平台吗真正被生产环境教育过几次之后你会明白这个问题的答案比你想象的要复杂。我自己的经历是这样的最早做一个推荐场景的 CTR 模型只需要把训练好的模型序列化出来包一个 Flask 接口加个 Docker 容器就能上线。后来开始做文本分类、实体抽取模型从一个变成两三个再后来要接 LLM 的生成式接口、多路 RAG 检索、模型版本灰度、A/B 测试、按调用方限流计费……这时候你就发现原来那套起了个服务就跑的打法根本扛不住。问题不在于单个模型的推理延迟而在于整个系统的可观测性、资源调度、多模型共存、流量治理这些事完全没有抓手。这篇文章想聊的就是从单模型服务走到LLM 推理平台这条路上你需要想清楚的框架选型逻辑、实操细节和坑。内容不会只停留在哪个框架好这种口水层面而是尽量把每一步选择背后的原因讲透。适合正在从传统模型部署往大模型推理方向转型的工程师也适合那些已经在用 vLLM、Ollama 或者自研推理网关但还想把体系补完整的人。2. 整体设计与选型先搞清楚你要解决的问题是什么2.1 单模型服务时代真正的痛点在哪很多人把单模型服务理解成写个 FastAPI 接口把模型跑起来其实这一步只解决了能用的问题离好用还差很远。单模型部署最常见的坑是先确定推理后端再确定框架结果框架和模型格式、硬件的搭配出了问题整个链路推倒重来。先说结论单模型服务的核心不是 API 框架本身而是模型格式、推理运行时、硬件调度这三者的匹配。比如你用 PyTorch 训练出一个模型如果直接拿 torchserve 部署那你的 GPU 显存占用通常会有大量冗余因为默认会把 CUDA context 整个占满如果你换成 ONNX Runtime 或者 TensorRT虽然要折腾一次格式转换但推理吞吐可能提升 30% 以上。选择什么样的推理运行时直接决定了你的机器成本。其次单模型服务面向的是单租户、单模型的场景它的价值边界很清楚模型只有一个版本调用方只有一两个接口 QPS 在几十到几百的量级。这时候框架的选型其实不复杂FastAPI 加 Gunicorn/Uvicorn worker外面套个 Docker再加上一个 Nginx 做负载均衡基本就是标配了。但这里有个容易被忽略的细节你的模型加载时间和内存占用决定了服务启动方式和 worker 数量。如果模型要加载 30 秒你就不能搞那种请求来了才加载的动态策略最好在进程启动时预加载否则第一个请求会直接超时。再往前一步生产级别的单模型服务还需要考虑灰度发布和回滚。那你的模型文件就不能直接塞进 Docker 镜像里而要放到一个外部存储上S3、MinIO、或者简单的 NAS镜像里只保留代码和依赖。启动时从存储拉模型文件到本地缓存目录这样可以做到代码不变模型版本可切换。这块我见过太多团队偷懒直接把模型打进了镜像结果每次更新模型都要重新构建镜像、重新滚动发布Pipeline 跑一次十几分钟完全是自我折磨。2.2 LLM 推理平台要解决的其实是四个核心问题当你开始接触 LLM 推理平台你会发现它不是一个新框架而是一组能力的集合。不管你是选 vLLM、Triton、Ray Serve还是自研本质上都是在解决下面四个核心问题。第一个是动态批处理。LLM 推理和传统模型最大的不同是单个请求的生成过程是逐步解码的token 一个个吐出来。如果你每个请求独占一个 batch 槽位GPU 利用率极低。连续批处理continuous batching的思路是批里某个请求已经生成完了就把它移出去让一个新请求插进来。vLLM 的核心优势就在这它能在请求级别做调度而不是等整个 batch 全部完成才换下一批。这就好比收银台传统批处理是一拨顾客全部结完账才放下一拨进来连续批处理是有人走了马上补位柜台利用率自然高。第二个问题是KV Cache 管理。LLM 推理的过程里每生成一个 token 都要重新计算整个序列的注意力权重而之前的 Key 和 Value 是可以缓存的。问题在于这个缓存非常吃显存而且它的大小跟并发请求数和序列长度直接相关。静态分配会导致显存浪费动态分配又涉及碎片整理。vLLM 用 PagedAttention 来解决思路类似于操作系统里的分页内存管理把 KV Cache 切成小块按需分配并且在物理块不连续的情况下依然能通过页表访问。这也是我建议你不要轻易自研推理引擎的原因之一KV Cache 的管理难度比你想象中大得多。第三个问题是前缀缓存Prefix Caching。如果你做的是 RAG 类的应用每个请求都会携带一大段系统提示词和检索出来的上下文这些内容往往在多个请求之间是重复的。如果每次请求都从头计算这些 prefix 的 KV Cache那就是纯粹的浪费。vLLM 有 automatic prefix caching对相同的 prefix 直接复用缓存实测在某些知识库问答场景下TTFT首 token 延迟能降低一半以上。这也是LLM 的 token 三个点——key、query、value——在实际工程里的体现缓存的是 value命中的是 key你要找的答案就是那个 query 对应的输出。第四个问题是多模型与多副本的流量调度。到了平台阶段你不是只跑一个模型可能同时跑着一个 7B 的对话模型、一个 embedding 模型、一个 reranker。每个模型的副本数、显存需求、负载特征都不一样。你需要一个控制面来管理哪些请求路由到哪个模型、每个模型下面有几个副本、副本的扩缩容策略是什么。Ray Serve 在在这方面做得比较成熟它有 per-model 的 deployment 配置原生支持 autoscaling。但这套体系是有学习成本的不是装完就能跑。2.3 框架选型别先用框架先算一笔资源账我见过不少团队第一步就先选框架然后被框架绑死。正确的做法是先算三笔账模型显存账、并发吞吐账、可用性账。显存账很容易算。以 7B 模型为例FP16 权重大约是 14GB如果要做 KV Cache还得根据你的最大序列长度和 batch 大小估算额外显存。经验公式大概是总显存 模型权重 KV Cache 推理引擎自身开销CUDA context 等。一张 24GB 的 4090跑 7B 模型做 2K 上下文批大小为 8是勉强的跑 32K 上下文基本就爆显存了。所以你别一上来就追求大 batch先把单条请求的显存占用测出来再反推并发上限。吞吐账要看你的场景。如果是内部工具、Copilot 类应用QPS 可能只有个位数这时候 Ollama 或者一个简单的 FastAPI vLLM 都够用。如果你要做面向 C 端的 AI 应用峰值 QPS 可能上千那就必须考虑分布式部署、多卡张量并行、GPU 池化。平台的意义在这里才体现出来。可用性账通常是被低估的。模型服务挂了业务方能不能接受 5 分钟的恢复时间如果不行你就得做多副本 健康检查 自动拉起的机制。Kubernetes 在这个环节是逃不掉的不管你的推理框架是 vLLM 还是 Triton最终都要跑在 K8s 上才有正经的故障恢复能力。所以框架选型不是谁火选谁而是你的负载特征决定了你至少需要哪一层。单模型和低并发FastAPI vLLM 就够多模型 动态扩缩容加 Ray Serve多租户 精细化的 GPU 隔离和配额再上 K8s GPU 池化调度比如 gpustack 这类工具在 Windows 上做本地实验还是很顺手的生产环境还是 K8s 为主。3. 单模型服务的实操细节从 FastAPI 到 GPU 容器化3.1 一个能上生产的 FastAPI 推理服务至少要写好这几块很多人写模型接口喜欢把逻辑全堆在main.py里这在小 demo 阶段没问题但一个能上生产的服务至少要拆成这几个模块模型加载与生命周期管理、推理封装、请求参数校验、监控指标暴露。模型加载这块关键是用 lru_cache 或者模块级单例来保证模型只加载一次。我曾经见过一个服务每次请求都重新执行torch.load()直接把显存撑爆了。这个问题的根源是很多人把模型加载写在了请求处理函数里面第一次调用能跑并发一上来就 OOM 或者延迟飙升。推理封装要多做一层协议转换外部传入的 JSON 不一定直接对应模型的输入 schema你要在接口层做清洗、截断、padding、转 tensor 这些操作。这里有一个容易被忽略的点输入文本长度必须做限制否则恶意或者意外的超长输入会把显存打满。BERT 类模型我一般限制 512 tokenLLM 接口限制 context window 之内的长度同时返回 400 让调用方知道是输入超限。监控指标暴露也很关键。用prometheus_client暴露/metrics端点至少要记录延迟直方图、请求计数、模型推理 batch 大小、当前并发数。没有这些数据后面做容量评估就是瞎猜。我在实际项目里见过太多服务看起来正常一到大促就崩的情况根本原因就是大家只看 CPU 和内存没人看模型推理延迟的 P99 趋势。3.2 Docker 打包与 GPU 透传别在最后一步翻车写好了服务打包成 Docker 镜像是常规操作。但 GPU 环境的容器化有几个细节值得单独说一下。首先基础镜像别乱选。NVIDIA 官方提供的nvidia/cuda:12.1-runtime-ubuntu22.04足够跑大部分推理场景如果你用 PyTorch就基于pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime。不要用-devel版本那是给编译用的体积大好几倍生产环境没必要。其次运行时怎么把 GPU 传给容器有两种方案。老牌的方式是nvidia-docker启动参数--gpus all新一点的是通过 NVIDIA Container Toolkit 配置 default runtime。这里有个常见的坑如果在 Docker 里跑 CUDA 程序报could not select device driver with capabilities: gpu几乎可以肯定是 Container Toolkit 没装好或者 daemon 没重启。在 Linux 上排查的顺序是宿主机nvidia-smi正常 →docker run --gpus all nvidia/cuda:12.1-runtime-ubuntu22.04 nvidia-smi测试 → 看/etc/docker/daemon.json里的 default-runtime 配置是否正确。再一个细节是内存和 shared memory。LLM 推理服务在容器里经常用到多进程如果/dev/shm太小会直接报无法分配内存的错误。在docker run里加--shm-size8g是比较稳妥的做法。我有一阵子在容器里跑 vLLM 频繁崩溃最后发现就是默认 shm 只有 64MB 导致的。这类问题不踩一次坑很难想到。3.3 模型热更新与版本管理生产服务的基本尊严如果你的模型每个月都要重新训练那你要处理好新旧模型切换这件事。我的做法是引入一层软链接机制容器内固定路径/models/current指向具体的模型目录模型文件放在外部卷挂载的/models/versions/model-20250101下面。要切换版本时先把新模型目录同步到服务器再通过脚本切换软链接指向最后重启核心 worker 进程。这样旧模型文件先不删做失败回滚的时候直接把软链接指回去重启一次就能恢复。对于多副本的集群部署这个方案要配合滚动发布先切一台验证指标正常再切剩下的。简单粗暴的全量同步切换很容易出现切完发现新模型效果有问题想回滚却发现旧版本被覆盖的窘境。所以模型目录的版本目录一旦发布我强烈建议设为只读。如果你跑的是 Ollama 这类工具它自带了模型管理能力ollama pull和ollama rm可以管理本地模型版本但没有显式的多个版本并行能力更适合做开发验证而不是生产多版本灰度。这块要心里有数。4. 模型格式与运行时GGUF、ONNX 与推理后端的匹配逻辑4.1 GGUF 是怎么火起来的它适合放在哪一层GGUF 是 llama.cpp 项目推出的模型格式它最大的价值是把模型权重、tokenizer、以及一些推理所需的元信息打包在了一个文件里。相比原本散落的pytorch_model.bin加config.json一个 GGUF 文件在分发和加载上简直太方便了。你下载一个 7B 模型的 GGUF 文件放到 Ollama 的模型目录下一个命令就能跑起来这对本地开发和私有化部署非常有吸引力。但 GGUF 的定位是面向 CPU 推理和消费级 GPU 的轻量化场景。它用的是量化后的权重比如 Q4_K_M、Q8_0 这些方案能把 7B 模型的体积从 14GB 压到 4GB 左右当然精度会有一点损失。如果你要追求极致性能、用 A100/H100 跑高并发生产推理GGUF 就不是首选了直接上 FP16 或 BF16 的权重格式配 vLLM 更合理。实操上Ollama 对 GGUF 的支持是最丝滑的ollama run qwen2.5:7b会把模型自动拉下来并转换好。判断 GGUF 文件的好坏一是看它的 quantization 类型二是看它的 metadata 信息是否完整。同一个模型不同量化等级的 GGUF 文件内存占用和推理质量差异很明显需要根据自己的显存和精度要求做权衡没有绝对最优解。4.2 ONNX 在 LLM 部署里的真实地位ONNX 本质是一个中间表示层它不负责具体的计算加速而是定义了一套计算图的标准格式。你的模型转成 ONNX 之后可以对接 ONNX Runtime、TensorRT、OpenVINO 等多个后端。对传统模型比如图像分类、目标检测、结构化数据模型ONNX 依然是跨平台部署的主流选择模型训练完之后转成 ONNX可以直接跑在 CPU 上也可以走 CUDA EP。在 LLM 这个方向上ONNX 也有它的位置。比如你用optimum的onnxruntime导出一些生成式小模型或者把 embedding 模型转成 ONNX 用于 CPU 场景性能比直接跑 PyTorch 更快。我自己在树莓派 5 上部署过一个自己训练的 YOLOv5 检测模型就是用 ONNX Runtime 跑的推理速度比纯 PyTorch 快不少。对于想要跑 LLM 来说ONNX Runtime 的generateAPI 支持已经慢慢在补齐但生态成熟度跟 vLLM 相比还有差距。我的建议是传统模型优先考虑 ONNXLLM 生产场景还是看 vLLM 或者 TensorRT-LLM。4.3 运行时选型以 LLM 生产推理为例的合适配置把推理运行时选型这件事具体化可以拉一张对照表。很多新手在这里最容易犯错看到 Ollama 觉得太简单看到 vLLM 又觉得复杂最后在自研和半成品之间反复横跳。我的建议是先对照你自己的负载特征再选。运行后端适合场景量化支持吞吐优化上手成本Ollama本地开发、小规模内网服务、离线演示GGUF 量化CPU/GPU 通吃较弱单请求为主极低一条命令启动vLLM生产 LLM 高并发推理支持 AWQ/GPTQ 等连续批处理 PagedAttention中等Python API 为主TensorRT-LLM极致性能、高吞吐在线服务FP8/INT4 等多种方案最强平台深度优化高需要构建引擎ONNX Runtime传统模型 跨平台部署INT8/FP16 等依赖执行后端中等如果你只是想在本机 Mac 或者 Windows 上跑一个 7B 模型做测试我强烈推荐 Ollama它的模型管理体验比手动下载权重再写加载代码好太多。如果你要部署一个面向多用户的 AI 接口直接上 vLLM 是正确选择它的--host 0.0.0.0 --port 8000启动之后自带 OpenAI 兼容接口业务方基本零改造接入。至于 TensorRT-LLM适合团队里有 GPU 优化经验的人因为引擎构建、动态 shape、量化校准这些环节都相当考验功底。5. 实战拆解用 Ollama vLLM Ray Serve 搭一个渐进式推理平台5.1 第一步从 Ollama 起步解决模型怎么本地跑起来我自己的建议是无论最终选什么方案第一步都先用 Ollama 把你需要的模型跑起来把模型选型和效果验证做完。Ollama 的优势是它可以跨平台安装Windows、macOS、Linux 都有对应的安装方式。在 Windows 上用 Docker Desktop 跑 Ollama 镜像也行但更省事的方式是直接安装官方客户端它会自动处理模型存储和 GPU 调用。部署完成之后Ollama 默认监听127.0.0.1:11434你通过ollama serve启动服务然后可以用curl调用http://localhost:11434/api/chat来验证模型是否能正常响应。这一步能帮你快速判断模型本身的回答质量、速度是否达到预期而不需要在工程架构上投入太多。我见过很多团队第一步就上 vLLM结果模型效果不好还要反复重建引擎浪费时间。这里提一个ollama 部署模型后如何可视化的问题。很多人跑通了 Ollama API但是觉得不够直观想有一个 Web UI。两个常用方案一是 Open WebUI它是一个独立的前端容器连上 Ollama 的 API 之后就能在浏览器里聊天、管理对话历史二是直接在 Grafana 里配 Ollama 的 metrics虽然 Ollama 暴露的指标不算全但基本的过程监控够用。我个人的建议是开发阶段用 Open WebUI 做交互验证生产监控还是走 Prometheus Grafana 这一套因为你要的是趋势数据而不是一个聊天界面。Ollama 的局限也要说清楚它对并发请求的处理效率一般。内部虽然会排队执行但没有连续批处理带来的吞吐优化。并发一高G显存就成瓶颈延迟会明显上涨。所以 Ollama 定位在验证、小规模场景一旦你的 QPS 超过两位数就要考虑迁移到 vLLM。5.2 第二步切换到 vLLM把吞吐和显存利用率提上来如果说 Ollama 是开箱即用的路线那 vLLM 就是生产级推理引擎的路线。安装 vLLM 只需要pip install vLLM如果你有 GPU 环境建议直接用官方镜像vllm/vllm-openai:latest因为 vLLM 和 CUDA 版本、PyTorch 版本的耦合比较紧自己用 pip 装容易踩依赖冲突的坑。启动 vLLM 服务的一个例子vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9这里几个参数值得解释一下。--tensor-parallel-size表示张量并行的 GPU 数量如果你的单卡显存不足以容纳模型加 KV Cache就需要设置为 2 或者 4但计算图会在多卡之间切分通信开销也要考虑不是越大越好。--gpu-memory-utilization表示允许 vLLM 使用的显存比例默认 0.9 是比较激进的值。如果你同一张卡上还要跑别的服务就要调低到 0.6~0.7 左右。vLLM 启动之后会提供一个 OpenAI 兼容的接口。这是它很聪明的一个设计意味着你之前的 prompt 模板、参数配置temperature、top_p 等几乎不需要改动直接迁移。这也是很多团队从独写推理逻辑迁移到 vLLM 时成本很低的原因。一个比较容易被忽略的参数是--max-num-seqs它控制并发 batch 的最大大小。如果设得太高显存会被 KV Cache 挤爆设得太低吞吐上不去。我的经验是7B 模型在 24GB 显存上--max-num-seqs设为 128 是比较平衡的值。5.3 第三步用 Docker Compose 把周边组件编排起来一个完整的推理服务除了模型引擎还需要有 API 网关、监控、日志等组件。用 Docker Compose 把这些串起来是最轻量又足够可靠的方案。以下是一个参考的docker-compose.yml结构services: ollama: image: ollama/ollama:latest ports: - 11434:11434 volumes: - ollama_models:/root/.ollama deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] open-webui: image: ghcr.io/open-webui/open-webui:main ports: - 3000:8080 environment: - OLLAMA_BASE_URLhttp://ollama:11434 depends_on: - ollama volumes: ollama_models:这个编排方案的思路是Ollama 容器负责模型推理Open WebUI 负责可视化交互模型数据通过 named volume 持久化避免容器重建导致模型丢失。如果你想用 vLLM 替代 Ollama只需要把服务定义里的镜像和启动命令换掉即可Open WebUI 的OLLAMA_BASE_URL换成 vLLM 的服务地址。此处特别提醒如果你要在docker-compose里跑 GPU 容器Deploy 段中的driver: nvidia、capabilities: [gpu]必须写对而且宿主机的 NVIDIA Container Toolkit 必须是装好的。如果docker compose up启动时提示 nvidia 相关的错误优先检查宿主机 toolkit 版本而不是镜像本身。5.4 第四步升级到 Ray Serve承载多模型和动态路由当你发现自己在同时部署三五个模型、每个模型还要有不同的副本策略时继续用 Docker Compose 硬堆服务会很痛苦。这时候把控制面升级到 Ray Serve 是一个自然的演进方向。Ray Serve 的核心概念是 Deployment一个 Deployment 就是一个模型的推理服务单元。你可以给每个模型定义不同的资源需求CPU/GPU并设置autoscaling_config让副本根据 QPS 自动伸缩。它的一个典型应用是 RAG 场景里的完整链路一个 LLM deployment一个 embedding deployment一个 reranker deployment然后用一个 graph 把它们编排起来每个请求进来先 embedding再去向量库检索最后给 LLM 生成答案。在选 Ray Serve 之前要明白它的成本它引入了控制平面、worker 进程和对象存储等概念运维复杂度比单容器高一个量级。如果你没有多模型、弹性伸缩的明确需求用 vLLM Nginx 路由就足够。技术选型不是越复杂越好复杂的代价是排障链路变长。5.5 可视化监控从 API 延迟到 GPU 利用率可视化是一个有没有差别很大的事。生产环境里没有监控你根本不知道模型服务是变慢了还是快崩了。我推荐的监控体系是 Prometheus 抓指标Grafana 画面板。vLLM 暴露了一些内置指标比如vllm:num_requests_running、vllm:num_requests_waiting、vllm:gpu_cache_usage_perc。这几个指标的组合可以判断当前系统的瓶颈如果 running 很少、waiting 很多说明并发处理能力到顶了如果gpu_cache_usage_perc持续接近 1说明显存不够用了要降低 batch 或者缩小 max-model-len。更重要的是模型服务的业务指标TTFT首 token 时间、ITLtoken 间延迟。这两个指标决定了用户的体感。TTFT 反映了排队和 prefill 阶段的耗时ITL 反映了解码阶段的耗时。如果 TTFT 高企优先看请求排队长度如果 ITL 高就要看是不是 GPU 算力不足或 KV Cache 命中率低。还有一个经常被问到的deploy 了一个 LLM有什么可视化的方案——其实最实用的不是把对话界面搞得花里胡哨而是把延迟、吞吐、显存、错误率这些曲线画清楚。对话界面只是用户体验层监控曲线才是工程决策的依据。可以先用 vLLM 自带的 metrics 接口 Prometheus Grafana 把基础监控搭起来再根据实际需要逐步加自定义指标。6. 常见问题排查与生产环境避坑6.1 显存相关OOM、CUDA Out of Memory 的定位与对策显存问题在 LLM 推理中排第一。最常见的表现是服务跑着跑着突然响应变慢然后某个请求直接报CUDA out of memory。这时候不要急着去调代码先看监控曲线——大概率是 KV Cache 增长把显存吃完了。对策有两种一种是调低--gpu-memory-utilization给其他进程留出空间一种是调低--max-model-len或者单请求的 token 上限从源头限制 KV Cache 的增长。还有一种情况是容器层面的显存隔离问题。nvidia-smi显示显存占用不高但容器启动时 vLLM 就是报 OOM这通常是因为容器看不到 GPU 或者老的 NVIDIA driver 不兼容新的 CUDA 版本。遇到这种玄学问题先检查驱动版本和 CUDA 版本的兼容矩阵。经验法则宿主机驱动版本低于 470 的话很多新框架直接不支持。6.2 请求失败与 schema 报错函数调用与工具调用时的坑如果你在 LLM 服务里接了函数调用function calling经常会遇到下面的报错llm request failed: provider rejected the request schema or tool payload.这类问题大多不是因为模型本身不行而是你传给模型的工具定义格式不合法。多数情况下是 JSON Schema 里缺少必要字段比如parameters没有定义type: object或者description字段缺失。不同模型对工具调用格式的宽容度不一样有的模型你给它不合法的 schema 也会硬生成有的模型则会直接拒绝响应。排查这个问题的标准动作是把传给模型的原始 payload 在本地用同样的模型复现一遍去掉工具的增量信息看模型是否响应正常。如果去掉工具后正常、加上后报错问题基本就锁定在 schema 格式上。6.3 幻觉与回答质量漂移平台侧的应对手段模型部署上线之后质量漂移是一个很难根治的问题。模型版本升级、Prompt 模板微调、上游 RAG 库的变化都会导致输出的分布发生变化。你不可能每次都靠人工逐条判断所以需要建立一套自动化的质量保障机制。我的做法是搭建三类自动化评测任务第一类是基于 LLM 的单元测试针对一些固定场景的输入用 reference answer 做相似度或规则校验确保核心能力没有明显退化第二类是回归测试集每次模型版本更新前跑一遍对打分项做对比第三类是线上日志的抽样分析定期从生产环境里拉取部分请求用 LLM-as-a-judge 的方式对新旧输出做对比。这个体系不需要很重但能让你在模型升级时心里有底而不是感觉好像变好了又感觉好像变差了。另外一个容易被忽视的点是确定性。LLM 推理默认是概率性的同一句话多次调用可能结果不同。在评测时如果没设置temperature0或seed测试结果就很难复现。建议在自动化评测任务里固定随机种子保证每次回归结果可比。6.4 常用故障速查表我把这些年踩过的典型问题和排查思路整理成一张速查表方便直接索引。症状可能原因排查顺序首 token 延迟高请求排队、prefill 计算量大1. 看 waiting 队列数 2. 检查 prefix cache 命中率 3. 降低 max-model-len响应速度越来越慢KV Cache 增长、显存接近上限1. 看 gpu_cache_usage 2. 降低并发 batch 3. 减少上下文长度CUDA OOM显存被占满、模型加载重复1. 查 nvidia-smi 2. 确认模型是否单例加载 3. 调整 gpu-memory-utilization接口返回超时worker 数量不足、模型推理卡住1. 看 CPU/GPU 利用率 2. 检查是否死锁 3. 增加 worker 或副本输出乱码或截断tokenizer 配置错误、max tokens 太小1. 查看 tokenizer 配置 2. 确认 generation config 3. 调大 max_tokensDocker 无法使用 GPUContainer Toolkit 未装或 runtime 未配置1. 宿主 nvidia-smi 2. docker run 实测 3. 检查 daemon.json6.5 资源池化与多租户的取舍建议平台阶段的另一个话题是 GPU 资源池化。把多张卡抽象成资源池按需分配给不同模型Google 的思路是这种做法K8s 的 device plugin 也能做类似的事但是Windows 上体验 GPU 池化、容器化运行推理模型用 gpustack 这一类工具会比 K8s 轻量很多适合单机多卡或者小团队做实验。生产环境还是要落到 K8s 自定义调度策略上因为你需要的是配额、优先级、抢占这些企业级能力。至于多租户要看你是否真的需要。如果只是内部十几个研发共用一张卡那排队就排队运维价值不大。如果要对外开放模型能力、按调用方计量计费那就必须做租户隔离、API Key 管理、限流配额。这些功能 vLLM 原生是不带的要自己做一个轻量的网关层或者集成现有的 API 网关。我的体感是很多团队在资源池化和多租户上过度设计。他们花了大量时间搭平台但上面的模型只有一两个用户。与其这样不如先把推理引擎和监控加好等真正的多模型、多团队使用需求出现时再逐步演进到完整平台。7. 从框架到平台最后聊点实在的模型部署这件事发展到 LLM 推理平台这个阶段缺的不是工具而是对负载的理解。很多人上 vLLM 是为了跟上潮流结果发现自己的 QPS 个位数完全用不上连续批处理的优势。也有人死守 Flask 裸跑模型并发请求一来直接卡死却不知道 vLLM 可以一条命令解决。我的建议是从实际负载出发逆推你需要的架构这才是推理平台建设的第一性原理。我在实际项目中的操作习惯是先用 Ollama 快速验证模型效果再切 vLLM 做生产服务最后根据多模型需求决定要不要上 Ray Serve 或者 K8s。每一层演进都是被真实瓶颈推着走的而不是提前把架构搭得又大又全。踩过几次坑之后你会认同一个道理模型部署框架也好推理平台也好最终目的是让模型稳定地、高效地、可控地对外提供价值。把监控做好把回滚路径留好把容量估算做准这三件事比任何花哨的框架都能救你于水火。