企业官网建设流程全解析

1. 为什么企业都在折腾私有化大模型部署

这两年跟不少做基础架构的朋友聊天，话题绕来绕去最后总会落到同一个点上：模型能力已经摆在那了，真正让人头疼的是怎么把它稳稳当当地塞进自己机房里，还得让业务方用得舒服。公有云API调用确实省事，但数据出域、调用成本、响应延迟这三座大山压下来，稍微有点规模的业务都扛不住。特别是金融、医疗、制造业这几个圈子，数据合规的红线碰都不能碰，私有化部署几乎是唯一解。

vLLM这个推理引擎就是在这个背景下火起来的。它最早是某高校实验室搞出来的开源项目，核心卖点就一个：把显存利用率拉满，让同样的卡跑出几倍的吞吐。传统推理框架做KV Cache的时候要么预分配一大块显存浪费严重，要么动态分配碎片化厉害，vLLM用了个叫PagedAttention的机制，把KV Cache切成固定大小的块来管理，思路跟操作系统虚拟内存分页几乎一模一样。这个设计直接让显存浪费从60%以上降到4%以下，吞吐量提升肉眼可见。

这篇内容适合谁看？如果你手里有几张A100或者H800，正琢磨着怎么给公司内部搭一套能扛住并发的大模型服务，那接下来的东西应该能帮你少走不少弯路。如果你只是想在单卡上跑个demo玩玩，那vLLM也能用，但很多调优参数你可能感受不深。我会从整体架构设计讲到具体参数怎么调，再到踩过的坑怎么填，尽量把每个决策背后的逻辑说清楚。

2. 部署前的整体架构设计与选型考量

2.1 推理引擎选型：为什么是vLLM而不是其他

市面上做LLM推理的方案不少，TensorRT-LLM、TGI、DeepSpeed-Inference各有各的拥趸。我当初选型的时候把几个主流方案都跑了一遍，最后落在vLLM上，主要基于几个很实际的考量。

TensorRT-LLM性能确实猛，NVIDIA亲儿子，算子融合做得极致，但它的模型转换流程太折磨人了。每次换个模型版本都要重新走一遍编译流程，调试信息也不够友好，出了问题排查起来像在黑盒里摸象。TGI是HuggingFace家的，生态整合好，部署简单，但它的调度策略相对保守，高并发场景下吞吐量跟vLLM比有差距。DeepSpeed-Inference更适合研究场景，生产环境的稳定性还需要更多验证。

vLLM最大的优势在于它的PagedAttention和Continuous Batching这两个机制配合起来，能把GPU利用率推到很高。Continuous Batching的意思是，不等一个batch里所有请求都生成完才处理下一批，而是哪个请求结束了就立刻把新请求塞进去，GPU几乎不会空转。这个在真实业务场景里太重要了，因为用户请求的长度参差不齐，传统静态batching会有大量等待时间。

注意：vLLM对模型架构的支持有优先级，Transformer类模型支持最好，一些特殊架构（比如Mamba）的支持还在完善中。选型前先去官方文档确认你要部署的模型在不在支持列表里。

2.2 硬件配置的取舍逻辑

硬件这块没有标准答案，但有几个关键参数决定了你的部署方案。首先是显存容量，它直接决定了你能跑多大的模型。粗略估算的话，FP16精度下，模型权重占用的显存大约是参数量乘以2字节。比如一个70B的模型，光权重就要140GB左右，加上KV Cache和中间激活值，至少需要2张80GB的卡才能跑起来。

但实际部署中你会发现，光看显存容量不够，显存带宽往往才是瓶颈。A100的HBM2e带宽是2TB/s，H800是3.35TB/s，这个差距在长序列推理时体现得特别明显。我实测过一个13B模型在A100和H800上的表现，短序列（输入输出都在512 token以内）差距不大，但序列长度拉到4K以上，H800的吞吐量能高出40%左右。

卡间互联也值得说道。NVLink和PCIe的带宽差距是数量级的，如果你打算做张量并行（Tensor Parallelism），NVLink几乎是必须的。PCIe环境下做TP，通信开销会把并行带来的收益吃掉大半。所以如果预算允许，尽量选同一台机器内NVLink互联的卡，实在不行再考虑多机方案。

2.3 网络与存储的前置准备

模型文件动辄几十上百GB，从存储加载到显存的时间如果太长，服务重启会变成一件很痛苦的事。我建议把模型文件放在本地NVMe SSD上，读取速度能到3GB/s以上，一个70B的模型加载时间可以控制在1分钟以内。如果放在网络存储上，这个时间可能翻好几倍。

