部署时先别急着按模型参数量买机器。视觉语言模型在线服务的硬件资源拆分，关键是把一次请求经过的环节分开核算：图片进入服务后要解码、调整尺寸，再由模型生成回答；任何一环排队，都可能拉高用户等待时间。以下五步适用于图片问答、图表解释等常见在线场景。
第一步：先画出请求路径
记录请求从网关到返回答案的顺序，并标出每段处理由谁承担。至少区分网络接入、图像预处理、模型计算、结果返回和日志写入。用同一批测试请求记录总时延及各阶段耗时，才能判断瓶颈是在算力、数据搬运还是排队。
先确定服务目标：每秒请求量、可接受的首 token 延迟、图片尺寸范围，以及高峰时允许的并发数。目标不同，硬件配比也不同；低流量服务重视单请求响应，高并发服务则更需要吞吐和缓存余量。
第二步：拆开图像处理与模型推理
让预处理有独立容量
图像预处理包括解码、方向修正、缩放和格式转换。把它单独放在通用计算节点上，或与推理进程共置，取决于图片量和延迟要求：共置部署简单、数据传输少，但处理高峰可能抢占模型进程的 CPU；分离部署更易独立扩容，却增加网络传输和运维环节。
应按照模型支持的输入规格设定图片上限，不要无条件保留原图尺寸。输入分辨率提高，可能带来更多视觉 token 和更重的编码计算；具体增幅取决于模型架构及切图策略。上线前用真实尺寸分布测量解码耗时、内存峰值和生成速度。
第三步：按模型权重与运行余量配置加速卡
估算推理设备时，模型权重只是底数，还要为视觉编码器、运行时临时张量、KV缓存和并发请求留空间。以约 7B 参数模型为例，若权重采用每参数约 2 字节的精度表示，仅权重就约需 14GB；这不是整机显存需求，实际占用会随精度、框架、输入长度和并发变化。
选型时比较显存容量、计算能力、设备间互联和软件兼容。NVIDIA L40S可作为通用推理卡的候选；较大模型或更高并发通常需要更充足的显存和设备资源。不要只看峰值算力：先在目标框架中验证模型能否加载，再测长图、长回答和多请求同时到达时的峰值占用。
第四步：把并发队列与KV缓存纳入预算
并发增加时，模型要为每个生成中的会话保留上下文状态，KV缓存会占用显存；上下文越长、并行会话越多，压力越大。服务端应设置并发上限和排队策略，避免请求无限堆积。若显存紧张，可先限制最大输入长度或并发，再评估缓存管理和模型量化；不同方案会影响吞吐、延迟或输出质量。
用阶梯方式压测：逐步增加并发，记录显存占用、队列长度、首 token 延迟及每秒生成 token 数。测试应覆盖常见图片和较大输入，不要只用短文本请求得出容量结论。
第五步：分配主机、网络、存储并复测
主机内存用于服务进程、图片缓冲和模型加载过程；磁盘保存模型文件、容器镜像及日志。按实际模型文件大小预留空间，并为版本回滚和日志轮转留余量。多节点部署时，检查节点间网络吞吐与延迟，尤其是模型分片或远程预处理会增加数据传输的情况。
- 固定模型版本、输入尺寸和压测请求集。
- 分别测单请求、目标并发和峰值并发下的时延与资源占用。
- 先调整队列、图片上限或缓存策略，再决定增加加速卡、预处理节点或存储容量。
- 配置监控告警，持续观察设备显存、内存、磁盘、网络和请求排队情况。
这样拆分后，视觉语言模型在线服务的硬件资源拆分就能对应到可观察的瓶颈，而不是按某个参数量直接猜机器规格。上线后结合真实流量复测，按最先触顶的资源扩容。
常见问题
只看模型参数量够不够？
不够。权重之外还要考虑视觉输入、运行时占用、KV缓存和并发。
图像预处理必须单独部署吗？
不必须。流量较小可共置；预处理造成排队或需要独立扩容时，再考虑分离。
如何判断该加卡还是限并发？
看压测时的显存、队列和延迟：显存已接近上限可先限并发或缩短输入；设备利用不足而队列变长，则排查预处理、网络或调度瓶颈。
