1. 从单模型到推理平台部署这件事到底在解决什么问题模型部署这个词听起来像是运维的活儿但真正做过的人都知道它其实是算法、工程、硬件三者的交叉地带。你训练出一个模型准确率再高如果推理延迟 3 秒、显存爆了、并发一上来就崩那它在业务侧的价值就是零。我见过太多团队在实验室里跑通了 demo一到正式环境就各种翻车问题往往不出在模型本身而是出在部署框架的选型和对推理链路的理解上。这篇内容想聊的是把“部署”这件事从单点拉成全景从最朴素的单模型服务到支撑多模型、多租户、动态扩缩容的 LLM 推理平台中间到底经历了哪些阶段每个阶段的核心技术点是什么工具该怎么选坑又在哪里。适合正在做模型上线、准备搭建推理服务、或者正在纠结 vLLM、Triton、Ollama 这些工具怎么配合使用的同学。不管你是刚接触部署的新手还是已经踩过几轮坑的老兵应该都能从中找到一些可以直接抄作业的东西。先说一个基本判断模型部署的本质是在“延迟、吞吐、成本、稳定性”这四个维度之间做权衡。单模型服务追求的是简单直接推理平台追求的是资源利用率和统一治理。你选择哪种框架取决于你现在处在哪个阶段而不是哪个工具最火就用哪个。2. 部署框架的四个演进阶段与选型逻辑2.1 单模型服务最简单也最容易低估的阶段最开始做部署大多数人的路径是一样的写一个 Flask 或 FastAPI 服务加载模型暴露一个/predict接口用 gunicorn 起几个 worker完事。这个阶段的核心诉求就是“能跑通”模型只有一个流量不大GPU 可能就一张。这个阶段最容易犯的错误是把模型加载放在请求处理函数里。我见过不少代码是这样的每次请求进来都model load_model()结果第一次请求慢得要死显存还反复分配释放。正确做法是在服务启动时加载一次全局持有模型对象。如果是多 worker 模式每个 worker 都会加载一份模型这时候要注意显存是否够用必要时用--preload或者共享内存的方式减少重复加载。另一个坑是并发模型的选择。Python 的 GIL 决定了多线程对 CPU 密集型任务没太大帮助但推理任务通常是 GPU 密集型CPU 侧主要是数据预处理和后处理。所以用多进程gunicorn 的 worker 模式配合每个进程独立加载模型往往比多线程更稳。但多进程意味着显存成倍占用一张 24G 的卡可能只能起 2 到 3 个 worker这个账要提前算清楚。单模型服务阶段还有一个隐形成本没有统一的监控和日志。服务挂了靠人肉发现延迟高了靠用户投诉。这个阶段如果业务量不大可以接受但一旦模型数量超过 3 个你就会开始怀念一个统一的入口。2.2 多模型服务路由、隔离与资源争抢当模型数量增加到多个第一个问题就是路由。你不能每个模型都占一个端口对外暴露需要一个网关根据请求参数把流量分发到对应的模型服务。这时候常见的做法是用 Nginx 做反向代理或者用 FastAPI 写一个统一入口内部再转发。但路由只是表面问题真正麻烦的是资源隔离。多个模型共享一张 GPU 时显存是硬隔离的但算力是软隔离的。一个模型如果突然来了一波大 batch 请求会把 GPU 占满其他模型的请求就得排队。我实测下来如果没有做请求队列和优先级控制一个高并发的模型能把整张卡的响应时间从 50ms 拉到 2s 以上。这个阶段的解决方案通常有两种一是按模型分配 GPU物理隔离简单粗暴但成本高二是用推理服务器做统一调度比如 Triton Inference Server它支持多模型共存、动态 batching、模型版本管理还能按模型设置实例数和资源限制。Triton 的核心价值在于它把“模型”抽象成了一个可配置的实体你可以为每个模型指定用几张卡、起几个实例、batch 怎么攒这些配置通过 config.pbtxt 管理改完不用动代码。不过 Triton 的学习曲线不低尤其是它的 backend 机制和 ensemble 功能第一次接触容易懵。我的建议是如果你的模型都是标准框架PyTorch、TensorFlow、ONNX且需要多模型统一管理Triton 值得投入如果只是两三个模型用 FastAPI 加进程隔离可能更快。2.3 LLM 推理服务vLLM 带来的范式变化到了 LLM 时代前面那套玩法基本失效了。传统模型一次推理几十毫秒LLM 一次生成可能要几秒甚至几十秒而且输出是流式的。更关键的是LLM 的显存占用极大一个 7B 模型 FP16 就要 14G 显存加上 KV Cache一张 24G 卡跑一个模型就到头了。vLLM 的出现改变了这个局面它的核心是PagedAttention。简单类比传统 KV Cache 就像给每个请求预分配一整块连续内存不管用不用得完先占着PagedAttention 则像操作系统的虚拟内存分页把 KV Cache 切成固定大小的 block按需分配用完了再回收。这个机制让显存利用率大幅提升吞吐量能比 HuggingFace 原生推理高出好几倍。vLLM 的部署方式很直接官方提供了 OpenAI 兼容的 API server一条命令就能起python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000这里几个参数值得展开说。--gpu-memory-utilization 0.9表示允许 vLLM 使用 90% 的显存剩下的留给系统和其他进程这个值设太高容易 OOM设太低浪费显存0.85 到 0.92 之间是比较稳的区间。--max-model-len控制最大上下文长度设得越大KV Cache 预留越多能同时处理的请求就越少需要根据实际业务场景权衡。--tensor-parallel-size是张量并行数等于使用的 GPU 数量单卡就设 1。vLLM 也支持量化模型比如 AWQ、GPTQ、FP8能在显存有限的情况下跑更大的模型。我试过在单张 24G 卡上用 AWQ 量化跑 14B 模型效果可以接受但量化会带来一定的精度损失需要在自己的评测集上验证。2.4 推理平台统一治理与弹性伸缩当模型数量、用户数量、并发量都上来了单靠 vLLM 命令行启动就不够了。你需要一个平台来做统一的事情模型注册、版本管理、灰度发布、自动扩缩容、配额管理、监控告警。这个层面的工具选择就多了。GPUStack是近两年比较活跃的一个开源方案支持在 Windows 和 Linux 上部署能管理多台机器的 GPU 资源统一调度模型。它的定位偏向“开箱即用”适合中小团队快速搭建推理平台。KServe则是 Kubernetes 生态里的标准方案基于 Knative 做 serverless 推理支持 scale-to-zero适合已经有 K8s 基础设施的团队。平台化的核心挑战不在部署本身而在调度策略。比如一个请求进来是优先用已经加载了该模型的节点还是找一个空闲节点冷启动冷启动一个 7B 模型可能要几十秒用户等不起。所以平台通常需要做模型预热和常驻实例把高频模型保持在加载状态低频模型按需加载。这个策略的配置直接决定了成本和体验的平衡点。3. 核心工具链拆解vLLM、Triton、Ollama 到底怎么选3.1 vLLMLLM 推理的性能天花板vLLM 的定位很明确专注 LLM 推理的高吞吐服务。它的优势在于 PagedAttention、连续批处理continuous batching和优化的 CUDA kernel。连续批处理的意思是不等一个 batch 里所有请求都生成完再处理下一批而是动态地把新请求插进来把已完成的请求踢出去这样 GPU 利用率能一直保持在高位。实测数据上在同样的硬件和模型下vLLM 的吞吐量通常是 HuggingFace transformers 的 5 到 10 倍具体取决于请求长度和并发数。但 vLLM 也不是没有短板它对非 LLM 模型的支持有限对多模型共存的支持不如 Triton 灵活而且它的调度策略偏向吞吐优先极端情况下单请求延迟可能不如优化过的单模型服务。vLLM 的部署方式现在也很多样除了直接跑 Python 命令还有官方 Docker 镜像vllm/vllm-openai指定版本号可以避免环境问题。比如加载 Qwen3-Embedding 这类 embedding 模型vLLM 也支持但要注意 embedding 模型和生成模型的接口参数不同需要查对应版本的文档。3.2 Triton多模型统一服务的老牌选手Triton 的核心竞争力是多框架、多模型、多实例的统一管理。它支持 PyTorch、TensorFlow、ONNX、TensorRT 等后端每个模型可以独立配置实例数、batch 策略、输入输出格式。对于同时有 CV 模型、NLP 模型、推荐模型的团队Triton 能把这些都收拢到一个服务里。Triton 的另一个强项是ensemble 和 business logic scripting。比如一个请求需要先过预处理模型再过主模型最后过后处理Triton 可以把这些串成一个 pipeline对外只暴露一个接口。这个能力在传统深度学习部署里非常实用。但 Triton 对 LLM 的支持相对晚一些虽然现在也有 TensorRT-LLM backend 和 vLLM backend但配置复杂度比直接用 vLLM 高。我的经验是传统模型多用 TritonLLM 为主用 vLLM两者都有就分开部署用网关统一路由。3.3 Ollama 与 LM Studio本地部署的轻量选择Ollama 和 LM Studio 走的是另一条路极简的本地部署体验。Ollama 一条ollama run llama3就能跑起来自动处理模型下载、量化、服务启动。它底层其实也用了 llama.cpp 做推理支持 GGUF 格式的量化模型在消费级显卡甚至 CPU 上都能跑。Ollama 适合的场景是个人开发、本地测试、边缘设备。它的 Docker 部署也很方便挂载模型目录就能持久化。但 Ollama 的并发能力有限不适合正式环境的高并发服务。LM Studio 则是图形化界面更适合非工程背景的用户做本地体验。这里要提一下GGUF 格式。GGUF 是 llama.cpp 推出的模型格式支持多种量化等级Q4、Q5、Q8 等能在有限显存下跑更大的模型。它的缺点是推理速度通常不如 vLLM 的 FP16 或 AWQ但在资源受限的场景下是很好的折中。3.4 工具选型对照表工具核心优势适用场景并发能力多模型支持vLLM高吞吐、PagedAttentionLLM 正式服务高有限Triton多框架统一管理传统模型多模型高强Ollama极简本地部署个人开发、边缘低中LM Studio图形化体验非工程用户低中GPUStack多机 GPU 调度中小团队平台中高强这张表不是绝对的实际选型还要看团队的技术栈和运维能力。比如你已经有 K8s那 KServe 可能比 GPUStack 更合适如果你只有一张卡那 vLLM 直接跑就是最优解。4. 正式环境部署的实操流程与关键配置4.1 环境准备CUDA、驱动与容器化正式环境部署的第一步不是写代码而是把环境锁死。CUDA 版本、驱动版本、Python 版本、框架版本任何一个不匹配都可能导致推理失败或者性能下降。我踩过最坑的一次是驱动版本比 CUDA 要求低了一个小版本结果 vLLM 能启动但推理结果全是乱码排查了半天才发现是驱动问题。推荐的做法是用 Docker 容器化部署把 CUDA、Python、依赖全部打包进镜像。vLLM 官方镜像已经做好了这些直接拉取对应版本即可。如果是自己构建镜像Dockerfile 里要明确指定基础镜像的 CUDA 版本比如nvidia/cuda:12.8.0-devel-ubuntu22.04然后在里面装 Python 和 vLLM。GPU 直通需要在启动容器时加--gpus all同时确保宿主机装了 nvidia-container-toolkit。验证方式是进容器后跑nvidia-smi能看到显卡信息就说明直通成功。4.2 模型加载与显存计算模型加载前要算一笔账模型权重 KV Cache 激活值 框架开销。以 7B 模型 FP16 为例权重约 14GKV Cache 取决于 max-model-len 和并发数激活值通常几百 M 到 1G框架开销 1 到 2G。一张 24G 卡跑 7B FP16留给 KV Cache 的大概 6 到 8G按每个 token 的 KV 占用算能支持的并发 token 数是有限的。计算公式大致是KV Cache 显存 2 * num_layers * num_heads * head_dim * max_seq_len * batch_size * dtype_size。这个公式不用手算vLLM 启动时会打印显存分配情况根据日志调整--gpu-memory-utilization和--max-model-len就行。如果显存不够有几个方向量化AWQ/GPTQ 把权重压到 4bit、张量并行多卡分摊、降低 max-model-len、减少并发。量化是最直接的但要注意量化模型的精度损失最好在自己的任务上做 A/B 测试。4.3 服务启动与接口验证vLLM 的 OpenAI 兼容接口启动后可以用 curl 验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好}], max_tokens: 100, temperature: 0.7 }返回正常就说明服务通了。接下来要测的是并发和稳定性。可以用wrk或locust做压测观察不同并发下的延迟和吞吐变化。重点关注 P99 延迟和错误率如果 P99 突然飙升或者出现超时说明显存或算力到了瓶颈。流式输出也要单独测因为流式和非流式的处理路径不同。vLLM 支持stream: true客户端要能正确处理 SSE 格式的响应。4.4 监控与日志上线只是开始服务上线后没有监控等于裸奔。至少要监控这几个指标GPU 利用率、显存占用、请求延迟P50/P95/P99、吞吐量tokens/s、错误率、队列长度。GPU 指标可以用 DCGM Exporter 采集应用指标可以用 Prometheus 客户端埋点。日志方面vLLM 会输出每个请求的耗时和 token 数这些日志要收集起来做分析。如果发现某些请求特别慢可能是输入太长或者生成了太多 token需要从业务侧做限制。告警策略上显存超过 95% 持续 1 分钟、P99 延迟超过阈值、错误率超过 1%这些都应该触发告警。告警不是目的快速定位和恢复才是。5. 常见问题排查与避坑经验实录5.1 启动就 OOM显存都去哪了OOM 是最常见的问题原因通常有几个模型权重比预期大比如加载了 FP32 而不是 FP16、gpu-memory-utilization设太高、max-model-len设太大、有其他进程占着显存。排查步骤先nvidia-smi看有没有残留进程再检查模型加载时的 dtype最后逐步降低gpu-memory-utilization和max-model-len。如果还是 OOM考虑量化或者换更小的模型。注意vLLM 启动时会预分配显存如果启动成功但运行中 OOM通常是 KV Cache 不够需要降低并发或 max-model-len。5.2 推理速度慢是模型问题还是配置问题速度慢的原因很多要分层排查。先看 GPU 利用率如果利用率很低说明瓶颈在 CPU 侧数据预处理、tokenization或者请求队列如果利用率很高但吞吐上不去可能是 batch 太小或者模型本身计算量大。vLLM 的连续批处理需要一定并发才能发挥优势单请求测试时吞吐看起来不高是正常的。另外--enforce-eager会禁用 CUDA graph速度会慢一些正式环境建议开启 CUDA graph。5.3 多模型共存时的资源争抢多个模型共享 GPU 时最常见的问题是显存碎片和算力争抢。显存碎片可以通过限制每个模型的gpu-memory-utilization来缓解算力争抢则需要用推理服务器做调度或者干脆物理隔离。如果非要在同一张卡上跑多个模型建议用 Triton 或者 GPUStack 做统一管理它们支持按模型设置资源配额和优先级。自己写调度逻辑的话至少要实现请求队列和超时控制。5.4 常见问题速查表问题现象可能原因排查方向解决方案启动 OOM显存不足nvidia-smi、dtype量化、降 max-model-len推理乱码驱动/CUDA 不匹配版本对照升级驱动或换镜像延迟高batch 小、CPU 瓶颈GPU 利用率提高并发、优化预处理吞吐低未开连续批处理启动参数开启 CUDA graph服务崩溃显存泄漏、OOM日志、监控限制并发、加内存回收多模型争抢无隔离资源监控用 Triton/GPUStack 调度5.5 几个容易被忽略的细节模型版本管理正式环境一定要记录每个服务用的是哪个模型版本最好用模型哈希或者版本号标记。否则出了问题都不知道回滚到哪个版本。请求超时设置LLM 生成可能很久客户端和服务端都要设合理的超时。服务端超时太短会误杀正常请求太长会占着连接不放。健康检查K8s 环境下的 liveness 和 readiness 探针要区分开。readiness 检查模型是否加载完成liveness 检查进程是否存活。探针配置不当会导致服务反复重启。日志脱敏用户输入可能包含敏感信息日志里要做好脱敏尤其是正式环境。6. 从单模型到平台的扩展路径建议如果你现在还在单模型阶段不要一上来就搞平台。先用最简单的方案把业务跑通等遇到瓶颈再逐步演进。我见过太多团队在业务还没验证的时候就搭了一套复杂的推理平台结果维护成本比业务本身还高。演进路径可以这样走单模型 FastAPI 服务 → 多模型加网关路由 → LLM 换 vLLM → 多机多卡用 GPUStack 或 KServe → 最后做统一平台。每一步都是被业务需求推着走而不是为了技术而技术。平台化之后重点会从“怎么部署”转向“怎么治理”配额管理、成本核算、灰度发布、A/B 测试、模型评估。这些才是推理平台真正的价值所在。vLLM 解决了单点性能问题Triton 解决了多模型管理问题但跨团队、跨业务的统一治理还是得靠平台层的设计。我在实际项目里的体会是部署框架的选型没有标准答案只有适不适合当前阶段。一张卡的时候 vLLM 命令行就是最优解十张卡的时候就得考虑调度和隔离一百张卡的时候平台化是唯一出路。关键是搞清楚自己现在在哪下一步要去哪然后选一个能平滑过渡的方案。
1. 从单模型到推理平台部署这件事到底在解决什么问题模型部署这个词听起来像是运维的活儿但真正做过的人都知道它其实是算法、工程、硬件三者的交叉地带。你训练出一个模型准确率再高如果推理延迟 3 秒、显存爆了、并发一上来就崩那它在业务侧的价值就是零。我见过太多团队在实验室里跑通了 demo一到正式环境就各种翻车问题往往不出在模型本身而是出在部署框架的选型和对推理链路的理解上。这篇内容想聊的是把“部署”这件事从单点拉成全景从最朴素的单模型服务到支撑多模型、多租户、动态扩缩容的 LLM 推理平台中间到底经历了哪些阶段每个阶段的核心技术点是什么工具该怎么选坑又在哪里。适合正在做模型上线、准备搭建推理服务、或者正在纠结 vLLM、Triton、Ollama 这些工具怎么配合使用的同学。不管你是刚接触部署的新手还是已经踩过几轮坑的老兵应该都能从中找到一些可以直接抄作业的东西。先说一个基本判断模型部署的本质是在“延迟、吞吐、成本、稳定性”这四个维度之间做权衡。单模型服务追求的是简单直接推理平台追求的是资源利用率和统一治理。你选择哪种框架取决于你现在处在哪个阶段而不是哪个工具最火就用哪个。2. 部署框架的四个演进阶段与选型逻辑2.1 单模型服务最简单也最容易低估的阶段最开始做部署大多数人的路径是一样的写一个 Flask 或 FastAPI 服务加载模型暴露一个/predict接口用 gunicorn 起几个 worker完事。这个阶段的核心诉求就是“能跑通”模型只有一个流量不大GPU 可能就一张。这个阶段最容易犯的错误是把模型加载放在请求处理函数里。我见过不少代码是这样的每次请求进来都model load_model()结果第一次请求慢得要死显存还反复分配释放。正确做法是在服务启动时加载一次全局持有模型对象。如果是多 worker 模式每个 worker 都会加载一份模型这时候要注意显存是否够用必要时用--preload或者共享内存的方式减少重复加载。另一个坑是并发模型的选择。Python 的 GIL 决定了多线程对 CPU 密集型任务没太大帮助但推理任务通常是 GPU 密集型CPU 侧主要是数据预处理和后处理。所以用多进程gunicorn 的 worker 模式配合每个进程独立加载模型往往比多线程更稳。但多进程意味着显存成倍占用一张 24G 的卡可能只能起 2 到 3 个 worker这个账要提前算清楚。单模型服务阶段还有一个隐形成本没有统一的监控和日志。服务挂了靠人肉发现延迟高了靠用户投诉。这个阶段如果业务量不大可以接受但一旦模型数量超过 3 个你就会开始怀念一个统一的入口。2.2 多模型服务路由、隔离与资源争抢当模型数量增加到多个第一个问题就是路由。你不能每个模型都占一个端口对外暴露需要一个网关根据请求参数把流量分发到对应的模型服务。这时候常见的做法是用 Nginx 做反向代理或者用 FastAPI 写一个统一入口内部再转发。但路由只是表面问题真正麻烦的是资源隔离。多个模型共享一张 GPU 时显存是硬隔离的但算力是软隔离的。一个模型如果突然来了一波大 batch 请求会把 GPU 占满其他模型的请求就得排队。我实测下来如果没有做请求队列和优先级控制一个高并发的模型能把整张卡的响应时间从 50ms 拉到 2s 以上。这个阶段的解决方案通常有两种一是按模型分配 GPU物理隔离简单粗暴但成本高二是用推理服务器做统一调度比如 Triton Inference Server它支持多模型共存、动态 batching、模型版本管理还能按模型设置实例数和资源限制。Triton 的核心价值在于它把“模型”抽象成了一个可配置的实体你可以为每个模型指定用几张卡、起几个实例、batch 怎么攒这些配置通过 config.pbtxt 管理改完不用动代码。不过 Triton 的学习曲线不低尤其是它的 backend 机制和 ensemble 功能第一次接触容易懵。我的建议是如果你的模型都是标准框架PyTorch、TensorFlow、ONNX且需要多模型统一管理Triton 值得投入如果只是两三个模型用 FastAPI 加进程隔离可能更快。2.3 LLM 推理服务vLLM 带来的范式变化到了 LLM 时代前面那套玩法基本失效了。传统模型一次推理几十毫秒LLM 一次生成可能要几秒甚至几十秒而且输出是流式的。更关键的是LLM 的显存占用极大一个 7B 模型 FP16 就要 14G 显存加上 KV Cache一张 24G 卡跑一个模型就到头了。vLLM 的出现改变了这个局面它的核心是PagedAttention。简单类比传统 KV Cache 就像给每个请求预分配一整块连续内存不管用不用得完先占着PagedAttention 则像操作系统的虚拟内存分页把 KV Cache 切成固定大小的 block按需分配用完了再回收。这个机制让显存利用率大幅提升吞吐量能比 HuggingFace 原生推理高出好几倍。vLLM 的部署方式很直接官方提供了 OpenAI 兼容的 API server一条命令就能起python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000这里几个参数值得展开说。--gpu-memory-utilization 0.9表示允许 vLLM 使用 90% 的显存剩下的留给系统和其他进程这个值设太高容易 OOM设太低浪费显存0.85 到 0.92 之间是比较稳的区间。--max-model-len控制最大上下文长度设得越大KV Cache 预留越多能同时处理的请求就越少需要根据实际业务场景权衡。--tensor-parallel-size是张量并行数等于使用的 GPU 数量单卡就设 1。vLLM 也支持量化模型比如 AWQ、GPTQ、FP8能在显存有限的情况下跑更大的模型。我试过在单张 24G 卡上用 AWQ 量化跑 14B 模型效果可以接受但量化会带来一定的精度损失需要在自己的评测集上验证。2.4 推理平台统一治理与弹性伸缩当模型数量、用户数量、并发量都上来了单靠 vLLM 命令行启动就不够了。你需要一个平台来做统一的事情模型注册、版本管理、灰度发布、自动扩缩容、配额管理、监控告警。这个层面的工具选择就多了。GPUStack是近两年比较活跃的一个开源方案支持在 Windows 和 Linux 上部署能管理多台机器的 GPU 资源统一调度模型。它的定位偏向“开箱即用”适合中小团队快速搭建推理平台。KServe则是 Kubernetes 生态里的标准方案基于 Knative 做 serverless 推理支持 scale-to-zero适合已经有 K8s 基础设施的团队。平台化的核心挑战不在部署本身而在调度策略。比如一个请求进来是优先用已经加载了该模型的节点还是找一个空闲节点冷启动冷启动一个 7B 模型可能要几十秒用户等不起。所以平台通常需要做模型预热和常驻实例把高频模型保持在加载状态低频模型按需加载。这个策略的配置直接决定了成本和体验的平衡点。3. 核心工具链拆解vLLM、Triton、Ollama 到底怎么选3.1 vLLMLLM 推理的性能天花板vLLM 的定位很明确专注 LLM 推理的高吞吐服务。它的优势在于 PagedAttention、连续批处理continuous batching和优化的 CUDA kernel。连续批处理的意思是不等一个 batch 里所有请求都生成完再处理下一批而是动态地把新请求插进来把已完成的请求踢出去这样 GPU 利用率能一直保持在高位。实测数据上在同样的硬件和模型下vLLM 的吞吐量通常是 HuggingFace transformers 的 5 到 10 倍具体取决于请求长度和并发数。但 vLLM 也不是没有短板它对非 LLM 模型的支持有限对多模型共存的支持不如 Triton 灵活而且它的调度策略偏向吞吐优先极端情况下单请求延迟可能不如优化过的单模型服务。vLLM 的部署方式现在也很多样除了直接跑 Python 命令还有官方 Docker 镜像vllm/vllm-openai指定版本号可以避免环境问题。比如加载 Qwen3-Embedding 这类 embedding 模型vLLM 也支持但要注意 embedding 模型和生成模型的接口参数不同需要查对应版本的文档。3.2 Triton多模型统一服务的老牌选手Triton 的核心竞争力是多框架、多模型、多实例的统一管理。它支持 PyTorch、TensorFlow、ONNX、TensorRT 等后端每个模型可以独立配置实例数、batch 策略、输入输出格式。对于同时有 CV 模型、NLP 模型、推荐模型的团队Triton 能把这些都收拢到一个服务里。Triton 的另一个强项是ensemble 和 business logic scripting。比如一个请求需要先过预处理模型再过主模型最后过后处理Triton 可以把这些串成一个 pipeline对外只暴露一个接口。这个能力在传统深度学习部署里非常实用。但 Triton 对 LLM 的支持相对晚一些虽然现在也有 TensorRT-LLM backend 和 vLLM backend但配置复杂度比直接用 vLLM 高。我的经验是传统模型多用 TritonLLM 为主用 vLLM两者都有就分开部署用网关统一路由。3.3 Ollama 与 LM Studio本地部署的轻量选择Ollama 和 LM Studio 走的是另一条路极简的本地部署体验。Ollama 一条ollama run llama3就能跑起来自动处理模型下载、量化、服务启动。它底层其实也用了 llama.cpp 做推理支持 GGUF 格式的量化模型在消费级显卡甚至 CPU 上都能跑。Ollama 适合的场景是个人开发、本地测试、边缘设备。它的 Docker 部署也很方便挂载模型目录就能持久化。但 Ollama 的并发能力有限不适合正式环境的高并发服务。LM Studio 则是图形化界面更适合非工程背景的用户做本地体验。这里要提一下GGUF 格式。GGUF 是 llama.cpp 推出的模型格式支持多种量化等级Q4、Q5、Q8 等能在有限显存下跑更大的模型。它的缺点是推理速度通常不如 vLLM 的 FP16 或 AWQ但在资源受限的场景下是很好的折中。3.4 工具选型对照表工具核心优势适用场景并发能力多模型支持vLLM高吞吐、PagedAttentionLLM 正式服务高有限Triton多框架统一管理传统模型多模型高强Ollama极简本地部署个人开发、边缘低中LM Studio图形化体验非工程用户低中GPUStack多机 GPU 调度中小团队平台中高强这张表不是绝对的实际选型还要看团队的技术栈和运维能力。比如你已经有 K8s那 KServe 可能比 GPUStack 更合适如果你只有一张卡那 vLLM 直接跑就是最优解。4. 正式环境部署的实操流程与关键配置4.1 环境准备CUDA、驱动与容器化正式环境部署的第一步不是写代码而是把环境锁死。CUDA 版本、驱动版本、Python 版本、框架版本任何一个不匹配都可能导致推理失败或者性能下降。我踩过最坑的一次是驱动版本比 CUDA 要求低了一个小版本结果 vLLM 能启动但推理结果全是乱码排查了半天才发现是驱动问题。推荐的做法是用 Docker 容器化部署把 CUDA、Python、依赖全部打包进镜像。vLLM 官方镜像已经做好了这些直接拉取对应版本即可。如果是自己构建镜像Dockerfile 里要明确指定基础镜像的 CUDA 版本比如nvidia/cuda:12.8.0-devel-ubuntu22.04然后在里面装 Python 和 vLLM。GPU 直通需要在启动容器时加--gpus all同时确保宿主机装了 nvidia-container-toolkit。验证方式是进容器后跑nvidia-smi能看到显卡信息就说明直通成功。4.2 模型加载与显存计算模型加载前要算一笔账模型权重 KV Cache 激活值 框架开销。以 7B 模型 FP16 为例权重约 14GKV Cache 取决于 max-model-len 和并发数激活值通常几百 M 到 1G框架开销 1 到 2G。一张 24G 卡跑 7B FP16留给 KV Cache 的大概 6 到 8G按每个 token 的 KV 占用算能支持的并发 token 数是有限的。计算公式大致是KV Cache 显存 2 * num_layers * num_heads * head_dim * max_seq_len * batch_size * dtype_size。这个公式不用手算vLLM 启动时会打印显存分配情况根据日志调整--gpu-memory-utilization和--max-model-len就行。如果显存不够有几个方向量化AWQ/GPTQ 把权重压到 4bit、张量并行多卡分摊、降低 max-model-len、减少并发。量化是最直接的但要注意量化模型的精度损失最好在自己的任务上做 A/B 测试。4.3 服务启动与接口验证vLLM 的 OpenAI 兼容接口启动后可以用 curl 验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好}], max_tokens: 100, temperature: 0.7 }返回正常就说明服务通了。接下来要测的是并发和稳定性。可以用wrk或locust做压测观察不同并发下的延迟和吞吐变化。重点关注 P99 延迟和错误率如果 P99 突然飙升或者出现超时说明显存或算力到了瓶颈。流式输出也要单独测因为流式和非流式的处理路径不同。vLLM 支持stream: true客户端要能正确处理 SSE 格式的响应。4.4 监控与日志上线只是开始服务上线后没有监控等于裸奔。至少要监控这几个指标GPU 利用率、显存占用、请求延迟P50/P95/P99、吞吐量tokens/s、错误率、队列长度。GPU 指标可以用 DCGM Exporter 采集应用指标可以用 Prometheus 客户端埋点。日志方面vLLM 会输出每个请求的耗时和 token 数这些日志要收集起来做分析。如果发现某些请求特别慢可能是输入太长或者生成了太多 token需要从业务侧做限制。告警策略上显存超过 95% 持续 1 分钟、P99 延迟超过阈值、错误率超过 1%这些都应该触发告警。告警不是目的快速定位和恢复才是。5. 常见问题排查与避坑经验实录5.1 启动就 OOM显存都去哪了OOM 是最常见的问题原因通常有几个模型权重比预期大比如加载了 FP32 而不是 FP16、gpu-memory-utilization设太高、max-model-len设太大、有其他进程占着显存。排查步骤先nvidia-smi看有没有残留进程再检查模型加载时的 dtype最后逐步降低gpu-memory-utilization和max-model-len。如果还是 OOM考虑量化或者换更小的模型。注意vLLM 启动时会预分配显存如果启动成功但运行中 OOM通常是 KV Cache 不够需要降低并发或 max-model-len。5.2 推理速度慢是模型问题还是配置问题速度慢的原因很多要分层排查。先看 GPU 利用率如果利用率很低说明瓶颈在 CPU 侧数据预处理、tokenization或者请求队列如果利用率很高但吞吐上不去可能是 batch 太小或者模型本身计算量大。vLLM 的连续批处理需要一定并发才能发挥优势单请求测试时吞吐看起来不高是正常的。另外--enforce-eager会禁用 CUDA graph速度会慢一些正式环境建议开启 CUDA graph。5.3 多模型共存时的资源争抢多个模型共享 GPU 时最常见的问题是显存碎片和算力争抢。显存碎片可以通过限制每个模型的gpu-memory-utilization来缓解算力争抢则需要用推理服务器做调度或者干脆物理隔离。如果非要在同一张卡上跑多个模型建议用 Triton 或者 GPUStack 做统一管理它们支持按模型设置资源配额和优先级。自己写调度逻辑的话至少要实现请求队列和超时控制。5.4 常见问题速查表问题现象可能原因排查方向解决方案启动 OOM显存不足nvidia-smi、dtype量化、降 max-model-len推理乱码驱动/CUDA 不匹配版本对照升级驱动或换镜像延迟高batch 小、CPU 瓶颈GPU 利用率提高并发、优化预处理吞吐低未开连续批处理启动参数开启 CUDA graph服务崩溃显存泄漏、OOM日志、监控限制并发、加内存回收多模型争抢无隔离资源监控用 Triton/GPUStack 调度5.5 几个容易被忽略的细节模型版本管理正式环境一定要记录每个服务用的是哪个模型版本最好用模型哈希或者版本号标记。否则出了问题都不知道回滚到哪个版本。请求超时设置LLM 生成可能很久客户端和服务端都要设合理的超时。服务端超时太短会误杀正常请求太长会占着连接不放。健康检查K8s 环境下的 liveness 和 readiness 探针要区分开。readiness 检查模型是否加载完成liveness 检查进程是否存活。探针配置不当会导致服务反复重启。日志脱敏用户输入可能包含敏感信息日志里要做好脱敏尤其是正式环境。6. 从单模型到平台的扩展路径建议如果你现在还在单模型阶段不要一上来就搞平台。先用最简单的方案把业务跑通等遇到瓶颈再逐步演进。我见过太多团队在业务还没验证的时候就搭了一套复杂的推理平台结果维护成本比业务本身还高。演进路径可以这样走单模型 FastAPI 服务 → 多模型加网关路由 → LLM 换 vLLM → 多机多卡用 GPUStack 或 KServe → 最后做统一平台。每一步都是被业务需求推着走而不是为了技术而技术。平台化之后重点会从“怎么部署”转向“怎么治理”配额管理、成本核算、灰度发布、A/B 测试、模型评估。这些才是推理平台真正的价值所在。vLLM 解决了单点性能问题Triton 解决了多模型管理问题但跨团队、跨业务的统一治理还是得靠平台层的设计。我在实际项目里的体会是部署框架的选型没有标准答案只有适不适合当前阶段。一张卡的时候 vLLM 命令行就是最优解十张卡的时候就得考虑调度和隔离一百张卡的时候平台化是唯一出路。关键是搞清楚自己现在在哪下一步要去哪然后选一个能平滑过渡的方案。
