前阵子群里有人发了个项目截图，标题写着“BAGEL-7B 多模态模型本地部署”，下面配了张显存占用图，三张 4090 跑得稳稳当当。我当时第一反应是：这名字起得挺有迷惑性，乍一看以为是什么百吉饼菜谱开源了。点进去才发现是个视觉语言多模态模型，能读图、能看文档、能按图片内容回答问题，7B 参数规模，主打本地部署。

我顺手实测了一遍，结论是：标题没夸张，3 张 RTX 4090 确实能跑，而且跑得很舒服。但整个过程中间其实藏了不少坑，尤其是 Flash Attention 的安装环节，网上资料很零散，官方 README 写得又过于精简，对第一次接触的人非常不友好。这篇文章我就把整个部署过程、显存计算逻辑、Flash Attention 安装踩坑点全部摆出来，给后面想玩多模态模型本地方案的朋友一个能直接照着操作的路子。

如果你手里正好有 2-3 张 4090、或者实验室有类似的 24GB 显存显卡，也想在本地跑一个能“看图说话”的大模型，这篇文章应该能帮你省下至少一晚上的折腾时间。

1. 为什么偏偏是 3 张 RTX 4090，方案是怎么定下来的

先说结论：跑 7B 级别的多模态模型，单张 4090 在极端配置下是能撑住的，但体验一言难尽。2 张卡属于“够用但紧巴巴”的状态。3 张卡是最舒服的甜点配置，既不会像 4 卡那样有边际效应，也能给长上下文和高分辨率图片留足显存余量。这条选择路径背后是有明确计算逻辑的，不是拍脑袋。

1.1 先把这个模型拆明白

BAGEL-7B 这类多模态模型的骨干结构，说白了就是“视觉编码器 + 语言模型 + 投影层”三段式。视觉部分负责把图片切块变成特征向量，语言部分负责理解文本和生成回答，投影层负责把视觉特征“翻译”成语言模型能看懂的向量。

7B 参数指的是语言模型那部分的参数量，爆显存的地方也主要在这块。很多人对 7B 模型有误解，以为 7B 参数就是 7GB 显存，实际上完全不是一回事。权重文件用 FP16 精度存储，每 10 亿参数大约占 2GB 显存，7B 模型光权重就是 14GB 左右。多模态模型还要额外挂一个视觉编码器，虽然视觉编码器本身只有几百 MB，但它产生的图像 token 会在推理时占用大量的 KV Cache 空间。

我在项目 config.json 里看到语言模型部分是 32 层 Transformer 结构，注意力头、隐藏层大小都属于市面上比较标准的 7B 配置。这类模型处理一张 336x336 的图片，一般会切成 24x24 的 patch，每张图产生 576 个视觉 token，再加上 1 个图像说明 token，577 个 token 就出去了。如果输入的是高分辨率文档扫描图，token 数会直接翻倍甚至更高，这还没算文本部分的 token。

1.2 “3 张 4090”是怎么算出来的

这个数学题值得展开算一遍，因为很多人就是搞不懂显存怎么分，才在部署阶段反复爆显存。

假设我们要跑一个 7B 语言模型，FP16 权重占 14GB。推理一个中等长度序列时，激活值大约占 2-4GB 显存，具体取决于 batch size 和序列长度。最容易被忽略的是 KV Cache，我们来算一下：32 层 Transformer、大约 50 个注意力头、每个头的维度是 128，推理时每个 token 需要用两层（K 和 V）缓存，每个参数 2 字节，那么每个 token 的 KV Cache 占用大概是：

32 层 × 2 × 50 头 × 128 维 × 2 字节 = 819,200 字节，也就是大约 0.8MB/token。

如果输入上下文是 16K token，KV Cache 就是 16,384 × 0.8MB = 13.1GB。单张 4090 的 24GB 显存，此时要同时塞下 14GB 权重、13GB KV Cache 和几 GB 激活值，显然已经超了。2 张卡可以用张量并行把权重和 KV Cache 平摊成两份，单卡压力大约在 7GB 权重 + 6.5GB KV Cache + 2GB 激活值，大约 15.5GB，能跑，但剩余空间不足以支撑更高分辨率图片。

