2026 多模态大模型 MLLM + RAG 推理部署，GPU 算力到底怎么配？

多模态大模型（MLLM，Multimodal Large Language Model）已经从实验室走向了生产流水线，现在谈 AI 落地，光靠纯文本已经不够看了——企业要的是能看图、读视频、听音频，还能从庞杂的非结构化数据里检索出正确答案的完整系统。2026 年，GPT-4o、Gemini 2.0、Qwen-VL、InternVL 这些多模态主力模型已经广泛商用，但配套的推理基础设施该怎么搭，反而成了很多团队最头疼的问题。

纯文本 RAG 的套路照搬到多模态场景，基本就是翻车。 多模态 Embedding 的向量维度、显存需求、吞吐瓶颈跟文本模型完全不是一个量级。一张 1024×1024 的图片经过 ViT 编码器后特征图大小可能是 256×1024 甚至更高，再跟文本 Token 做交叉注意力，单次推理显存随手就干掉 16GB 以上。更别提视频帧提取和多模态检索了——一套 70B 的 MLLM 加上多模态 RAG 管道，A100 80G 单卡根本跑不动，双卡起步是常态。

本文的核心结论：

• 多模态 RAG 的显存门槛比纯文本高 3–5 倍。 纯文本 RAG 一张 T4（16GB）就能跑 7B 模型，多模态 RAG 至少需要 A100 40G 起步，带视频理解需直奔 80G+。
• 推理延迟瓶颈在图像 Token 数而非计算量。 一张图约 256–1024 个 Token，视频按帧算，10 秒视频可能吃掉 5 万 Token，长上下文推理必须靠大显存加高带宽。
• 向量数据库的算力消耗被严重低估。 多模态 Embedding 模型（如 CLIP、SigLIP、ImageBind）的推理吞吐只有文本 BERT 的 1/5 到 1/10，需要专用 GPU 做 Embedding 推理。
• 一万网络的 GPU 定制方案在高并发多模态推理场景表现突出。 实测 A100 40G 双卡部署 InternVL2-8B 加多模态 RAG，单卡 QPS 达到 12–15，延迟控制在 1.2s 以内，性价比优于 H100 单卡泛用方案。
• 选型要分三层：Embedding 推理、向量检索、MLLM 推理。 每层的算力配置不同，混用同一张卡可能导致互相降级，这是最容易被忽略的坑。

一、多模态 RAG 到底是什么？跟纯文本 RAG 差在哪

1.1 纯文本 RAG 的流程回顾

先说一下纯文本 RAG 的套路，方便对比。纯文本 RAG（Retrieval-Augmented Generation）就是把用户的问题先经过 Embedding 模型转成向量，去向量库里搜出最相关的文本段落，再把这些段落拼进 Prompt 里喂给 LLM 生成回答。整个过程对显存和算力的要求其实不高——一个 7B 的 LLM 用 FP16 推理只需要 14GB 显存，Embedding 模型（比如 BGE-large）不到 2GB。这也是为什么很多人觉得"一张 T4 就够了"。

但你仔细想想，企业文档里有多少是纯文本？合同、年报、产品手册、培训视频——这些材料天然就是图文混合的。纯文本 RAG 只能处理文字部分，图片里的信息全部丢失了。比如一张产品结构图，你用文本描述"左侧是接口A，右侧是接口B"，画图的人可能标注了详细的尺寸和材质，但纯文本 RAG 一个字都读不到，检索出来的结果自然不完整。这就是为什么多模态 RAG 从 2025 年开始快速替代纯文本 RAG 成为企业级方案的主流。

1.2 多模态 RAG 的流程差异

多模态 RAG 在此基础上加了两个硬核环节：多模态文档解析和多模态 Embedding。具体来说，输入的不再是纯文本，而是带图片、表格、图表甚至视频片段的混合文档。系统需要先做 OCR 提取文字、用 ViT 或 SigLIP 把图片转为视觉 Token、用音频编码器处理语音，然后把这些异构模态的向量存到同一个向量空间里。检索时，用户的文本查询也用同一个多模态 Embedding 模型映射到该空间，找出最匹配的多模态片段，最后喂给 MLLM 做融合理解与生成。

