上线前只看模型参数量，常会低估显存：图片会经过视觉编码器，生成过程还要保留上下文缓存。估算视觉语言模型在线服务的硬件资源拆分，应把模型、请求并发和数据处理放进同一张账里，而不是只问“这张卡能不能装下模型”。
先算显存：权重只是底线
以公开发布的 Qwen2-VL-7B-Instruct 为例，若权重以 BF16 或 FP16 保存，7B 参数仅权重约需 14 GB（十进制），换算成 GiB 约为 13 GiB。实际运行还要给推理框架、视觉编码器、临时张量和显存碎片留余量，因此不能把卡的标称显存全部视为可用空间。若使用量化权重，权重占用会下降，但算子支持和输出质量需要实测确认。
并发与图片尺寸会改变余量
生成阶段的 KV缓存会随请求数、输入上下文长度和输出长度增长；多轮对话若连同历史一起提交，也会增加占用。图像经视觉编码器后形成的视觉 token 数，受图片尺寸、裁切策略和动态分辨率影响。因而同一模型在单张小图问答与多张高分辨率图片分析中，显存峰值可能不同。预算时至少分别测单图、常见多图和允许的最大输入。
CPU和主机内存负责“进模型之前”
CPU主要处理网络请求、图片解码、尺寸调整、格式转换、分词及结果封装；解码线程不足会让 GPU 等待，线程开得过多又会争抢算力和内存带宽。主机内存则容纳服务进程、请求队列、输入图片和模型加载时的临时副本。单机起步可把 8–16 个 vCPU、32–64 GB 主机内存作为试运行配置区间，而非通用答案；图片吞吐高、进程多或要并行加载模型时，应按压测结果增加资源。
磁盘也需纳入资源清单：除权重文件外，还要考虑模型版本并存、容器镜像、缓存与日志。部署多个模型版本便于回滚，但会增加存储占用和加载时的内存压力。
用目标负载验证估算
- 固定输入边界：记录图片数量、长边尺寸、对话历史长度和最大生成长度；明确是否启用动态分辨率。
- 选定运行配置：固定权重精度、推理框架、单卡模型副本数及批处理策略，避免多个变量同时变化。
- 逐步加并发：从单请求开始，再递增并发，观察显存峰值、CPU利用率、主机内存、排队时间和响应时延。
- 复测最重请求：使用允许范围内最大的图片与上下文，连续运行一段时间，检查是否出现显存溢出、内存持续上涨或延迟恶化。
记录结果后再决定加卡、缩短上下文、限制图片尺寸，还是增加 CPU。若瓶颈在 KV缓存，单纯增加 CPU 帮助有限；若 GPU 利用率偏低而图片处理排队明显，应先检查 CPU 预处理与队列设置。
按瓶颈分配，而不是按型号猜
小并发、短上下文的在线问答，重点是权重能否装入显存并留出运行余量；长对话或多图请求，缓存和视觉 token 可能更先成为限制。多实例部署能提高整体吞吐，却会重复占用权重显存；单实例配合批处理更省权重空间，但可能增加等待时间。选哪种方式，要看延迟目标和请求形态。
归纳起来，视觉语言模型在线服务的硬件资源拆分应分别核算权重、视觉编码器与缓存的显存，CPU与主机内存的数据通路，以及磁盘和并发带来的额外开销。先按模型精度做底线估算，再用真实输入边界压测，才是可复核的上线方案。
常见问题
显存刚好装下权重，就能上线吗？
不建议。运行时开销、输入图像和生成缓存都需要额外显存，应通过最大请求压测确认峰值余量。
增加 CPU 能解决显存不足吗？
不能。CPU可改善图片处理或请求排队瓶颈，但不会替代模型权重和缓存所需的 GPU 显存。
量化后是否一定能承载更多并发？
未必。量化能减少权重占用，但并发还受 KV缓存、视觉输入、框架实现及延迟目标影响，需按目标负载复测。