3 张卡做张量并行，所有大件被平分成三份，单卡压力约为 4.7GB 权重 + 4.4GB KV Cache + 1.5GB 激活值，加起来大约 10.6GB，24GB 的卡还剩下一半以上空间。这时你可以放心地把 batch size 调大、上下文拉长，甚至同时处理多张高清图片，都不会有窒息感。

这个计算过程其实也解释了另外一个现象：为什么很多人用单卡跑同级别模型，一旦把图片分辨率调高或者上下文拉长就瞬间报 OOM。根子不在模型太大，而是 KV Cache 吃掉了所有富余显存。

1.3 为什么要本地部署，而不是调 API

这个项目本质上是把原本需要在云端跑的模型搬回本地，核心诉求其实是三个：数据不出门、不按 token 付费、能完全掌控推理参数。

对于处理敏感资料的场景，比如医疗影像、企业内部文档、个人相册，把图片传到云端 API 本身就是一种数据合规风险。本地部署之后，所有图片和文本都只在本机内存和显存之间流转，物理上杜绝了外传路径。

另外，API 是按 token 算钱的，一张高清图片在处理时会换算成大量视觉 token，多问几个问题就烧掉不少费用。而本地部署是一次性硬件投入，之后怎么跑都不额外花钱。再加上 API 版本往往不支持你自定义采样参数、不支持挂载自己的视觉编码器，所以对于想深入做二次开发的玩家来说，本地部署几乎是唯一选择。

2. 上手前必须搞懂的三个核心概念

实际操作之前，我建议先把三个关键概念理清楚，否则代码报错的时候你根本不知道该查哪里。这三个概念分别是：多模态模型的数据流转方式、Flash Attention 的工作原理、以及多卡并行里张量并行和流水线并行的区别。

2.1 多模态模型到底“多”在哪

传统语言模型的输入只有文本 token，一条输入从 tokenizer 到 embedding 再到 Transformer 层，路径非常单调。多模态模型多出来的部分在于：图片被视觉编码器处理后，输出的是一组视觉特征向量，需要通过投影层映射到语言模型的 embedding 空间，然后和文本 token 拼接在一起，往后统一走语言模型。

这个“拼接”过程是整个多模态模型最容易出问题的地方。视觉 token 和文本 token 的维度必须完全对上，否则投影层会报错。实际部署时，很多人遇到的“token 错位”现象，就是视觉特征和文本特征拼接顺序出了问题，导致模型生成内容牛头不对马嘴。

部署这类模型时，我习惯先把一张图和一段短文本同时输入，然后打印出模型内部参与计算的 token 类型分布，确认视觉 token 确实在文本 token 前面，再开始跑正式任务。这一步虽然麻烦，但能提前发现八成以上的多模态兼容问题。

2.2 Flash Attention 到底是提速还是省显存

很多教程把 Flash Attention 吹得神乎其神，其实它的核心作用就是两件事：减少显存占用、加速注意力计算。传统 attention 在计算过程中要保存完整的注意力矩阵，复杂度是序列长度的平方，导致长上下文时显存飞速膨胀。Flash Attention 通过分块计算和重计算，避免了把完整注意力矩阵写到显存里，内存占用从 O(N²) 级别降到 O(N) 级别。

打个比方：传统 attention 是你要写一封很长的信，必须把每一页草稿都摊在桌面上，写到后面桌子就满了；Flash Attention 是只保留当前正在写的一页，其余内容随时可以重新推导，桌面永远干净。

对本地部署来说，Flash Attention 不是可选项，而是必选项。没有它，16K 上下文的显存占用会瞬间击穿 4090 的显存上限。不过在安装阶段，很多人都会被 Flash Attention 的编译折磨到怀疑人生，这个问题我在后面第三章单独说。

2.3 多卡并行选哪种：张量并行 vs 流水线并行 vs 数据并行

很多人听说过“并行计算”，但不知道多卡并行也分好几种，选错了方案，三张卡的效果可能还不如一张卡。

数据并行是每张卡放一份完整模型，分别处理不同的 batch，最后汇总梯度。这种方式适合训练，不适合推理，因为推理时每张卡都要完整加载模型权重，三张 4090 根本放不下一个 7B 模型加完整 KV Cache。

