多模态大模型在图文理解、视频问答、语音交互等场景中的落地速度非常快，但算力调度的问题也随之变得突出：不同模态的输入长度差异极大，图片一次能产生上千个视觉 Token，而文本可能只有几十个 Token，同一个请求内部的计算需求天然不均衡。如果仍然按照传统的“固定并行度 + 静态显存分配”方式去部署多模态大模型，很容易出现部分 GPU 吃满、部分 GPU 空转的情况。本文围绕 ParVL 所代表的并行扩展（Parallel Scaling）与可扩展计算分配（Expandable Compute Allocation）思路展开，梳理多模态 LLM 场景下的计算调度原理、架构设计、工程实现与排查方法，适合正在做多模态推理服务、大模型集群调度或性能优化的读者参考。
1. 背景与核心概念
1.1 从大语言模型到多模态大模型的算力挑战
传统大语言模型（LLM）的输入是一段文本序列，模型计算量主要由 Sequence Length 和 Hidden Size 决定。对一个请求来说，只要输入 Token 数量确认，计算量基本可以预估。推理框架在分配计算资源时，可以基于 Token 数做比较准确的负载预估。
多模态大模型（Multimodal LLM）的情况则复杂很多。以视觉语言模型为例，一张 224x224 的图片经过 Vision Encoder 和 Projector 后可能产生数百甚至上千个视觉 Token，而模型在做图文问答时，文本部分的 Token 数量可能只有几十。更关键的是，图像特征已经进入语言模型后，后续每个 Decoder Layer 都要在视觉 Token 上做 Attention 计算，计算量会随着图片尺寸和分辨率动态变化。
音频、视频、3D 点云等模态同样存在类似问题。多模态请求之间的计算需求方差非常大，简单粗暴地“按请求数均分 GPU”或“按文本序列长度预估显存”都会导致严重的资源浪费。
1.2 什么是 ParVL
ParVL 可以理解为一套面向多模态 LLM 的并行扩展与可扩展计算分配思路。它从以下两个层面解决多模态大模型推理中的算力浪费问题：
- 并行扩展（Parallel Scaling）：将单个多模态请求或一批请求按计算维度拆解到多个计算设备上，通过数据并行、张量并行、序列并行等策略叠加，在多个 GPU/NPU 上同时执行。
- 可扩展计算分配（Expandable Compute Allocation）：在并行扩展的基础上，根据请求的实际计算需求和模态组成，动态调整分配给每个请求的计算单元数量、显存资源和并行度，而不是采用固定配置。
简单来说，ParVL 既解决“如何把计算摊到多张卡上”，也解决“每张卡应该分多少计算量”。
需要说明的是，ParVL 作为一个研究与实践方向，目前还没有统一的官方实现规范。本文重点介绍其中的核心技术原理与可落地的工程框架，读者可以根据自己的集群环境和模型结构做适配。
1.3 为什么并行扩展不能只靠“加卡”
在多模态模型刚出现时，很多团队的做法是“模型太大，就做张量并行；请求太多，就做数据并行；再不够就加卡”。这种思路能解决模型单卡放不下的问题，却无法解决多模态请求内部计算量不均衡的问题。
举一个具体的例子：
- 请求 A：一张 1024x1024 高清图片 + 一句话，视觉 Token 可能超过 2000 个。
- 请求 B：纯文本问题，只有 100 个 Token。
如果两个请求被分配到同一个数据并行组内，每个 GPU 都需要处理自己那张卡上的完整模型计算。请求 A 会造成较高的显存占用和算力消耗，而请求 B 的相对轻量。当没有细粒度的计算分配机制时，系统只能按最大可能负载去预留资源，造成大量显存碎片和空闲算力。
ParVL 的核心思路，就是把“一次请求的完整计算”通过并行性和可扩展计算分配组合起来，让系统能够感知请求模态，实时决定：
- 当前请求需要多少并行度；
- 当前请求占用多少显存；
- 如果有新增请求，能否动态扩展计算单元；
- 如果已经执行完一部分，能否释放和回收计算资源。
这个能力对部署多模态大模型服务的企业来说，直接影响吞吐量、响应延迟和 GPU 成本。
2. 多模态工作负载的计算特征分析
2.1 不同模态 Token 粒度差异
在设计并行扩展和计算分配方案之前，先要理解多模态工作负载的基本特征。
| 模态 | 典型表示方式 | Token/特征数量 | 计算特点 |
|---|---|---|---|
| 文本 | Token 序列 | 几十到几千 | 依赖序列长度，可预测性强 |
| 图像 | Patch + Position Embedding | 数百到数千 | 随分辨率变化，Attention 开销大 |
| 视频 | 多帧图像特征 | 数千到数万 | 帧数影响显存，时序建模复杂 |
| 音频 | Mel 谱图特征 | 数百到数千 | 长度随音频时长变化 |
这些模态特征最终都会映射到大模型的 Transformer Layers 中。即使并行策略相同，不同模态请求的计算量也存在数量级差异。
如果不做模态感知的调度，那么 GPU 的显存分配只能取上限，负载均衡完全靠运气。
2.2 静态并行方案的不适配
传统推理方案中，一个很常见的做法是预先设置一个固定并行度。例如，模型需要 2 张 GPU 才能放下，就在每组请求到来时都使用 Tensor Parallel Size = 2。
这种方案有两个问题：
- 轻量请求也被迫占用多卡。纯文本请求并不需要 2 张卡的并行度，但系统为了一致性仍然给它分配 2 卡，导致 GPU 利用率下降。
- 重量请求无法弹性扩展。当高清图片请求到来时，2 卡并行度可能不足以支撑低延迟推理，而系统又没有能力临时把并行度扩展到 4 卡。
可扩展计算分配要解决的核心问题，就是让并行度成为可调节变量。
2.3 动态计算分配的核心诉求
从工程角度看，可扩展计算分配需要满足以下诉求：
- 请求级感知：系统能获取每个请求的模态组成和预估计算量。
- 资源池化：GPU 计算单元不再固定属于某个请求，而是放入统一资源池，按需领取。
- 动态扩展与回收：请求在运行过程中可以追加计算单元，也可以释放已经不需要的计算单元。
- 并行度可变化：同一个模型在不同请求下，可以运行在不同的并行度配置上。
这些能力组合起来，才能真正逼近“算力按需分配”的理想状态。
3. ParVL 的核心设计：并行扩展与可扩展计算分配
3.1 并行扩展的三个维度
在多模态 LLM 场景中，并行扩展可以从以下三个维度理解。
数据并行（Data Parallelism）：将不同的请求分发到不同的 GPU 副本上执行。每个副本持有完整模型，请求之间互不干扰。这是最直观的扩展方式，适合大量独立请求并发的场景。
张量并行（Tensor Parallelism）：将模型的矩阵计算按层内维度切分，例如把 Attention 的头分布到多张卡上，每个设备计算一部分，再通过通信合并结果。张量并行能降低单卡显存压力，但对通信带宽要求很高。
序列并行（Sequence Parallelism）：将超长的序列切分为多个片段，分别在不同设备上计算 Attention，再组合结果。对视觉 Token 数量多的请求很有用，因为多模态请求的序列长度波动大，序列并行能有效降低单设备显存峰值。
ParVL 的设计思想并不是在三个维度中选一个，而是根据请求特征组合使用。例如：
- 纯文本短请求：采用数据并行，一组卡同时处理多个请求。
- 高分辨率图片请求：采用张量并行 + 序列并行，降低单卡显存峰值。
- 视频长序列请求：以序列并行为主，结合流水线并行分摊视频帧编码计算。
3.2 可扩展计算分配的含义
可扩展计算分配可以理解为资源池化下的动态并行度调整。
传统方案中，一个推理实例一旦启动，它的并行度和显存占用就固定了。比如某个推理服务配置为 2 卡张量并行、显存占用 16GB，那么每个请求都要在这 2 卡上执行。
ParVL 风格的计算分配则采用类似“资源租约”的方式：
- 请求进入调度器。
- 调度器根据请求的模态信息预估计算需求。
- 从资源池中申请一个“计算单元组”，例如 2 卡或 4 卡。
- 如果在执行过程中发现算力不足，可以动态扩展计算单元。
- 请求完成后，资源释放回资源池。
这种设计的一个关键点，是模型本身的参数如何在不同并行度之间切换。因为模型参数分布在多张卡上，如果并行度从 2 卡变成 4 卡，参数需要重新切分。实现时通常有两种方式：
- 预先保存多种并行度的模型副本，切换时加载对应副本；
- 在运行时通过 AllGather 等通信操作重新分发模型权重。
前者简单但显存冗余大，后者灵活但通信开销高，实际可以根据集群规模和切换频率选择。
3.3 整体工作流程
请求进入 → 多模态输入解析（图片/文本/音频特征提取） → 计算需求预估（Token 数量、序列长度、显存估算） → 并行度决策（选择数据并行/张量并行/序列并行组合） → 从资源池申请计算单元 → 模型推理执行 → 资源监控与动态调整 → 结果回收，计算单元释放这个流程的关键是“计算需求预估”和“并行度决策”，它们直接决定了后续资源分配的合理性。
4. 概念架构与关键模块
下面给出一个概念层面的架构拆分，不涉及具体框架，适合作为团队设计参考。
4.1 资源池与调度器
资源池维护所有可用的计算设备信息，包括：
- 每张 GPU 的显存总量和剩余显存；
- 每张 GPU 当前的计算负载；
- GPU 之间的通信带宽；
- 已经分配给哪些请求。
调度器负责任务到资源池的映射。它的输入是一个请求描述，输出是一个资源分配方案，包含：
- 分配的 GPU 列表；
- 并行度类型和大小；
- 预估显存与执行时长。
4.2 多模态编码任务切分
多模态 LLM 请求在进入语言模型之前，通常要经过各自的 Encoder。图片、音频、视频的编码阶段计算量差异很大，而且编码阶段和语言模型阶段的计算比例不稳定。
一个好的做法是把编码阶段和推理阶段拆分为独立的计算阶段。图片编码可以在小批量 GPU 上执行，编码产生的视觉特征再进入语言模型阶段。这样可以避免某个请求的图片编码阻塞其他请求的语言模型计算。
4.3 推理执行与结果聚合
语言模型阶段是计算密集型任务，建议采用张量并行或序列并行。执行过程中，调度器需要持续监控各设备的负载。
当某个设备显存不足或算力吃紧时，可以通过以下方式调整：
- 将部分序列片段迁移到其他设备；
- 扩大序列并行度；
- 将该请求的后续计算迁移到另一个计算单元组。
最终输出结果由所有设备聚合后返回，聚合操作通常位于调度器或前向代理层。
5. 工程实现思路（示例）
下面用一个简化示例展示 ParVL 风格的调度逻辑。示例使用 Python 描述核心思想，需要根据你使用的推理框架和集群环境做调整。
5.1 任务描述模型
首先定义一个任务描述结构，记录请求的模态信息、预估 Token 数和优先级。
# 文件路径：task_desc.py from dataclasses import dataclass, field from typing import Dict, List @dataclass class MultimodalTask: request_id: str text_tokens: int = 0 image_tokens: int = 0 audio_tokens: int = 0 video_frames: int = 0 priority: int = 0 def total_tokens(self) -> int: return ( self.text_tokens + self.image_tokens + self.audio_tokens + self.video_frames * 128 ) def est_memory_mb(self) -> int: # 简化估算：以 Token 数为主要因子 return self.total_tokens() * 2 + 1024 def suggested_parallelism(self) -> int: tokens = self.total_tokens() if tokens > 10000: return 4 elif tokens > 2000: return 2 return 1这个类的作用是让调度器快速了解一个请求的资源需求。实际项目中，Token 数可以在编码阶段获得，优先级可以从用户或业务侧传入。
5.2 资源池管理
接下来定义一个简单的资源池，记录 GPU 的状态。
# 文件路径：resource_pool.py from dataclasses import dataclass @dataclass class GpuInfo: gpu_id: str total_memory_mb: int free_memory_mb: int load: float # 0.0 - 1.0 assigned_task_id: str = "" class GpuResourcePool: def __init__(self, gpus: List[GpuInfo]): self._gpus = {gpu.gpu_id: gpu for gpu in gpus} def available_gpus(self): return [ gpu for gpu in self._gpus.values() if gpu.free_memory_mb > 4096 and gpu.load < 0.8 ] def acquire(self, task: MultimodalTask, parallelism: int) -> List[str]: available = self.available_gpus() if len(available) < parallelism: raise RuntimeError("not enough gpu resource") selected = available[:parallelism] mem_per_gpu = task.est_memory_mb() // parallelism for gpu in selected: gpu.free_memory_mb -= mem_per_gpu gpu.assigned_task_id = task.request_id return [gpu.gpu_id for gpu in selected] def release(self, task_id: str, mem_per_gpu: int): for gpu in self._gpus.values(): if gpu.assigned_task_id == task_id: gpu.free_memory_mb += mem_per_gpu gpu.assigned_task_id = ""真实场景中还需要考虑显存碎片、通信拓扑、GPU 亲和性等复杂因素，这里只演示资源分配的基本骨架。
5.3 调度主流程
下面把任务解析、资源申请和并行度决策串联起来。
# 文件路径：scheduler.py from task_desc import MultimodalTask from resource_pool import GpuResourcePool def dispatch(task: MultimodalTask, pool: GpuResourcePool): # 1. 预估资源需求 parallelism = task.suggested_parallelism() # 2. 尝试申请资源 try: gpu_ids = pool.acquire(task, parallelism) except RuntimeError as e: # 资源不足时降级到较低并行度 parallelism = 1 gpu_ids = pool.acquire(task, parallelism) # 3. 返回调度信息 return { "request_id": task.request_id, "gpu_ids": gpu_ids, "parallelism": parallelism, "est_memory_mb": task.est_memory_mb(), } if __name__ == "__main__": pool = GpuResourcePool( gpus=[ GpuInfo(gpu_id="gpu-0", total_memory_mb=32768, free_memory_mb=30000, load=0.3), GpuInfo(gpu_id="gpu-1", total_memory_mb=32768, free_memory_mb=30000, load=0.3), GpuInfo(gpu_id="gpu-2", total_memory_mb=32768, free_memory_mb=30000, load=0.3), GpuInfo(gpu_id="gpu-3", total_memory_mb=32768, free_memory_mb=30000, load=0.3), ] ) task = MultimodalTask( request_id="req-001", text_tokens=64, image_tokens=4096, ) plan = dispatch(task, pool) print(plan)这段代码展示了可扩展计算分配调度的核心流程：任务描述 → 资源预估 → 并行度决策 → 资源申请 → 调度结果返回。实际项目中，还需要在推理完成后调用release()释放资源。
5.4 动态扩展与回收
真正的可扩展计算分配还要求在执行过程中能动态调整并行度。以视觉 Token 较多的请求为例，如果编码阶段结束后发现实际序列长度超过预估，调度器可以触发“扩容”。
扩容流程可以概括为：
- 当前请求正在 2 卡上执行，并行度为 2。
- 调度器发现 GPU 显存峰值接近上限，或预计剩余计算时间过长。
- 调度器从资源池找到另外 2 张空闲 GPU。
- 通过通信操作同步中间状态，将并行度从 2 扩展到 4。
- 继续执行后续计算。
这类动态调整对推理框架的要求很高，因为模型中间激活值、KV Cache 都需要在设备间重新分布。因此，工程上通常采用“分块调度”来降低迁移成本：将长序列按块分配到不同设备，设备间只传递关键中间结果。
6. 性能评估方法与指标
6.1 核心评价指标
评估 ParVL 风格调度方案，建议关注以下指标：
| 指标 | 含义 | 观察方式 |
|---|---|---|
| 吞吐量 | 单位时间完成的请求数 | 压测工具统计 |
| 首 Token 延迟 | 请求发出到第一个 Token 返回的时间 | 端到端监控 |
| 端到端延迟 | 完整输出耗时 | 端到端监控 |
| GPU 利用率 | 计算单元的平均利用率 | nvidia-smi / NPU 监控 |
| 显存碎片率 | 可用显存与实际可分配显存的比例 | 资源池内部统计 |
| 扩容耗时 | 并行度从低到高的切换时间 | 调度日志统计 |
多模态场景下，建议指标按“模态类型”和“序列长度区间”拆分统计，否则平均值会掩盖负载不均的问题。
6.2 压测与调优流程
压测时不要只用简单文本请求。推荐构造包含以下类型的混合负载：
- 纯文本短请求，Token 数 50 到 200；
- 图文请求，图片分辨率从 224 到 1024；
- 长文本 + 多图请求，Token 数 3000 到 8000；
- 视频帧序列，帧数从 8 到 32。
每一轮压测后记录不同模态请求的延迟分布、吞吐量和 GPU 利用率。调优时重点观察：
- 资源池剩余显存是否充足；
- 是否存在某个模态请求长时间占用大批 GPU；
- 扩容过程中是否出现通信阻塞；
- 并行度从 1 变成 4 的决策是否过于频繁。
6.3 不同负载下的对比
如果希望验证“可扩展计算分配”相比“静态固定并行度”的优势，可以设计两组对比实验：
- 静态方案：所有请求统一使用固定并行度，例如 2 卡张量并行。
- 动态方案：按请求特征动态分配并行度，例如轻量请求 1 卡，重量请求 4 卡。
在混合负载下，动态方案通常能在吞吐量上提升 20% 到 40%，端到端延迟尤其在高分辨率图片请求上会有明显改善。但具体数值与模型结构、GPU 型号、通信拓扑强相关，需要通过真实压测验证。
7. 常见问题与排查思路
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 请求在扩容后反而变慢 | 通信开销大于计算收益 | 检查 GPU 间通信带宽；在小规模并行度下对比耗时 |
| 显存碎片率升高 | 请求频繁申请/释放显存 | 引入显存缓存池，避免频繁释放 |
| 轻量请求延迟被拉长 | 调度器为等待资源而排队 | 设置优先级；为轻量请求预留最低保证资源 |
| 多模态编码阶段阻塞推理 | 编码和其他推理混在同一资源池 | 拆分编码队列与解码队列 |
| 调度器成为单点瓶颈 | 请求量过大，调度计算耗时上升 | 把调度器拆成多实例，或采用批量调度 |
| 扩容后 KV Cache 不一致 | 中间状态迁移不完整 | 检查通信操作；增加状态同步校验 |
如果遇到“并行度提升但吞吐量不升反降”的情况，优先排查通信开销。多卡并行不是免费的，NCCL / RCCL 集合通信耗时随着卡数和消息体量上升，只有当单卡计算量显著大于通信量时，增加并行度才有正收益。
8. 最佳实践与工程建议
8.1 调度决策要快
可扩展计算分配对调度器的实时性要求很高。如果每次决策都依赖复杂的优化求解，调度时延反而会拖累整体吞吐。建议采用两层决策：
- 快速决策层：基于 Token 数、模态类型和简单阈值，快速给出并行度。
- 精细优化层：对长周期任务或高优先级任务，在后台运行更细粒度的资源规划。
这样既能保证普通请求的低延迟，又能为重要请求提供优化空间。
8.2 给不同模态预留独立算力池
多模态请求最怕的是相互争抢。当一个视频请求正在占用大量 GPU，突发的大量图片请求可能把资源池打满，导致视频任务频繁扩容/迁移。
建议在资源池内划分逻辑隔离区：
- 文本轻量请求池；
- 图片请求池；
- 视频长序列请求池；
- 弹性共享池。
共享池只在独立池资源不足时启用，避免单一模态的突发流量拖垮整体服务。
8.3 合理设置扩容阈值
扩容不是越快越好。频繁扩容会导致模型状态反复迁移，通信开销占比升高。建议为扩容设置“条件组合”：
- 当前并行度下预估剩余时延超过 N 秒；
- 资源池中空闲 GPU 数量充足；
- 通信拓扑满足低延迟条件。
同时满足时再触发扩容。同类条件也适用于缩容，避免资源释放后又立即被需要。
8.4 提前缓存常用模态编码结果
图片、视频、音频经过 Encoder 后产生的特征是可以重复利用的。对于同一条图片或视频反复出现在不同请求中的场景，可以通过特征缓存降低重复编码的算力消耗。这虽然不是 ParVL 调度的核心，但在实际系统中能显著降低计算负载。
8.5 关注显存分配策略
可扩展计算分配不仅涉及 GPU 数量和并行度，还要关注显存分配策略。建议：
- 使用显存池，避免频繁
cudaMalloc； - 对 KV Cache 做分页管理，减少碎片；
- 在扩缩容时尽量复用同一个显存块，降低迁移成本。
如果框架支持 PagedAttention 类似机制，优先开启，它能有效缓解多模态长序列场景的显存碎片问题。
8.6 安全与权限边界
在实际生产环境使用资源池和调度器时，要遵循最小权限原则：
- 调度器只能操作计算资源，不应具备修改模型权重或业务数据的权限；
- 资源池接口需要鉴权，避免内部接口被未授权调用；
- 扩容、缩容、重启等操作应记录审计日志；
- 对生产集群做变更前，先在测试环境验证调度策略。
请务必注意，任何涉及生产环境的资源调整都应经过充分测试，具备回滚方案。
9. 总结
ParVL 所代表的并行扩展与可扩展计算分配，核心价值在于让多模态大模型推理不再被“固定并行度”和“静态显存分配”束缚。通过感知请求的模态组成，动态决定计算单元数量，能够有效提升 GPU 利用率，降低轻量请求的排队延迟，同时为高分辨率图片、长视频等重型请求提供足够的算力保障。
这篇文章重点介绍了 ParVL 的设计思路、资源池调度架构、核心调度流程和工程实现示例。文中给出的 Python 代码是简化概念原型，真实落地时还需要结合具体框架、集群拓扑和显存管理策略做大量适配。建议读者从小规模集群开始，先建立请求级监控，再逐步引入动态并行度和可扩展计算分配机制。
如果大家在自己的多模态推理服务中尝试了类似方案，遇到调度、显存或吞吐方面的问题，欢迎在评论区交流，一起完善这套工程方法论。收藏本文可以随时翻查调度流程和排错建议。
