部署大模型服务这件事这两年看着热闹真上手的人都知道坑全在细节里。团队拿到一台8卡机器或者准备开一组云GPU第一反应往往是“赶紧把模型跑起来”但跑起来和稳定服务是两码事。我自己踩过一轮之后最大的体会是部署的本质不是加载模型而是让它在持续的并发请求下保持稳定、可控、可观测地运行一整年。这篇文章我打算按照自己实际调研和上线的路径来写——先讲怎么根据业务负载反推硬件和模型配置再对比主流推理框架的取舍然后是云服务选型的真实成本账最后给出一条可以照着做的生产级部署流程以及几个我翻过车的配置项。适合刚接触大模型部署的工程师、准备做私有化交付的小团队也适合那些在云GPU和自建机房之间犹豫的负责人。1. 先想清楚你的负载长什么样再谈部署很多人上来就问“用哪个框架”“租哪家GPU”我建议先停一下。部署方案百分之八十取决于你的流量形态剩下的才是框架和硬件。同样是7B模型做一个企业内部问答机器人和做一个对外API服务架构上完全不是一个量级。1.1 在线问答和离线批处理部署思路完全不同在线问答场景用户发一条消息模型要在2到3秒内开始吐字这要求模型常驻显存并且推理引擎要在极低延迟下处理并发。这个场景最怕的是排队一旦请求堆积P95延迟会瞬间失控用户感觉就是“卡死了”。离线批处理则相反比如批量给几万条文本打标签、批量生成摘要。这种负载不要求单条多快但要求总吞吐量尽量高。你可以把请求压得很满就算单条要跑20秒也无所谓只要每小时能处理完足够多的样本就行。还有一个被低估的场景是流式交互也就是SSE式的一边生成一边输出。它对网络链路和推理框架的增量解码能力有额外要求但很多基础性能对比文章根本没提这一层。如果你要做聊天机器人选框架之前必须先确认它对流式输出支持得好不好。我的建议是先写清楚你的场景占哪一类再往下走。混合负载也不是不行但对框架调优的要求会高很多初期不建议这么干。1.2 用一张显存公式提前算明白要租多大的机器模型部署第一个硬约束是显存。很多人直接看“模型参数量对应多少GB”这其实只算了一半。推理时显存占用大致是下面三块的加总模型权重以7B模型FP16为例大约是14GB70亿参数 × 2字节。KV Cache这部分随并发数和上下文长度线性增长往往是最大的变量。激活值和中间状态Batch Size越大占得越多但在推理框架里通常比前两块小。KV Cache的计算公式不复杂KV显存 ≈ 层数 × 键值头数 × 头维度 × 2K和V × 序列长度 × 精度字节数 × 当前并发数。我知道这么说有点抽象举一个具体例子。用7B规模、约32层、GQA分组查询注意力配置的模型假设KV Cache每个Token大概占用0.5MB左右如果每个请求上下文4000 Token并发32个请求那KV Cache大约就是0.5MB × 4000 × 32 ≈ 64GB。加上权重14GB这就已经接近单张80GB显存卡的上限了。这就是为什么我坚持让团队先算再买卡。你以为7B模型一张A100/80G跑三个并发没问题实际上一算可能只能跑十几个并发根本撑不起生产流量。2026年前后的主流做法是把上下文窗口做大这直接推高了KV Cache的显存占比所以KV Cache的量化技术比如KV8、KV4已经成了标配这点后面聊框架的时候还会提到。1.3 量化不是省显存的小技巧是部署方案的默认项现在做生产部署基本不会再有人跑纯FP16了。FP8、INT8、INT4量化已经是默认操作原因很简单量化直接决定你能塞进一张卡里的并发数也就决定了你的单位推理成本。FP8是目前最稳妥的选择精度损失极小显存直接减半而且主流框架和加速卡支持都很成熟。INT4能把7B模型压到4GB以内但需要用AWQ或GPTQ这类算法做校准低比特下对敏感任务比如数学推理、代码生成的输出质量会有可感知的下降。我的经验是通用对话、摘要、分类任务FP8完全可以闭眼用数学和代码类场景先拿评测集做AB对比再决定要不要降比特。2. 推理框架地图vLLM、TGI、SGLang、TensorRT-LLM各自解决什么问题框架选型是所有人问得最多的但也是最不需要纠结的。如果你没有特殊理由vLLM就是默认答案。它生态成熟、文档全、社区活跃度最高遇到问题基本都能搜到解决方案。这话我先放这儿再讲清楚为什么。2.1 vLLM为什么能成为默认选项vLLM的核心是PagedAttention和Continuous Batching。这两件事解决的都是同一个问题如何让GPU在并发请求下不闲着。PagedAttention借鉴了操作系统虚拟内存的思路把KV Cache切成固定大小的块按需分配显存碎片少利用率自然高。Continuous Batching则是把不同请求的动态计算过程拼在一起推进前一个请求生成完了新的请求立刻顶上GPU的利用率能拉到很高。这两项技术在2026年已经被所有主流框架吸收了但vLLM是第一个把它们做成成熟产品的这个先发优势非常明显。实操层面vLLM支持OpenAI兼容的接口这意味着你代码里所有按OpenAI格式写的客户端改个BaseUrl就能切过来。这个兼容性帮我省掉了大量适配工作。生产部署时它的监控指标也比较全可以通过Prometheus暴露TTFT、TPOT、吞吐等关键指标后面做告警直接能用。2.2 TGI和SGLang什么情况下值得选TGI是Hugging Face家的推理服务器。它的优势在于和Transformers生态天然一体新增模型架构的支持速度非常快。如果你用的是比较新的模型发布当天就想要官方支持TGI往往是最先跟上的。我们之前测过一批刚开源的模型TGI的兼容性确实比vLLM还早一步。缺点是它在极低延迟场景下的调度灵活性不如vLLM吞吐上在部分模型上会略低一点。SGLang则是一个强调性能上限的后起之秀。它引入了RadixAttention这个技术会缓存公共前缀的KV在多轮对话、Agent场景里因为每轮都会带上历史上下文公共前缀命中率很高SGLang可以省掉大量重复计算。如果你做的是长上下文、多轮对话密集的产品SGLang在吞吐上的优势是能测出来的。我自己在Agent类应用上做过对比同样并发下SGLang的吞吐确实显著高出一截。TGI适合追新模型、和HF生态强绑定的团队SGLang适合对吞吐有极致要求、且请求中重复前缀很多的场景。除此之外老老实实vLLM。2.3 不要忽视TensorRT-LLM这类专有栈如果说上面几个框架是用灵活换性能TensorRT-LLM就是纯粹的为性能而生。它需要把模型编译成TensorRT引擎针对特定GPU架构做极致优化吞吐和延迟都能压到很低。代价是编译流程重、模型迭代一次要重新编译、GPU型号一变又要重新编译。它适合什么场景模型基本冻结、长期不变、GPU型号固定的对外服务。这种场景下TensorRT-LLM的收益非常实在单卡能比通用框架多扛出不少并发。我的建议是前期不要用它做原型验证除非你团队里有专门的推理优化工程师否则调试成本会吃掉你省下来的那部分性能红利。这里还应该提一个不在对比表里的选项——Ollama。它是定位个人电脑和开发机的轻量工具胜在安装即用、环境零配置。但生产环境真的不建议它在大并发下的稳定性和指标暴露都撑不住我见过几个团队图省事把Ollama直接当生产服务用的上线一周就换回vLLM了。2.4 框架选型速查表框架最佳场景最大优点主要代价vLLM默认首选、通用生产服务生态成熟、OpenAI兼容、指标全部分新模型支持稍慢TGI追新模型、HF生态绑定新架构支持最快调度效率略逊SGLang多轮对话、Agent、长上下文RadixAttention前缀复用吞吐高社区和文档体量略小TensorRT-LLM模型冻结、GPU固定极致性能编译重、迭代慢Ollama本地开发、个人体验零配置上手不支撑生产并发与监控3. 云服务怎么选租显卡、托管推理还是Serverless API框架定了接下来是跑在哪里的问题。自己做机房对小团队不现实云服务基本是唯一解。但云服务的形态这几年分化得很快很多人还在拿“租GPU服务器”当唯一选项其实已经落后了。3.1 三类云服务形态本质区别在运维责任第一类是GPU云主机或裸金属比如阿里云、腾讯云、AWS的GPU实例。你拿到一台带显卡的Linux机器从装驱动开始什么都自己来。这是最灵活也是责任最重的方案要自己处理推理框架部署、监控、故障恢复、滚轮更新。第二类是托管推理服务比如开箱即用的推理Endpoint。你把模型传上去平台自动做负载均衡、弹性伸缩、版本管理你只需要调用API。这类服务省运维但灵活度下降而且模型结构和框架版本往往由平台锁死。第三类是Serverless GPU按调用次数计费。我接触过的很多团队一上来就租了GPU云主机然后发现其中一半的运维工作其实和业务无关。如果你不是有明确的自定义需求比如要用TensorRT-LLM、要定制调度策略我反而建议认真考虑托管推理和Serverless。3.2 成本账怎么算才靠谱先泼一盆冷水GPU按小时价格看着不贵但跑满一个月的账单会吓到你。以一张中高端显卡为例按2026年主流云厂商的刊例价包月一般在几千到一万多元区间这个数字听起来还行但注意这只是单卡。生产环境你至少要两卡起步保冗余加上存储、网络、备份年度费用很快就是六位数。Serverless按Token计费的模式有一个隐性优点低谷不花钱。如果你的业务有明显的峰谷差异比如白天实习生疯狂调用、晚上几乎没人用Serverless的账单会比包机器便宜得多。我用Lambda跑过一个原型验证一周的调用量只花了包月几分之一的钱。但要提醒的是Serverless的冷启动在模型推理领域要比普通Web服务严重得多因为加载一个7B模型就要几十秒。目前平台上通常会用“预置并发”解决但预置并发是要额外付费的。所以省钱还是费钱取决于你的流量曲线是否平滑。3.3 延迟和数据合规往往比价格更致命选云服务的时候价格和性能表都能查到但有两件事是表格里看不出来的。一是地域网络延迟。你的用户在国内就优先选国内节点用户如果在海外就选对应区域的节点。很多海外云厂商的中国区节点选择有限而国内云厂商的海外节点覆盖也各有侧重。我们曾经把服务部署在了一个离用户很远的区域接口延迟直接多了几十毫秒真实体感就是“慢半拍”。二是数据出境合规。做企业服务的人都懂客户数据放在哪个区域、由谁处理是合同里死磕的条款。如果你的模型要处理的是业务敏感数据千万别为了省几百块钱把服务部署到不合规的区域。这一步出问题不是技术事故是合规事故。我的建议是新项目先按“用户地域 数据合规”筛出候选区域再在候选区域里比价。反过来选的话之后往往要付出迁移的代价。3.4 混合部署是2026年很务实的折中方案这里我分享一个自己觉得很好用的结构核心底座用云GPU主机自建扛主力流量弹性部分接Serverless或托管推理应对突发的流量洪峰。底层主机保证性能和可控性上层弹性能力保证高可用。真的遇到流量暴涨的时候临时扩容是来不及的提前把Serverless作为缓冲池接好多出来的流量自然溢过去。这个方案唯一的额外成本是代码里多写一层路由逻辑但对生产稳定性来说是值得的。4. 生产级部署完整链路从拉取模型到压测、监控、灰度前面把方案都定了接下来是动手。这一节我按一条干净的路径来写跟着做基本能把一个模型从零跑成生产服务。4.1 模型获取与镜像固化第一道规范不要直接从模型仓库随意下载文件到生产机。训练完的模型应该有明确的版本管理至少做到使用带版本号的模型仓库地址固定到具体commit或tag。对模型文件计算校验和部署脚本里做校验。把推理环境固化成容器镜像镜像标签和模型版本一一对应。这个规范看起来繁琐但作用很大。我们有过一次事故就是有人手动在机器上下载了一个最新版模型结果和代码里假设的输入输出格式不兼容线上直接开始报错回滚还花了半天。4.2 启动参数要点不要只改端口就跑vLLM启动参数里有一组是需要根据业务流量反复调的--max-model-len模型最大上下文长度。设太短长文档请求会直接报错设太长KV Cache预留过多并发上不去。--max-num-seqs最大并发序列数。这个数值直接决定显存分配策略。--gpu-memory-utilization允许框架使用的显存比例。默认0.9但如果机器上还要跑其他进程要手动调低。--tensor-parallel-size张量并行卡数。单卡能放下就别开这个参数一开就涉及卡间通信会有性能损耗。一个7B模型在单张80GB卡上的示例启动命令python -m vllm.entrypoints.openai.api_server \ --model /models/my-company-7b \ --served-model-name my-model \ --max-model-len 8192 \ --max-num-seqs 64 \ --gpu-memory-utilization 0.92 \ --tensor-parallel-size 1 \ --kv-cache-dtype fp8 \ --port 8000--kv-cache-dtype fp8这一项要单独说它就是把KV Cache量化到FP8能显著省显存对质量影响很小。2026年做生产部署我建议默认开启。4.3 压测做不好上线就是事故现场我见过太多团队跳过压测直接上线的。模型服务不比普通Web接口它的性能曲线不是线性的——并发一超过某个阈值响应时间会突然恶化呈悬崖式下降。所以压测的目的不是“看能不能跑”而是找到那个悬崖在哪里然后把线上并发控制在悬崖之前并留足余量。压测测什么至少三个指标TTFT首Token时间用户发出请求到收到第一个字的时间这是体感关键。TPOT单个Token生成时间决定了整体的输出速度也决定了流式输出的流畅度。吞吐量每分钟能处理多少请求决定你的服务容量。压测工具可以直接用Locust或wrk这类通用工具但要注意必须模拟真实的请求体大小和并发模式不要只发一个“你好”。我们当时用一个线上日志重放的方案把真实请求里的Prompt长度分布拿出来按同样的比例去压测。第一轮压测就把问题暴露了并发一上到30P99延迟从2秒飙到15秒原因就是前面提到的KV Cache预留不够请求全在排队。压测通过后建议把结果存档。后面每次改模型、改框架参数都跑一遍同样的压测形成对照基线。这比任何监控告警都能更早发现问题。4.4 监控告警GPU利用率之外更要盯队列和Token指标GPU利用率和显存占用当然要看但这两个指标在推理服务里有滞后性。GPU利用率高可能是好事也可能是任务积压导致一直在算。我建议重点盯业务侧指标请求队列长度队列一涨就说明容量告急了。P95 / P99 TTFT比平均延迟敏感得多。每分钟Token产出量这个指标能反映服务的真实吞吐。vLLM通过Prometheus暴露的指标基本覆盖了这些建议在Grafana里建好面板。告警规则我常用的三条队列长度连续5分钟超过阈值报警。P99 TTFT超过目标值的1.5倍报警。GPU显存占用接近上限且持续不降报警这可能意味着显存泄漏。监控这东西宁可先多配几条规则也不要裸奔。4.5 灰度发布和秒级回滚模型升级不能直接替换线上实例。一个模型换掉输出格式、质量、延迟都可能变化必须灰度。我的标准流程是花几分钟拉起一个新实例把5%到10%的流量切过去观察准确率、延迟、错误率确认没问题再逐步切完。这里需要强调回滚比灰度更重要。你永远不知道新模型什么时候会出问题所以旧版本的镜像和权重至少保留一个周期。我们定的规矩是每次发布前确保旧版本能一键恢复恢复时间目标控制在5分钟以内。5. 接入层的隐性成本并发、超时、令牌限流与慢请求治理部署完模型只是第一步。真正让服务稳定跑下去的往往是模型前面的接入层。很多人只盯着推理框架的参数忽略了API网关和客户端的设计结果模型本身没问题服务却在用户那里表现为“卡住”“报错”“不回复”。5.1 超时和重试不要默认用客户端默认值LLM服务天然比普通API慢单个请求可能跑几十秒。如果你用的是普通HTTP客户端的默认超时比如3秒那所有长请求都会被误杀。更糟的是客户端超时后会忍不住重试同一批请求被重复打进服务端队列压力翻倍整个服务就被重试流量打挂了。我踩过这个坑后来定了一套规则读超时设到模型单请求上限的三倍以上。只对明确失败的请求做重试超时的不重试或指数退避重试。服务端做幂等控制同一个请求ID重复进来只处理一次。5.2 Token限流比QPS限流更贴合LLM的实际负载传统的QPS限流对LLM服务其实不太适用。一个1000 Token的请求和一个50 Token的请求消耗的资源差了20倍。所以限流应该按Token算而不是按请求次数算。方案上可以按用户维度、按API Key维度分别设置每分钟Token上限防止某个调用方把并发打满挤占其他人的资源。这也是很多人的误区以为模型部署好了服务就完事了实际上不设限流的话一个脚本循环就能把你的GPU跑满。5.3 慢请求治理流式输出和排队上限缺一不可LLM服务的次要瓶颈常常在慢请求上。一个长上下文的请求可能要算很久占着显存不放。如果不限制单请求的最大Token数和最大上下文长度少数几个慢请求就能把整个服务拖垮。解决方案有两个层面。一是流式输出让用户尽快收到第一个Token体感上慢请求也没那么慢二是在网关层设置最大排队时间排不上的请求直接返回“系统繁忙”而不是让用户一直等。我自己有一个原则宁可明明白白拒绝一个请求也不要让它无意义地占着队列。6. 上线后容易翻车的几个配置项与排查思路最后写几个我真实遇到、并且花了不少时间排查的问题。这些不会写在官方文档的显眼位置但每一个都能让服务在半夜报警。6.1 显存泄漏明明没有流量显存占用却不降有一次我们的服务在低峰期显存占用越来越高最后直接把GPU打OOM了。排查过程走了不少弯路最终定位到是推理框架的一个已知问题某个版本的显存池没有正确释放碎片。这类问题没有通用答案但我给出几个建议拉起服务后先观察一个周期的基线显存增量。GPU显存监控要落在告警规则里。遇到异常先查框架版本更新日志很多问题在后续版本里已经修复。6.2 量化后输出质量异常的排查模型量化之后输出变差排查时要先确认是量化精度问题还是推理参数问题。做法是把量化后的模型和原模型在固定评测集上跑一遍逐条对比。如果差异集中在数学计算、代码这类敏感任务上那大概率是量化精度问题可以考虑退回FP8或者对量化算法做校准如果差异是随机散落的那更可能是采样参数设置不当。6.3 多卡并行时卡间通信成了瓶颈开了张量并行吞吐不升反降的案例并不少见。排查思路很直接用小批量请求测一下单卡和多卡的延迟差异如果多卡没优势看看是不是卡间通信协议的问题。实际生产中能用单卡解决的模型尽量用单卡只有显存放不下了再上多卡这个选择顺序会让你的运维轻松很多。6.4 并发参数不是越大越好--max-num-seqs并不是调得越高吞吐越高。调高之后多个请求共享显存每个序列的Batch太大可能让单Token生成时间明显变慢整体吞吐反而掉下来。我测试过这个参数在某个值附近有一个明显的吞吐拐点前期压测一定要做参数扫描不要只试一个值。以大模型部署为题的项目我这两年陆陆续续跑了不少从最早的七零八落踩坑到现在基本能按照一套固定流程快速交付。最大的感触是模型部署这个事它的难点从来不在于哪个框架更厉害、哪家云厂商更便宜而在于你能不能把从负载分析、框架选型、容量规划到监控运维的整条链路想清楚。如果你正准备开始做这件事我的建议是先花半天时间算清楚自己的显存账再花半天时间跑一轮真实负载的压测然后再去纠结框架和云厂商的细微差异。这两个半天会帮你省下后面无数的半夜报警。