视觉语言模型在线服务的硬件资源拆分，关键不是简单地“GPU越多越好”，而是让耗时的模型计算留在GPU，把适合并行、轻量且需要灵活调度的工作交给CPU。图像解码、请求校验和模型生成争抢同一类资源时，才是需要调整配置的信号。
先分清哪些工作该由谁承担
一条常见的在线推理链路包含接收请求、读取图像、缩放或裁剪、视觉特征提取、语言模型生成，以及格式整理和返回。GPU擅长大规模矩阵运算，通常适合执行视觉编码器和语言模型的主要推理计算；CPU更适合网络服务、图像文件解码、尺寸调整、排队调度、文本处理及日志记录。
图像预处理并非必须全放CPU：如果CPU解码和缩放成为瓶颈，或系统已有适合GPU的预处理实现，可以把部分操作移到GPU。但数据搬运、显存占用和实现复杂度也会增加，不能只看单项算子更快就迁移。
成本差异主要由显存、并发和延迟决定
GPU先看显存是否装得下
模型权重只是显存需求的一部分，运行时还要留空间给KV缓存、临时张量和批处理。以约70亿参数模型为例，BF16权重本身约占14GB（按十进制估算）；实际显存需求会更高，具体取决于视觉编码器、上下文长度、并发请求和推理框架。不能据此直接认定某个显存容量一定够用。
低比特量化可以减少权重占用，但效果与模型、量化方法和运行框架有关，也可能影响输出质量或兼容性。选卡时应在目标并发和输入尺寸下实测显存峰值，而不是只按参数量计算。
CPU按数据入口和并发配置
CPU资源不足时，GPU可能在等图像解码、请求调度或数据传输；CPU过多而GPU已满载，则增加CPU通常不会提高生成吞吐。适合的CPU核心数没有统一比例，应观察CPU利用率、运行队列、GPU利用率和请求的P95延迟。CPU亲和性、线程数及预处理并行度也会影响结果。
按服务目标选择拆分方式
- 低并发、重视响应时间：把视觉编码和语言生成放在GPU，CPU负责必要预处理，控制排队和批处理等待。适用于交互式问答；过度合批可能提高吞吐，却拉长单个请求的等待时间。
- 请求稳定、重视单位成本：通过小批量合并请求提高GPU利用率，同时由CPU并行解码和准备图像。适用于可以接受一定等待的任务；批量过大可能触及显存上限或增加尾延迟。
- GPU利用率偏低：先查CPU是否被解码、线程竞争或数据传输卡住，也要检查请求是否太零散。只有确认GPU计算已饱和，再考虑增加GPU算力或拆分实例。
因此，视觉语言模型在线服务的硬件资源拆分应围绕瓶颈调整：GPU按模型计算和显存需求配置，CPU按入口流量、预处理和并发调度配置。单纯提升一侧规格，未必能改善端到端表现。
用小规模压测找到合适配置
- 固定模型版本、图像分辨率、提示词长度和生成上限，记录业务中的典型请求，避免不同测试条件互相干扰。
- 先测单并发，再逐步增加并发；分别记录吞吐量、首字延迟、总延迟、P95延迟、CPU利用率和GPU显存峰值。
- 观察瓶颈：GPU持续繁忙且延迟上升，优先优化模型、批处理或GPU配置；CPU繁忙而GPU有空闲，则检查解码线程、调度和数据管道。
- 每次只改一个变量，例如批量大小、预处理线程数或最大并发，并在目标流量下复测。留出显存余量应对输入变化和运行时开销。
比较方案时，还要把设备采购或租用、功耗、机器数量与服务目标放在一起看。吞吐最高的配置不一定最划算；如果业务要求低延迟，较小批量可能比追求峰值吞吐更合适。
常见问题
图像缩放一定要放在CPU吗？
不一定。CPU实现简单且便于调度；当CPU成为瓶颈时可测试GPU预处理，但需计入数据搬运和显存成本。
CPU利用率不高，是否说明CPU配多了？
未必。平均利用率可能掩盖单核线程瓶颈，应结合线程占用、排队情况及GPU等待时间判断。
先升级GPU还是增加CPU？
先看瓶颈指标：GPU计算或显存饱和时评估GPU；CPU预处理排队且GPU空闲时，先优化CPU侧流程。以目标负载压测结果为准。
