Генерация 5-секундного видео в разрешении 720p на модели Wan2.2-14B занимает два часа на одном NVIDIA H20. При этом 74.1% времени уходит на вычисление внимания — операции, квадратично растущей с увеличением длины последовательности. Шаг за шагом, кадр за кадром, диффузионные трансформеры пересчитывают взаимодействие между тысячами токенов, даже когда большинство из них вносят минимальный вклад в результат. Исследователи из FVAttn предложили решение: адаптивное разреженное внимание с runtime-балансировкой нагрузки, которое ускоряет инференс в 2.5 раза без переобучения модели и с минимальной потерей качества. Это training-free оптимизация, которая работает с существующими видео-моделями прямо сейчас. ## Что такое разреженное внимание в видео-трансформерах Видео-диффузионные трансформеры (Video DiTs) обрабатывают длинные пространственно-временные последовательности. Для видео 720p с 81 кадрами это 3600 токенов на латентный кадр, умноженных на количество кадров. Полное внимание вычисляет взаимодействие каждого токена с каждым, что даёт квадратичный рост вычислений. Разреженное внимание эксплуатирует избыточность: для большинства query-токенов лишь небольшая подгруппа key-блоков вносит существенный вклад в выход. Training-free методы строят блочные маски во время инференса и пропускают низковажные взаимодействия. Это работает, но создаёт новую проблему — неравномерную загрузку GPU. ### Top-p vs Top-k: адаптивность против предсказуемости Два основных подхода к разреживанию: Top-k фиксирует количество сохраняемых блоков для каждого query-блока, Top-p адаптирует количество под распределение важности. Concentrated head (когда внимание сосредоточено в нескольких блоках) требует меньше вычислений, flat head (когда внимание распределено равномерно) — больше. Top-p улучшает fidelity маски: она сохраняет точность внимания при схожем среднем бюджете вычислений. Но эта адаптивность создаёт гетерогенность нагрузки. Разные attention heads сохраняют разное количество key-блоков, что при sequence parallelism превращается в ранговый дисбаланс. ## Проблема straggler в мульти-GPU инференсе Ulysses-style sequence parallelism распределяет attention heads по GPU rank'ам. Каждый rank получает полную последовательность для подмножества heads и вычисляет внимание независимо. При dense attention все heads имеют одинаковую вычислительную нагрузку — баланс идеален. Динамическое разреженное внимание ломает это свойство. Каждый head фактически вычисляет разное количество операций в зависимости от текущей sparse mask. Когда несколько high-density heads попадают на один rank, этот rank становится straggler — другие GPU ждут его завершения и простаивают. Максимальное изменение нагрузки между соседними шагами достигает 97% на уровне heads и 44% на уровне ranks в 4-шаговом distilled setting. Predictive pre-scheduling до sequence-to-head All-to-All опирается на устаревшие или приблизительные сигналы. Полная репартиция после маскирования требует дополнительной передачи данных и может стереть выигрыш от разреживания. ## Архитектура FVAttn: Two-Stage Runtime Scheduling FVAttn начинает работу после того, как текущая sparse mask уже материализована. Система выполняет двухэтапное планирование: Runtime Load Balancing (RLB) сокращает критический путь, Slack-Aware Sparse Augmentation (SASA) конвертирует остаточный slack не-критических ranks в дополнительные высокоценные блоки. ### Sparse-routing frontend FVAttn комбинирует Top-p routing с Top-k safety floor. Top-p обеспечивает адаптивный бюджет вычислений, Top-k поддерживает минимальный бюджет против ошибок маршрутизации или чрезмерного разреживания. Блоки переупорядочиваются по кривой Гильберта, чтобы пространственно близкие токены попадали в соседние блоки на разных масштабах. Один pass маршрутизации производит per-head density для RLB и порядок важности key-блоков для SASA. Дополнительные вычисления не требуются — Top-p адаптивность одновременно источник выигрыша в fidelity и источник гетерогенности, которую RLB должна обработать. ### Runtime Load Balancing (RLB) После материализации маски нагрузка каждого head L_h полностью наблюдаема. Нагрузка rank r равна L_r = Σ L_h для heads, назначенных на этот rank. Топ-p адаптивность создаёт вариацию L_h между heads, что усиливается в ранговый дисбаланс. FVAttn формулирует балансировку как явную оптимизацию выигрыша. Critical-path benefit K = c × (max L_r - max L_r_new), где c — unit compute time одного sparse block. Cost состоит из communication overhead P для перемещения head states и scheduling overhead C для планирования миграции. Net gain G = K - P - C. Ключевое наблюдение: нагрузка, создаваемая Top-p, сконцентрирована в небольшом количестве heads, а не равномерно распределена. Перемещение нескольких dense heads с перегруженных ranks на ranks с оставшейся ёмкостью убирает большинство straggler времени без коммуникационной стоимости глобального reshuffling. Миграция только 20% локальных heads (один head на rank в 8-GPU setting) снижает средний дисбаланс с 1.34 до 1.08. Дальнейшее увеличение бюджета миграции даёт значительно меньший выигрыш. FVAttn ограничивает пространство кандидатов от глобальной репартиции до lightweight P2P head migration — каждый rank мигрирует максимум один локальный head. ### Slack-Aware Sparse Augmentation (SASA) После балансировки не-критические ranks имеют остаточный slack — время, которое они ждут завершения критического пути. SASA конвертирует этот slack в дополнительные высокоценные блоки. Система добавляет маски预算 на ranks, которые не являются bottleneck, улучшая coverage sparse mask без удлинения критического пути. Piecewise thresholds k1=1.05 и k2=1.10 определяют режим: SASA alone включается при k1 ≤ ρ < k2, RLB+SASA при ρ ≥ k2. Augmentation coefficient n1=0.8 и trigger threshold n2=0.07 контролируют агрессивность добавления блоков. ## Экспериментальные результаты на 8×H20 FVAttn оценивался на трёх видео-диффузионных workload: Wan2.2 I2V 14B, Wan2.2 Animate 14B, Wan2.1 T2V 14B. Все используют LightX2V 4-step distilled LoRA configuration, генерируют 720p видео с 81 кадрами (21 latent frame, 3600 tokens per latent frame). Hardware: сервер с 8× NVIDIA H20 GPU, соединённых через NVLink, CUDA 13.1. Метрики: VBench для общего качества видео, PSNR/SSIM/LPIPS/CLIP-Sim для сравнения с FlashAttention output, DiT latency для эффективности. ### Image-to-Video (Wan2.2-14B I2V) FlashAttention dense baseline: VBench 88.7%, DiT latency 38.59s. FVAttn Top-p=0.95: VBench 88.8%, PSNR 23.801, SSIM 0.8092, LPIPS 0.1045, CLIP-Sim 0.9906, DiT latency 19.10s (2.02× speedup). FVAttn Top-p=0.90: VBench 88.8%, PSNR 23.473, DiT latency 18.30s (2.11× speedup). Для сравнения, SpargeAttention Top-p=0.95 даёт VBench 88.3%, PSNR 22.400, latency 19.92s (2.01× speedup). SpargeAttention Top-p=0.90: VBench 88.2%, PSNR 21.477, latency 19.23s (2.01× speedup). FVAttn при той же скорости показывает существенно лучшие метрики fidelity: PSNR +1.4 dB, SSIM +0.036, LPIPS -0.022. ### Animate (Wan2.2-14B) FlashAttention: latency 36.95s. FVAttn Top-p=0.95: PSNR 22.640, SSIM 0.8488, latency 15.21s (2.43× speedup). FVAttn Top-p=0.90: PSNR 21.512, latency 14.79s (2.50× speedup). Для сравнения, SageAttention dense: PSNR 22.259, latency 17.96s (2.06× speedup). FVAttn быстрее и сохраняет качество. Jenga Top-p=0.95: PSNR 21.534, latency 22.24s (1.66× speedup) — значительно медленнее. ### Text-to-Video (Wan2.1-14B T2V) FlashAttention: VBench 81.3%, latency 34.70s. FVAttn Top-p=0.90: VBench 81.6%, PSNR 19.585, latency 14.96s (2.32× speedup). SpargeAttention Top-p=0.90: VBench 80.9%, PSNR 17.161, latency 15.69s (2.21× speedup). FVAttn быстрее на 0.73s и показывает VBench +0.7%, PSNR +2.4 dB. ## Внимание: 4.41× ускорение over FlashAttention Среднее ускорение внимания (attention latency, включая mask routing, scheduling, sparse attention execution) составляет 4.41× над FlashAttention. Это превышает ускорение самих DiT инференса (2.02-2.50×), потому что attention — не единственная операция в трансформере, но доминирующая (74.1% времени). Ускорение DiT latency ниже, потому что включает другие компоненты: feed-forward networks, layer normalization, residual connections, All-to-All коммуникацию. Но поскольку attention — bottleneck, его ускорение непосредственно определяет общее ускорение. ## Ablation studies: вклад RLB и SASA Controlled experiments с SpargeAttention frontend (тот же Top-p sparse-routing) изолируют эффект runtime scheduling. Без load balancing: SpargeAttention Top-p=0.90 даёт 19.23s. С db-SP: 19.09s (2.02× speedup) — минимальный выигрыш. С RLB+SASA: 18.84s (2.05× speedup) — дополнительное ускорение. FVAttn-Base (адаптивный sparse-routing без RLB/SASA) на Animate: latency 16.40s (2.25×). FVAttn полный: 15.21s (2.43×). Разница 1.19s показывает вклад runtime scheduling поверх адаптивного маршрутизирования. FVAttn-Base + db-SP: 15.51s (2.38×) — db-SP даёт ограниченный выигрыш над no load balancing. FVAttn с RLB+SASA превосходит db-SP на 0.30s (2.43× vs 2.38×). ## Почему training-free подход важен FVAttn не требует переобучения модели, модификации весов, или доступа к training data. Это pure inference-time оптимизация, которая работает с существующими видео-диффузионными моделями. Для production-систем это означает: можно интегрировать в существующий pipeline без retraining cost. Step distillation (4-step LoRA) уменьшает количество denoising steps и даёт до 25× ускорение инференса. Но step distillation оставляет per-step sequence length и квадратичную стоимость внимания неизменными. Внимание остаётся bottleneck даже в few-step regime. FVAttn — комплементарная оптимизация: она работает внутри каждого denoising step и ускоряет самую дорогую операцию. ## Практические implications Для видео-продакшена: генерация 5-секундного 720p видео на 8×H20 сокращается с ~38 секунд DiT latency до ~15 секунд с FVAttn Top-p=0.90. Это 2.5× ускорение при сохранении качества (VBench 88.8% vs 88.7% baseline, PSNR 23.473 vs 22.400 для SpargeAttention). Для масштабирования: FVAttn работает с sequence parallelism, что критично для длинных видео. 3600 tokens per latent frame × 21 latent frames = 75,600 tokens — последовательность, требующая мульти-GPU распределения. Training-free sparse attention с load balancing делает инференс практичным без牺牲 качества. Для исследований: FVAttn показывает, что systems-level оптимизации (load balancing, P2P migration, slack utilization) могут давать больший выигрыш, чем algorithmic improvements (более сложные sparse patterns). Одна и та же sparse mask с runtime scheduling превосходит более сложные методы без scheduling. ## Часто задаваемые вопросы ### Требует ли FVAttn переобучения модели? Нет, FVAttn — training-free оптимизация. Она работает с существующими видео-диффузионными моделями без модификации весов или доступа к training data. Интеграция происходит на уровне inference pipeline. ### Насколько FVAttn быстрее FlashAttention? FVAttn даёт 4.41× ускорение attention latency и 2.02-2.50× ускорение DiT inference latency на 8×H20 GPU с NVLink. Ускорение DiT ниже, потому что attention — не единственная операция, но доминирующая (74.1% времени). ### Работает ли FVAttn с другими моделями, кроме Wan2.2? FVAttn оценивался на Wan2.2 I2V, Wan2.2 Animate, и Wan2.1 T2V. Архитектура применима к любым Video DiTs с Ulysses-style sequence parallelism и динамическим sparse attention. Требует адаптации thresholds для конкретных моделей. ### Что лучше: FVAttn или SageAttention? FVAttn и SageAttention решают разные задачи. SageAttention — dense quantized attention, ускоряет полное внимание через квантование. FVAttn — sparse attention с load balancing, пропускает низковажные взаимодействия. FVAttn показывает лучшее качество (PSNR 23.473 vs 22.259 для SageAttention на Animate) и большее ускорение (2.50× vs 2.06×). ## Итог FVAttn решает системную проблему мульти-GPU инференса видео-трансформеров: дисбаланс нагрузки, создаваемый адаптивным разреженным вниманием. Runtime Load Balancing через P2P head migration снижает imbalance factor с 1.34 до 1.08, Slack-Aware Sparse Augmentation конвертирует остаточный slack в дополнительные высокоценные блоки. Результат — 2.5× ускорение инференса с сохранением качества (VBench 88.8%, PSNR +1.4 dB над конкурентами). Если вы работаете с видео-генерацией на диффузионных трансформерах, FVAttn — training-free оптимизация, которую можно интегрировать без переобучения модели. Проверьте код на GitHub и попробуйте на своих workload.