1. 大模型推理部署的现状与选型逻辑1.1 为什么GPU推理部署成了绕不开的坎这两年跟不少团队聊下来一个共同的感受是模型训练那关过了真正让人头疼的反而是在线推理部署。训练可以慢慢调、可以排队跑但推理是面向真实用户的延迟高一点、吞吐低一点用户体验和成本账单立刻就会给你脸色看。大模型和生成式AI产品的推理负载有几个很鲜明的特点。第一是显存饥渴一个7B参数的模型FP16精度下光权重就要占掉大约14GB显存再加上KV Cache、中间激活值实际占用往往要奔着18到20GB去。第二是计算密集但访存更密集自回归生成是一个token一个token往外蹦的每生成一个token都要把整个模型权重过一遍所以推理性能往往卡在显存带宽上而不是纯算力上。第三是请求长度差异极大有的用户就问一句话有的用户贴进来一整篇文档这种变长输入对批处理调度提出了很高要求。正是这些特点决定了GPU推理部署不能简单地买张卡、装个环境、跑起来就完事。你需要考虑用什么样的推理引擎、选什么样的GPU规格、走云端还是本地、成本怎么控制、并发上来之后怎么扩缩容。这一整套问题就是本文要拆解的核心。1.2 云端推理方案到底在解决什么问题先把问题定义清楚。所谓云端GPU推理方案本质上是在回答三个层面的问题算力从哪来是租用云厂商的GPU实例还是用Serverless形态的按需调用还是自建机房。推理怎么跑用什么推理框架vLLM、TensorRT-LLM、llama.cpp、SGLang等怎么做量化怎么管理KV Cache。服务怎么交付怎么暴露API、怎么做流式输出、怎么做并发调度和自动扩缩容。这三个层面是层层递进的。很多人一上来就纠结选哪家云其实更合理的顺序是先想清楚推理框架和服务架构再反过来决定算力形态。因为不同的推理框架对GPU型号、显存、驱动版本的要求差别很大选错了框架后面换云就是大工程。我个人的经验是选型时按这个优先级来排推理框架 GPU规格 云厂商 计费模式。框架决定了你的性能上限和迁移成本GPU规格决定了你能不能跑得动云厂商更多是价格和稳定性的差异计费模式则是最后优化成本的手段。1.3 三类主流云端推理形态的取舍目前市面上能落地的云端GPU推理方案大致可以归为三类各有各的适用场景。第一类GPU云服务器IaaS。就是租一台带GPU的虚拟机你自己装驱动、装推理框架、部署服务。代表形态就是各家云厂商的GPU实例。这种方案控制力最强什么都能自己调适合对性能有极致要求、或者需要跑自定义模型的团队。缺点是运维成本高你得自己处理扩缩容、故障恢复、驱动兼容这些琐事。第二类容器化推理服务PaaS。云厂商或第三方平台提供预置了推理框架的容器镜像你把自己的模型挂上去就能跑平台帮你处理调度和扩缩容。这种方案在灵活性和省心之间取了个平衡适合大多数中小团队。第三类Serverless推理FaaS形态。你只管调用API底层GPU资源完全由平台管理按实际调用量计费。这种方案最省心冷启动是主要痛点适合流量波动大、或者刚起步验证产品的场景。下面这张表可以帮你快速定位自己该往哪个方向走方案形态控制力运维成本成本模型适用场景GPU云服务器最强最高按实例时长高性能要求、自定义模型、稳定流量容器化推理服务中等中等按实例调用大多数生产场景Serverless推理最弱最低按调用量流量波动大、快速验证提示不要一上来就追求最省钱的方案。推理部署的第一优先级永远是跑得稳、延迟可控成本优化是稳定之后再做的事。我见过太多团队为了省一点GPU钱选了不合适的方案结果线上频繁超时最后返工的成本远超省下的钱。2. 推理框架选型决定性能上限的关键一步2.1 vLLM高吞吐场景的默认答案如果只能推荐一个通用的大模型推理框架我会毫不犹豫地说vLLM。它的核心杀器是PagedAttention这个技术把KV Cache按页来管理就像操作系统管理内存分页一样极大减少了显存碎片让显存利用率能跑到90%以上。传统推理框架处理变长请求时KV Cache要么预分配一大块浪费要么动态增长碎片化vLLM的PagedAttention直接绕开了这个矛盾。实测下来同样的GPUvLLM的吞吐量能比朴素的HuggingFace Transformers实现高出十几倍甚至更多尤其在并发请求多、输入长度差异大的场景下优势极其明显。vLLM的部署也相对简单基本就是一条命令的事pip install vllm 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这里几个参数值得说道说道。--tensor-parallel-size是张量并行度单卡就填1多卡按GPU数量填。--gpu-memory-utilization 0.9表示让vLLM用掉90%的显存留10%给系统和其他进程这个值不要设太满否则容易OOM。--max-model-len是最大上下文长度设得越大KV Cache预留越多能支持的并发就越少需要根据实际业务权衡。vLLM原生支持OpenAI兼容的API接口这意味着你现有的基于OpenAI SDK写的代码改个base_url就能直接对接迁移成本极低。这一点对产品团队特别友好。2.2 TensorRT-LLM极致性能的代价如果你的业务对延迟极其敏感比如要做实时对话、或者单次推理的响应时间必须压到某个阈值以下那TensorRT-LLM值得认真考虑。它是NVIDIA官方出的推理优化框架会把模型编译成针对特定GPU架构优化的TensorRT引擎能榨干硬件的每一分性能。TensorRT-LLM的优势在于极致的低延迟和高吞吐尤其在配合FP8、INT8量化时性能提升非常可观。但它的代价也很明显编译流程复杂、和GPU型号强绑定。你为A100编译的引擎换到H100上就得重新编译甚至驱动版本变了都可能要重来。而且它的模型支持不如vLLM那么即插即用很多新模型需要等官方或社区适配。我的建议是除非你有明确的极致性能需求并且有专人维护否则优先选vLLM。TensorRT-LLM更适合那些已经把推理性能优化到瓶颈、需要再压榨最后一点性能的团队。2.3 llama.cpp与GGUF轻量部署的另一条路前面两个都是面向数据中心GPU的方案但现实中很多场景并不需要那么重的配置。比如内部工具、边缘设备、或者只是想快速验证一个想法这时候llama.cpp配合GGUF格式的模型就非常合适。GGUF是llama.cpp推出的模型格式支持多种量化级别从Q2到Q8量化越狠模型越小、速度越快但质量损失也越大。它的最大优势是CPU也能跑GPU加速可选而且对显存要求极低。一个7B模型量化到Q4大概只要4GB左右一张消费级显卡甚至纯CPU都能带得动。# 用llama.cpp的server模式启动 ./llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf \ -c 4096 \ -ngl 35 \ --host 0.0.0.0 --port 8080-ngl 35表示把35层放到GPU上跑剩下的在CPU上这个数字要根据你的显存大小来调。-c 4096是上下文长度。llama.cpp的server同样提供OpenAI兼容接口对接起来很方便。不过要清醒认识到llama.cpp的吞吐能力跟vLLM不在一个量级它更适合低并发、对成本敏感、或者需要本地化部署的场景。如果你的产品要面向大量用户还是老老实实上vLLM。2.4 框架选型速查表框架核心优势主要短板推荐场景vLLM高吞吐、易部署、生态好极致延迟略逊通用生产环境、高并发TensorRT-LLM极致性能、低延迟编译复杂、绑定硬件延迟敏感、有专人维护llama.cpp轻量、低显存、CPU可跑吞吐低内部工具、边缘、验证SGLang结构化输出强、RadixAttention生态相对新复杂Prompt、多轮对话SGLang这里也提一句它的RadixAttention对多轮对话场景的前缀复用做得很好如果你的产品是聊天机器人形态多轮对话占比高SGLang能省下大量重复计算。选型时值得纳入对比。3. GPU规格与云端实例怎么挑3.1 显存是硬门槛先算清楚再选卡选GPU的第一原则显存决定你能不能跑算力决定你跑多快。很多人选卡时盯着算力参数看结果买回来发现模型根本装不下这是最常见的坑。显存需求怎么估算给你一个粗略但实用的公式推理显存 ≈ 模型参数量 × 精度字节数 × 1.2开销系数 KV Cache以7B模型为例FP16精度下7B × 2字节 × 1.2 ≈ 16.8GB再加上KV Cache。KV Cache的大小跟上下文长度、批大小、层数、隐藏维度都有关粗略估算每1000 token上下文、每路并发大概要几百MB。所以一个7B模型跑FP16、支持8K上下文、并发4路显存需求大概在20GB出头。这就意味着一张24GB的卡比如4090、A10能比较舒服地跑7B FP16但如果你想跑14B甚至32B就得考虑量化或者多卡了。INT8量化能把显存需求砍半INT4再砍半代价是质量有轻微损失但对很多业务来说完全可接受。3.2 主流云端GPU型号对比云端能租到的GPU型号不少我按常见程度和性价比梳理一下GPU型号显存典型用途特点NVIDIA A1024GB7B-13B推理性价比高通用推理NVIDIA L424GB7B-13B推理能效比好支持FP8NVIDIA A10040/80GB13B-70B推理性能强价格高NVIDIA H10080GB70B推理顶级性能价格最贵NVIDIA L40S48GB13B-34B推理显存大性价比不错消费级409024GB7B-13B推理便宜但云端供给少选卡的核心逻辑是匹配你的模型规模和并发需求。7B模型、中等并发A10或L4就够了没必要上A100。13B到34B考虑L40S或A100 40GB。70B级别基本就得A100 80GB或H100而且往往需要多卡张量并行。这里有个容易被忽略的点显存带宽对推理性能的影响往往比算力更大。因为自回归生成是访存密集型的每生成一个token都要读一遍权重。A100的显存带宽是A10的好几倍所以在长文本生成场景下A100的优势会非常明显哪怕算力参数看起来差距没那么大。3.3 多卡并行的两种方式及选择当单卡装不下模型时就得上多卡。多卡并行主要有两种张量并行Tensor Parallelism把每一层的权重切分到多张卡上每张卡算一部分然后通信汇总。这种方式延迟低但卡间通信频繁对带宽要求高一般要求卡在同一节点内、走NVLink或高速PCIe。vLLM的--tensor-parallel-size就是干这个的。流水线并行Pipeline Parallelism把模型的不同层放到不同卡上像流水线一样传递。这种方式通信量小但会有流水线气泡延迟相对高。适合跨节点部署超大模型。实际部署中同节点内优先用张量并行跨节点才考虑流水线并行。vLLM目前对张量并行支持很好流水线并行支持相对有限这也是选型时要考虑的因素。注意多卡并行不是简单的卡越多越快。张量并行的通信开销会随着卡数增加而上升2卡到4卡可能还有明显收益8卡以上收益就递减了。而且多卡实例的价格往往不是线性增长的要算清楚性价比。3.4 云端实例的隐藏成本租GPU实例时有几个隐藏成本容易被忽略存储成本模型文件动辄几十GB云盘存储是要单独计费的而且模型加载时从云盘读取的速度会影响冷启动时间。网络成本如果推理服务要和其它服务通信跨可用区的流量是要收费的。闲置成本GPU实例按小时计费但你的流量不可能24小时满负荷闲置时段就是在烧钱。这也是为什么自动扩缩容很重要。快照和镜像成本为了快速恢复你可能会做实例快照这些也是要占存储的。我踩过的一个坑是模型文件放在普通云盘上每次实例重启加载模型要等好几分钟后来换成高性能云盘加载时间直接砍半。如果你的服务需要频繁扩缩容模型加载速度直接决定了扩容的响应时间这个钱不能省。4. 从零搭建一套云端推理服务的完整流程4.1 环境准备与依赖安装假设我们选定了vLLM A10实例的方案从一台干净的GPU云服务器开始。第一步是确认驱动和CUDA环境。# 查看GPU信息 nvidia-smi # 查看CUDA版本 nvcc --versionvLLM对CUDA版本有要求一般需要CUDA 11.8以上。如果驱动太旧需要先升级驱动。这里有个经验云厂商提供的GPU镜像通常已经预装了合适的驱动和CUDA直接用官方镜像能省掉大量兼容性折腾。自己从裸系统装驱动很容易遇到版本冲突。接下来装Python环境和vLLM# 建议用conda隔离环境 conda create -n vllm python3.10 -y conda activate vllm # 安装vLLM pip install vllm如果你的模型在HuggingFace上还需要配置模型下载。国内环境下载大模型文件可能比较慢可以提前用工具把模型拉到本地或者对象存储再挂载到实例上。这一步的优化对冷启动速度影响很大。4.2 模型加载与显存参数调优启动vLLM服务时参数调优是核心。除了前面提到的--gpu-memory-utilization和--max-model-len还有几个关键参数python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 32 \ --dtype auto \ --quantization awq--max-num-seqs控制同时处理的最大请求数这个值直接影响吞吐和延迟的平衡。设大了吞吐高但单请求延迟可能上升设小了延迟低但吞吐上不去。一般从16到64之间调根据实际压测结果定。--quantization awq表示用AWQ量化如果你用的是量化模型就加上用原始FP16模型就不加。量化能显著降低显存占用让同样的卡能跑更大的模型或更高的并发。--dtype auto让vLLM自动判断精度一般不用手动指定。启动后vLLM会打印显存分配情况和模型加载进度。第一次启动会比较慢因为要加载权重、初始化KV Cache。如果显存不够它会直接报OOM这时候就要降低--gpu-memory-utilization或者--max-model-len或者换量化模型。4.3 服务暴露与流式输出对接vLLM默认在8000端口提供OpenAI兼容API。生产环境一般不会直接暴露这个端口而是前面挂一层网关比如Nginx做鉴权、限流、负载均衡。流式输出是大模型产品的标配体验用户不希望等整个回答生成完才看到内容。vLLM原生支持SSE流式输出客户端只要在请求里带上stream: true就行from openai import OpenAI client OpenAI( base_urlhttp://your-server:8000/v1, api_keyyour-key ) response client.chat.completions.create( modelmy-model, messages[{role: user, content: 介绍一下大模型推理}], streamTrue ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)前端对接时用EventSource或者fetch的ReadableStream来接收SSE数据逐块渲染。这里有个细节要处理用户中途取消请求的情况前端abort之后后端也要能感知并停止生成否则GPU还在白白计算。vLLM支持请求取消但需要你的网关层正确传递取消信号。4.4 自动扩缩容与成本控制流量不可能一直平稳所以自动扩缩容是生产环境的必备能力。核心思路是根据GPU利用率和请求队列长度来触发扩缩容。具体做法上可以监控vLLM暴露的metrics它内置了Prometheus指标当请求排队数持续超过阈值、或者GPU利用率持续高位时就增加实例反之则减少。云厂商的弹性伸缩组一般支持基于自定义指标来扩缩容。成本控制方面几个实用手段用竞价实例跑非核心流量竞价实例价格便宜很多但可能被回收适合能容忍中断的批处理任务。错峰调度如果业务有明显的流量波峰波谷可以在低谷期缩容到最小实例数。量化换成本INT8或INT4量化能让同样的卡跑更多并发等于变相降本。共享实例多个小模型共享一张卡用vLLM的多模型支持或者多个进程分时复用。我实测下来一个7B模型、中等流量的产品用A10实例配合自动扩缩容月成本能控制在比较合理的范围。关键是要把扩缩容的触发阈值调准扩得太激进浪费钱扩得太慢用户等得急。5. 常见问题排查与避坑经验5.1 显存相关的典型问题问题一启动就OOM。这是最常见的。原因通常是--gpu-memory-utilization设太高或者--max-model-len设太大导致KV Cache预留过多。解决办法是先把这两个值调低跑起来之后再逐步往上加找到稳定运行的临界点。问题二跑一段时间后OOM。这通常是KV Cache随着并发请求增长而耗尽。vLLM有抢占机制显存不够时会抢占低优先级请求但如果抢占太频繁性能会急剧下降。这时候要么降低--max-num-seqs要么降低--max-model-len要么加卡。问题三显存碎片化。虽然vLLM的PagedAttention已经大幅缓解了碎片问题但长时间运行后仍可能有碎片。定期重启服务是个简单有效的办法或者用vLLM的显存分析工具排查。5.2 性能不达预期的排查思路性能问题排查我一般按这个顺序来先看GPU利用率。如果利用率很低说明瓶颈不在GPU可能在CPU预处理、网络传输或者调度上。看显存带宽。自回归生成是访存密集型的如果显存带宽跑满了说明已经到硬件极限只能换更好的卡或者量化。看批处理效率。vLLM的连续批处理continuous batching是吞吐的关键如果批大小一直上不去检查是不是请求太稀疏或者--max-num-seqs设太小。看输入输出长度分布。如果大量请求是超长输入prefill阶段会占用大量时间可以考虑用chunked prefill来优化。5.3 常见问题速查表现象可能原因排查方向解决手段启动OOM显存参数设太高看启动日志降gpu-memory-utilization运行中OOMKV Cache耗尽看并发和上下文降max-num-seqs或加卡延迟高批处理效率低看GPU利用率调max-num-seqs吞吐低请求太稀疏看请求间隔合并请求或调调度首token慢prefill耗时长看输入长度用chunked prefill输出乱码模型或tokenizer问题看模型加载检查模型文件完整性5.4 几个血泪教训教训一不要在生产环境用latest标签的镜像。我有次图省事用了vLLM的latest镜像结果某天自动更新后行为变了服务直接出问题。生产环境一定要锁定版本号。教训二模型文件一定要做校验。下载大模型文件时网络中断导致文件损坏是常有的事加载时报的错往往很隐晦。下载完用哈希校验一下能省掉大量排查时间。教训三压测要用真实流量分布。用固定长度的请求压测结果和真实场景差很远。真实用户的输入长度是长尾分布的一定要用接近真实的分布来压测否则上线后性能会打脸。教训四日志要打全但别打太多。推理服务的日志量很大全量打会拖慢性能还占存储。关键是要记录每个请求的输入输出长度、耗时、是否被抢占这些是排查问题的核心信息。教训五监控GPU温度。云端GPU实例如果散热有问题温度过高会触发降频性能莫名其妙下降。这个坑比较隐蔽但监控加上温度指标就能提前发现。6. 不同业务场景的方案组合建议6.1 面向C端的对话产品这类产品流量大、并发高、对延迟敏感推荐vLLM A10/L4实例 自动扩缩容的组合。模型用7B到13B级别配合INT8量化控制成本。前端用SSE流式输出保证体验。网关层做好限流和鉴权防止被刷。如果对话轮次多可以考虑SGLang它的前缀复用能省下大量重复计算。如果延迟要求极致再考虑TensorRT-LLM。6.2 面向B端的文档处理这类场景输入长、并发低、对吞吐要求不高但对准确性要求高。推荐vLLM L40S/A100实例模型可以用14B到34B上下文长度开到32K甚至更长。因为输入长prefill是瓶颈chunked prefill和前缀缓存能帮上大忙。6.3 内部工具与验证场景这类场景流量小、成本敏感、不需要高可用。推荐llama.cpp 消费级GPU或纯CPU模型量化到Q4一张4090甚至纯CPU就能跑。部署简单维护成本低适合快速验证想法。6.4 超大规模模型部署70B以上的模型单卡装不下需要多卡张量并行。推荐vLLM A100 80GB/H100多卡实例配合FP8量化。这种配置成本很高一定要做好流量预测和成本核算避免资源浪费。提示方案组合没有标准答案核心是匹配你的业务特点。流量大就优先吞吐延迟敏感就优先响应速度成本敏感就优先量化和小卡。先明确约束条件再选方案不要反过来。7. 我个人的一些实操体会折腾了这么多套推理部署最大的体会是部署方案的复杂度要和团队能力匹配。见过太多团队盲目追求先进方案上了TensorRT-LLM或者复杂的多卡并行结果没人维护得动出问题排查半天最后还不如老老实实用vLLM单卡跑得稳。另一个体会是量化是性价比最高的优化手段。很多团队一上来就想加卡其实先把模型量化到INT8显存直接砍半同样的卡能跑双倍并发成本立竿见影地降下来。质量损失在大多数业务场景下用户根本感知不到。当然量化前一定要做效果评估有些对精度敏感的任务比如代码生成、数学推理量化后质量下降会比较明显。还有一点冷启动速度经常被低估。Serverless推理和自动扩缩容场景下冷启动时间直接决定用户体验。优化冷启动的关键是加快模型加载把模型放在高性能存储上、用更快的加载方式、甚至预热常驻实例这些投入都是值得的。最后分享一个小技巧用vLLM的--enable-prefix-caching开启前缀缓存。如果你的产品有大量系统提示词system prompt是固定的这个功能能把系统提示词的计算结果缓存下来后续请求直接复用能省下可观的prefill时间。这个开关默认可能是关的记得手动打开。推理部署这个领域变化很快新的框架、新的优化技术层出不穷。但底层的逻辑是不变的搞清楚你的瓶颈在哪是显存、是带宽、还是调度然后针对性地选方案。把这一层想透了具体用哪个框架、哪家云都是可以灵活调整的。 大模型推理部署实战：vLLM、GPU选型与云端方案全解析
1. 大模型推理部署的现状与选型逻辑1.1 为什么GPU推理部署成了绕不开的坎这两年跟不少团队聊下来一个共同的感受是模型训练那关过了真正让人头疼的反而是在线推理部署。训练可以慢慢调、可以排队跑但推理是面向真实用户的延迟高一点、吞吐低一点用户体验和成本账单立刻就会给你脸色看。大模型和生成式AI产品的推理负载有几个很鲜明的特点。第一是显存饥渴一个7B参数的模型FP16精度下光权重就要占掉大约14GB显存再加上KV Cache、中间激活值实际占用往往要奔着18到20GB去。第二是计算密集但访存更密集自回归生成是一个token一个token往外蹦的每生成一个token都要把整个模型权重过一遍所以推理性能往往卡在显存带宽上而不是纯算力上。第三是请求长度差异极大有的用户就问一句话有的用户贴进来一整篇文档这种变长输入对批处理调度提出了很高要求。正是这些特点决定了GPU推理部署不能简单地买张卡、装个环境、跑起来就完事。你需要考虑用什么样的推理引擎、选什么样的GPU规格、走云端还是本地、成本怎么控制、并发上来之后怎么扩缩容。这一整套问题就是本文要拆解的核心。1.2 云端推理方案到底在解决什么问题先把问题定义清楚。所谓云端GPU推理方案本质上是在回答三个层面的问题算力从哪来是租用云厂商的GPU实例还是用Serverless形态的按需调用还是自建机房。推理怎么跑用什么推理框架vLLM、TensorRT-LLM、llama.cpp、SGLang等怎么做量化怎么管理KV Cache。服务怎么交付怎么暴露API、怎么做流式输出、怎么做并发调度和自动扩缩容。这三个层面是层层递进的。很多人一上来就纠结选哪家云其实更合理的顺序是先想清楚推理框架和服务架构再反过来决定算力形态。因为不同的推理框架对GPU型号、显存、驱动版本的要求差别很大选错了框架后面换云就是大工程。我个人的经验是选型时按这个优先级来排推理框架 GPU规格 云厂商 计费模式。框架决定了你的性能上限和迁移成本GPU规格决定了你能不能跑得动云厂商更多是价格和稳定性的差异计费模式则是最后优化成本的手段。1.3 三类主流云端推理形态的取舍目前市面上能落地的云端GPU推理方案大致可以归为三类各有各的适用场景。第一类GPU云服务器IaaS。就是租一台带GPU的虚拟机你自己装驱动、装推理框架、部署服务。代表形态就是各家云厂商的GPU实例。这种方案控制力最强什么都能自己调适合对性能有极致要求、或者需要跑自定义模型的团队。缺点是运维成本高你得自己处理扩缩容、故障恢复、驱动兼容这些琐事。第二类容器化推理服务PaaS。云厂商或第三方平台提供预置了推理框架的容器镜像你把自己的模型挂上去就能跑平台帮你处理调度和扩缩容。这种方案在灵活性和省心之间取了个平衡适合大多数中小团队。第三类Serverless推理FaaS形态。你只管调用API底层GPU资源完全由平台管理按实际调用量计费。这种方案最省心冷启动是主要痛点适合流量波动大、或者刚起步验证产品的场景。下面这张表可以帮你快速定位自己该往哪个方向走方案形态控制力运维成本成本模型适用场景GPU云服务器最强最高按实例时长高性能要求、自定义模型、稳定流量容器化推理服务中等中等按实例调用大多数生产场景Serverless推理最弱最低按调用量流量波动大、快速验证提示不要一上来就追求最省钱的方案。推理部署的第一优先级永远是跑得稳、延迟可控成本优化是稳定之后再做的事。我见过太多团队为了省一点GPU钱选了不合适的方案结果线上频繁超时最后返工的成本远超省下的钱。2. 推理框架选型决定性能上限的关键一步2.1 vLLM高吞吐场景的默认答案如果只能推荐一个通用的大模型推理框架我会毫不犹豫地说vLLM。它的核心杀器是PagedAttention这个技术把KV Cache按页来管理就像操作系统管理内存分页一样极大减少了显存碎片让显存利用率能跑到90%以上。传统推理框架处理变长请求时KV Cache要么预分配一大块浪费要么动态增长碎片化vLLM的PagedAttention直接绕开了这个矛盾。实测下来同样的GPUvLLM的吞吐量能比朴素的HuggingFace Transformers实现高出十几倍甚至更多尤其在并发请求多、输入长度差异大的场景下优势极其明显。vLLM的部署也相对简单基本就是一条命令的事pip install vllm 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这里几个参数值得说道说道。--tensor-parallel-size是张量并行度单卡就填1多卡按GPU数量填。--gpu-memory-utilization 0.9表示让vLLM用掉90%的显存留10%给系统和其他进程这个值不要设太满否则容易OOM。--max-model-len是最大上下文长度设得越大KV Cache预留越多能支持的并发就越少需要根据实际业务权衡。vLLM原生支持OpenAI兼容的API接口这意味着你现有的基于OpenAI SDK写的代码改个base_url就能直接对接迁移成本极低。这一点对产品团队特别友好。2.2 TensorRT-LLM极致性能的代价如果你的业务对延迟极其敏感比如要做实时对话、或者单次推理的响应时间必须压到某个阈值以下那TensorRT-LLM值得认真考虑。它是NVIDIA官方出的推理优化框架会把模型编译成针对特定GPU架构优化的TensorRT引擎能榨干硬件的每一分性能。TensorRT-LLM的优势在于极致的低延迟和高吞吐尤其在配合FP8、INT8量化时性能提升非常可观。但它的代价也很明显编译流程复杂、和GPU型号强绑定。你为A100编译的引擎换到H100上就得重新编译甚至驱动版本变了都可能要重来。而且它的模型支持不如vLLM那么即插即用很多新模型需要等官方或社区适配。我的建议是除非你有明确的极致性能需求并且有专人维护否则优先选vLLM。TensorRT-LLM更适合那些已经把推理性能优化到瓶颈、需要再压榨最后一点性能的团队。2.3 llama.cpp与GGUF轻量部署的另一条路前面两个都是面向数据中心GPU的方案但现实中很多场景并不需要那么重的配置。比如内部工具、边缘设备、或者只是想快速验证一个想法这时候llama.cpp配合GGUF格式的模型就非常合适。GGUF是llama.cpp推出的模型格式支持多种量化级别从Q2到Q8量化越狠模型越小、速度越快但质量损失也越大。它的最大优势是CPU也能跑GPU加速可选而且对显存要求极低。一个7B模型量化到Q4大概只要4GB左右一张消费级显卡甚至纯CPU都能带得动。# 用llama.cpp的server模式启动 ./llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf \ -c 4096 \ -ngl 35 \ --host 0.0.0.0 --port 8080-ngl 35表示把35层放到GPU上跑剩下的在CPU上这个数字要根据你的显存大小来调。-c 4096是上下文长度。llama.cpp的server同样提供OpenAI兼容接口对接起来很方便。不过要清醒认识到llama.cpp的吞吐能力跟vLLM不在一个量级它更适合低并发、对成本敏感、或者需要本地化部署的场景。如果你的产品要面向大量用户还是老老实实上vLLM。2.4 框架选型速查表框架核心优势主要短板推荐场景vLLM高吞吐、易部署、生态好极致延迟略逊通用生产环境、高并发TensorRT-LLM极致性能、低延迟编译复杂、绑定硬件延迟敏感、有专人维护llama.cpp轻量、低显存、CPU可跑吞吐低内部工具、边缘、验证SGLang结构化输出强、RadixAttention生态相对新复杂Prompt、多轮对话SGLang这里也提一句它的RadixAttention对多轮对话场景的前缀复用做得很好如果你的产品是聊天机器人形态多轮对话占比高SGLang能省下大量重复计算。选型时值得纳入对比。3. GPU规格与云端实例怎么挑3.1 显存是硬门槛先算清楚再选卡选GPU的第一原则显存决定你能不能跑算力决定你跑多快。很多人选卡时盯着算力参数看结果买回来发现模型根本装不下这是最常见的坑。显存需求怎么估算给你一个粗略但实用的公式推理显存 ≈ 模型参数量 × 精度字节数 × 1.2开销系数 KV Cache以7B模型为例FP16精度下7B × 2字节 × 1.2 ≈ 16.8GB再加上KV Cache。KV Cache的大小跟上下文长度、批大小、层数、隐藏维度都有关粗略估算每1000 token上下文、每路并发大概要几百MB。所以一个7B模型跑FP16、支持8K上下文、并发4路显存需求大概在20GB出头。这就意味着一张24GB的卡比如4090、A10能比较舒服地跑7B FP16但如果你想跑14B甚至32B就得考虑量化或者多卡了。INT8量化能把显存需求砍半INT4再砍半代价是质量有轻微损失但对很多业务来说完全可接受。3.2 主流云端GPU型号对比云端能租到的GPU型号不少我按常见程度和性价比梳理一下GPU型号显存典型用途特点NVIDIA A1024GB7B-13B推理性价比高通用推理NVIDIA L424GB7B-13B推理能效比好支持FP8NVIDIA A10040/80GB13B-70B推理性能强价格高NVIDIA H10080GB70B推理顶级性能价格最贵NVIDIA L40S48GB13B-34B推理显存大性价比不错消费级409024GB7B-13B推理便宜但云端供给少选卡的核心逻辑是匹配你的模型规模和并发需求。7B模型、中等并发A10或L4就够了没必要上A100。13B到34B考虑L40S或A100 40GB。70B级别基本就得A100 80GB或H100而且往往需要多卡张量并行。这里有个容易被忽略的点显存带宽对推理性能的影响往往比算力更大。因为自回归生成是访存密集型的每生成一个token都要读一遍权重。A100的显存带宽是A10的好几倍所以在长文本生成场景下A100的优势会非常明显哪怕算力参数看起来差距没那么大。3.3 多卡并行的两种方式及选择当单卡装不下模型时就得上多卡。多卡并行主要有两种张量并行Tensor Parallelism把每一层的权重切分到多张卡上每张卡算一部分然后通信汇总。这种方式延迟低但卡间通信频繁对带宽要求高一般要求卡在同一节点内、走NVLink或高速PCIe。vLLM的--tensor-parallel-size就是干这个的。流水线并行Pipeline Parallelism把模型的不同层放到不同卡上像流水线一样传递。这种方式通信量小但会有流水线气泡延迟相对高。适合跨节点部署超大模型。实际部署中同节点内优先用张量并行跨节点才考虑流水线并行。vLLM目前对张量并行支持很好流水线并行支持相对有限这也是选型时要考虑的因素。注意多卡并行不是简单的卡越多越快。张量并行的通信开销会随着卡数增加而上升2卡到4卡可能还有明显收益8卡以上收益就递减了。而且多卡实例的价格往往不是线性增长的要算清楚性价比。3.4 云端实例的隐藏成本租GPU实例时有几个隐藏成本容易被忽略存储成本模型文件动辄几十GB云盘存储是要单独计费的而且模型加载时从云盘读取的速度会影响冷启动时间。网络成本如果推理服务要和其它服务通信跨可用区的流量是要收费的。闲置成本GPU实例按小时计费但你的流量不可能24小时满负荷闲置时段就是在烧钱。这也是为什么自动扩缩容很重要。快照和镜像成本为了快速恢复你可能会做实例快照这些也是要占存储的。我踩过的一个坑是模型文件放在普通云盘上每次实例重启加载模型要等好几分钟后来换成高性能云盘加载时间直接砍半。如果你的服务需要频繁扩缩容模型加载速度直接决定了扩容的响应时间这个钱不能省。4. 从零搭建一套云端推理服务的完整流程4.1 环境准备与依赖安装假设我们选定了vLLM A10实例的方案从一台干净的GPU云服务器开始。第一步是确认驱动和CUDA环境。# 查看GPU信息 nvidia-smi # 查看CUDA版本 nvcc --versionvLLM对CUDA版本有要求一般需要CUDA 11.8以上。如果驱动太旧需要先升级驱动。这里有个经验云厂商提供的GPU镜像通常已经预装了合适的驱动和CUDA直接用官方镜像能省掉大量兼容性折腾。自己从裸系统装驱动很容易遇到版本冲突。接下来装Python环境和vLLM# 建议用conda隔离环境 conda create -n vllm python3.10 -y conda activate vllm # 安装vLLM pip install vllm如果你的模型在HuggingFace上还需要配置模型下载。国内环境下载大模型文件可能比较慢可以提前用工具把模型拉到本地或者对象存储再挂载到实例上。这一步的优化对冷启动速度影响很大。4.2 模型加载与显存参数调优启动vLLM服务时参数调优是核心。除了前面提到的--gpu-memory-utilization和--max-model-len还有几个关键参数python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 32 \ --dtype auto \ --quantization awq--max-num-seqs控制同时处理的最大请求数这个值直接影响吞吐和延迟的平衡。设大了吞吐高但单请求延迟可能上升设小了延迟低但吞吐上不去。一般从16到64之间调根据实际压测结果定。--quantization awq表示用AWQ量化如果你用的是量化模型就加上用原始FP16模型就不加。量化能显著降低显存占用让同样的卡能跑更大的模型或更高的并发。--dtype auto让vLLM自动判断精度一般不用手动指定。启动后vLLM会打印显存分配情况和模型加载进度。第一次启动会比较慢因为要加载权重、初始化KV Cache。如果显存不够它会直接报OOM这时候就要降低--gpu-memory-utilization或者--max-model-len或者换量化模型。4.3 服务暴露与流式输出对接vLLM默认在8000端口提供OpenAI兼容API。生产环境一般不会直接暴露这个端口而是前面挂一层网关比如Nginx做鉴权、限流、负载均衡。流式输出是大模型产品的标配体验用户不希望等整个回答生成完才看到内容。vLLM原生支持SSE流式输出客户端只要在请求里带上stream: true就行from openai import OpenAI client OpenAI( base_urlhttp://your-server:8000/v1, api_keyyour-key ) response client.chat.completions.create( modelmy-model, messages[{role: user, content: 介绍一下大模型推理}], streamTrue ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)前端对接时用EventSource或者fetch的ReadableStream来接收SSE数据逐块渲染。这里有个细节要处理用户中途取消请求的情况前端abort之后后端也要能感知并停止生成否则GPU还在白白计算。vLLM支持请求取消但需要你的网关层正确传递取消信号。4.4 自动扩缩容与成本控制流量不可能一直平稳所以自动扩缩容是生产环境的必备能力。核心思路是根据GPU利用率和请求队列长度来触发扩缩容。具体做法上可以监控vLLM暴露的metrics它内置了Prometheus指标当请求排队数持续超过阈值、或者GPU利用率持续高位时就增加实例反之则减少。云厂商的弹性伸缩组一般支持基于自定义指标来扩缩容。成本控制方面几个实用手段用竞价实例跑非核心流量竞价实例价格便宜很多但可能被回收适合能容忍中断的批处理任务。错峰调度如果业务有明显的流量波峰波谷可以在低谷期缩容到最小实例数。量化换成本INT8或INT4量化能让同样的卡跑更多并发等于变相降本。共享实例多个小模型共享一张卡用vLLM的多模型支持或者多个进程分时复用。我实测下来一个7B模型、中等流量的产品用A10实例配合自动扩缩容月成本能控制在比较合理的范围。关键是要把扩缩容的触发阈值调准扩得太激进浪费钱扩得太慢用户等得急。5. 常见问题排查与避坑经验5.1 显存相关的典型问题问题一启动就OOM。这是最常见的。原因通常是--gpu-memory-utilization设太高或者--max-model-len设太大导致KV Cache预留过多。解决办法是先把这两个值调低跑起来之后再逐步往上加找到稳定运行的临界点。问题二跑一段时间后OOM。这通常是KV Cache随着并发请求增长而耗尽。vLLM有抢占机制显存不够时会抢占低优先级请求但如果抢占太频繁性能会急剧下降。这时候要么降低--max-num-seqs要么降低--max-model-len要么加卡。问题三显存碎片化。虽然vLLM的PagedAttention已经大幅缓解了碎片问题但长时间运行后仍可能有碎片。定期重启服务是个简单有效的办法或者用vLLM的显存分析工具排查。5.2 性能不达预期的排查思路性能问题排查我一般按这个顺序来先看GPU利用率。如果利用率很低说明瓶颈不在GPU可能在CPU预处理、网络传输或者调度上。看显存带宽。自回归生成是访存密集型的如果显存带宽跑满了说明已经到硬件极限只能换更好的卡或者量化。看批处理效率。vLLM的连续批处理continuous batching是吞吐的关键如果批大小一直上不去检查是不是请求太稀疏或者--max-num-seqs设太小。看输入输出长度分布。如果大量请求是超长输入prefill阶段会占用大量时间可以考虑用chunked prefill来优化。5.3 常见问题速查表现象可能原因排查方向解决手段启动OOM显存参数设太高看启动日志降gpu-memory-utilization运行中OOMKV Cache耗尽看并发和上下文降max-num-seqs或加卡延迟高批处理效率低看GPU利用率调max-num-seqs吞吐低请求太稀疏看请求间隔合并请求或调调度首token慢prefill耗时长看输入长度用chunked prefill输出乱码模型或tokenizer问题看模型加载检查模型文件完整性5.4 几个血泪教训教训一不要在生产环境用latest标签的镜像。我有次图省事用了vLLM的latest镜像结果某天自动更新后行为变了服务直接出问题。生产环境一定要锁定版本号。教训二模型文件一定要做校验。下载大模型文件时网络中断导致文件损坏是常有的事加载时报的错往往很隐晦。下载完用哈希校验一下能省掉大量排查时间。教训三压测要用真实流量分布。用固定长度的请求压测结果和真实场景差很远。真实用户的输入长度是长尾分布的一定要用接近真实的分布来压测否则上线后性能会打脸。教训四日志要打全但别打太多。推理服务的日志量很大全量打会拖慢性能还占存储。关键是要记录每个请求的输入输出长度、耗时、是否被抢占这些是排查问题的核心信息。教训五监控GPU温度。云端GPU实例如果散热有问题温度过高会触发降频性能莫名其妙下降。这个坑比较隐蔽但监控加上温度指标就能提前发现。6. 不同业务场景的方案组合建议6.1 面向C端的对话产品这类产品流量大、并发高、对延迟敏感推荐vLLM A10/L4实例 自动扩缩容的组合。模型用7B到13B级别配合INT8量化控制成本。前端用SSE流式输出保证体验。网关层做好限流和鉴权防止被刷。如果对话轮次多可以考虑SGLang它的前缀复用能省下大量重复计算。如果延迟要求极致再考虑TensorRT-LLM。6.2 面向B端的文档处理这类场景输入长、并发低、对吞吐要求不高但对准确性要求高。推荐vLLM L40S/A100实例模型可以用14B到34B上下文长度开到32K甚至更长。因为输入长prefill是瓶颈chunked prefill和前缀缓存能帮上大忙。6.3 内部工具与验证场景这类场景流量小、成本敏感、不需要高可用。推荐llama.cpp 消费级GPU或纯CPU模型量化到Q4一张4090甚至纯CPU就能跑。部署简单维护成本低适合快速验证想法。6.4 超大规模模型部署70B以上的模型单卡装不下需要多卡张量并行。推荐vLLM A100 80GB/H100多卡实例配合FP8量化。这种配置成本很高一定要做好流量预测和成本核算避免资源浪费。提示方案组合没有标准答案核心是匹配你的业务特点。流量大就优先吞吐延迟敏感就优先响应速度成本敏感就优先量化和小卡。先明确约束条件再选方案不要反过来。7. 我个人的一些实操体会折腾了这么多套推理部署最大的体会是部署方案的复杂度要和团队能力匹配。见过太多团队盲目追求先进方案上了TensorRT-LLM或者复杂的多卡并行结果没人维护得动出问题排查半天最后还不如老老实实用vLLM单卡跑得稳。另一个体会是量化是性价比最高的优化手段。很多团队一上来就想加卡其实先把模型量化到INT8显存直接砍半同样的卡能跑双倍并发成本立竿见影地降下来。质量损失在大多数业务场景下用户根本感知不到。当然量化前一定要做效果评估有些对精度敏感的任务比如代码生成、数学推理量化后质量下降会比较明显。还有一点冷启动速度经常被低估。Serverless推理和自动扩缩容场景下冷启动时间直接决定用户体验。优化冷启动的关键是加快模型加载把模型放在高性能存储上、用更快的加载方式、甚至预热常驻实例这些投入都是值得的。最后分享一个小技巧用vLLM的--enable-prefix-caching开启前缀缓存。如果你的产品有大量系统提示词system prompt是固定的这个功能能把系统提示词的计算结果缓存下来后续请求直接复用能省下可观的prefill时间。这个开关默认可能是关的记得手动打开。推理部署这个领域变化很快新的框架、新的优化技术层出不穷。但底层的逻辑是不变的搞清楚你的瓶颈在哪是显存、是带宽、还是调度然后针对性地选方案。把这一层想透了具体用哪个框架、哪家云都是可以灵活调整的。