部署视觉问答服务时，显卡利用率看起来不高，显存却可能先满；也可能显存充足，但请求排队、响应仍然很慢。理解视觉语言模型在线服务的硬件资源拆分，关键是把“算得动”和“装得下”分别估算，再把图像输入、并发和延迟目标放进同一张账里。
先把资源分成计算与容量
计算资源决定模型处理请求的速度，主要看 GPU 的计算能力、显存带宽，以及 CPU 对图像解码和请求调度的支撑。容量资源则包括 GPU 显存、主机内存和磁盘空间。它们用途不同：磁盘可以存模型文件，却不能替代推理时需要的显存。
以常见的自回归视觉语言模型为例，显存不仅要放模型权重，还要容纳视觉编码器、运行时工作区和 KV缓存。模型参数量为 7B 时，仅按每个参数约 2 字节估算，FP16 权重就约需 14GB；这只是权重的粗略值，实际占用还会受模型结构、框架、量化方式和图像输入影响。因此，不能看到显卡标称显存大于权重体积，就断定服务一定能稳定运行。
图像输入会改变资源账本
分辨率与图像切块
视觉编码器需要把图像转换成视觉 token。输入分辨率提高、模型采用多裁剪或切块策略时，视觉 token 数通常会增加，计算量和中间张量占用也随之上升。处理一张商品图和处理一页高分辨率扫描件，并不一定是同等成本的请求；后者还可能需要额外的方向校正、缩放或页面拆分。
因此，规划视觉语言模型在线服务时，应明确允许的图片尺寸、每次请求的图片数，以及超出限制时的处理方式。限制输入并非单纯省显存：统一尺寸范围也能减少请求耗时差异，降低少数大图拖慢整批请求的风险。
并发时，内存比单次推理更容易失控
每个正在生成回答的请求，都可能占用与上下文长度、生成长度和批处理策略相关的 KV缓存。并发增加时，这部分显存会累积；较长的对话历史和较长的输出，也会比短问答消耗更多资源。若服务使用连续批处理，吞吐量可能提高，但调度方式和请求长度仍会影响显存峰值及延迟。
主机内存则常用于模型加载、图像解码、网络缓冲和数据队列。内存不足时，可能出现系统换页或进程被终止，表现为延迟抖动甚至服务中断。SSD适合保存模型权重和日志，不适合当作实时推理显存的替代品。
按目标估算，再用压测校正
- 固定请求边界。记录图片尺寸上限、单次图片数、提示词长度、最大输出长度和目标并发。边界不清，估算结果就无法比较。
- 核算静态占用。按模型参数量和权重精度估算权重体积，再查所用推理框架的运行要求，为视觉模块和工作区留出余量。量化能减少权重占用，但不代表其他显存开销同比下降。
- 核算动态占用。用目标上下文和并发测试 KV缓存及峰值显存。无法先得到准确值时，先从低并发开始逐级增加，并观察显存、吞吐和请求延迟。
- 区分瓶颈。若显存已接近上限，优先检查上下文、并发和输入尺寸；若显存有余量但 GPU 持续繁忙、吞吐不足，再评估计算能力或增加推理实例。CPU繁忙时，则检查图像解码、预处理和数据搬运。
- 复现真实流量。用实际图片类型与提示词压测，记录首 token 延迟、完整响应时间、吞吐和错误率。测试冷启动与持续运行，并在容量留有余量的配置上复测，避免只按理想状态上线。
硬件选择看限制，不看单一参数
NVIDIA L4 与 A100 属于不同定位的 GPU 产品，比较时应核对具体型号的显存容量、带宽、计算能力、服务器功耗与软件兼容性，而不只看型号名称。显存容量决定能否容纳目标模型与运行时状态；计算能力和带宽则影响处理速度。大显存不自动等于低延迟，算力较强也不代表长上下文、多并发一定放得下。
单卡部署更简单，适合模型和并发都能在单卡预算内运行的服务；多卡切分可以容纳更大的模型或提高并行能力，但会增加通信、调度和运维复杂度。应先以单机实测确认瓶颈，再决定扩显存、增加 GPU，还是缩小输入和上下文范围。视觉语言模型在线服务的硬件资源拆分，最终要由模型、请求形态和服务目标共同决定。
常见问题
权重能放进显存，就能启动服务吗？
不一定。还要给视觉模块、运行时工作区、KV缓存和并发请求留空间。
增加主机内存能解决显存不足吗？
通常不能直接解决。主机内存可支撑解码和缓存，但 GPU 推理所需的显存仍需单独满足。
量化后可以直接提高并发吗？
量化可能释放权重占用，但并发还受 KV缓存、计算能力和调度方式限制，需压测验证。
部署前最值得测什么？
用真实图片和目标上下文测试峰值显存、首 token 延迟、完整响应时间及持续吞吐，再确定并发上限。
先明确请求边界，再分别核算权重、视觉输入和并发缓存，才能让视觉语言模型在线服务的硬件资源拆分落到可验证的配置上，而不是只凭显卡规格猜测。