网络方面，如果做多机推理，节点间至少需要25Gbps以上的带宽。100Gbps RoCEv2是更理想的选择，但需要交换机支持PFC和ECN，配置起来有一定门槛。单机多卡的话，NVLink内部通信就够了，网络压力不大。

3. 核心细节解析与实操要点

3.1 PagedAttention到底解决了什么问题

要理解vLLM为什么快，得先搞明白传统KV Cache管理的痛点。在标准Transformer推理中，每个请求的KV Cache需要预先分配一块连续显存，大小等于最大序列长度乘以层数乘以注意力头维度。问题是，大部分请求的实际生成长度远小于最大长度，预分配的空间就白白浪费了。更麻烦的是，不同请求的KV Cache大小不一，显存碎片化严重，最后可能总显存够但找不到连续的大块空间。

PagedAttention的思路是把KV Cache切成固定大小的block，比如每个block存16个token的KV。每个请求维护一个block table，记录它用了哪些block。这些block在物理显存上不需要连续，逻辑上通过block table映射成连续的序列。这个设计跟操作系统用页表管理虚拟内存是一个道理。

带来的好处很直接：显存浪费从预分配模式下的60%-80%降到4%以下，同样硬件能同时服务的请求数翻了好几倍。而且因为block是固定大小，显存分配和回收都很快，不会产生碎片。

提示：vLLM的block size可以通过--block-size参数调整，默认是16。调大能减少block table的管理开销，但内部碎片会增加；调小则相反。大多数场景下默认值就够用，除非你有特别的序列长度分布。

3.2 张量并行的切分策略与通信开销

当单卡显存装不下模型时，张量并行（TP）是最常用的方案。它的做法是把每一层的权重矩阵按维度切分到多张卡上，每张卡计算一部分，然后通过All-Reduce通信把结果汇总。比如一个注意力层的QKV投影矩阵，可以按列切分成N份，每张卡负责一份。

TP的通信开销跟切分数量成正比。2卡TP的通信量是单卡的1倍，4卡就是3倍。所以TP不是越多越好，一般建议控制在8卡以内。超过8卡，通信开销的增长会超过计算收益，整体吞吐反而下降。

实际配置中，--tensor-parallel-size这个参数要跟你的卡数匹配。比如4张A100，可以设成4，也可以设成2然后跑两个实例。哪种更好取决于你的请求模式：如果请求的序列长度差异很大，两个TP=2的实例可能比一个TP=4的实例吞吐更高，因为调度粒度更细。

# 4卡TP=4的启动命令 python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000

3.3 量化方案的选择与精度权衡

量化是降低显存占用的另一条路。vLLM支持AWQ、GPTQ、FP8等多种量化格式。AWQ和GPTQ是4bit量化，能把显存占用降到FP16的1/4左右，但精度损失因模型而异。FP8是8bit量化，精度损失更小，但需要H100/H800这种支持FP8的硬件。

我实测过几个模型在AWQ 4bit下的表现，大部分场景下跟FP16的差异肉眼很难分辨，但在需要精确推理的任务上（比如数学计算、代码生成），4bit量化的错误率会明显上升。所以我的建议是：对话类应用可以放心用4bit，推理密集型任务还是老老实实上FP16或者FP8。

注意：量化模型的加载需要对应的量化配置，AWQ模型在加载时要指定--quantization awq，否则会报错。另外不是所有模型都有现成的量化版本，自己量化需要额外的校准数据集和计算资源。

4. 实操过程与核心环节实现

4.1 环境搭建与依赖安装

环境这块我踩过最大的坑就是CUDA版本和PyTorch版本的匹配。vLLM对版本比较敏感，官方推荐用CUDA 12.1以上配PyTorch 2.1以上。如果你用conda装，建议直接创建一个干净的环境，别在已有环境上折腾，依赖冲突能让你怀疑人生。

# 创建虚拟环境 conda create -n vllm python=3.10 -y conda activate vllm # 安装vLLM，会自动拉取匹配的PyTorch pip install vllm # 验证安装 python -c "import vllm; print(vllm.__version__)"

如果网络环境受限，可以用国内镜像源加速。但要注意有些镜像源同步不及时，可能拉不到最新版本。我一般用清华源，大部分时候没问题。

pip install vllm -i https://pypi.tuna.tsinghua.edu.cn/simple

