LongVILA

1.提出问题？

LongVA 等前期工作证明 "扩 LLM 上下文就能看长视频"，但 LongVILA 作者指出那是简化做法：视觉对齐只用短图文数据、模型从没在长视频上 SFT 过，只是靠长文本语感硬猜；社区又缺长视频指令数据；更根本的是系统扛不住 —— 一条 1400 帧样本就 27 万 token，单卡直接 OOM，而现有 text-only 序列并行要么像 Ring SP 一样不分节点内外带宽差异瞎走 P2P，要么像 Ulysses 一样按 attention head 切、被 8B 模型只有 8 个 KV head 卡死，都没为 "图像 token 和文本 token 混排" 的多模态负载设计过。

2.解决问题？

算法上扩展为五阶段流水线：阶段 1-3 沿用 VILA 标准做法；阶段 4 在 LLM 上做纯文本长上下文续训，用 SlimPajama 17B token、渐进式从 8K 拉到 262K、RoPE base 调大、LoRA 微调；阶段 5 专门做长视频 SFT。长视频 SFT 数据来自 Shot2Story 的 15292 个长视频，造数据流程是把长视频切成 10 秒一段、每段用 VILA-1.5 自动写 caption、再把所有 clip 的 caption 拼起来喂 LLM 跨段生成需要看完整片才能答的 QA。系统上设计 MM-SP：视觉编码器阶段按帧数切分以平衡视觉塔负载，视觉 token 算完后再按 token 数重切进 LLM；通信上节点内走 All-to-All 吃满 NVLink 900 GB/s、节点间走 P2P 走 InfiniBand 50 GB/s，用 2D-Attention 同时拿到 Ulysses 的节点内带宽和 Ring SP 的节点间可扩展性，不再受 attention head 数限制。

3.成果

大海捞针实验里，32 帧 baseline 超过 32 帧就崩，LongVA 在 3000 帧时 87.6%，LongVILA 在 6000 帧（超 100 万 token）做到 99.8%。Video-MME 上 LongVILA-7B 用 256 帧拿到 w/o 字幕 60.1、w/ 字幕 65.1，Long 子集 53.0，显著超过 LongVA（128 帧 52.6）和 VideoLLaMA2.1；帧数加密时 Long 子集分数持续上升。9 个视频基准（ActNet-QA 59.5、EgoSchema 67.7、EventBench 58.0、LongVideoBench 57.1、MVBench 67.1、NExT-QA 80.7、VNBench 63.0）全面拿到 7B 开源 SOTA。系统侧 32 张 H100 上 MM-SP 达到 ZigZag-RingAttn 的可扩展性和 Ulysses 的吞吐，8 张 H100 上 256K token 推理首 token 从 26 秒压到 1.8 秒，代码原生兼容 HuggingFace Transformers。

4.启发

LongVILA 补完了 LongVA 的两个短板：光扩 LLM 上下文不够，视觉端必须在长视频上专门 SFT，大海捞针才能从 87.6% 拉到 99.8%；同时它证明系统不是配菜，视觉编码器阶段和 LLM 阶段负载异构，sharding 策略必须分开设计 —— 这套 "先按帧切视觉塔、再按 token 切 LLM" 的思路对单卡 L20 复现长视频模型时很有参考价值。放在你读的这条线里，MA-LMM 是隐式记忆、LongVA 是不压缩硬塞、LongVILA 是不压缩硬塞 + 长视频 SFT + 系统满配、MemDreamer 是离线建图加 agent 查、ReTaKe 是在长上下文基础上压 KV Cache 省推理成本。LongVILA 这种满配路线推理时仍要吃几十万 token 的 KV Cache，成本极高，这恰好反证你做 token 压缩 / KV Cache 压缩方向的必要性 —— 大家都能看长视频了，但没人看得起。做 baseline 对比时 LongVA 和 LongVILA 这组 "不压缩" 工作必须放进来，否则审稿人会问为什么不直接上长上下文。