多模态大模型在图文理解、视频问答、语音交互等场景中的落地速度非常快但算力调度的问题也随之变得突出不同模态的输入长度差异极大图片一次能产生上千个视觉 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 什么是 ParVLParVL 可以理解为一套面向多模态 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_idgpu-0, total_memory_mb32768, free_memory_mb30000, load0.3), GpuInfo(gpu_idgpu-1, total_memory_mb32768, free_memory_mb30000, load0.3), GpuInfo(gpu_idgpu-2, total_memory_mb32768, free_memory_mb30000, load0.3), GpuInfo(gpu_idgpu-3, total_memory_mb32768, free_memory_mb30000, load0.3), ] ) task MultimodalTask( request_idreq-001, text_tokens64, image_tokens4096, ) 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 代码是简化概念原型真实落地时还需要结合具体框架、集群拓扑和显存管理策略做大量适配。建议读者从小规模集群开始先建立请求级监控再逐步引入动态并行度和可扩展计算分配机制。如果大家在自己的多模态推理服务中尝试了类似方案遇到调度、显存或吞吐方面的问题欢迎在评论区交流一起完善这套工程方法论。收藏本文可以随时翻查调度流程和排错建议。