安装完成后，建议跑一个简单的推理测试确认环境没问题。用vLLM自带的示例脚本就行，加载一个小模型比如Qwen-7B，生成几句话看看输出是否正常。

4.2 模型下载与格式转换

模型下载是个体力活，几十GB的文件从HuggingFace拉下来，网络不稳的时候能下一整天。我一般用huggingface-cli配合--resume-download参数，断了能续传。

# 安装huggingface-cli pip install huggingface_hub # 下载模型，支持断点续传 huggingface-cli download Qwen/Qwen-7B-Chat \ --local-dir /data/models/Qwen-7B-Chat \ --resume-download

如果模型是safetensors格式，vLLM可以直接加载，不需要转换。但如果是PyTorch的bin格式，建议转成safetensors，加载速度更快，安全性也更好。转换脚本HuggingFace提供了，几行代码的事。

from safetensors.torch import save_file import torch # 加载bin格式权重 state_dict = torch.load("pytorch_model.bin", map_location="cpu") # 保存为safetensors save_file(state_dict, "model.safetensors")

提示：下载大模型前先确认磁盘空间，一个70B模型FP16格式大约140GB，加上转换过程中的临时文件，建议预留300GB以上空间。

4.3 服务启动参数详解与调优

启动vLLM服务时，有几个参数直接决定了服务的性能和稳定性，我逐个说一下我的理解。

--gpu-memory-utilization控制vLLM能使用的显存比例，默认0.9。这个值不能设太高，因为CUDA本身和一些中间操作需要预留显存，设成0.95以上容易OOM。但也不能太低，否则KV Cache空间不够，并发上不去。我一般设0.85到0.9之间，根据实际显存大小微调。

--max-model-len是模型支持的最大序列长度。这个值设得越大，KV Cache占用的显存越多。如果你的业务场景输入输出都在2K token以内，就没必要设成8K，白白浪费显存。我一般会统计一下线上请求的序列长度分布，取P99值再留一点余量。

--max-num-seqs控制同时处理的最大请求数。这个值跟显存大小和序列长度有关。显存充足时可以设大一些，比如256；显存紧张时设小一些，比如64。vLLM会根据实际显存动态调整，但设一个上限能防止突发流量把显存打满。

# 生产环境启动示例 python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen-7B-Chat \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.88 \ --max-model-len 4096 \ --max-num-seqs 128 \ --served-model-name qwen-7b \ --port 8000 \ --host 0.0.0.0

启动后可以用curl测试一下服务是否正常。

curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen-7b", "prompt": "你好，请介绍一下你自己", "max_tokens": 100, "temperature": 0.7 }'

4.4 压力测试与性能基线建立

服务跑起来只是第一步，知道它能扛多少并发才是关键。我一般用locust或者wrk做压测，但这两个工具对LLM场景的支持不够直观，后来换成了vLLM自带的benchmark脚本。

# 使用vLLM benchmark工具 python -m vllm.benchmarks.benchmark_serving \ --backend openai \ --base-url http://localhost:8000 \ --model qwen-7b \ --num-prompts 1000 \ --request-rate 10

这个脚本会模拟不同请求速率下的表现，输出吞吐量、延迟分布等关键指标。我一般会跑几轮，从低速率开始逐步加压，找到吞吐量开始下降的拐点，那个点就是当前配置下的最优工作负载。

压测时重点关注两个指标：Time to First Token（TTFT）和Time per Output Token（TPOT）。TTFT反映的是用户等待第一个字出来的时间，TPOT反映的是生成速度。对话场景下TTFT更重要，因为用户对首字延迟很敏感；批量生成场景下TPOT更关键，因为它决定了整体完成时间。

注意：压测时不要用生产环境正在服务的实例，压测流量会挤占正常请求的资源。最好单独起一个实例做压测，或者选择业务低峰期进行。

5. 常见问题与排查技巧实录

5.1 显存溢出（OOM）的排查思路

OOM是部署vLLM时最常见的问题，没有之一。报错信息一般是CUDA out of memory，但背后的原因可能有好几种。

第一种是模型本身太大，单卡装不下。这种情况看报错时显存缺口有多大，如果只差几个GB，可以尝试降低--gpu-memory-utilization或者启用量化。如果差得太多，就得考虑TP或者换卡了。

第二种是KV Cache空间不足。表现是服务能启动，但并发一上来就OOM。这时候要检查--max-model-len和--max-num-seqs是不是设得太激进。我遇到过一个案例，max-model-len设了32K，但实际业务请求平均长度不到1K，白白浪费了大量显存给KV Cache预留。改成4K后，并发能力直接翻倍。