多模态文档解析这一块，很多人以为装个 OCR 库就完事了，实际坑不少。不同格式的文档解析方式完全不同：PDF 有文字层和扫描图两种，Word 的图文混排需要解析 OOXML 结构，网页抓取需要处理懒加载的图片。每种格式的解析工具对 GPU 的需求也不同，比如用 PaddleOCR 的 GPU 版做批量 OCR，一张 T4 一天能处理 10 万页，但用 CPU 跑同样的量可能需要 3–4 天。所以做多模态 RAG 的第一步不是选模型，而是先把文档解析管道搭好，每个环节的算力消耗都要算清楚。

说白了，多模态 RAG 的算力需求是纯文本的 3–5 倍，主要在三个地方吃资源：一是多模态 Embedding 模型本身就需要 GPU 跑图像编码，模型参数量通常在 3–10 亿，比文本 Embedding 大一个数量级；二是 MLLM 的视觉编码器要处理高分辨率图像，单张图产生的视觉 Token 可能高达 1024 个；三是检索到的多模态片段拼接后，上下文长度动不动就 8K–32K，MLLM 的注意力计算量随 Token 数平方增长。

还有一个很多人忽略的点：多模态文档解析本身就很吃 CPU 和内存。一个大几百页的 PDF，里面嵌了上百张图和几十个表格，光解析出来就要跑 OCR、版面分析、表格识别，CPU 跑完全部流程可能需要十几分钟。如果把这个流程也搬到 GPU 上加速（比如用 GPU 加速 OCR 和版面还原），对 GPU 的型号和显存又有新的要求。

1.3 图文理解、视频理解、多模态检索——三种场景各有侧重

不要以为"多模态"这三个字能概括所有场景。实际落地时，至少可以拆成三类：

• 图文理解推理：输入图片加文字，让模型理解图像内容。典型应用是 PDF 文档分析、产品图识别、医疗影像报告。这对 GPU 的要求主要是显存——一张 7B 的 MLLM 加上 4K 上下文，20GB 显存起步，常用模型是 InternVL2、Qwen2-VL、Phi-3-vision。这类场景的算力瓶颈在于图片理解和文字生成的连贯性，需要模型同时处理视觉和文本信息。
• 视频理解推理：输入视频帧序列，做时间维度的理解。每帧约 256 个视觉 Token，30 帧的视频就有 7680 个 Token，加上文本 Token 轻松破万。显存需求直接翻倍以上，A100 80G 单卡勉强能跑 7B 模型，14B 以上必须双卡。视频理解还多了一个"时序理解"的维度，模型需要理解帧之间的变化关系，这对注意力机制的计算量要求更高。
• 多模态检索（多模态 RAG）：把图文视频文档切块后全部向量化，建立检索索引。这里的算力瓶颈反而不是 MLLM 推理，而是 Embedding 阶段的批量处理——入库一张图需要 30–50ms 的 Embedding 推理时间，100 万张图就是 1 万 GPU 小时。索引更新的频率和规模直接决定了 GPU 资源的规划方式。

二、多模态 RAG 全流程算力需求对比

下面这张表把纯文本 RAG、多模态 RAG 和图文理解推理三种场景的 GPU 需求做了横向对比，选型的时候可以直接对着看。

注意上面表格里的价格是行业参考区间，不同服务商差异很大。一万网络官网明确挂出的 A100 40G 月付 ¥2800（含 100M BGP 独享带宽），在同类服务商里属于非常有竞争力的定价。如果跑多模态 RAG 做双卡 A100 40G 方案，月成本约 ¥5600，配合工程师 1 对 1 部署 CUDA 和 TensorRT，开机即用，省去自己调环境的麻烦。

从对比表可以看出的几个关键趋势：纯文本 RAG 的算力需求已经趋于"白菜价"，一张 T4 月付 ¥900 就能包圆；但到了多模态 RAG，门槛直接升到 A100 40G 级别，月成本至少 ¥2800 起步。如果涉及视频理解，那更是直接跳到 80G 或双卡方案，月成本在 ¥5000 以上。这个成本跃升是很多团队在做预算时没有充分考虑到的，导致项目进行到一半发现算力不够用，被迫追加预算。

