多模态训练
目录
多模态训练挑战
多模态训练相比纯文本，系统优化上的新增挑战？
答：
| 挑战 | 说明 |
|---|---|
| Token 数量暴增 | 图像/视频编码后 Token 数量呈指数级增长（Sequence 过长） |
| 负载不均衡 | 视觉编码器（ViT）和语言模型（LLM）的参数分布和计算特征不同，难以平衡负载 |
| 跨模态同步 | Cross-Modal 对齐通常涉及复杂的 Contrastive Loss，增加跨卡全局特征同步开销 |
视频模型训练为什么资源压力更大？
答：
视频引入了时间维度（T×H×W），导致：
图像： 1 × H × W → 约 1024 Tokens
视频： T × H × W → 约 T × 1024 Tokens (T=30 时达 30K+ Tokens)
↓
Attention 计算量 O(N²) 爆炸！
KV Cache 显存爆炸！
- 3D Attention 序列长度呈指数级爆炸
- 极易达到 100K 级别
- 触发显存 OOM 和计算二次方复杂度墙
- 必须依赖 Context Parallel 等长序列并行技术
Omni 模型训练最难优化的点可能在哪里？
答：
异构负载不均衡（Straggler Effect）
数据样例 1: [音频 10s] [视频 5s] [文本 100 tokens]
数据样例 2: [音频 60s] [视频 60s] [文本 10 tokens]
数据样例 3: [纯文本 500 tokens]
GPU0 处理样例1: ████
GPU1 处理样例2: ████████████████████████████████████████████████████████
GPU2 处理样例3: █
↑ GPU0 和 GPU2 长时间等待 GPU1
一段数据的音频/视频/文本比例完全不同，导致不同 GPU 上计算时间差异极大。在 Pipeline 或 TP 同步时，算得快的卡被迫长时间等待算得慢的卡。
优化方向：
- 动态负载均衡：按模态比例分组
- Dynamic Padding/Packing：减少无效计算
- 快慢车道隔离：短审核请求走高优通道，长文件审核走离线大 Batch 通道
视频模型优化
视频理解模型为什么通常比图像理解模型更难做低延迟优化？
答：
贴合商业审核场景的回答：
1. Token 爆炸
图像可能只产生 1024 个 Token，但一段 30 秒的审核视频，即使按 1FPS 抽帧，也有 30 张图，瞬间产生数万个 Token。
这导致：
- Prefill 阶段的计算量（Attention 是 O(N²)）呈指数级爆炸
- KV Cache 占用呈指数级爆炸
2. 内存墙极高
庞大的 Vision Encoder（如 ViT）提取特征不仅慢，而且极其占用显存，导致留给 LLM 主干网络做 KV Cache 的空间被严重压缩。
3. 优化思路
针对视频审核，必须引入：
- Prefix Caching（前缀缓存）：如果视频包含重复的模板
- Token 压缩/池化：丢弃视频背景冗余 Token
- Ring-Attention 或 Context Parallel：解决单卡装不下超长视频 KV 的问题
Omni 模型训练难点
优化多模态大模型框架，优先优化的三个点？
答：
| 优先级 | 优化点 | 解决的问题 |
|---|---|---|
| 1 | 长序列并行（Context/Ring Attention） | 解决 OOM |
| 2 | 统一内存池与动态显存分配 | 解决异构模态频繁碎片化显存 |
| 3 | 动态负载均衡（Dynamic Padding/Packing） | 解决模态数据差异带来的空等 |
面试金句
"多模态训练最大的差异在于'序列长度爆炸'和'内存碎片化'。一段 1 分钟的视频抽帧后可能瞬间产生几万个 Vision Tokens，不仅 Attention 计算量呈二次方爆炸，更要命的是会撑爆显存的 KV Cache。"
"Omni 模型的最大难点是异构负载不均衡（Straggler Problem）。审核并发请求中，有的是纯短文本，有的是长视频，如果强行塞进同一个 Batch，纯文本请求会在几毫秒内算完，然后白白空转几十秒等待长视频算完。"