企业官网建设流程全解析

上周临时接手一个私有化部署项目，要在单机双卡上把 Qwen3 30B 的 FP8 权重用 vLLM 跑成对外服务。机器是双卡，显存合计 48GB，权重、KV cache、激活都得挤在这 48GB 里，任何参数稍微激进一点就会直接翻车。整个过程走下来，最大的感受是：网上聊 vLLM 部署的文章很多，但真遇到显存边界、FP8 混合权重、张量并行通讯这类问题，还是要靠现场一点一点排查。这篇就是那次部署的完整踩坑记录。

如果你正准备做 30B 级模型的双卡私有化部署，或者对 FP8 到底能省多少显存、会带来哪些启动问题感兴趣，这篇文章会比较对胃口。我会从选型时的显存账开始讲，然后是权重准备、启动参数、三次印象深刻的报错、最后的压测数据，最后给出可以直接套用的启动脚本。

1. 从显存账说起：为什么最后定在 Qwen3 30B + FP8 + 双卡

1.1 项目需求与硬件约束

我手头这个项目来自一个朋友的公司，要对外提供文档摘要服务，对模型效果要求不能太低，于是范围大致锁定在 30B 量级的开源模型。硬件方面有个硬约束：客户不打算采购新设备，只允许用机房现有的单机双卡服务器。单卡 24GB、双卡合计 48GB，这台机器之前只跑过 7B 和 14B 的模型，要直接上 30B 需要仔细掂量。

30B 量级模型用 BF16 格式存储，权重大约 60GB。双卡合计 48GB 根本装不下；理论上 INT4 能装下，但 int4 的精度损失和 kernel 兼容性都让人不放心。中间我试过把 BF16 权重硬塞进双卡，还没等 vLLM 完成权重加载，CUDA OOM 就来了。于是 FP8 进入备选：同样 30B 参数，FP8 权重约 30GB，双卡还剩 18GB 给 KV cache 和激活，虽然紧但有余地。再叠加当时 vLLM 对 FP8 的支持已经比较成熟，就这么定了。

1.2 显存账怎么算

部署前我习惯先手算一次显存账，不是精算，而是为了避免被“应该是够的吧”这种想法坑到。30B 参数，BF16 下每个参数占 2 字节，权重约 60GB；FP8 下每个参数占 1 字节，权重约 30GB。注意这只是权重本身，还没算 CUDA context 和每个进程的中间 buffer。双卡 TP=2 时，每一张卡只需要装一半权重，约 15GB。

KV cache 的估算要依赖具体模型的注意力结构。Qwen3 30B 这类模型用了分组查询注意力结构，KV cache 相对传统多头注意力已经小了不少，但双卡合计可用显存只有 48GB，扣掉权重后每张卡大约剩下 9GB 可用。这 9GB 里还要放运行时临时张量和 prefill 中间结果，所以 max_model_len 和并发数不能拍脑袋设。我后续把 max_model_len 从 32768 一路降到 16384，本质就是在还这笔显存账。

KV cache 大致的估算公式是：2（K 和 V 两份）乘层数、注意力头数、每头维度、序列总长、dtype 字节数。序列总长是并发下所有请求序列长度的总和。把 max_model_len 设为 16384，如果只剩 10GB 给 KV cache，vLLM 就能算出能分配的 block 数，超出的请求会被拒；设成 32768 时，KV cache 占用的显存翻倍，启动阶段就可能直接失败。这也是后面 OOM 的根源。

其实当时还有一个备选方案：在单卡 80GB 显存的机器上跑 BF16，但客户只有这台双卡机器，租卡又超预算。综合下来，FP8 双卡方案不是最优解，而是在现有硬件约束下的最不坏解。认清这一点很重要，因为后面所有参数调优都围绕“如何把显存用得更狠但又不越过红线”。

2. FP8 权重准备：下载之后先做一次 dtype 审计