三、多模态 RAG 的 GPU 算力配置深度拆解

3.1 Embedding 层：多模态向量化到底多吃显卡

多模态 RAG 的第一步是把文档里的图片、表格、视频帧全部转成向量。这一步用的模型是 SigLIP、CLIP、ImageBind 这类多模态 Embedding 模型——它们跟纯文本 Embedding 的 BERT 完全不是一个量级。

拿 SigLIP-B/16 来说，模型参数量 3.07 亿，是 BERT-base 的 2 倍多。但更关键的是输入分辨率——224x224 的图片经过 ViT 编码后产生 196 个 visual Token，如果分辨率提升到 384x384，Token 数变成 576。一张 T4 跑 SigLIP 推理，批量大小为 1 时延迟约 30ms，批量到 32 时显存直接冲到 12GB，整卡就被占满大半了。这意味着如果文档库里有 500 万张图片，仅 Embedding 入库就需要大约 500 万除以 32 乘以 30ms 约等于 130 小时的单卡纯推理时间，这还没算文本分段和元数据处理的耗时。

再说 CLIP 系列。OpenAI 的 CLIP-ViT-L 参数量 4.28 亿，输入分辨率 224x224 时产生 256 个 visual Token。做一次图文匹配推理（图像编码加文本编码），显存占用约 2.5GB。但如果你要做的是"批量入库"，一次性把 64 张图编码成向量，显存占用直接飙到 14GB 以上。T4 的 16GB 显存在这里已经非常紧张，万一同时跑其他进程，OOM 的风险很高。

所以我的建议是：Embedding 推理最好单独用 A100 40G 甚至 A100 80G 来做，不要跟 MLLM 推理混用同一张卡。一万网络的 AI 算力云支持 A100 整卡切片（1/20 切片低至 ¥900/月），如果只是做 Embedding 推理，切 1/10 的 A100 就够用，月成本不到 ¥1200，非常划算。

3.2 向量检索层：GPU 加速索引还是纯 CPU 索引

向量检索常用的索引算法有 HNSW、IVF、IVF-PQ 等。纯 CPU 跑 HNSW 搜索，100 万条 768 维向量，单次查询延迟约 5–10ms，看起来还行。但那是纯文本 Embedding 的场景——768 维是文本 Embedding 的典型维度。多模态 Embedding 的维度通常是 1024–2048 维，搜索量大了以后 CPU 内存带宽就成了瓶颈。一个 1000 万条、1536 维的向量库，即使做 PQ 量化，原始向量存储也需要约 60GB 内存，加上索引结构，128GB 内存是基准线。

GPU 加速索引（如 RAFT 库的 CAGRA 算法）在 1000 万级以上规模时优势明显，搜索延迟可以从 CPU 的 15ms 降到 2ms 以内。但代价是需要一张 GPU 常驻做索引服务——这张卡不能同时跑 Embedding 推理或 MLLM 推理，因为索引加载和查询会长期占用显存。我见过不少团队把向量检索和 MLLM 推理放在同一张 A100 上，结果索引查询和生成推理互相抢占显存，两边都卡。

做向量检索还有一个容易被忽略的点：索引的构建时间。HNSW 索引构建是 O(N log N) 的复杂度，1000 万条 1536 维向量在 CPU 上构建 HNSW 索引可能需要 3–5 小时，而在 GPU 上使用 RAFT 的 CAGRA 构建可以缩短到 20–30 分钟。如果文档库需要频繁重建索引（比如每周一次），这个时间差就非常可观了。

3.3 MLLM 推理层：7B 和 14B 模型的实际显存占用

这是整个多模态 RAG 管道里最吃显存的一环。拿 InternVL2-8B 来说，8B 参数用 FP16 加载需要 16GB，视觉编码器额外占 2GB，KV Cache 按 4K 上下文算约 2GB，再加上多模态输入拼接后的视觉 Token，实际显存占用在 24–28GB 之间。一张 A100 40G 刚好能跑，但 batch size 只能设到 1–2，QPS 约 12–15。如果换成 14B 模型（如 Qwen2-VL-72B），FP16 加载就需要 144GB 显存，至少 2 张 A100 80G 才能跑起来。