流水线并行是把模型的不同层分到不同卡上，第一张卡算完传给第二张卡。问题在于同一时刻只有一张卡在真正计算，其他卡都在等待，GPU 利用率大打折扣。

张量并行是把每一层内部的计算切开，分到多张卡上同时算，这也是目前大模型推理的主流方案。vLLM、SGLang、TensorRT-LLM 都支持张量并行。三张 4090 跑 BAGEL-7B 用的就是这个模式，每张卡只存模型权重的一部分，显存被均匀摊开，计算时三张卡同时干活。

4090 之间没有 NVLink，只有 PCIe 带宽，这意味着张量并行通信会有一定等待时间。实测下来，三卡相对单卡在显存上宽松了很多，但推理速度并不是严格的三倍，这符合预期，属于正常现象。

3. 从零开始的完整实操过程

下面进入正题，我把整个部署过程拆成五步，每步都给出可直接复制的命令和配置。这套流程我在 Ubuntu 22.04 系统、三张 RTX 4090、驱动版本 550+ 的环境下完整跑通过。

3.1 第一步：环境准备与驱动检查

如果你用的是全新机器，首先要装显卡驱动和 CUDA 环境。这块建议直接用 NVIDIA 官方驱动，不要通过系统自带的软件源乱装，否则容易版本冲突。

先检查显卡是否被系统正确识别：

nvidia-smi

正常情况下应该能看到三张 RTX 4090，每张显存显示 24564 MiB，驱动版本建议 525.60.13 以上，CUDA 版本建议 12.1 以上。如果只显示一张卡，先检查 PCIe 插槽是否插紧，再看是不是主板 BIOS 禁用了某个插槽。

接下来安装 Python 环境和 PyTorch。我建议直接用 conda 建一个干净的环境，免得和系统 Python 冲突：

conda create -n bagel python=3.10 -y conda activate bagel pip install torch==2.3.0 torchvision==0.18.0 --index-url https://download.pytorch.org/whl/cu121

PyTorch 版本我选择 2.3.0 + CUDA 12.1 的组合，原因是这个组合和 Flash Attention 2.6.x 系列兼容性最好，后面的编译环节不容易出幺蛾子。太新的 PyTorch 反而可能在 Flash Attention 编译时碰到算子签名不匹配的问题。

验证 PyTorch 是否能用 GPU：

python -c "import torch; print(torch.cuda.device_count(), torch.cuda.get_device_name(0))"

输出应该是3 NVIDIA GeForce RTX 4090这样的信息。这里有个小坑，如果你看到的 device_count 是 0，大概率是 PyTorch 安装成了 CPU 版本，重新安装 CUDA 版本即可。

3.2 第二步：拉取模型权重与依赖

模型权重我建议从 HuggingFace 拉取，如果你所在网络访问 HuggingFace 有延迟，可以先设置镜像环境变量：

export HF_ENDPOINT=https://hf-mirror.com

然后安装推理框架和模型依赖：

pip install vllm==0.6.3 transformers accelerate sentencepiece

vllm 选用 0.6.3 是因为这个版本对多模态模型的支持相对稳定，后续 0.7.x 系列虽然新功能多，但在我测试时某些视觉模型的兼容性还有问题，具体表现是图片输入会报奇怪的维度错误。

模型权重下载这一步，用 HuggingFace CLI 拉也可以，直接在 Python 里调snapshot_download也行。我习惯用命令行：

huggingface-cli download BAGEL-7B模型路径 --local-dir ./models/bagel-7b

下载完成后检查一下目录结构，正常应该包含权重文件、config.json、tokenizer 文件和 preprocessor_config.json，其中 preprocessor_config.json 是视觉部分的配置，缺少它会在图片预处理阶段直接报错。

3.3 第三步：Flash Attention 安装技巧，这步最容易劝退

Flash Attention 是整个部署流程里最难啃的骨头，我把安装过程中所有可能踩的坑替你踩了一遍，最终的可执行方案如下。

先安装预编译版本试试：

pip install flash-attn==2.6.3

