随着多模态 AI 模型的快速发展，vLLM-Omni 作为 vLLM 的扩展框架，支持文本、图像、视频、音频等全模态模型的推理服务。然而，多模态请求的异构性给批处理调度带来了前所未有的挑战：不同模态的计算特性、内存需求、延迟要求差异显著，传统的批处理策略难以直接应用。本文深入探讨 vLLM-Omni 多模态批处理调度器的设计思路，提出动态批大小调整、异构请求优先级调度和资源感知的批组合策略。
多模态批处理调度的核心挑战
多模态批处理调度面临三大核心挑战：
-
请求异构性：文本生成、图像生成、视频生成等不同模态请求的计算模式、内存占用、处理时长差异巨大。例如，文本生成通常采用自回归（AR）方式逐 token 生成，而图像生成采用扩散变换器（DiT）并行生成整个图像。
-
资源约束复杂性：GPU 内存、计算单元、显存带宽等资源约束在多模态场景下更加复杂。不同模态对各类资源的敏感度不同，需要精细化的资源感知调度。
-
服务质量（QoS）多样性：实时对话、批量图像生成、视频渲染等不同应用场景对延迟、吞吐量的要求各不相同，需要灵活的优先级调度机制。
vLLM-Omni 现有调度架构分析
根据 vLLM-Omni 的官方文档，当前系统采用阶段化架构，不同阶段使用不同的调度器：
- AR 阶段：使用原始 vLLM 调度器，支持高效的 KV 缓存管理和自回归生成
- DiT 阶段：使用新的
DiffusionScheduler，目前采用简单的 FIFO（先进先出）策略 - OmniGenerationScheduler：实现了 "Diffusion fast path"，尝试一次性分配所有输入 token 的 KV 缓存，当内存不足时回退到标准调度
这种架构虽然为多模态推理提供了基础支持，但在批处理调度方面仍存在明显不足：
- 缺乏动态批大小调整：当前调度器主要关注单个请求的处理，缺乏根据系统负载和资源状况动态调整批大小的能力
- 优先级调度缺失：FIFO 策略无法满足不同 QoS 要求的请求调度需求
- 资源感知不足：调度决策未充分考虑 GPU 内存、计算单元等资源的实时状态
动态批大小调整策略
动态批大小调整是多模态批处理调度的核心能力。我们提出基于内存和计算资源的自适应算法：
内存感知的批大小调整
class MemoryAwareBatchScheduler:
def __init__(self, total_vram_gb, safety_margin=0.2):
self.total_vram = total_vram_gb * 1024**3 # 转换为字节
self.safety_margin = safety_margin
self.available_vram = self.total_vram * (1 - safety_margin)
def calculate_max_batch_size(self, request_type, model_config):
"""根据请求类型和模型配置计算最大批大小"""
# 不同模态的内存需求估算
memory_per_request = self._estimate_memory_usage(request_type, model_config)
# 考虑KV缓存、中间激活值等额外开销
overhead_factor = self._get_overhead_factor(request_type)
# 计算最大批大小
max_batch = int(self.available_vram / (memory_per_request * overhead_factor))
# 应用启发式限制
return min(max_batch, self._get_heuristic_limit(request_type))
def _estimate_memory_usage(self, request_type, model_config):
"""估算单请求内存使用"""
if request_type == "text":
# 文本生成：模型权重 + KV缓存
return model_config.param_size + model_config.kv_cache_per_token * model_config.max_tokens
elif request_type == "image":
# 图像生成：模型权重 + 特征图
return model_config.param_size + model_config.feature_map_size
elif request_type == "video":
# 视频生成：模型权重 + 时序特征
return model_config.param_size + model_config.temporal_features_size
计算资源感知的批大小调整
除了内存约束，还需要考虑计算资源的限制：
- SM 利用率监控：实时监控 GPU 流多处理器（SM）的利用率，避免计算瓶颈
- 内存带宽评估：不同模态对内存带宽的需求不同，需要动态调整
- 流水线阶段重叠：利用 vLLM-Omni 的阶段化架构，实现计算和内存传输的重叠
异构请求优先级调度
多模态服务需要支持不同 QoS 要求的请求。我们设计基于权重的优先级调度算法：
优先级分类
- 实时优先级：对话、实时图像编辑等低延迟需求
- 批量优先级：批量图像生成、视频渲染等高吞吐量需求
- 后台优先级：模型训练、数据预处理等后台任务
调度算法实现
class PriorityScheduler:
def __init__(self):
self.priority_queues = {
"realtime": deque(),
"batch": deque(),
"background": deque()
}
self.priority_weights = {
"realtime": 0.6,
"batch": 0.3,
"background": 0.1
}
def schedule_next_batch(self, available_resources):
"""基于优先级和资源约束调度下一批请求"""
scheduled_requests = []
remaining_resources = available_resources.copy()
# 按优先级顺序调度
for priority in ["realtime", "batch", "background"]:
if not self.priority_queues[priority]:
continue
# 计算该优先级可分配的资源比例
allocatable_resources = self._calculate_allocatable(
remaining_resources, self.priority_weights[priority]
)
# 从队列中选择请求
selected = self._select_requests(
self.priority_queues[priority], allocatable_resources
)
scheduled_requests.extend(selected)
remaining_resources = self._update_resources(
remaining_resources, selected
)
return scheduled_requests
公平性保障机制
为了避免低优先级请求饿死，需要实现公平性保障：
- 优先级提升：长时间等待的低优先级请求自动提升优先级
- 资源预留：为每个优先级类别预留最小资源配额
- 动态权重调整：根据系统负载动态调整优先级权重
资源感知的批组合策略
批组合策略的目标是在满足资源约束的前提下最大化吞吐量。我们提出多维资源感知的批组合算法：
资源维度建模
- GPU 内存维度：模型权重、KV 缓存、中间激活值
- 计算维度：FLOPs 需求、SM 利用率
- 带宽维度：内存带宽、PCIe 带宽
- 存储维度：模型加载时间、缓存命中率
批组合算法
class ResourceAwareBatchComposer:
def __init__(self, resource_constraints):
self.constraints = resource_constraints
self.request_profiles = {} # 请求资源画像缓存
def compose_batch(self, candidate_requests):
"""基于多维资源约束组合最优批次"""
# 构建资源需求矩阵
resource_matrix = self._build_resource_matrix(candidate_requests)
# 多维背包问题求解
selected_indices = self._solve_multi_dimension_knapsack(
resource_matrix, self.constraints
)
# 考虑请求亲和性（相同模态、相似参数）
optimized_indices = self._optimize_for_affinity(selected_indices, candidate_requests)
return [candidate_requests[i] for i in optimized_indices]
def _build_resource_matrix(self, requests):
"""构建请求资源需求矩阵"""
matrix = []
for req in requests:
profile = self._get_request_profile(req)
matrix.append([
profile.memory_usage,
profile.compute_flops,
profile.memory_bandwidth,
profile.storage_access
])
return matrix
缓存感知的批组合
利用 vLLM-Omni 的缓存机制优化批组合：
- KV 缓存重用：将使用相同 prompt 前缀的请求组合在一起
- 特征图共享：图像生成请求共享中间特征图
- 模型参数缓存：频繁使用的模型参数保持在 GPU 内存中
实现参数与监控指标
关键配置参数
-
动态批调整参数：
max_batch_size_per_modality: 各模态最大批大小memory_safety_margin: 内存安全边界（默认 0.2）batch_timeout_ms: 批组合超时时间（默认 50ms）
-
优先级调度参数：
priority_weights: 各优先级权重配置starvation_threshold_s: 饿死检测阈值（默认 30s）min_resource_quota: 最小资源配额
-
资源监控参数：
gpu_utilization_threshold: GPU 利用率阈值（默认 0.8）memory_bandwidth_threshold: 内存带宽阈值（默认 0.9）cache_hit_rate_target: 缓存命中率目标（默认 0.7）
监控指标体系
-
吞吐量指标：
- 请求处理速率（RPS）
- 令牌生成速率（TPS）
- 图像生成速率（IPS）
-
延迟指标：
- 端到端延迟分布
- 排队延迟
- 处理延迟
-
资源利用率指标：
- GPU 内存使用率
- SM 利用率
- 内存带宽使用率
-
服务质量指标：
- 各优先级请求的 SLA 达成率
- 请求成功率
- 错误率分布
性能优化建议
基于上述设计，我们提出以下性能优化建议：
- 渐进式部署：首先在 DiT 调度器中实现动态批调整，逐步扩展到全系统
- A/B 测试：对比新旧调度策略的性能差异，验证优化效果
- 参数调优：根据实际负载模式调整调度参数，实现最佳性能
- 监控告警：建立完善的监控告警体系，及时发现调度问题
总结
vLLM-Omni 多模态批处理调度器的设计需要综合考虑请求异构性、资源约束和服务质量要求。通过动态批大小调整、异构请求优先级调度和资源感知的批组合策略，可以显著提升多模态推理的吞吐量和资源利用率。未来，随着多模态 AI 应用的普及，智能调度将成为提升推理服务效率的关键技术。
本文提出的设计方案为 vLLM-Omni 的调度器优化提供了具体的技术路径和实现参数，相关思路也可应用于其他多模态推理框架的调度器设计。
资料来源
- vLLM-Omni 官方文档：https://docs.vllm.ai/projects/vllm-omni
- vLLM-Omni GitHub 仓库：https://github.com/vllm-project/vllm-omni
- RLTune: Hybrid Learning and Optimization-Based Dynamic Scheduling for DL Workloads on Heterogeneous GPU Clusters