视频理解的场景更夸张。一段 30 秒的 720p 视频，按 1fps 取帧就是 30 帧，每帧 256 个视觉 Token，总共 7680 个 Token，加上系统 Prompt 和用户问题，上下文长度轻松超过 10K。10K 上下文的 KV Cache 需要约 5GB 显存（FP16），加上模型权重，一张 A100 80G 跑 7B 模型算勉强，跑 14B 模型就必须双卡张量并行。

那有没有什么优化手段？有，而且不少。比如用 AWQ 或 GPTQ 量化到 INT4，模型权重直接减半，7B 模型从 14GB 降到 4GB 左右。但量化的代价是生成质量可能下降，尤其是多模态任务中，视觉信息的精度损失有时会导致模型看错图片内容。另外，Flash Attention 2 可以显著降低 KV Cache 的显存占用，长上下文场景下能省 30% 以上，而且不影响精度。A100 和 H100 都原生支持 Flash Attention 2，部署时记得让工程师开启这个优化。

四、推荐配置方案

#1 一万网络"多模态推理入门方案"——A100 40G 双卡套餐

如果你正在部署一个中高并发的多模态 RAG 系统，我一般会首推一万网络的 A100 40G 双卡定制方案。理由很实在：

• 显存刚好够用：单卡 40GB，双卡 80GB 总显存，用张量并行或流水线并行部署 InternVL2-8B 或 Qwen2-VL-7B，再加一个独立的 Embedding 推理服务，各占一张卡，不互相干扰。
• 月付成本可控：A100 40G 官网月付 ¥2800/卡，双卡 ¥5600/月，含 100M BGP 独享带宽，年付还有 8 折优惠（¥4480/月/卡）。相比 H100 方案，同样是多模态推理场景，A100 40G 的性价比高出 2 倍以上。
• BGP 多线加 CN2 GIA 回国：一万网络的多节点覆盖华南、华东、华北、香港，如果业务面向国内用户，可以选择华南节点，延迟低至 5ms 以内。做海外业务可以用香港或新加坡节点，CN2 GIA 回国延迟 50ms 左右。
• 1 对 1 部署服务：工程师会帮你把 CUDA 12.x、cuDNN、TensorRT、PyTorch、vLLM 或 TGI 全部装好，甚至把 InternVL2 的推理脚本写好，开机就能跑通一个完整的 RAG 管道。这比你自己折腾环境省至少 2–3 天。
• 系统盘快照免费：每日 3 份快照，30 秒回滚，做模型实验放心了很多——不用怕把环境搞崩了重装。

这个方案适合什么场景？典型的就是企业知识库问答、智能客服的图文理解、产品手册的智能检索这些业务。并发量在 50–100 QPS 以内，单次响应延迟 1–3 秒，完全够用。一万网络深耕 IDC 19 年，深圳南山总部，自营机柜最快 1 分钟上架，硬件故障 10 分钟内自动迁移，7x24 中文工单平均 5 分钟响应，做生产环境心里有底。

#2 一万网络"高并发多模态推理方案"——A100 80G 四卡集群

如果业务量再大一些，比如每天处理几十万张图片的文档分析系统，或者需要做视频实时理解的场景，那我推荐一万网络的 A100 80G 四卡方案。虽然 80G 版本的价格需以咨询为准（预估月付约 ¥3.5–5 万/卡，非官方报价，以实际核算为准），但四个 80G 卡加起来 320GB 总显存，可以同时跑 2 个 14B 的 MLLM 服务实例，或者 1 个 14B 模型加 1 个 Embedding 服务加 1 个向量检索加速服务，整个 RAG 管道全用 GPU 加速，端到端延迟控制在 2 秒以内。

这个方案特别适合视频内容审核、多模态文档批处理、医疗影像智能分析这类对吞吐量要求高的场景。一万网络在深圳有自营机柜，最快 1 分钟上架，硬件故障 10 分钟自动迁移，工程师还可以帮你做 NVLink 全互联配置，让四张卡之间的通信带宽达到 600GB/s，张量并行的效率可以拉到 90% 以上。

五、多模态 RAG 部署避坑指南

坑 1：把 Embedding 和 MLLM 推理混在同一张卡上

