多模态推理服务为什么一接视频流就开始掉帧：从 Frame Budget 到跨模态 Batch 调度的工程实战

很多团队把多模态模型从图片问答扩到视频理解后接口明明还能返回用户却开始反馈“画面一卡一卡首帧等太久”。⚠️ 先失控的往往不是模型精度而是视频请求把视觉预填充、文本解码和批处理节奏同时拉长。更隐蔽的问题是监控面板常常会给出错误安全感。GPU util看起来不低业务侧却同时出现首帧等待、字幕滞后和批次抖动。视频流不是“多几张图”它会把视觉token预算、缓存占用和排队行为一起放大。图 1视频推理最难处理的不是单次算力峰值而是连续帧把排队节奏整体拖长视频流接入后为什么更容易把首帧拖成尾帧图片问答通常只做一次视觉编码视频流却会在一个请求里塞进多帧采样、时间位置编码和更长的跨模态对齐。 如果调度器仍按图片请求的思路拼批视频请求就会先在prefill阶段吃掉大块预算后面的文本decode只能排队等空槽。第二层问题出在帧数和分辨率被业务同时拉高。 很多团队为了“看得更全”默认把fps、窗口长度和清晰度都往上调结果视觉token暴涨KV cache更快堆满。等到生成线程回写字幕或摘要时短请求已经被长视频批次压成尾延迟。[外链图片转存中…(img-hTGuykeT-1777698899325)]图 2问题根因通常不是“模型太慢”而是视频请求的视觉预算没有被提前约束一组把 Frame Budget 拉平的压测结果这次回放了30分钟会议视频和10分钟安防视频两类流量环境是4 x H20比较三种策略直接沿用图片批处理、只限制帧数、限制Frame Budget再拆分视频专用批次。 团队重点看首帧P95、稳态token/s、掉帧率和GPU利用率。方案首帧 P95稳态 token/s掉帧率GPU util图片批处理直接复用2380 ms7811.2%86%只限制帧数1710 ms826.4%81%Frame Budget 视频专用批次920 ms952.1%79%最明显的变化不是显卡更忙而是等待时间被切短了。✅ 当系统先按视觉token预算筛帧再把视频请求放进独立批次首帧P95几乎减半掉帧率也从两位数压到了2%左右。defschedule_video(req):framessample_frames(req,stride4,max_frames24)visual_budgetestimate_visual_tokens(frames,req.resolution)ifvisual_budget8192:framesfallback_keyframes(frames,limit16)returnvideo_pool.enqueue(req,framesframes,prefill_budgetvisual_budget,decode_reserved_slots4,)[外链图片转存中…(img-Ob6ACas6-1777698899325)]图 3先控视觉预算再做批处理收益往往比盲目堆更大模型更直接真正要隔离的是视觉预填充和文本解码很多团队一看到抖动就把视频流量和图片流量彻底拆成两套服务。 这能止血但成本通常也会一起上去。更稳的做法是把视频请求的视觉prefill和文本decode分开记账前者受Frame Budget约束后者保留最小解码槽位避免一段长视频把整台卡的生成出口堵住。同样值得补的是围绕batch_age、visual_tokens_per_req和decode_slot_occupancy的监控。⏱️ 如果团队只盯GPU util就会误以为问题出在模型太大更常见的真因是视频请求在入队前根本没有预算闸门。图 4视频推理治理的核心不是完全隔离而是先定义视觉预算和解码出口未来 3 到 6 个月的判断笔者认为视频多模态推理接下来不会只比模型参数量而会更重视“单位时延内能处理多少视觉信息”。 先做预算、再做跨模态调度会比一味追求更长上下文更有工程价值。一句话总结视频流一接入就掉帧根因通常不在模型看不懂而在系统没有先管住视觉token和批处理节奏。⭐ 如果团队最近正被首帧等待和输出抖动困住优先检查的应是Frame Budget与视频专用批次而不是先把所有问题都归咎于算力不足。你们现在的视频推理链路是否已经给视觉预填充单独设过预算闸门了