多模态模型本地部署，是不是非得 A100/H100 才能碰？这是我最近被问得最多的一句话。上个月我拿 3 张 RTX 4090 把 BAGEL-7B 整个跑通了，顺带把 Flash Attention 从编译到加载踩了个遍，最后得出的结论是：7B 级别的视觉语言模型，消费卡完全能扛，只是细节决定成败。
这篇文章就是一次完整的实战复盘，我会把下面这几件事讲透：BAGEL-7B 到底吃多少显存、为什么 3 张卡是这个规模的平衡点；驱动/CUDA/PyTorch 怎么对齐才不翻车；Flash Attention 安装时那一排编译报错逐个怎么解；最后是多卡推理选 vLLM 还是 transformers，以及我实测的性能数据。不管你手里是 1 张卡还是 4 张卡，看完都能照着这套思路去规划自己的部署方案。
1. 先算一笔账：BAGEL-7B 的显存需求到底是多少
1.1 别被"7B"骗了，它是 LLM + 视觉塔的组合体
动手之前很多人问我，7B 模型不是一张 24GB 显卡就够了吗，为什么非要三张 4090？每次我都让他们先去拆一下模型的 config.json 和权重文件再回来聊。BAGEL-7B 名义上是 7B，实际部署时的负载远不止 7B——它是典型的多模态结构，包含三个部分：
- 视觉塔（vision tower）：负责把图像切成 patch 并编码成视觉 token，我拿到的这个权重版本里是一个 ViT-L 规模的 encoder，参数大约 1.2B。
- 投影层（projector）：把视觉 token 映射到 LLM 的 embedding 空间，参数很少，基本可以忽略。
- LLM backbone：真正的 7B 语言模型，用的是 Llama 系结构，GQA 注意力 + SwiGLU + RoPE，支持文本和图像 token 混合建模。
所以真正要装进显存的是"7B + 1.2B + KV cache + 激活值 + 推理中间结果"，不是一个 7B 就完事。
先算静态权重：fp16 下每个参数占 2 字节，(6.7 + 1.2) × 10^9 × 2 ≈ 15.8GB。如果误用了 fp32，直接翻倍到 31GB 以上，单卡当场去世。这也是很多人第一次加载多模态大模型就 OOM 的头号原因——dtype 没设置。
再看 KV cache。我手里这个版本的 LLM 部分是 32 层、hidden size 4096、32 个 Q head、8 个 KV head（GQA）。每个 token 每层产生的 KV 缓存是 8（KV head）× 128（head dim）× 2（K 和 V）× 2（fp16 字节）= 4096 字节 = 4KB，32 层下来每个 token 就是 128KB。换算一下：
- 8K 上下文：约 1GB
- 32K 上下文：约 4GB
- 128K 上下文：约 16GB
注意这只是 KV cache，还没算图像 token 和激活值。一张图经 ViT 切成 patch 后能产生几百到上千个视觉 token，prefill 阶段所有 token 的激活值会瞬间涨起来。这么盘下来，单张 4090 的 24GB 在"fp16 + 8K 上下文 + batch 1"的极限场景下能挤进去，但只要你稍微想多开几个并发请求，KV cache 立刻就不够用了。
单卡能跑、单卡很勉强、单卡没法服务——这就是 BAGEL-7B 这类多模态模型的真实处境。
1.2 为什么是 3 张而不是 1 张、2 张、8 张
多卡并行的思路很简单：把模型切到多张卡上，每张卡只扛一部分权重和运算。我这里列一个对比表，是我在动手前的静态估算：
| 方案 | 显存总量 | 能做什么 | 典型瓶颈 |
|---|---|---|---|
| 1×4090 (24GB) | 24GB | fp16 + 8K 上下文 + 单用户，或 4bit 量化 + 较长上下文 | 并发一上来就 OOM，prefill 激活值紧张 |
| 2×4090 (48GB) | 48GB | fp16 + 32K 上下文 + 小并发 | 单用户场景够用，服务化后余量不足 |
| 3×4090 (72GB) | 72GB | fp16/bf16 + 32K~64K 上下文 + 4~8 并发服务 | PCIe 通信，无 NVLink |
| 8×4090 (192GB) | 192GB | 大上下文 + 大并发 | 通信开销大，收益递减明显 |
三卡方案的核心逻辑是"余量"。推理服务最怕的不是平均负载，而是峰值：一个超长 prompt 进来、一批图像 token 同时 prefill、多个请求同时 decode，显存占用会突然飙升 2~3 倍。72GB 给了足够的缓冲，让 KV cache 和激活值有地方待，不至于在业务高峰期直接 OOM 给你看。
至于 8 卡，纯粹是过度设计。7B 规模很小，TP=3 时单层计算量也就那么多，再往上加卡，跨卡同步的开销会吃掉大部分收益。何况 4090 没有 NVLink，卡间通信只能走 PCIe 4.0 x16，卡越多，通信等待越明显。
这里强烈建议动手前先跑一下 nvidia-smi topo -m 看看三张卡的物理拓扑，确认它们各自都在 x16 槽位上。如果有一张卡被插在 x8 甚至 x4 槽位上，那张卡的通信带宽会明显拖后腿。
账算完了，接下来是环境。
2. 环境准备：版本铁三角不对齐，后面全是白干
2.1 驱动、CUDA、PyTorch 的版本关系
多模态推理环境里，NVIDIA 驱动、CUDA Toolkit、PyTorch 三者是典型的铁三角。驱动版本决定你能不能支持 CUDA 12.x，CUDA Toolkit 提供编译和运行时的库，PyTorch 则要链接对应版本的 CUDA runtime。任何一个错位，常常不是安装的时候报错，而是运行到一半才冒出来一个奇怪的 CUDA error，排查成本极高。
我这次用的组合，实测稳定：
| 组件 | 版本 | 说明 |
|---|---|---|
| 操作系统 | Ubuntu 22.04 LTS | 内核 6.2+ |
| NVIDIA 驱动 | 550.54.15 | 至少 535 起步，否则 CUDA 12 跑不起来 |
| CUDA Toolkit | 12.4 | 通过 conda 装也可以，关键是跑 PyTorch 时不要混版本 |
| Python | 3.10.14 | 3.11/3.12 对部分 wheel 兼容性仍有坑 |
| PyTorch | 2.4.1 | 必须 cu124 版本，不是 CPU 版 |
| Transformers | 4.46.x | 高版本对多模态 LLM 的支持更完整 |
| Flash Attention | 2.6.3 | 后面专门讲，4090 上别装 3.x |
| vLLM | 0.6.5.post1 | 单独环境，避免 triton 冲突 |
驱动和 CUDA 的关系我多说一句：驱动是"操作系统和 GPU 之间的翻译官"，CUDA Toolkit 是"编译和运行 CUDA 代码的工具箱"。你装好驱动后，nvidia-smi 顶部显示的 CUDA 版本只是驱动所支持的最高版本，不代表你的 Python 环境就能用那个版本。PyTorch 是自带 CUDA runtime 的，所以最关键的是 PyTorch 的 cu 版本和驱动匹配，而不是你手动装了哪个 CUDA。
2.2 环境搭建命令
完整流程如下：
conda create -n bagel python=3.10 -y conda activate bagel安装 PyTorch（cu124 版）：
pip install torch==2.4.1 torchvision==0.19.1 torchaudio==2.4.1 --index-url https://download.pytorch.org/whl/cu124装完后立刻验证：
python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.device_count())"如果你看到 True 和 3，说明三张卡都被识别了。如果显示 False，大概率是驱动没装好或者 PyTorch 装成了 CPU 版，先别往后走，回头查这两个点。另外我建议跑一段真实的矩阵运算，而不是只看 is_available：
python -c "import torch; x=torch.randn(1024,1024,device='cuda:0'); print((x@x).shape); [print(torch.cuda.get_device_properties(i).name) for i in range(torch.cuda.device_count())]"这一步能确保 CUDA 上下文真的能在每张卡上创建，排查早期驱动问题特别管用。
2.3 为什么必须在意 sm_89 这个架构代号
装依赖之前，先记住一个数字：sm_89。4090 的 compute capability 是 8.9，对应的架构代号是 sm_89，属于 Ada Lovelace 代。A100 是 sm_80，H100 是 sm_90。这三个代号决定了 CUDA kernel 该怎么编译：一个为 sm_90 编译的 kernel，在 sm_89 上根本加载不了，运行时会直接报 "no kernel image is available for execution on the device"。
这个错误在 Flash Attention、xformers、bitsandbytes 这类底层库上特别常见。因为这些库都需要在安装时针对目标 GPU 架构编译 kernel，如果编译环境没有正确识别到 4090，它就会默认编译一个通用版本，或者干脆编译错架构。所以后面所有需要现场编译的组件，我都会带上 TORCH_CUDA_ARCH_LIST 这个环境变量，强制指定架构。
3. Flash Attention：整个部署里最折磨人的环节
3.1 先搞明白：4090 该装 FA2，不是 FA3
Flash Attention 用分块计算重写了注意力机制，把 O(n²) 的中间矩阵省掉，既省显存又加速，长上下文场景基本是必备。BAGEL-7B 也发布了对它的支持，但恰恰是坑最多的环节。
我见过太多人在 4090 上直接 pip install flash-attn 拿了最新版，结果装上后 import 报错。原因是 FlashAttention-3（FA3）主要面向 Hopper 架构（sm_90），也就是 H100 那代，用到了 wgmma 这类新指令集；4090 是 Ada（sm_89），根本用不上。你需要在 4090 上装的是 FlashAttention-2 系列。
我最后选的版本是 2.6.3，它同时包含 sm_80、sm_86、sm_89、sm_90 的 kernel，对 4090 支持良好。装之前也先确认一下 PyTorch 版本和 transformers 版本。
3.2 安装路径：源码编译的完整参数
Flash Attention 在 PyPI 上有预编译 wheel，但它的 wheel 强依赖 PyTorch 的编译 ABI，你环境的 torch 版本如果不是它编译时对应的版本，import 就会报 undefined symbol。为避免这种扯皮，我建议直接源码编译，一次配置好后大约 15 到 20 分钟出结果。
步骤：
# 安装编译工具链 conda install -c conda-forge ninja -y sudo apt install build-essential # 设架构，只编 4090 的 kernel export TORCH_CUDA_ARCH_LIST="8.9" # 限制并行编译任务数 export MAX_JOBS=4 # 安装 pip install flash-attn==2.6.3 --no-build-isolation这里几个参数解释一下：
- TORCH_CUDA_ARCH_LIST="8.9"：告诉编译系统只针对 Ada 生成 kernel，编译时间会显著缩短，也能避免默认多架构编译导致的各类兼容问题。
- MAX_JOBS=4：限制并行编译任务数，防止内存被编译器吃满导致 OOM。我之前用默认值编译时，内存直接飙到 40GB+，机器差点卡死。
- --no-build-isolation：让 pip 直接复用当前环境里的 torch 和 pybind11，避免它在隔离环境里又拉一套版本。
提示：编译 flash-attn 之前，先把 conda 环境里的 cudatoolkit 检查一遍。如果 conda 里已经装了 cudatoolkit，而 PyTorch 又是自带 CUDA runtime 的，编译时可能出现 -lcudart 找不到的链接错误。我踩过一次后，就直接不在 conda 环境里手动装 cudatoolkit 了。
装完验证：
python -c "import flash_attn; print(flash_attn.__version__)"能打印出 2.6.3 基本就成了。
3.3 编译期的高频报错与解法
我把这次实际遇到的、以及朋友遇到过的报错整理了一下：
- error: unsupported gpu architecture 'compute_89'
原因是 flash-attn 版本太老，老版本对 Ada 支持不完整。解决办法是升级到 2.4 以上。如果你因为某些原因必须用老版本，可以把 TORCH_CUDA_ARCH_LIST 设成 "8.0;8.6;8.9" 试试，但我不推荐绕。
- ninja 编译到一半卡住不动，或者直接报 Killed
前者通常是正在编译大量 kernel，正常现象，等就行；后者是内存吃紧，把 MAX_JOBS 调小到 4 甚至 2。编译过程中最好不要同时开 vLLM 服务。
- python -c "import flash_attn" 时报 undefined symbol
很典型的 ABI 不匹配。比如你之前装过一个在 PyTorch 2.1 下编译的 flash_attn wheel，后来 torch 升到 2.4，两者的 C++ ABI 对不上。解法：把 flash_attn 卸载，用上面的源码编译流程重装一遍。
- 和 xformers 的 kernel 冲突
如果环境里已有 xformers，flash_attn 的某些版本会和它在同一个 Triton 后端打架。BAGEL-7B 推理不需要 xformers，直接 pip uninstall xformers 即可。
还有一个隐形坑：如果你用 conda 的 cudatoolkit 版本和 PyTorch 自带的 cuda runtime 不一致，flash_attn 编译时可能报链接错误。这时统一用 PyTorch 自带的 CUDA，问题就没了。
3.4 怎么确认 Flash Attention 真的在推理时生效了
装完不代表它一定会被用上。在用 transformers 加载时，必须显式指定 attn_implementation="flash_attention_2"，否则某些模型会因为"配置里没写"或"版本判断不出来"而退回 eager 模式。我后面加载模型时会给出完整代码。简单判断方法：加载时如果看到 "setting attn_implementation to flash_attention_2" 之类的日志，并且没有 "Trying to use flash attention but ... falling back" 的警告，基本就是生效了。
4. 权重下载、加载和精度选择
4.1 下载通道与磁盘规划
BAGEL-7B 的权重不算小，fp16 的 safetensors 一套下来 20GB 左右，加上视觉塔权重、配置文件、tokenizer 等，建议预留 100GB 磁盘空间，别卡在大文件上下到一半没有盘了。
我个人推荐优先从 ModelScope（魔搭）这类源拉权重，大文件下载稳定性更好。流程是：
sudo apt install git-lfs && git lfs install git clone https://www.modelscope.cn/你的组织/BAGEL-7B.git如果你更习惯从 Hugging Face 拉权重，也可以直接用 huggingface-cli download 拉取，但注意保持完整的仓库结构，别只拖权重文件。很多多模态模型的加载依赖 config.json、preprocessor_config.json 和自定义 modeling 文件，缺一个都会在加载时报莫名其妙的问题。
4.2 加载前必查的三个配置
权重拉下来先别急着跑，打开 config.json 看三个地方：
- architectures 和 model_type：确认是不是你预想的 Llama 系结构，以及是否包含 vision_config / image_token_index 这类多模态字段。
- vocab_size：和模型权重里的 embedding 矩阵维度要一致。有些模型发布时 vocab 做过扩展，如果你用了一个不匹配的 tokenizer，生成的句子会乱码。
- max_position_embeddings：这个值决定模型自带的 RoPE 位置编码上限。比如默认 4096 的模型，你要硬塞 32K 上下文，不额外处理就会出警告或者效果变差。BAGEL-7B 如果官方明确支持长上下文，这个值通常已经调大。
除此之外，查看 tokenizer_config.json 里 chat_template 是否存在。我在第一次加载时没注意，结果 model 加载成功了，但一调 apply_chat_template 就报 AttributeError，折腾了半小时才发现是 tokenizer 文件没下全。
4.3 trust_remote_code：能不开就不开，开之前先看代码
多模态模型的视觉塔往往是自定义结构，transformers 内置的 AutoModel 认不出来，所以很多权重仓库要求加载时带 trust_remote_code=True。这个参数的含义是：允许 transformers 加载仓库里的自定义 Python 代码并执行。简单说，你运行的不是官方框架代码，而是权重作者写的代码——执行别人的代码，先确认来源可信。
我的做法：下载后先翻一翻仓库根目录下的 modeling_xxx.py，看看里面有没有可疑的操作（比如联网请求、执行系统命令）。正常情况下就是定义了几个自定义层，逻辑和官方实现没什么大区别，看一遍心里有底再 trust。如果某个仓库让你 trust 却连源码文件都不放完整，那建议直接换一个来源。
4.4 bf16 还是 fp16
4090 原生支持 bf16，所以推荐用 torch.bfloat16 加载。来对比一下两种精度的区别：fp16 的指数位只有 5 位，数值范围小，某些激活值稍大一点就容易溢出变成 inf 或 nan；bf16 的指数位有 8 位，范围和 fp32 一样宽，虽然尾数精度低一点，但对推理影响很小。FlashAttention-2 从 2.x 起就支持 bf16 的 K/V，所以多模态模型里视觉编码层的激活值不容易出问题。
5. 多卡并行：vLLM 和 transformers 两条路线怎么选
5.1 快速验证：transformers 的 device_map 方案
如果你只是想验证模型能不能跑、回答效果对不对，不需要上 vLLM，用 transformers 就足够了。加载代码：
from transformers import AutoModelForVision2Seq, AutoProcessor import torch model_path = "./BAGEL-7B" model = AutoModelForVision2Seq.from_pretrained( model_path, torch_dtype=torch.bfloat16, device_map="auto", attn_implementation="flash_attention_2", trust_remote_code=True, ) processor = AutoProcessor.from_pretrained(model_path, trust_remote_code=True)然后准备一张图和一段文字：
from PIL import Image image = Image.open("test.jpg") messages = [ {"type": "image", "image": image}, {"type": "text", "text": "请描述这张图片里的主要内容。"}, ] prompt = processor.apply_chat_template(messages, tokenize=False, add_generation_prompt=True) inputs = processor(prompt, image=image, return_tensors="pt").to("cuda:0") output = model.generate( **inputs, max_new_tokens=512, do_sample=False, ) print(processor.decode(output[0], skip_special_tokens=True))device_map="auto" 会自动把模型层按显存余量分配到三张卡上，这种切法本质是流水线并行——每一层完整存在于某一张卡上。好处是部署零成本，坏处是 prefill 阶段某一时刻只会有部分 GPU 在忙，利用率一般。但作为验证手段，它的稳定性是最好的。
5.2 服务化：vLLM 的 Tensor Parallel 配置
如果要给团队用，或者要接 OpenAI 兼容 API，直接用 vLLM。vLLM 内部自带 FlashAttention，而且它对 KV cache 做了 paged attention 管理，显存利用效率比 transformers 的 naive 实现高不少。
注意，vLLM 自带特定版本的 triton 和 flash_attn 依赖，所以我建议给 vLLM 单独建一个 conda 环境，别和上面的 transformers 环境混在一起，否则很可能出现 triton 版本冲突，表现为 vLLM 启动时报一大堆不相关的错误。
pip install vllm==0.6.5.post1启动服务：
vllm serve /data/BAGEL-7B \ --tensor-parallel-size 3 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --dtype bfloat16 \ --trust-remote-code \ --port 8000参数解释：
- tensor-parallel-size 3：把权重和注意力计算切到 3 张卡上，这是三卡部署的核心。
- max-model-len 32768：KV cache 的配额是按这个值预先规划的，设得过大，启动时可能直接 OOM；设得过小，长文本会被截断。
- gpu-memory-utilization 0.92：预留 8% 的显存给 CUDA context 和临时分配，别设成 1.0，否则多卡环境下容易在运行时才炸。
等服务起来后，用 curl 验证：
curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "/data/BAGEL-7B", "messages": [ {"role": "user", "content": [ {"type": "image_url", "image_url": {"url": "http://127.0.0.1:9000/test.jpg"}}, {"type": "text", "text": "这张图里有什么？"} ]} ], "max_tokens": 256 }'这里有一个容易踩的坑：curl 里的 model 字段必须和 vLLM 启动时识别的模型名一致，否则会报 model not found。vLLM 启动日志里会打印 "Using model /data/BAGEL-7B"，你直接把那个路径或名字填进去就行。
5.3 4090 没有 NVLink，通信瓶颈要有数
RTX 4090 没有 NVLink 接口，这是消费卡和企业卡的根本区别。H100/A100 上 NVLink 可以提供数百 GB/s 的卡间带宽，而 4090 之间只能走 PCIe 4.0 x16，理论单向约 32GB/s，实测全双工读写也就 25GB/s 上下。
Tensor Parallel 的每一个注意力层和 MLP 层，做完局部计算后都要做一次 all-reduce 来同步结果。7B 模型虽然单层计算量不大，但层数多，通信次数也多。短上下文时计算能盖住通信，越长的序列、越大的 batch，通信占比就越明显。
所以我的建议是：
- 如果只是单用户低并发，TP=3 的收益在长上下文下会变弱，这时用 transformers 的 device_map 或者干脆单卡量化运行，延迟反而可能更好；
- 如果要做多用户服务，TP=3 仍然值得，因为它把 KV cache 也摊到了三张卡上，总并发容量大得多；
- 把 max-model-len 控制在 32K 以内，别贪到 128K，否则 PCIe 会被 all-reduce 占满，每请求延迟肉眼可见地上升。
6. 高频故障排查清单：按症状直接对号入座
这一节列出的都是我在整个部署期间真实遇到或者帮朋友排查过的问题，直接按"症状 → 根因 → 解法"对号入座：
| 症状 | 根因 | 解法 |
|---|---|---|
| 加载权重时 CUDA out of memory | dtype 没设，默认 fp32，7B+视觉塔需要 31GB+ | 加 torch_dtype=torch.bfloat16 |
| 运行时报 no kernel image is available | flash_attn / xformers 没针对 sm_89 编译 | 重装 flash-attn，并设置 TORCH_CUDA_ARCH_LIST="8.9" |
| import flash_attn 报 undefined symbol | PyTorch ABI 版本不匹配 | 卸载后用 --no-build-isolation 源码重编 |
| vLLM 启动失败，报 KV cache size 相关 ValueError | max-model-len 设置过大，或 gpu-memory-utilization 过高 | 降低 max-model-len，utilization 降到 0.9 左右 |
| 显存显示还有几 GB 空闲，但仍然 OOM | CUDA context 预留 + 显存碎片化 | 设 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True；或用 vLLM 的 paged attention |
| 调用 apply_chat_template 报错 | tokenizer/chat template 文件没下全 | 确认 tokenizer_config.json、tokenizer.json、special_tokens_map 都在 |
| 生成结果乱码 | tokenizer 与模型 vocab 不匹配 | 核对 config.json 的 vocab_size 和 tokenizer 文件是否同一套 |
| vLLM 返回 model not found | curl 里 model 名和 vLLM 识别名不一致 | 看启动日志，用打印出来的模型名 |
6.1 显存不够用，未必是卡不够多
nvidia-smi 显示的 free memory 和 PyTorch 认为的可分配内存是两回事。CUDA 一启动就在每张卡上预留了约 300~500MB 的 context，且 PyTorch 的缓存分配器会保留已释放的块。所以你在 vLLM 里把 gpu-memory-utilization 设到 0.99，看着预留的显存没超，实际运行时却突然 OOM——就是忽略了 CUDA context 这部分。
如果你在用 transformers 调试，遇到显存碎片化导致的 OOM，可以先在代码最前面加一行：
import os os.environ["PYTORCH_CUDA_ALLOC_CONF"] = "expandable_segments:True"该方法会在 CUDA 12.x 下启用可扩展段，能有效缓解碎片问题。但也别把它当成万能药，问题本质还是显存不够的时候，它救不了你。
6.2 加载阶段和运行阶段的报错，定位方式完全不同
加载阶段（from_pretrained 时）的报错，90% 出在配置和依赖上：dtype 没设、trust_remote_code 没开、权重仓库文件不完整、flash_attn 没装对。这个阶段不要怀疑代码逻辑，先把仓库结构、文件哈希、环境依赖逐一核对。
运行阶段（generate / 请求时）的报错，多半出在显存和通信上：OOM、all-reduce 超时、某个 token 触发 nan。这个阶段先把输入长度降下来测试，再逐步加 batch，定位是哪一层炸的。我见过有人在运行阶段遇到 OOM，结果反复调模型代码，浪费了一下午，最后发现只是 batch 里混进了一张 4K 分辨率大图，prefill 激活值撑爆了。
6.3 通信拓扑问题：一张慢卡拖垮全局
如果三张卡间的 PCIe 拓扑不对称（比如一张卡在 x8 槽位），TP 模式下的吞吐会被最慢那条链路卡住。用 nvidia-smi topo -m 看输出，NV1/NV2 这类连接最理想，PIX 或 PHB 也要注意，性能会差一截。这一点在买主板、插卡的时候就要规划好，装机后才发现就只能换槽位重插了。
7. 实测数据与使用建议
7.1 我跑出来的性能数字
部署完成后的实测数据如下（bf16 + FlashAttention-2 + TP=3，32K 上下文，三张 4090 全走 PCIe 4.0 x16）：
| 场景 | 指标 | 实测值 |
|---|---|---|
| 单请求 decode | 生成速度 | 55~80 tokens/s |
| 4 并发 decode | 服务端总吞吐 | 180~220 tokens/s |
| 单请求 prefill（1024 token + 1 张图） | 首 token 延迟 | 1.5~2.5s |
| 长文本 prefill（16K token） | 首 token 延迟 | 8~12s |
| 多卡推理时 PCIe 通信占比（32K 上下文） | 通信占比 | 约 20%~30% |
这个数据仅供参考。4090 因体质、PCIe 拓扑、散热和电源分配不同会有浮动。实测下来，decode 阶段 55~80 tokens/s 这个区间对 7B 模型来说是合理范围，长文本场景下 FA2 的收益很明显——相比之下，同样的权重在 eager 注意力模式下，长文本 prefill 经常要到 20 秒以上。
7.2 三卡方案的功耗和时间成本
3 张 4090 满负载功耗约 1050W，整机算上 CPU、风扇、硬盘，峰值 1300W 左右。这意味着电源至少要 1600W 的铂金级，或者双电源方案。日常使用如果只是偶尔跑推理，功耗不会一直顶满，但长时间挂着服务的话，一个月电费也要留意——按 0.6 元/度、日均跑 8 小时算，大约每月 180 元左右。比起租云上的 A100 实例，这笔开销在一两个月内就能回本，这也是本地部署的核心价值。
另一个容易被忽略的是散热：三卡并排插在塔式机箱里，如果风道不畅，显存温度很容易到 90 度以上，触发降频。我的方案是把三张卡之间留出至少一个 PCIe 槽位的空隙，机箱顶部加两个排风扇。如果条件允许，用竖装显卡支架或者开放式机架效果更好。
7.3 我的几条经验总结
最后说几个在这次部署里沉淀下来的判断，不一定全对，但对后来者应该有用：
一是版本组合要克制。PyTorch、flash-attn、vLLM、transformers 这四个库，建议都选已经发布超过半年的稳定版，别一上来就追最新主版本。我自己最初就是手滑装了一个 flash-attn 的 pre-release，结果和 vLLM 的三方依赖撞了个稀碎，白折腾了半个晚上。
二是 Flash Attention 编译失败时，先查 TORCH_CUDA_ARCH_LIST，再查 MAX_JOBS，最后才怀疑代码和网络。这个顺序帮我省了很多时间。
三是第一次跑通之前，不要急着把三个环境（transformers 实验环境、vLLM 服务环境、日常开发环境）混在一起。混环境的后果就是你分不清报错来自哪个库。我现在的习惯是每个大项目单独建 conda 环境，并在环境名前缀标注用途，比如 bagel-dev、bagel-vllm，出问题直接删掉重建，成本很低。
四是把启动命令和参数记到笔记里。vLLM 的启动参数组合很多，每次调优都要反复改，记下来之后重建服务就是抄作业，不用再从报错信息倒推参数。
这套"算账 → 对齐环境 → 编译 FA → 加载权重 → 多卡并行"的流程，我前前后后跑了三遍，第一遍花了整整一周，第二遍两天，第三遍半天就搞定了。换成其他 7B~13B 规模的多模态模型，这套流程也基本能复用，尤其是 Flash Attention 那套编译参数和报错排查思路，换卡换模型都绕不开。如果你手里正好也是 4090 或者其他消费级显卡，希望这篇能帮你把踩坑时间从一周压缩到一个晚上。