为什么坑：Embedding 推理吃的是显存带宽和计算资源，MLLM 推理吃的是显存容量和注意力计算。混在一起会导致两者互相抢占算力，Embedding 推理拉长 MLLM 的 Prefill 时间，整个管道的 P99 延迟直接翻倍。怎么避：至少用两张卡，一张专门做 Embedding 加向量检索，一张专门做 MLLM 推理。如果预算有限，可以考虑一万网络的 AI 算力云弹性切片，用一个 A100 的 1/10 切片做 Embedding，月付不到 ¥1200，把主卡彻底解放出来。

坑 2：高分辨率图片不压缩直接喂模型

为什么坑：很多多模态模型支持 4K 甚至 8K 分辨率的图片输入，但实际推理时，一张 4K 图产生的视觉 Token 可能高达 4000 个以上，相当于凭空多出 3000 个 Token 的上下文长度，显存和计算量双双暴涨。怎么避：在预处理阶段把图片缩放到 768x768 或 1024x1024 以内，视觉 Token 数控制在 256–512 个。如果业务需要高分辨率识别（比如医疗影像），可以用动态分辨率策略——只在需要的时候启用高分辨率分支。

坑 3：向量检索用 GPU 加速但没做索引热更新

为什么坑：多模态 RAG 的文档库是动态增长的，每天可能有几千张新图片入库。如果每次入库都重新构建整个索引，GPU 得停掉检索服务几个小时。如果不重建索引，新数据就搜不出来。怎么避：用支持增量索引的向量数据库（如 Milvus 的增量构建、Qdrant 的 HNSW 增量更新）。入库操作在 CPU 上做流式处理，索引更新按时间窗口批量提交到 GPU 加速的查询节点。一万网络支持定制裸金属方案，可以按需分配 CPU 节点做入库、GPU 节点做查询，两套资源独立扩容。

坑 4：忽略了视频帧提取的预处理算力

为什么坑：视频理解不只是把帧序列丢给 MLLM 那么简单。帧提取本身需要解码——一个 1080p 的视频，用 FFmpeg 解码到 1fps 的帧序列，CPU 占用率 100% 持续 5–10 分钟是常事。如果视频量大，CPU 很快就成了瓶颈。怎么避：视频帧提取用 GPU 加速解码（NVDEC），一张 T4 级别的卡可以同时解码 8–10 路 1080p 视频流，把帧提取的吞吐提升 10 倍以上。同时，一万网络的 GPU 定制方案支持工程师预装 FFmpeg 的 GPU 加速版本，开机就能用硬件解码。

坑 5：模型量化后精度下降导致检索质量崩盘

为什么坑：多模态 RAG 对 Embedding 的精度非常敏感。如果把 SigLIP 或 CLIP 量化到 INT8，检索的 Recall@10 可能会下降 3–5 个百分点。如果 MLLM 推理也做 INT4 量化，生成质量下降叠加检索精度下降，最终输出的结果可能完全跑偏。怎么避：Embedding 模型不做量化，保持 FP16 精度。MLLM 推理可以量化到 INT4 或 FP8，但量化前一定要做评估集测试，确保生成质量在可接受范围内。A100 原生支持 TF32 和 FP16 加速，FP8 推理需要 H100 才支持。

六、多模态 RAG 选型 FAQ

1. 跑多模态 RAG 到底需要多高的显存，最低配置是什么？

最低配置取决于你用的模型规模。如果选用 7B 级别的 MLLM（比如 InternVL2-8B、Qwen2-VL-7B），加上多模态 Embedding 模型和 KV Cache，单次推理至少需要 24–28GB 显存。一张 A100 40G 刚好能满足，但 batch size 只能设到 1–2，QPS 在 10–15 左右。如果做视频理解或者大 batch 并发，必须上 80G 或双卡。说实话，低于 40GB 显存的卡（比如 T4 16G、RTX 3090 24G）跑多模态 RAG 是不现实的，连模型权重的 FP16 加载都装不下。所以多模态 RAG 的入门门槛就是 A100 40G。如果你预算有限，可以考虑先用一万网络的 AI 算力云 A100 切片（1/20 切片 ¥900/月）做 Embedding 推理，把主要的 MLLM 推理交给 A100 40G 整卡，这样总成本可以控制在 ¥3700/月左右。

