1. 为什么企业私有化部署大模型绕不开推理引擎这道坎
很多团队第一次做大模型私有化部署时，脑子里想的都是"把模型权重下载下来，找个脚本加载进去，起个HTTP服务就完事了"。我见过太多这样的项目：用原生Transformers加载一个70B参数的模型，单张A100跑推理，结果吞吐量低得可怜，并发稍微上来一点延迟就飙到十几秒，显存还动不动就OOM。最后业务方抱怨"这玩意儿根本没法用"，项目组只能硬着头皮加卡，成本翻了几倍，问题依然没根治。
这里面的核心矛盾在于：大模型的推理瓶颈从来不在算力峰值，而在显存管理和请求调度。一个70B的模型，FP16精度下光权重就要占140GB左右显存，单卡根本放不下；就算用多卡张量并行塞进去了，KV Cache（键值缓存）随着并发请求增长会迅速吃掉剩余显存，导致要么限制并发数、要么频繁换入换出。原生推理框架对这些问题的处理非常粗糙，它假设你一次只跑一个请求，或者并发量很小。
vLLM这个推理引擎之所以在企业私有化场景里被反复提及，就是因为它用两个关键机制把上面这些问题系统性地解决了：PagedAttention和连续批处理（Continuous Batching）。PagedAttention把KV Cache按块（Block）管理，像操作系统管理内存分页一样，避免了显存碎片化，显存利用率能从原生方案的百分之二三十提升到百分之八九十；连续批处理则让不同请求的生成过程可以交错进行，一个请求生成完立刻腾出位置给新请求，GPU几乎不会空转。
这篇文章面向的是真正要把大模型落到企业内网、数据不出域、还要扛住一定并发量的工程团队。我会从环境准备、模型加载、服务配置、性能调优、监控排障几个维度，把vLLM私有化部署的完整链路拆开讲清楚，包括那些官方文档里不会写、但实际部署时一定会踩的坑。读完你至少能做到：知道自己的硬件该选什么并行策略、知道显存怎么算、知道并发上不去该调哪个参数、知道出问题了从哪查起。
2. 部署前的硬件账与并行策略选型
2.1 先算清楚你的显存到底够不够
私有化部署第一步不是装环境，是算账。很多项目失败在选型阶段，就是因为没提前算清楚显存需求，卡买回来了发现跑不起来，或者跑起来了并发低得没法用。
显存占用主要分三块：模型权重、KV Cache、激活值和其他开销。模型权重最好算，参数量乘以精度字节数。FP16是2字节，INT8是1字节，INT4是0.5字节。一个70B模型FP16就是140GB，INT8是70GB，INT4是35GB。但注意，这只是权重，你还得留出KV Cache的空间。
KV Cache的估算稍微复杂一点，公式是：
KV Cache总字节数 = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 并发数 × 精度字节数其中2是因为要存Key和Value两份。以常见的70B模型为例，80层、64个头、头维度128，FP16精度，序列长度4096，单请求的KV Cache大约是：
2 × 80 × 64 × 128 × 4096 × 2 ≈ 10.7GB也就是说，光一个4096长度的请求就要占10GB以上的KV Cache。如果你要支持10个并发，那就是107GB，加上权重140GB，总共247GB，单张80GB的卡想都别想。这就是为什么大模型部署必须用张量并行把模型切开，同时还要用PagedAttention把KV Cache的浪费降到最低。
实际选型时，我一般建议按这个顺序倒推：先确定业务需要的最大并发数和平均序列长度，算出KV Cache需求；再加上权重占用；最后留20%的余量给激活值和碎片。得到的总显存需求除以单卡显存，就是你需要的最少卡数。
| 模型规模 | 精度 | 权重显存 | 建议最小卡数（80GB卡） | 典型并行策略 |
|---|---|---|---|---|
| 7B | FP16 | 14GB | 1 | 单卡 |
| 13B | FP16 | 26GB | 1 | 单卡 |
| 34B | FP16 | 68GB | 1-2 | 单卡或TP=2 |
| 70B | FP16 | 140GB | 2-4 | TP=2或TP=4 |
| 70B | INT8 | 70GB | 1-2 | TP=1或TP=2 |
| 70B | INT4 | 35GB | 1 | 单卡（需量化支持） |
注意：上表的卡数只是"能跑起来"的下限，要支撑实际并发还得往上加。我见过太多团队按最低配置买卡，结果上线后并发一压就崩。
2.2 张量并行、流水线并行到底怎么选
vLLM支持张量并行（Tensor Parallelism，TP）和流水线并行（Pipeline Parallelism，PP），但实际生产环境里绝大多数场景只用TP就够了，PP用得很少。原因在于PP会把模型按层切成多个阶段，阶段之间有通信开销，而且容易出现流水线气泡，除非模型大到单机装不下、必须跨节点，否则没必要上PP。
TP的选择有个经验法则：优先让TP数等于单机内的GPU数，且尽量是2的幂次。比如一台8卡机器，跑70B模型，TP=4或TP=8都行。TP=4时每张卡放17.5B的权重，约35GB，剩下45GB给KV Cache，能支撑的并发就比较可观了。TP=8时每张卡放8.75B，约17.5GB，KV Cache空间更大，但卡间通信开销也更大，因为TP每层都要做All-Reduce。
这里有个反直觉的点：TP不是越大越好。TP增大虽然单卡显存压力小了，但通信开销线性增长，而且GPU利用率可能反而下降。我实测过一个70B模型，TP=4和TP=8在低并发下延迟差不多，但TP=8的吞吐量只比TP=4高15%左右，而卡数翻倍。所以如果你的并发需求不是特别高，TP=4往往性价比更好。
还有一个关键参数是--max-model-len，它决定了KV Cache按多长的序列来预分配。这个值设大了浪费显存，设小了长请求会被截断。我的做法是统计业务里95%的请求长度，按那个值来设，再留一点余量。比如业务请求大多在2000 token以内，那就设--max-model-len 4096，别一上来就设32768，那会白白吃掉大量显存。
2.3 量化：省显存的利器，但别乱用
量化是私有化部署里绕不开的话题，尤其是卡不够的时候。vLLM支持AWQ、GPTQ、FP8等多种量化格式。量化的本质是用更低的精度表示权重，INT8是1字节，INT4是0.5字节，显存直接减半或减到四分之一。
但量化有代价。INT4量化在大多数任务上精度损失可控，但在一些对数值敏感的任务上（比如数学推理、代码生成）可能会有明显下降。我的经验是：如果显存够，优先用FP16；实在不够，先试INT8；INT8还不够再考虑INT4。而且量化模型的加载和普通模型不一样，需要指定--quantization参数，比如--quantization awq。
另外要注意，不是所有模型都有现成的量化版本。如果没有，你得自己用工具量化，这个过程需要校准数据集，量化后的效果也得自己验证。我一般建议先用小模型验证量化流程，确认精度可接受再上大模型。
3. 从零搭建vLLM服务：环境、加载与启动
3.1 环境准备里最容易翻车的几个细节
vLLM的环境依赖说简单也简单，说坑也多。最核心的是CUDA版本、PyTorch版本、vLLM版本三者的匹配。vLLM对CUDA和PyTorch版本很敏感，版本不匹配轻则报错，重则跑起来结果不对。
我的建议是直接用官方提供的Docker镜像，比如vllm/vllm-openai:latest，这样能避开大部分依赖问题。如果非要自己装，那就严格按官方文档的版本对应表来。我踩过的一个坑是：系统里预装了某个版本的PyTorch，pip install vllm时它不会自动降级或升级PyTorch，结果vLLM编译的CUDA kernel和PyTorch的CUDA版本对不上，推理时直接段错误。
还有一个容易被忽略的点是共享内存（shared memory）。vLLM在多进程模式下会用共享内存做进程间通信，如果Docker容器的/dev/shm太小（默认64MB），大模型加载时会报共享内存不足。解决办法是启动容器时加--shm-size=16g或者更大。
# 推荐的Docker启动方式 docker run --gpus all \ --shm-size=16g \ -p 8000:8000 \ -v /path/to/models:/models \ vllm/vllm-openai:latest \ --model /models/your-model \ --tensor-parallel-size 4 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9--gpu-memory-utilization这个参数很关键，它控制vLLM预分配多少比例的显存。默认是0.9，意思是占90%的显存。这个值设太高容易OOM，设太低又浪费。我一般设0.85到0.9之间，留一点给系统和其他进程。
3.2 模型加载：路径、格式与常见报错
模型加载这块，vLLM支持HuggingFace格式的模型目录，也支持直接从HuggingFace Hub拉取（但私有化场景一般不会联网，所以都是本地目录）。模型目录里必须有config.json、tokenizer相关文件、以及权重文件（.safetensors或.bin）。
常见的加载报错有这么几类：
第一类是权重文件不完整或损坏。下载大模型时如果网络中断，可能只下了一半，加载时报"unexpected EOF"或者shape不匹配。解决办法是校验文件大小和哈希值。
第二类是config.json里的参数和实际权重对不上。比如config里写的是num_hidden_layers: 80，但权重文件只有79层。这种情况一般是模型转换时出的问题，需要重新转换。
第三类是tokenizer缺失或版本不兼容。有些模型用的是自定义tokenizer，需要额外的代码文件。如果加载时报tokenizer相关错误，检查模型目录里有没有tokenizer_config.json和special_tokens_map.json。
第四类是显存不足导致的加载失败。这个最直接，报错信息里会有"CUDA out of memory"。这时候要么减TP、要么量化、要么换更大的卡。
提示：加载大模型时建议先用小模型（比如7B）跑通整个流程，确认环境没问题再上大模型。这样能快速定位是环境问题还是模型问题。
3.3 启动参数详解：哪些必须调，哪些别乱动
vLLM的启动参数很多，但真正影响生产可用性的就那么几个。我把它们分成三类：必调、建议调、别乱动。
必调的参数：
--model：模型路径，这个不用多说。--tensor-parallel-size：TP数，根据你的卡数和模型大小定。--max-model-len：最大序列长度，按业务需求设，别贪大。--gpu-memory-utilization：显存利用率，0.85-0.9之间比较稳。
建议调的参数：
--dtype：数据类型，默认auto，一般不用改。如果模型是FP16的，显存够就用FP16。--quantization：量化方式，用量化模型时必须指定。--max-num-seqs：最大并发序列数，默认256。如果并发上不去，可以适当调大，但要注意显存。--swap-space：CPU交换空间，默认4GB。显存紧张时可以调大，让vLLM把部分KV Cache换到CPU内存。--disable-log-requests：生产环境建议加上，避免日志刷屏。
别乱动的参数：
--block-size：PagedAttention的块大小，默认16。这个值一般不用改，改了可能影响性能。--scheduler-policy：调度策略，默认FCFS。除非你有特殊需求，否则别动。--enable-prefix-caching：前缀缓存，对多轮对话场景有用，但会增加显存开销。按需开启。
启动命令示例：
python -m vllm.entrypoints.openai.api_server \ --model /models/qwen-72b \ --tensor-parallel-size 4 \ --max-model-len 8192 \ --gpu-memory-utilization 0.88 \ --max-num-seqs 128 \ --swap-space 16 \ --disable-log-requests \ --port 8000启动后，vLLM会暴露一个兼容OpenAI API的接口，可以直接用OpenAI的SDK调用，也可以curl测试：
curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "/models/qwen-72b", "prompt": "你好，请介绍一下你自己", "max_tokens": 128, "temperature": 0.7 }'4. 性能调优：让并发和吞吐真正跑起来
4.1 连续批处理为什么能提升吞吐
要理解vLLM的性能优势，得先理解连续批处理。传统的批处理是"静态批"：攒一批请求，一起送进模型，等这批全部生成完，再处理下一批。问题是不同请求的生成长度不一样，有的生成10个token就结束了，有的要生成500个。静态批里，短请求结束后它占的位置就空着，GPU在等长请求，利用率很低。
连续批处理则是动态的：每个请求独立生成，生成完一个立刻从批次里移除，空出的位置马上给新来的请求。这样GPU几乎一直在处理有效请求，利用率大幅提升。vLLM的调度器就是干这个的，它维护一个等待队列和运行队列，每次迭代时从等待队列取请求补进运行队列。
这个机制带来的直接好处是：在相同硬件下，vLLM的吞吐量通常是原生方案的几倍到十几倍。我实测过一个13B模型，原生方案在并发8时吞吐约200 tokens/s，vLLM能到1500 tokens/s以上。
但连续批处理也有代价：它对显存管理要求极高，因为运行队列里的请求数动态变化，KV Cache也得动态分配。这就是PagedAttention发挥作用的地方——它把KV Cache切成固定大小的块，按需分配，用完回收，避免了显存碎片。
4.2 关键参数调优：max-num-seqs、gpu-memory-utilization、swap-space
调优的核心是平衡三个东西：并发数、延迟、显存。这三个是互相制约的，并发越高，单请求延迟越大，显存占用越多。
--max-num-seqs控制同时处理的请求数上限。设太小，并发上不去；设太大，显存不够会OOM。怎么定这个值？我的方法是：先用一个保守值（比如64）跑起来，然后用压测工具逐步加压，观察显存和延迟。当显存接近gpu-memory-utilization设定的上限时，就是并发的瓶颈了。
--gpu-memory-utilization前面说过，控制预分配显存比例。这里补充一点：vLLM启动时会按这个比例预分配显存，如果实际使用超过这个比例，会触发KV Cache的换出（swap）或者直接OOM。所以这个值不能设得太满，留10%-15%的余量比较安全。
--swap-space是CPU交换空间。当显存不够时，vLLM会把部分KV Cache换到CPU内存。这个机制能防止OOM，但换入换出有延迟，会拖慢推理速度。我的建议是：如果显存够，swap-space设小一点（比如4GB）；如果显存紧张，可以设大一点（比如32GB），但要接受性能下降。
还有一个参数--enable-chunked-prefill，它把长prompt的预填充（prefill）切成小块，和生成（decode）交错进行。这个对长prompt场景很有用，能降低首token延迟。但开启后会增加调度复杂度，建议在长prompt多的场景下开启。
| 参数 | 作用 | 推荐值 | 调整方向 |
|---|---|---|---|
| max-num-seqs | 最大并发数 | 64-256 | 显存够就调大 |
| gpu-memory-utilization | 显存预分配比例 | 0.85-0.9 | 别超过0.95 |
| swap-space | CPU交换空间 | 4-32GB | 显存紧张时调大 |
| max-model-len | 最大序列长度 | 按业务定 | 别贪大 |
| enable-chunked-prefill | 分块预填充 | 长prompt场景开启 | 按需 |
4.3 压测与容量规划：别等上线了才发现扛不住
压测是私有化部署里最容易被跳过、但最不能跳过的一步。很多团队觉得"本地跑通了就行"，结果上线后并发一上来就崩。压测的目的不是测出极限值，而是找到满足业务SLA的稳定工作点。
压测工具我一般用locust或者自己写脚本，核心是模拟真实请求分布：prompt长度、生成长度、并发数都要贴近实际。压测时重点观察几个指标：
- 首token延迟（TTFT）：从请求发出到收到第一个token的时间。这个指标对交互式应用很关键，一般要求1秒以内。
- 每token延迟（TPOT）：生成每个token的平均时间。这个指标影响流式输出的流畅度。
- 吞吐量（tokens/s）：单位时间生成的token总数。这个指标决定成本。
- 显存占用：压测过程中显存是否稳定，有没有持续增长（内存泄漏）。
压测的典型流程是：从低并发开始，逐步增加并发数，每个并发级别跑5-10分钟，记录上述指标。当TTFT或TPOT超过业务容忍阈值时，前一个并发级别就是稳定工作点。
容量规划则是在压测基础上，按业务峰值流量的1.5-2倍来配置资源。比如压测发现单实例能稳定支撑50并发，业务峰值是100并发，那就部署2-3个实例，留出冗余。
注意：压测时一定要用真实模型和真实数据，别用小模型代替。小模型的性能特征和大模型差别很大，压测结果没有参考价值。
5. 生产环境排障：那些半夜把你叫醒的问题
5.1 显存OOM的几种典型场景与排查路径
OOM是私有化部署里最常见的故障，没有之一。但OOM的原因有很多种，不能一看到OOM就加卡。我一般按这个路径排查：
第一步，看OOM发生的时间点。如果是启动时就OOM，那是权重加载阶段显存不够，需要减TP、量化或者换卡。如果是运行一段时间后OOM，那是KV Cache增长导致的，需要调小max-num-seqs或max-model-len，或者调大swap-space。
第二步，看OOM时的并发数。如果并发很低就OOM，那可能是gpu-memory-utilization设太高，或者有其他进程占了显存。用nvidia-smi看看显存被谁占了。
第三步，看是不是内存泄漏。vLLM本身比较稳定，但如果你的调用代码里有bug，比如没释放请求对象，可能导致显存缓慢增长。这种情况需要看显存随时间的变化曲线。
第四步，看是不是长序列请求导致的。一个超长序列（比如32000 token）的请求，KV Cache占用可能是普通请求的十几倍，瞬间就能把显存吃满。解决办法是限制max-model-len，或者在网关层拦截超长请求。
我遇到过一个典型案例：某业务上线后每隔几小时就OOM一次，排查发现是有一个定时任务会发送超长prompt，长度超过max-model-len，vLLM处理时KV Cache爆了。后来在网关层加了长度校验，问题解决。
5.2 吞吐突然下降：从GPU利用率反推瓶颈
吞吐突然下降比OOM更隐蔽，因为服务没挂，但性能变差了。这时候第一件事是看GPU利用率。用nvidia-smi或者nvitop看GPU的utilization和显存占用。
如果GPU利用率很低（比如30%以下），说明GPU在等数据，瓶颈可能在CPU或者网络。检查一下请求队列是不是积压了，或者数据预处理是不是太慢。
如果GPU利用率很高（90%以上）但吞吐下降，说明GPU在满负荷跑，但有效计算少。这可能是KV Cache换入换出导致的，检查swap-space的使用情况。也可能是批次里长序列太多，短序列被拖累。
如果GPU利用率忽高忽低，说明调度有问题。检查max-num-seqs是不是设得太小，导致批次经常空转。也可能是请求分布不均匀，有的时刻请求多、有的时刻请求少。
还有一个容易被忽略的点是温度降频。GPU长时间满负荷运行会发热，温度过高时会自动降频，导致性能下降。用nvidia-smi -q -d TEMPERATURE看温度，如果超过80度就要考虑加强散热。
5.3 请求超时与错误码：网关层该怎么配
vLLM的OpenAI兼容接口会返回标准HTTP错误码，常见的几个：
- 400：请求参数错误，比如
max_tokens超过限制、prompt格式不对。 - 404：模型名不对，检查请求里的
model字段和启动时的--model是否一致。 - 500：服务内部错误，一般是推理过程中出的问题，看vLLM日志。
- 503：服务不可用，一般是显存不足或者服务正在启动。
网关层（比如Nginx）需要配置合理的超时时间。大模型推理的延迟比普通API高得多，首token可能要几秒，完整生成可能要几十秒。如果网关超时设得太短（比如默认的60秒），长请求会被截断。我的建议是：连接超时设10秒，读超时设300秒，根据业务的最长生成时间调整。
另外，网关层最好加上重试机制，但要小心：大模型推理不是幂等的，重试可能导致重复生成。如果业务能接受重复，可以重试；如果不能，就别重试，直接返回错误让客户端处理。
还有一个实践是在网关层做请求排队和限流。vLLM本身有调度器，但如果请求量超过服务能力，直接打过去会导致所有请求都变慢。在网关层用令牌桶或者漏桶算法限流，超出的请求直接返回429，让客户端稍后重试，这样能保护服务稳定。
6. 多实例与高可用：单点部署的生产化改造
6.1 单实例的局限与多实例架构
单实例vLLM服务有几个硬伤：一是单点故障，实例挂了服务就没了；二是扩容不灵活，加卡就得重启；三是资源隔离差，一个异常请求可能影响所有请求。生产环境一般都要多实例部署。
多实例架构的核心是负载均衡。最前面放一个负载均衡器（Nginx、HAProxy或者云厂商的LB），后面挂多个vLLM实例。负载均衡策略用最少连接数（least connections）比较合适，因为大模型请求的处理时间差异很大，轮询会导致负载不均。
但多实例有个问题：每个实例都要加载一份完整的模型权重。如果模型是140GB，3个实例就要420GB显存，成本很高。解决办法是用TP把模型切到多卡，然后每个实例用不同的卡组。比如8卡机器，可以分成两组4卡，每组跑一个TP=4的实例，这样两个实例共享一台机器，但显存是独立的。
还有一种更省资源的方案是模型共享，多个实例共享同一份权重，只独立管理KV Cache。但这需要更复杂的架构支持，vLLM本身不直接支持，得靠上层框架或者自定义实现。一般中小规模部署用不上。
6.2 健康检查与优雅重启
多实例部署必须配健康检查，否则负载均衡器会把请求打到挂掉的实例上。vLLM提供了/health接口，返回200表示服务正常。但要注意，这个接口只检查服务进程是否活着，不检查推理是否正常。更严格的做法是发一个小的推理请求，看能不能正常返回。
健康检查的频率和超时也要注意。太频繁会增加服务负担，太稀疏又发现不了故障。我一般设10秒检查一次，超时3秒，连续3次失败就摘除实例。
优雅重启是另一个关键点。大模型加载很慢，一个70B模型可能要几分钟才能加载完。如果直接重启，这几分钟内服务是不可用的。优雅重启的做法是：先启动新实例，等新实例健康检查通过后，再从负载均衡器里摘除旧实例，最后停掉旧实例。这样服务全程可用。
# 优雅重启的简化流程 # 1. 启动新实例（不同端口） python -m vllm.entrypoints.openai.api_server --model /models/xxx --port 8001 & # 2. 等待新实例健康 until curl -s http://localhost:8001/health; do sleep 5; done # 3. 负载均衡器切换到新实例 # 4. 停掉旧实例 kill $OLD_PID6.3 日志、监控与告警该盯哪些指标
生产环境没有监控就是裸奔。vLLM本身会输出日志，但默认日志比较简略，建议开启详细日志（但别开--disable-log-requests的反面，那个会刷屏）。更好的做法是接入Prometheus，vLLM支持暴露metrics接口。
需要重点监控的指标：
- 请求数、成功数、失败数：看服务整体健康度。
- 首token延迟、每token延迟：看用户体验。
- 吞吐量：看资源利用效率。
- 显存占用、GPU利用率：看资源瓶颈。
- KV Cache使用率：看显存管理是否健康。
- 队列长度：看是否有请求积压。
告警阈值根据业务定。比如首token延迟超过3秒告警，显存占用超过90%告警，失败率超过1%告警。告警要分级，P0告警（服务不可用）直接打电话，P1告警（性能下降）发消息，P2告警（趋势异常）记工单。
日志方面，建议把vLLM的日志收集到统一的日志平台，方便排查。日志里要包含请求ID，这样能追踪单个请求的完整链路。但注意别把用户数据打到日志里，私有化场景对数据安全要求高。
7. 私有化场景下的安全与数据隔离实践
7.1 数据不出域：网络隔离与访问控制
私有化部署的核心诉求就是数据不出域。这意味着模型推理全程在内网完成，不能有任何数据外传。实现这一点需要几层保障：
网络层：vLLM服务部署在内网，不暴露公网。如果必须对外提供服务，通过内网网关做转发，网关层做鉴权和审计。防火墙规则要严格，只允许必要的端口通信。
访问控制：vLLM的API默认没有鉴权，任何人都能调。生产环境必须在前面加一层鉴权，可以用API Key、JWT或者对接企业的统一认证。API Key要定期轮换，别硬编码在代码里。
审计日志：所有请求都要记录，包括谁调的、什么时候调的、调了什么模型、输入输出是什么（如果合规允许）。审计日志要单独存储，防止被篡改。
模型安全：模型权重文件要加密存储，加载时解密。防止模型被窃取。有些企业还会在模型里嵌入水印，追踪泄露源头。
7.2 多租户隔离：不同部门怎么共用一套推理服务
大企业里，多个部门可能都想用大模型，但预算只够买一套。这时候就需要多租户隔离。隔离的维度有几个：
资源隔离：给每个租户分配独立的vLLM实例或者独立的GPU卡组，防止一个租户的流量影响另一个。如果资源有限，至少要在调度层做优先级和配额管理。
数据隔离：不同租户的请求和响应要严格隔离，不能串。这要求服务层能识别租户身份，并在日志、缓存等环节做隔离。前缀缓存（prefix caching）在多租户场景下要特别小心，别让租户A的缓存被租户B命中。
配额管理：给每个租户设token配额或者请求数配额，防止某个租户把资源用光。配额可以在网关层实现，也可以在vLLM上层封装。
模型隔离：如果不同租户用不同的模型，那就得部署多套实例。如果共用模型，那就在请求里区分租户，但要注意别让租户通过prompt注入等方式影响其他租户。
多租户架构会增加复杂度，但如果企业规模大，这是必须的。我的建议是先从简单的API Key隔离做起，随着需求增长再逐步完善。
7.3 模型更新与版本管理：怎么做到不停机切换
模型不是部署完就一劳永逸的，业务需求变化、模型迭代、bug修复都需要更新模型。但大模型加载慢，直接替换会导致服务中断。怎么做到不停机更新？
蓝绿部署是最常用的方案。准备两套环境，一套跑旧模型（蓝），一套跑新模型（绿）。新模型加载好、验证通过后，把流量从蓝切到绿。切换过程秒级完成，用户无感知。如果新模型有问题，快速切回蓝。
灰度发布更稳妥。先切一小部分流量到新模型，观察一段时间，没问题再逐步扩大比例。灰度期间要重点监控新模型的延迟、错误率、输出质量。如果发现异常，立即回滚。
版本管理方面，每个模型版本要有唯一标识，请求里可以指定版本，也可以由服务端根据策略路由。模型文件要版本化存储，别覆盖旧版本，方便回滚。
# 蓝绿部署的简化流程 # 蓝环境跑旧模型 python -m vllm.entrypoints.openai.api_server --model /models/v1 --port 8000 & # 绿环境跑新模型 python -m vllm.entrypoints.openai.api_server --model /models/v2 --port 8001 & # 验证绿环境 curl http://localhost:8001/v1/completions -d '{"model":"/models/v2","prompt":"test"}' # 切换流量（修改负载均衡器配置） # 如果出问题，切回蓝环境提示：模型更新前一定要做充分的回归测试，尤其是输出质量。大模型的输出有随机性，同样的输入可能得到不同的输出，所以测试要覆盖多种输入，并且用自动化工具对比新旧模型的输出差异。
8. 我踩过的那些坑与实战心得
8.1 模型下载与转换的坑
模型下载看似简单，实则坑很多。最大的坑是下载不完整。大模型动辄几十上百GB，下载过程中网络抖动、磁盘满、进程被杀都可能导致文件不完整。而很多下载工具不会校验完整性，你以为下完了，加载时才发现问题。
我的做法是：下载完后用sha256sum校验每个文件的哈希值，和官方提供的哈希对比。如果没有官方哈希，至少检查文件大小是否和预期一致。另外，下载时用支持断点续传的工具，别用那种断了就得重下的。
模型转换也是坑区。有些模型是PyTorch格式（.bin），有些是safetensors格式，vLLM对两种都支持，但safetensors加载更快、更安全。如果拿到的是.bin格式，建议转成safetensors。转换工具用HuggingFace的transformers库就行。
还有一个坑是模型配置不匹配。比如你下载的是基础模型，但config.json里写的是对话模型的配置，加载后行为会不对。这种情况要仔细核对模型来源和配置。
8.2 并发上不去时的排查清单
并发上不去是私有化部署里最让人头疼的问题之一。我整理了一个排查清单，按顺序检查：
- 检查
max-num-seqs：是不是设得太小？默认256，如果设成16，那并发上限就是16。 - 检查显存：
gpu-memory-utilization是不是设得太低？显存没用满，并发自然上不去。 - 检查
max-model-len：是不是设得太大？每个请求预分配的KV Cache太多，能同时处理的请求就少。 - 检查请求分布：是不是有很多超长请求？一个超长请求占用的资源相当于几十个普通请求。
- 检查GPU利用率：如果GPU利用率很低，说明瓶颈不在GPU，可能在CPU预处理或者网络。
- 检查批次大小：vLLM的批次是动态的，如果请求来得太慢，批次攒不起来，GPU就空转。
- 检查swap：如果KV Cache频繁换入换出，性能会大幅下降。看swap的使用率。
- 检查温度：GPU温度过高会降频，性能下降。看温度是否超过80度。
这个清单我基本每次排查都会过一遍，大部分问题都能定位到。
8.3 一些让部署更稳的小技巧
最后分享几个实战中总结的小技巧，都是文档里不会写的：
技巧一：预热。vLLM启动后第一次推理会比较慢，因为要编译CUDA kernel、初始化各种缓存。生产环境建议在服务正式接流量前，先发几个预热请求，把常用路径跑一遍。这样第一个真实请求的延迟就不会太高。
技巧二：限制单请求最大token数。在网关层限制max_tokens，防止某个请求生成几千个token把资源占满。一般设512到1024就够了，除非业务确实需要长生成。
技巧三：用流式输出。对于交互式应用，开启流式输出（streaming）能大幅提升用户体验。虽然总生成时间没变，但用户看到第一个token的时间早，感觉上快很多。vLLM的OpenAI接口支持stream: true。
技巧四：定期重启。大模型服务跑久了可能会有显存碎片或者内存泄漏，定期重启（比如每周一次）能保持稳定。重启用优雅重启，别直接kill。
技巧五：保留降级方案。大模型服务不是100%可靠的，要有降级方案。比如模型服务挂了，自动切换到小模型或者规则引擎，保证业务不中断。降级方案平时要演练，别等真出事了才发现不能用。
技巧六：文档化。部署过程中的所有配置、参数、踩过的坑都要文档化。大模型部署的细节太多，人的记忆不可靠。文档化不仅方便自己回顾，也方便团队协作和交接。
这些技巧看起来简单，但都是真金白银换来的经验。私有化部署大模型是个系统工程，光把服务跑起来只是第一步，要让它稳定、高效、安全地运行，需要持续的调优和运维。希望这篇内容能帮你少走一些弯路。