如果你的环境恰好匹配，这一步直接成功，那你运气很好，可以直接跳到下一步。但很多人会遇到预编译包不存在、安装报错、或者装上之后 import 时崩溃这些问题。此时需要走源码编译路线。

源码编译前务必确认三个前提：CUDA_HOME 环境变量正确、ninja 已安装、系统有足够的编译线程。我踩过最深的坑是 CUDA_HOME 没设置，导致编译器找不到 CUDA 头文件，报错信息却错误地指向了显卡架构不支持。

接下来设置编译参数：

export CUDA_HOME=/usr/local/cuda-12.1 export MAX_JOBS=4 export TORCH_CUDA_ARCH_LIST="8.9"

MAX_JOBS=4 是关键，因为 4090 的显存只有 24GB，编译过程中如果并行编译任务过多，编译器进程会吃掉大量内存导致机器卡死。TORCH_CUDA_ARCH_LIST=8.9 是指定编译目标架构，RTX 4090 的计算能力是 8.9，必须明确指定，否则编译出来的算子可能没法用。

然后用 pip 从源码安装：

pip install flash-attn==2.6.3 --no-build-isolation

加上--no-build-isolation是为了让编译过程复用当前环境里已有的 PyTorch 和 CUDA 库，不加这个参数的话，pip 会新建一个隔离环境重新下载依赖，非常容易导致版本错乱。

编译时间取决于你的 CPU 核心数，我这边大概花了 15 到 20 分钟。期间屏幕如果滚动大量编译日志，不要慌，看到Building wheel for flash-attn之后耐心等待即可。

安装完成之后务必验证：

python -c "from flash_attn import flash_attn_func; print('flash attn ok')"

如果能无报错输出，说明 Flash Attention 安装成功。这一步通过之后，后面整个部署过程就会顺畅很多。

3.4 第四步：配置三卡张量并行推理

vLLM 对多卡张量并行的支持非常成熟，关键是启动参数要写对。这里我用一段完整的 Python 代码来演示，因为实际项目中我都是用 Python 方式启动服务，方便后续集成到业务代码里。

from vllm import LLM, SamplingParams import torch model_path = "./models/bagel-7b" llm = LLM( model=model_path, tensor_parallel_size=3, dtype="bfloat16", gpu_memory_utilization=0.9, max_model_len=16384, trust_remote_code=True, enforce_eager=False ) sampling_params = SamplingParams( temperature=0.7, top_p=0.9, max_tokens=2048 )

参数说明：tensor_parallel_size=3让模型被切成三份分别加载到三张卡上，max_model_len=16384把上下文长度控制在 16K，gpu_memory_utilization=0.9意思是每张卡最多用 90% 的显存，剩下 10% 留给模型加载和碎片开销。

启动过程如果在初始化阶段看到类似Cannot set dest_device to ...或者通信超时的报错，十有八九是 NCCL 相关的问题，可以设置环境变量export NCCL_P2P_DISABLE=1再试。这也是 4090 这种无 NVLink 显卡上比较常见的现象。

3.5 第五步：多模态输入验证

模型加载完成后，用图片加文本的输入方式做一次完整验证。我拿一张带文字说明的图表图片试了一遍：

from PIL import Image image = Image.open("test_chart.png").convert("RGB") prompt = "请描述这张图片中的主要信息，并总结发展趋势。" output = llm.chat( messages=[ { "role": "user", "content": [ {"type": "image", "image": image}, {"type": "text", "text": prompt} ] } ], sampling_params=sampling_params ) print(output[0].outputs[0].text)

正常输出会是一段对图片内容的描述和趋势总结，内容连贯且能对应上图片中的关键元素。如果输出内容完全和图片无关，或者报了 token 维度不匹配的错误，请看下一章的问题排查部分。

验证通过后，可以用 OpenAI 兼容接口方式启动常驻服务，对外提供 API：

python -m vllm.entrypoints.openai.api_server \ --model ./models/bagel-7b \ --tensor-parallel-size 3 \ --dtype bfloat16 \ --port 8000