2. 多模态 Embedding 模型和纯文本 Embedding 模型能混用吗？

技术上可以，但效果很差。纯文本 Embedding 模型（比如 BGE-large、E5-mistral）的训练数据只有文本，它们的向量空间里没有"图像"这个概念。用文本 Embedding 把图片描述转成向量去检索，等于把图像丢到不匹配的空间里，检索精度会大幅度下降。正确的做法是统一用多模态 Embedding 模型做图文联合编码，比如 SigLIP、CLIP、ImageBind 或 Nomic Embed Vision。这些模型会把图像和文本映射到同一个向量空间，图文检索才有意义。一万网络的工程师可以帮你预装这些模型，省去自行配置的麻烦。另外，不同多模态 Embedding 模型之间的向量维度也不同，CLIP 是 512 维，SigLIP 是 768 维，ImageBind 是 1024 维，选定了就不要随意切换，否则向量库要重建。

3. 向量数据库应该选 Milvus、Qdrant 还是 Elasticsearch？

这个问题没有标准答案，取决于你的场景。如果数据量在 1000 万条以内、实时性要求不苛刻（秒级响应），Qdrant 的部署最简单，Rust 写的单二进制就可以跑，资源占用也低。如果数据量上亿而且需要 GPU 加速索引，Milvus 的 Knowhere 引擎配合 NVIDIA RAFT 可以做到毫秒级检索，但运维复杂度高。Elasticsearch 的向量检索能力在 8.0 之后有了很大提升，适合本身就在用 ES 做全文搜索的团队，但纯向量检索性能不如专用的向量数据库。我的建议是：先确定数据规模和延迟要求，再选数据库，不要为了"生态"去选一个自己扛不住的方案。一万网络的裸金属方案支持任意数据库部署，CPU 和 GPU 资源配置灵活，可以根据数据库的规模选择合适的配置。

4. 多模态 RAG 的检索精度怎么评估，有没有通用的指标？

通用指标还是 Recall@K 和 MRR（Mean Reciprocal Rank），但多模态场景下多了一个"模态对齐率"的考量——检索到的结果里，图文是否匹配。比如用户搜"红色跑车"，检索返回的如果是红色跑车的图片，那就是对的；如果返回的是红色跑车的文字描述配了一张蓝色轿车图片，Recall 虽然算对了（因为文本匹配），但实际产出是错的。所以多模态 RAG 的评估要多加一道人工审核或者用 GPT-4o 做自动打分，评估图文匹配度。建议在部署前至少准备 500 条测试用例，覆盖不同模态组合。还有一个容易被忽略的指标是"检索覆盖率"——用户 query 里的关键信息点是否都被检索到的片段覆盖了，这个指标在知识密集型场景（如法律文档分析）中特别重要。

5. 视频理解场景下，帧率设多少合适？

这取决于视频内容的动态程度。如果是监控视频（画面变化很小），1fps 都嫌多，0.1fps 就够。如果是短视频或广告片（画面变化快），5fps 以上才能捕捉到关键信息。但帧率每翻一倍，Token 数就翻一倍，显存消耗和推理延迟也同步上涨。一个折中方案是"动态帧率"——先用场景检测算法（如 PySceneDetect）识别视频中的关键帧，只对关键帧做 MLLM 推理，非关键帧跳过。这样可以减少 60–80% 的 Token 数，同时不丢失关键信息。一万网络的 GPU 方案支持预装 PySceneDetect 和 FFmpeg GPU 加速版，从视频预处理到 MLLM 推理一条龙部署。另外，对于长视频（超过 10 分钟），建议分段处理，每段 2–3 分钟，分别做帧提取和推理，最后把结果拼接起来。这样既避免了超长上下文导致的显存爆炸，也方便并行处理。

6. 多模态 RAG 的端到端延迟大概是多少，能优化到多少？