第三种是显存碎片化。长时间运行后，显存分配器可能产生碎片，导致明明总显存够但分配失败。vLLM的PagedAttention本身就是为了解决碎片问题设计的，但如果你的服务跑了很久没重启，还是可能遇到。定期重启服务是个简单有效的办法。

# 查看GPU显存使用情况 nvidia-smi # 更详细的显存分配信息 python -c "import torch; print(torch.cuda.memory_summary())"

5.2 推理速度慢的优化方向

推理速度慢可能出在多个环节，需要逐层排查。

先看是不是模型加载的问题。如果每次请求都重新加载模型，那肯定慢。vLLM默认会把模型常驻显存，不会重复加载。检查一下启动日志，确认模型只加载了一次。

再看是不是batching没生效。vLLM的Continuous Batching需要一定并发量才能体现优势，如果请求是串行的，每个请求单独处理，那跟普通推理没区别。可以适当增加客户端并发数，让vLLM有机会做batch。

然后看是不是序列太长。长序列的注意力计算是O(n²)复杂度，序列长度翻倍，计算量翻四倍。如果业务允许，尽量控制输入输出长度。实在需要长序列，可以考虑用FlashAttention或者PagedAttention的优化版本。

最后看是不是通信瓶颈。多卡TP场景下，卡间通信如果走PCIe而不是NVLink，通信开销会很大。用nvidia-smi topo -m可以查看卡间互联类型，确认是不是NVLink。

5.3 服务稳定性保障经验

生产环境的稳定性和实验室跑demo是两码事。我总结了几个保障稳定性的关键点。

健康检查必须做。vLLM提供了/health接口，Kubernetes的liveness probe可以配这个。但要注意，模型加载期间服务是不可用的，健康检查要设置足够的初始延迟，否则容器会被反复重启。

日志要收集全。vLLM的日志包括请求日志、错误日志、性能日志，分开收集方便排查。我一般用ELK或者Loki做日志聚合，出问题时能快速定位。

监控要到位。除了常规的CPU、内存、GPU监控，还要监控vLLM特有的指标，比如运行中的请求数、等待队列长度、KV Cache使用率。这些指标能提前预警容量问题。

提示：vLLM暴露了Prometheus格式的metrics接口，路径是/metrics。配一个Prometheus抓取任务，再配几个告警规则，能省很多半夜起来处理故障的麻烦。

5.4 模型更新与版本管理

业务迭代过程中，模型更新是常态。怎么做到不中断服务地更新模型，是个需要提前设计的问题。

最简单的方案是蓝绿部署。起一个新版本的实例，等它加载好模型、健康检查通过后，把流量切过去，然后下线旧实例。这个方案需要双倍资源，但切换过程平滑，回滚也快。

资源紧张的话可以用滚动更新。逐个替换实例，每次只更新一个，更新完确认没问题再更新下一个。这个方案资源占用少，但更新期间服务容量会下降，需要评估业务能否接受。

模型文件的管理建议用版本号区分，别用latest这种模糊的标签。每次更新记录清楚模型版本、量化方式、启动参数，出问题时能快速回滚到已知可用的版本。

# 模型目录结构建议 /data/models/ ├── qwen-7b-chat/ │ ├── v1.0-fp16/ │ ├── v1.1-awq/ │ └── v1.2-fp8/ └── qwen-14b-chat/ ├── v1.0-fp16/ └── v1.1-awq/

6. 一些掏心窝子的实操心得

部署vLLM这件事，说难不难，说简单也不简单。框架本身已经把很多复杂的东西封装好了，但生产环境的各种边界情况还是得自己趟。我最大的体会是，别一上来就追求极致性能，先把服务跑通、跑稳，再逐步调优。很多性能问题不是调参能解决的，而是架构设计阶段就埋下的。

另外，压测数据只能参考，不能全信。实验室环境跟生产环境的请求模式差异很大，线上真实的序列长度分布、并发模式、错误率，都跟压测脚本模拟的不一样。我一般会在生产环境先小流量灰度，观察真实表现后再逐步放量。

最后说个容易被忽略的点：文档。部署过程中遇到的每个问题、每个参数的调整理由、每次故障的处理过程，都值得记录下来。过几个月再回头看，这些记录能帮你省下大量重新摸索的时间。团队里其他人接手时，也能快速上手。