之后任何机器都可通过http://localhost:8000/v1/chat/completions调用接口，请求格式和 OpenAI 的多模态接口一致。这对后续做前端应用或自动化脚本非常友好。

4. 踩坑实录与排查速查表

部署这一类多模态模型，几乎不可能一次成功。以下是我这次过程中遇到的典型问题和排查方法，整理成速查表方便你对照使用。

4.1 我在部署中遇到的六个典型问题

第一个问题是驱动识别显卡数量不对。从nvidia-smi看到三张卡，但 PyTorch 只识别到一张。原因通常是安装 PyTorch 时没有用 CUDA 版本，或者系统存在多个 Python 环境导致加载了错误的包。解决办法是确认torch.version.cuda不等于 None，且重新用 cu121 索引安装 PyTorch。

第二个问题是 Flash Attention 编译时一直报CUDA error: no kernel image is available。这个报错的原因是编译时没有指定显卡架构，导致编译出的算子只支持默认架构，无法在 Ada 架构的 4090 上运行。解决办法就是上面说的设立TORCH_CUDA_ARCH_LIST="8.9"后重新编译。

第三个问题是模型初始化后立刻报 OOM。多半是因为gpu_memory_utilization设置过大，且没有启用 Flash Attention。如果模型 runs 在 eager 模式而不是 flash attention 模式，显存压力会大很多。打开enforce_eager=False，并确保 Flash Attention 安装成功，才能把 KV Cache 压到最低。

第四个问题是多卡通信超时。三张 4090 在没有 NVLink 的普通主板上通过 PCIe 通信，偶尔会因通信初始化过慢报超时。这个一般不会影响最终结果，设NCCL_P2P_DISABLE=1或者NCCL_SHM_DISABLE=1可以绕开。

第五个问题是视觉输入报维度错误。这是多模态模型部署中最容易踩的坑。解决方案是在输入图片前统一执行Image.open(...).convert("RGB")，确保图片通道数是三通道，并且尺寸不要超过模型支持的最大分辨率。

第六个问题是模型输出中文效果不佳，有概率出现词尾截断或重复。这个问题一般和采样参数设置有关，可以降低temperature到 0.6、适当调大frequency_penalty，效果会有明显改善。

4.2 一张故障排查速查表

4.3 关于显存优化和长上下文的额外提醒

如果你之后想把上下文长度提升到 32K 或更高，需要特别注意 KV Cache 的膨胀速度。根据前面的计算公式，32K 上下文的 KV Cache 每张卡大约要承担 8.7GB，叠加权重和其他开销，三卡虽然能装下，但剩余余量不多。此时建议把gpu_memory_utilization提高到 0.95，同时降低 batch size，避免因查找资源失败而报 OOM。

另外，把图片分辨率从 336 提升到 672 会使视觉 token 数变成原来的四倍左右，如果你的任务对图片细节要求很高，务必同步监控显存变化，必要时把 max_model_len 往下降一档，给视觉 token 腾出空间。

5. 说点个人体会和后续建议

整套流程跑下来，我认为这个部署方案最大的价值不是“跑通了一个模型”，而是验证了一条完全可复用的技术路径：普通消费级显卡 + 开源模型 + 合理并行策略 = 能商用的本地多模态推理环境。这套路径不限定于 BAGEL-7B 这个具体模型，其他 7B 级别的视觉语言模型基本可以照搬同样的流程。

给我留下印象最深的一点是 Flash Attention 的安装竟然成了整个过程中最大的门槛，比模型下载、多卡并行这些听起来更“高端”的环节都麻烦。这提醒我一件事：很多项目看似庞大复杂，真正卡住效率的往往是基础设施层面的小坑。

如果你条件允许，下一步我建议做两件事：一是把接口服务封装成 Docker 镜像，方便迁移到其他机器；二是用多模态模型做一些更具体的业务测试，比如论文图表理解、产品图属性提取、老照片描述等，看看模型在你的领域里到底能补上哪块拼图。本地部署的优势就在于你随时可以在离线状态下反复实验，把模型能力边界摸清楚，这个过程的价值可能比模型本身还大。

如果你按上面的步骤操作过程中遇到其他奇怪的问题，欢迎留言，我这边踩过的坑会持续更新。