2.1 现成量化权重还是自己转换

FP8 权重有两个来源：直接用社区中转好的量化权重，或者自己拿 BF16 权重做 FP8 转换。一开始我想省事，直接从社区拉了一份标注“FP8 全量权重”的权重包，约 31GB，8 个 safetensors 分片。结果启动时发现模型里混着 BF16 层，这就是没做 dtype 审计的教训。

自己转的好处是可以按显存余量决定跳过哪些层，并且能确认最终 dtype 分布。代价是转换需要一台能装下完整 BF16 权重的机器，量化耗时也看模型规模。Qwen3 30B 如果自己转换，在一台 80GB 显存的机器上大概半小时到一小时可以完成，跑多少步量化校准则取决于工具。为了上线效率，很多人会直接拿现成权重，但我不建议拿到手就开始部署，最好先扫描一遍权重内部 dtype。

2.2 用 safetensors 扫一遍权重 dtype

我写了一个小脚本，用来查一个权重目录内所有张量的 dtype 分布：

import glob from collections import Counter from safetensors import safe_open dtype_counter = Counter() file_list = sorted(glob.glob("/data/models/qwen3-30b-fp8/*.safetensors")) for path in file_list: with safe_open(path, framework="pt", device="cpu") as f: for name in f.keys(): tensor = f.get_tensor(name) dtype_counter[tensor.dtype] += 1 print(dtype_counter)

跑出来大概是：绝大多数张量是torch.float8_e4m3fn，一小部分是torch.bfloat16。看到这个结果先别急着骂权重发布者，因为量化工具通常有意把某些敏感层保留为 BF16。常见被保留的是 embedding 层、lm_head（输出头）和个别容易被量化噪声放大的层。这是很常见的做法，不是权重损坏。

2.3 混合 dtype 会在启动时变成报错

混合精度不是问题，问题在于 vLLM 默认按配置文件里的量化声明去加载。如果权重里的 lm_head 是 BF16，而量化配置里没有把它列入忽略列表，加载时就会报类似“expected float8_e4m3fn, got bfloat16”的错误。所以要提前核对权重目录里的模型配置和实际 dtype 是否一致。

如果发现不一致，处理顺序是：确认权重发布方是否额外提供了适配 vLLM 的配置文件；没有的话，可以自己按 vLLM 支持的量化配置格式，给非量化层补充忽略列表。我这次最终用了权重发布方配套的配置，没有自己造。这个步骤虽然简单，但能省得后面启动时两眼一抹黑。

3. vLLM 启动参数：TP=2、KV cache 与 max_model_len 的三组取舍

3.1 双卡并行不是填个数字就行

部署第一步是设置张量并行。vLLM 命令行里对应--tensor-parallel-size 2，它会把模型权重按层切成两半，分别加载到两张卡上，forward 时通过 NCCL 做通信。TP=2 对 30B 模型很合适，因为单卡放不下完整权重，而 4 卡以上会有更高的通信开销和更复杂的调度问题。

这里最容易踩的坑是卡序。机器上可能插了多张显卡，vLLM 看到的设备编号和你心里想的物理编号不一定一致。我习惯先通过显卡驱动自带的状态命令查看显卡之间的连接拓扑，再在启动命令里用CUDA_VISIBLE_DEVICES指明要用的物理卡。比如打算用物理 2、3 号卡，就写CUDA_VISIBLE_DEVICES=2,3，这样 vLLM 内部看到的 rank 0 和 rank 1 就分别对应物理 2、3 号卡。如果你写的是CUDA_VISIBLE_DEVICES=1,3，而这两张卡不在同一个高速互连域里，TP 后每次 forward 都要走 PCIe，吞吐会明显变差。

另外要留意容器共享内存。TP 多卡启动时，rank 之间需要同步状态，NCCL 初始化会用到共享内存。Docker 默认共享内存经常只有 64MB，对 30B 模型的多卡初始化来说很容易卡住。这个坑我后面单独讲，但建议一开始就把容器共享内存设到 16GB 甚至更高。

