1. 大模型工程部署到底在解决什么问题1.1 从“跑通Demo”到“扛住流量”的鸿沟很多人第一次接触大模型都是在自己的笔记本上装个Ollama拉一个7B或8B的模型跑通一句“你好请介绍一下你自己”然后就觉得“部署不过如此”。但真正到了企业环境里事情完全不是这个量级。你面对的不再是一个用户、一条请求而是几十上百个并发调用是不同业务线对响应时间的要求是GPU显存随时可能爆掉的告警是模型版本迭代后如何灰度上线的流程问题。大模型工程部署的核心说白了就一句话把训练好或下载好的模型权重变成一个稳定、高效、可观测、可扩展的在线服务。这件事听起来简单但中间涉及的环节非常多——推理引擎选型、显存优化、批处理策略、量化方案、服务编排、监控告警、版本管理每一个环节都有坑。我见过太多团队在Demo阶段用Flask写个接口就上线了结果并发一上来直接OOM或者响应时间从2秒飙到30秒。这不是模型不行是工程部署没做好。所以这个专栏要聊的就是怎么把“能跑”变成“能扛”。1.2 哪些人最需要关注工程部署第一类是企业内部的AI平台团队。他们需要为公司多个业务线提供统一的模型推理服务既要控制GPU成本又要保证不同业务方的SLA。这类团队最关心的是资源利用率、多模型共存、弹性伸缩。第二类是应用开发团队。他们可能不直接管GPU集群但需要调用模型接口关心的是接口稳定性、响应延迟、并发上限、以及如何做流式输出。他们经常遇到的问题是“本地跑得好好的怎么一上服务就超时”。第三类是个人开发者和中小团队。预算有限可能只有一两张消费级显卡想在本地部署开源模型做产品验证。他们最需要的是在有限硬件上榨出最大性能的实操方案。不管你是哪一类工程部署的思路是相通的先明确你的场景约束延迟优先还是吞吐优先、显存多大、并发多少再选择合适的技术栈最后通过压测和调优把系统稳定下来。1.3 部署方案选型的核心决策树在动手之前先回答几个问题这决定了你后面所有的技术选择模型规模多大7B、13B、70B还是更大这直接决定你需要什么级别的显卡以及是否必须做量化。并发量级多少是个位数并发还是上百并发这决定你是用单实例还是需要做负载均衡和多副本。延迟要求多高是要求首Token在1秒内返回还是可以接受3-5秒这决定你是否需要上vLLM这类高吞吐推理引擎。有没有多模型需求如果同时要服务多个不同模型就需要考虑显存分时复用或模型路由。运维能力如何团队有没有K8s运维经验这决定你是用裸机Docker还是上K8s编排。把这几个问题想清楚后面的路就顺了。最怕的是一上来就抄别人的配置结果硬件不匹配、场景不匹配调了半天也跑不起来。2. 推理引擎与硬件选型的关键考量2.1 Ollama、vLLM、TGI到底怎么选这是被问得最多的问题。我先给一个直接的结论个人本地玩用Ollama生产环境高并发用vLLMHuggingFace生态重度用户可以用TGI。但这三者之间的差异远不止这么简单。Ollama的最大优势是安装极其简单一条命令就能拉模型跑起来而且自带模型管理、量化版本选择、API服务。它底层用的是llama.cpp对消费级硬件非常友好CPU推理也能跑。但它的短板也很明显并发能力弱没有真正的连续批处理continuous batching在高并发场景下吞吐量上不去。所以Ollama适合开发调试、个人使用、低并发内部工具。vLLM是目前生产环境部署开源大模型的主流选择。它的核心杀器是PagedAttention和连续批处理能把GPU利用率拉到很高。同样一张A100vLLM的吞吐量可能是朴素HuggingFace Transformers的10倍以上。它还支持张量并行可以多卡跑一个大模型。缺点是配置相对复杂对模型格式有一定要求而且主要面向NVIDIA GPU。TGI是HuggingFace推出的推理服务框架和Transformers生态无缝衔接支持多种量化方案部署也比较规范。它的性能介于Ollama和vLLM之间优势在于对HuggingFace模型库的支持最全面很多新模型发布当天就能用。对比维度OllamavLLMTGI安装难度极低中等中等并发吞吐低极高高显存效率一般优秀良好多卡支持有限完善支持模型格式GGUF为主HF格式HF格式适合场景本地开发生产高并发HF生态用户2.2 显存计算你到底需要多大的卡这是部署前必须算清楚的账。很多人买卡之前不算显存买回来发现模型加载不进去或者加载进去了但一跑就OOM。先给一个粗略的估算公式。模型推理时的显存占用主要分三块模型权重、KV Cache、激活值。模型权重最简单FP16精度下大约是参数量乘以2字节。比如7B模型FP16权重约14GB13B约26GB70B约140GB。如果做INT8量化权重占用减半INT4量化再减半。KV Cache是大头尤其在高并发长上下文场景下。它的计算公式是2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 批大小 × 精度字节数。以Llama 2 7B为例32层32个头头维度128FP16精度。如果序列长度4096批大小16那KV Cache大约是2 × 32 × 32 × 128 × 4096 × 16 × 2字节 ≈ 34GB。这已经超过模型权重本身了。所以实际部署中KV Cache往往是显存瓶颈。vLLM的PagedAttention就是为了解决这个问题它把KV Cache分页管理按需分配大幅减少碎片和浪费。实操建议如果你要部署7B模型做中等并发服务一张24GB显存的卡如3090/4090在INT8量化下勉强够用但上下文长度和并发数都要控制。如果要跑13B以上或者长上下文建议至少48GB显存起步。70B模型基本需要多卡或INT4量化加多卡。2.3 量化方案的选择与取舍量化是让小显存跑大模型的关键手段但量化不是免费的午餐它会带来精度损失。常见的量化方案有GPTQ、AWQ、GGUF、bitsandbytes等。GPTQ是训练后量化把权重量化到4bit或8bit推理时反量化。它的优点是压缩率高7B模型INT4后只要约4GB显存。缺点是量化过程需要校准数据集而且不同模型的量化效果差异较大。AWQ是激活感知的权重量化相比GPTQ在精度保持上更好尤其对小模型效果更明显。vLLM对AWQ的支持很好是目前生产环境比较推荐的4bit方案。GGUF是llama.cpp生态的格式支持CPUGPU混合推理Ollama用的就是它。GGUF的Q4_K_M量化在精度和大小之间平衡得不错适合本地部署。bitsandbytes是HuggingFace生态的在线量化方案支持8bit和4bit加载不需要预先量化。它的优点是方便缺点是推理速度不如GPTQ/AWQ。我的经验是生产环境优先考虑AWQ 4bit本地开发用GGUF Q4_K_M对精度要求极高的场景用FP16或INT8。量化到4bit后7B模型的困惑度perplexity通常会上升0.1-0.3对大多数应用来说可以接受但如果是做代码生成或数学推理建议至少用INT8。3. 从零搭建一个可用的推理服务3.1 环境准备与依赖安装假设我们在一台Ubuntu 22.04的机器上有一张24GB显存的NVIDIA显卡要部署一个7B模型做API服务。我以vLLM为例走一遍完整流程。首先确认驱动和CUDA。nvidia-smi能看到显卡信息驱动版本建议535以上。CUDA版本vLLM会自带运行时但驱动要匹配。然后装Python环境建议用conda或venv隔离conda create -n vllm python3.10 -y conda activate vllm pip install vllmvLLM的安装会自动拉取对应版本的PyTorch和CUDA运行时。如果你要用AWQ量化模型还需要装autoawq。如果要跑特定模型可能还需要transformers的特定版本。注意vLLM对PyTorch版本比较敏感不要随意升级或降级PyTorch否则可能出现CUDA kernel不匹配的问题。建议严格按照vLLM官方文档的版本要求来。3.2 模型下载与格式转换国内下载HuggingFace模型经常遇到网络问题可以用ModelScope或者HF镜像。以Qwen2.5-7B-Instruct为例# 用modelscope下载 pip install modelscope python -c from modelscope import snapshot_download; snapshot_download(Qwen/Qwen2.5-7B-Instruct, cache_dir./models)下载完成后模型目录里应该有config.json、tokenizer.json、*.safetensors等文件。vLLM可以直接加载这种HF格式的模型。如果你要用AWQ量化版本直接下载对应的AWQ模型即可比如Qwen/Qwen2.5-7B-Instruct-AWQ。不需要自己量化除非你有特殊需求。3.3 启动推理服务与参数调优启动vLLM的OpenAI兼容服务python -m vllm.entrypoints.openai.api_server \ --model ./models/Qwen2.5-7B-Instruct-AWQ \ --quantization awq \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 64 \ --port 8000几个关键参数解释一下。--max-model-len是最大上下文长度设得越大KV Cache占用越多要根据显存来。--gpu-memory-utilization是GPU显存使用上限比例0.9表示用90%显存留一点给系统。--max-num-seqs是最大并发序列数直接影响吞吐和显存。启动后用curl测试curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: ./models/Qwen2.5-7B-Instruct-AWQ, messages: [{role: user, content: 你好}], max_tokens: 128, temperature: 0.7 }如果返回正常说明服务跑起来了。接下来就是压测和调优。3.4 压测与性能基线建立不要凭感觉说“够快”要用数据说话。推荐用locust或wrk做压测。我一般用Python写个简单的并发测试脚本import asyncio import aiohttp import time async def send_request(session, prompt): async with session.post( http://localhost:8000/v1/chat/completions, json{ model: ./models/Qwen2.5-7B-Instruct-AWQ, messages: [{role: user, content: prompt}], max_tokens: 256 } ) as resp: return await resp.json() async def main(): prompts [写一段Python快速排序] * 32 async with aiohttp.ClientSession() as session: start time.time() tasks [send_request(session, p) for p in prompts] results await asyncio.gather(*tasks) elapsed time.time() - start print(f32并发耗时: {elapsed:.2f}s, 平均每请求: {elapsed/32:.2f}s) asyncio.run(main())记录几个关键指标首Token延迟TTFT、每Token输出时间TPOT、总吞吐tokens/s、并发下的P99延迟。这些数据是你后续调优的基线。4. 生产环境部署的进阶话题4.1 多模型共存与显存分时复用企业里往往不是只服务一个模型。可能A业务用7B通用模型B业务用13B代码模型C业务用多模态模型。如果每个模型独占一张卡成本太高。方案一是用vLLM的多模型支持但vLLM本身对多模型共存的支持有限通常还是一个实例一个模型。方案二是用模型路由层根据请求内容分发到不同后端。方案三是用显存分时复用比如用vLLM的--swap-space配合模型卸载但切换开销大不适合高频切换。我实际用下来比较稳的方案是核心高频模型常驻显存低频模型按需加载。用一个调度服务管理模型生命周期请求来了先检查模型是否在显存不在就触发加载加载完再推理。加载时间从几秒到几十秒不等所以适合对延迟不敏感的场景。4.2 监控告警与可观测性建设服务上线只是开始能不能稳定运行靠的是监控。至少要采集这几类指标GPU指标显存使用率、GPU利用率、温度、功耗。用nvidia-smi或DCGM exporter采集。服务指标QPS、TTFT、TPOT、P99延迟、错误率。vLLM自带Prometheus metrics接口。业务指标Token消耗量、请求长度分布、模型调用分布。告警规则建议设显存使用率持续5分钟超过95%、P99延迟超过阈值、错误率超过1%、GPU温度超过85度。这些都能提前发现潜在问题。实操心得很多OOM不是突然发生的而是显存缓慢增长导致的。如果你的服务跑了几天后显存越来越高大概率是KV Cache没有正确释放或者有内存泄漏。定期重启服务是个笨但有效的办法但更好的做法是定位根因。4.3 版本管理与灰度发布模型迭代是常态。新模型上线不能直接全量替换要有灰度流程。基本思路是新模型起一个新实例通过路由层把少量流量导过去观察指标正常后逐步扩大比例直到全量。模型版本管理建议用类似model-name:version的命名规范每次上线记录模型哈希、量化方式、推理引擎版本、关键参数。这样出问题时能快速回滚到已知可用的版本。5. 常见问题与排查技巧实录5.1 启动就OOM怎么办这是最高频的问题。排查顺序先看模型权重是否超过显存再看--max-model-len是否设得太大然后看--gpu-memory-utilization是否设得太高。如果是AWQ模型确认--quantization awq参数有没有加不加的话vLLM会按FP16加载显存直接翻倍。还有一个隐蔽的坑有些模型下载不完整vLLM加载时可能报奇怪的错误。检查模型目录下所有safetensors文件是否完整可以用sha256sum校验。5.2 推理速度慢得离谱先确认是不是用了CPU推理。nvidia-smi看GPU利用率如果一直是0%说明模型跑在CPU上。检查vLLM启动日志有没有Using device: cuda。如果GPU利用率正常但速度慢检查是否开了连续批处理。vLLM默认开启但如果你用的是其他框架可能没有。另外--max-num-seqs设得太小会导致批处理效率低设得太大又可能OOM需要压测找平衡点。还有一种情况是输入太长。长上下文下注意力计算是O(n²)4096长度和8192长度的推理时间可能差好几倍。如果业务允许尽量控制输入长度。5.3 并发一高就超时这通常是KV Cache不够或者批处理策略问题。先看vLLM日志有没有Preemption或Swap相关的警告这说明显存不够请求被抢占或换出。解决办法是降低--max-num-seqs或--max-model-len或者升级显卡。如果显存够但延迟还是高检查是不是网络瓶颈。用curl本地测试和远程测试对比如果本地快远程慢说明网络或反向代理有问题。问题现象可能原因排查方法解决方向启动OOM显存不足/量化未生效看日志、算显存量化、降长度、换卡推理慢CPU推理/无批处理看GPU利用率确认CUDA、开连续批处理并发超时KV Cache不足看Preemption日志降并发、降长度、加显存显存缓慢增长内存泄漏长期监控定位泄漏、定期重启输出乱码量化精度损失对比FP16输出换量化方案、提精度5.4 模型输出质量下降如果量化后输出质量明显下降先对比FP16和量化版本的输出。如果差异大考虑换量化方案比如从GPTQ换AWQ或者从4bit换8bit。另外采样参数也会影响输出temperature、top_p、repetition_penalty这些要根据模型推荐值来设不要照搬其他模型的配置。我个人踩过的一个坑是用AWQ量化模型时如果--dtype设成autovLLM可能选错精度导致输出异常。显式指定--dtype float16就正常了。这种问题不看日志很难发现所以启动参数尽量明确不要依赖自动推断。6. 硬件成本与扩展性的一些实在话6.1 消费级卡能不能用于生产能但有条件。4090 24GB在INT4量化下跑7B模型做中等并发是可行的单卡成本远低于A100。但消费级卡有几个硬伤没有NVLink多卡通信慢显存纠错能力弱长时间高负载可能出静默错误驱动和CUDA支持不如专业卡稳定。如果业务对可用性要求不是99.99%预算又有限消费级卡是可以接受的。但要做好监控和容错比如双卡冗余、请求重试。6.2 什么时候该考虑多卡单卡显存不够、或者单卡吞吐扛不住的时候。多卡有两种模式张量并行TP和流水线并行PP。vLLM支持TP把模型切到多张卡上每张卡算一部分。TP的通信开销大建议用NVLink连接的卡比如A100/H100。消费级卡用PCIe做TP性能损失可能达到30%以上。另一个思路是数据并行每个卡跑一个完整模型副本请求分发到不同副本。这种方式没有通信开销扩展性好但每张卡都要能装下完整模型。7B模型INT4约4GB一张24GB卡可以跑多个副本用数据并行比TP更划算。6.3 云上部署还是本地部署这是个成本账。云上按需付费灵活但长期成本高。本地部署前期投入大但长期摊薄后便宜。粗略估算一张A100云上每小时约10-20元一年约9-18万。买一张A100约8-10万加上服务器和运维一年左右回本。所以如果长期稳定使用本地部署更划算如果是短期项目或流量波动大云上更合适。混合方案也值得考虑核心业务本地部署峰值流量溢出到云上。这样兼顾成本和弹性。7. 我个人的一些实操体会部署这件事最怕的就是“想当然”。我见过太多人拿着网上的配置直接抄结果硬件不一样、模型不一样、并发场景不一样跑不起来就到处问。其实只要把显存算清楚、把参数含义搞明白、把压测做扎实大部分问题都能自己解决。另外不要追求一步到位。先跑通再优化。先单卡单模型再考虑多卡多模型。先保证功能正确再调性能。很多团队一上来就想搞个大而全的平台结果半年过去了还没上线。小步快跑快速迭代才是工程部署的正确节奏。最后分享一个我常用的排查套路遇到问题先看日志日志里通常有答案日志看不出来就看监控监控能告诉你什么时候开始异常的监控也看不出来就做最小复现把问题隔离到最小范围。这三步能解决90%以上的部署问题。