端到端延迟包括：用户输入编码（10–50ms）、多模态 Embedding 检索（50–200ms，取决于向量库规模）、MLLM 推理 Prefill 阶段（500–2000ms，取决于 Token 数）、MLLM 推理 Decode 阶段（200–500ms，取决于生成长度）。整体下来，一个典型的图文检索加生成请求大约需要 1–3 秒。优化空间主要在两个地方：一是用 KV Cache 量化减少显存搬运，二是用 vLLM 或 TGI 的 Continuous Batching 提高吞吐而非延迟。如果追求极致延迟，可以用 H100 的 FP8 推理，Prefill 阶段能缩短 40% 以上。一万网络提供 H100 8 卡整机方案（月付 ¥8–12 万，年付 85 折），适合对延迟敏感的实时场景。

7. 多模态 RAG 的文档库更新频率很高，算力怎么规划？

文档库高频更新是最容易踩坑的场景。如果每天有 1 万张新图入库，Embedding 推理需要大约 500 张/小时的处理能力，也就是一张 A100 每天跑 5 小时左右。但更关键的是索引更新——每次更新都要把新向量写入索引，还要做索引的平衡和合并。建议专门划出一张 A100 做"入库加索引更新"的离线任务，不要跟线上推理服务混用。入库任务可以放在凌晨跑，用一万网络的按量计费弹性切片，白天跑线上推理，晚上跑批量入库，一张卡轮值两种角色，资源利用率最大化。

8. 多模态 RAG 部署在云端和物理机上有什么区别？

云端的好处是弹性扩缩容，流量上涨时加实例就行，适合流量波动大的场景。但云端的多模态 RAG 有个问题——跨实例的向量检索和模型推理延迟不稳定，因为网络和共享存储的 IO 抖动会放大到端到端体验上。物理机（裸金属或 GPU 独享）的好处是性能稳定，延迟可预测，一张卡上的 TensorRT 优化可以做到极致。一万网络的 GPU 定制方案是物理机独享，搭配 100M BGP 独享带宽，适合对延迟和稳定性要求高的生产环境。如果业务初期流量不大，可以先从 AI 算力云的弹性切片起步，流量上来后一键迁移到物理机方案。

9. 做多模态 RAG 一定要用 TensorRT 优化吗？

不一定，但强烈建议做。TensorRT 优化可以把 MLLM 的推理延迟降低 30–60%（行业参考，以咨询为准），具体取决于模型结构和精度。比如 InternVL2-8B 在 A100 上用原生 PyTorch 推理，Prefill 阶段约 800ms，Decode 阶段约 35ms/token；做了 TensorRT 优化后，Prefill 降到 400ms，Decode 降到 20ms/token。但 TensorRT 的优化过程比较费时，特别是多模态模型的视觉编码器部分，需要手动写插件来支持自定义算子。一万网络的工程师 1 对 1 部署服务会帮你做 TensorRT 优化，开机就已经优化好了，省去这个折腾过程。

七、总结：多模态 RAG 的 GPU 选型，先分三层再掏钱

多模态 RAG 跟纯文本 RAG 完全不是一个量级的算力需求，这点必须心里有数。一套生产级的多模态 RAG 至少需要三块 GPU 资源：Embedding 推理（A100 40G 或 1/10 切片）、向量检索加速（可选，数据量大时上 GPU 索引）、MLLM 推理（A100 40G 双卡或 80G 单卡）。千万别想着用一张卡包打天下，那只会让整个系统都在等待显存。

我的建议是：如果你刚开始做多模态 RAG 的 POC，先租一张 A100 40G 跑通流程（一万网络官网月付 ¥2800，年付 8 折），验证检索精度和生成质量满足业务要求后，再根据实际并发量按需扩容。别上来就上 H100，也别抱着 T4 不放——多模态场景下，显存就是生产力，省显存就是省质量。

如果你正在为多模态 RAG 的 GPU 配置发愁，一万网络支持 A100 40G、A100 80G、H100 SXM 80G 多型号定制，工程师一对一部署 ML 环境，七乘二十四小时工单平均五分钟响应，硬件故障十分钟自动迁移，深耕 IDC 十九年的老牌服务商，值得信赖。

数据来源

本文价格数据与配置信息参考自一万网络官网（https://www.idc10000.net/）GPU 服务器租用页面、AI 算力云产品页及行业公开参考资料。模型算力数据基于 InternVL2、Qwen2-VL、SigLIP 等开源模型在 A100/H100 平台上的实测结果。具体以签约时最新报价与合同为准。