3.2 KV cache 是按预算分配的

vLLM 里 KV cache 不是按需分配，而是启动时基于gpu_memory_utilization预算出来的。模型权重先占掉显存，剩下的显存会被切成 block 作为 KV cache。gpu_memory_utilization默认值一般是 0.9，表示它能“看到”每张卡 90% 的显存，然后在这块区域内同时装权重和 KV cache。双卡部署时，这个值以单卡为粒度，不是两张合起来算。

这带来一个直觉陷阱：你以为双卡 48GB 减去 FP8 权重 30GB 还剩 18GB，很宽裕。但在 TP=2 下，每张卡只装 15GB 权重，如果设--gpu-memory-utilization 0.92，每张卡可用约 22GB，减掉 15GB 权重后还有 7GB 给 KV cache；两张卡合计 KV cache 大概 14GB。如果设成 0.98，则每卡可用 23.5GB，看起来剩余很多，但 CUDA context 和激活一挤，可能直接 OOM。所以 0.90 到 0.92 是我这次试下来相对安全的区间。

max_model_len决定了单条请求输入加输出能到多长，同时直接影响 KV cache 预算。同样显存下，max_model_len从 32768 降到 16384，KV cache 占用明显收缩，能承载的并发请求也更多。我建议先用实际业务里的最长文档长度乘一点余量来估算，而不是照着模型上下文上限填。最后稳定运行的参数组合大概是这样：

4. 启动阶段三个印象最深的报错

4.1 张量并行启动卡死

第一次启动时，日志停在权重加载完成后的位置，类似 “Waiting for all TP ranks to start”，等二三十秒才报 NCCL timeout。这类启动卡死大多不是模型代码问题，而是多进程通信问题。

我当时先检查了 NCCL 相关环境变量，发现容器共享内存只有 64MB。TP 两个 rank 之间需要通过共享内存交换元数据，64MB 太小导致握手失败。把容器启动参数改成--shm-size=16g后，vLLM 正常完成初始化。如果权重放在网络文件系统（NFS）上，还可能遇到两个 rank 抢同一个权重文件锁的问题，表现也类似。最简单的方法是把权重下载到本地磁盘，减少 IO 和锁竞争。

4.2 FP8 权重加载报 dtype 错

第二次启动时，vLLM 在加载权重的步骤直接报错，大意是ValueError: lm_head.weight expected dtype torch.float8_e4m3fn but found torch.bfloat16。看到这个报错我心里反而踏实了，因为之前做过 dtype 审计，知道这个层本来就是 BF16。根因就是权重发布方的量化流程把输出头保留为 BF16，但量化配置里没有对应说明，vLLM 默认按全 FP8 处理。

解决办法是让配置明确写出哪些层不用量化。可以在权重目录的配置文件中检查量化相关字段，按 vLLM 支持的格式补充忽略列表；如果权重自带适配配置，直接使用。我不建议用脚本强行把 BF16 层转成 FP8，虽然能绕过报错，但会把模型输出头压到 8bit，可能影响生成质量。绕过报错的同时，也一定要在评测集上验证效果。

4.3 服务起来了，第一条请求却打爆显存

第三次问题最隐蔽：服务能启动，日志显示 KV cache 已经预分配完，但压测脚本一发长文档请求，CUDA OOM 直接出现，服务返回 503。

根因是max_model_len设得太激进。长 prompt 的 prefill 阶段会产生大量中间激活张量，这些不完全在 KV cache 预分配里。尤其是我之前把max_model_len设成 32768，长文档请求的 prefill 峰值可以到好几个 GB，直接把最后的显存余量顶穿。

解决方法是把max_model_len从 32768 降到 16384，同时开启--enable-chunked-prefill，让长 prompt 分块做 prefill，峰值明显下降。如果模型支持 FP8 KV cache，再把--kv-cache-dtype fp8_e5m2打开，KV cache 显存还能再省接近一半。之后同一批测试请求就稳定跑过了。

5. 压测调优：FP8 带来的吞吐和延迟变化

5.1 压测对比数据

跑通之后，我做了两组对比测试。测试集是 30 条文档摘要请求，平均输入 6000 tokens，平均输出 400 tokens，并发请求 16。因为这台 48GB 双卡机器装不下 BF16 权重，BF16 基线是用另一台有 80GB 显存的机器单独测的，FP8 数据则是在双卡 48GB 机器上测的。模型、请求、采样参数保持一致。

结果如下：

FP8 相比 BF16，总吞吐提升大约 45%，首 token 延迟和每个输出 token 的延迟也都有改善。一方面是因为权重显存减半，能容纳更大的 KV cache 和更多 batch；另一方面是 FP8 计算在部分显卡上有更高的理论吞吐。省下来的显存换来的是更激进的并发配置，这让 FP8 的收益远不止“省显存”这么简单。不过这个数值会因具体显卡型号、驱动版本而差异很大，不要当成硬指标。

5.2 参数再调整

第一版 FP8 双卡配置在并发 8 时表现不错，但并发上到 32 后吞吐不再线性增长，瓶颈从显存变成了 batch 调度。后来开了--enable-prefix-caching，相同前缀的长文本请求 TTFT 明显下降，因为相同前缀的 KV cache 被直接复用了；代价是多占一点显存。再调--max-num-batched-tokens 4096之后，单次迭代能吞下的 token 变多，吞吐又提了一截。

另外，FP8 精度问题要实测。我跑了三个业务场景的摘要一致性评测，和 BF16 相比结果基本一致，个别长尾案例有偏差，但在可接受范围。如果你的业务是代码生成或者要求严格数值输出的场景，建议把 FP8 和 BF16 的各自输出对比一遍再上线，不要盲信“FP8 无损”。

6. 最终稳定运行的配置与收尾经验

6.1 可以直接套用的启动命令

最后给一份我们线上已经在用的启动命令，路径按你自己的权重目录改：

CUDA_VISIBLE_DEVICES=2,3 \ vllm serve /data/models/qwen3-30b-fp8 \ --tensor-parallel-size 2 \ --max-model-len 16384 \ --gpu-memory-utilization 0.90 \ --kv-cache-dtype fp8_e5m2 \ --max-num-batched-tokens 4096 \ --max-num-seqs 32 \ --enable-chunked-prefill \ --enable-prefix-caching

注意：--kv-cache-dtype fp8_e5m2依赖具体模型和 vLLM 版本的 kernel 支持。如果启动时报 kernel 不支持，直接删掉这个参数，回退到 auto 即可。CUDA_VISIBLE_DEVICES=2,3要根据实际卡槽情况调整，如果机器只有两张卡，就写CUDA_VISIBLE_DEVICES=0,1。

6.2 上线后还要盯的几个点

容器共享内存建议在创建容器时就设置大一点，例如--shm-size=16g。权重文件尽量放本地 SSD，不要放在 NFS。vLLM 服务进程建议交给 systemd 或 supervisor 托管，机器重启后自动拉起。另外建议定期看显存占用和卡间通信状态，出现 NCCL 相关报错时优先检查共享内存和网络挂载。

跑了快两周，感觉最麻烦的确实是启动阶段那些混合 dtype 和 TP 通讯问题，真正进入稳定期之后反而省心。最后再分享一个实际体会：双卡部署 Qwen3 30B FP8，真正的复杂度都集中在权重 dtype、显存预算、TP 通信这三件事上，把这三点理顺，后面的运维并没有想象中难。把启动命令、权重审计脚本和压测数据固化到项目仓库里，下次换一台机器部署同样规格的模型，基本可以照着抄作业。