Глава 15. Компромиссы

Глава 15. Проектирование компромиссов

FLOPs, latency и accuracy — это не три метрики.
Это три языка, на которых железо, продукт и статья спорят между собой.

К этой главе у вас уже достаточно кирпичей, чтобы не спрашивать «какая архитектура лучшая?».
Правильный вопрос звучит иначе:

Лучшая для какого бюджета, какого хвоста ошибок и какого железа?

15.1. Три шкалы, которые путают даже опытных

Accuracy / mAP / FID / perplexity — язык качества на бенчмарке.
FLOPs / params — язык абстрактной сложности.
Latency / Joules / VRAM — язык реальности.

Они коррелируют плохо ровно тогда, когда вам больше всего нужна интуиция.

Модель A: меньше FLOPs, больше latency  (неудачная карта на память / низкая утилизация)
Модель B: больше params, быстрее на GPU (тензорные ядра, fused kernels)
Модель C: лучше mAP, неприемлема на camera pipeline

Поэтому «взяли модель из paperswithcode» без профиля на вашем батче/разрешении — не инженерия, а лотерея.

15.2. Карта обменов, которые мы уже видели

Решение Отдали Получили
Convolution Универсальность Локальность, масштаб
Residual Простоту графа Глубину
BatchNorm Независимость от соседей по батчу Стабильность train
YOLO one-stage Часть точности FPS
FPN / PAN Простоту / latency Многомасштабность
CSP / C2f Симметрию каналов Дешёвую глубину
Attention O(N) наивность Параллелизм, гибкость
ViT Сильный prior Потолок на big data
GAN Стабильность Острый критерий
Diffusion Быстрый инференс Стабильный train / quality

Если умеете заполнять такую таблицу для нового блока из статьи — вы читаете статью как архитектор, а не как коллекционер названий.

15.3. Практический алгоритм выбора

Не ритуал ради ритуала — чеклист, который спасает недели:

  1. Зафиксируйте неснижаемый бюджет: ms на кадр, MB на устройство, максимальное разрешение, batch.
  2. Зафиксируйте неснижаемый хвост качества: что нельзя провалить (мелкие объекты? ложные тревоги? токсичные генерации?).
  3. Выберите prior: данных мало → сильнее индуктивные смещения; данных море → можно ослаблять prior.
  4. Профилируйте на целевом рантайме, не на FLOPs-калькуляторе.
  5. Абляции по одному рычагу: шея, голова, input size, precision (FP16/INT8), число шагов диффузии.
  6. Смотрите на failure cases, не только на среднее.
flowchart TD
    A[Бюджет железа] --> C[Кандидаты архитектур]
    B[Хвост ошибок продукта] --> C
    C --> D[Профиль latency/памяти]
    C --> E[Метрики + разбор ошибок]
    D --> F[Выбор / новый обмен]
    E --> F

15.4. Когда «лучшая статья» — неправильный ответ

Иногда выигрывает скучное:

  • тот же YOLO, но лучше данные и лейблы;
  • тот же backbone, но letterbox/разрешение под камеру;
  • та же диффузия, но fewer steps + distillation;
  • INT8 с калибровкой вместо новой архитектуры.

Архитектура — мощный рычаг.
Не единственный. Книга про архитектуры не должна врать, что мир крутится только вокруг них.

Если бы вы были автором статьи…

  1. Придумайте отчёт, где модель с худшим mAP побеждает в продукте. Какие колонки обязательны?

  2. Переведите требование «30 FPS на Jetson» в ограничения на input size, шею и postprocess (NMS и т.п.).

  3. Найдите блок в вашей текущей модели, который ест 20%+ времени и даёт <1% качества. Какой обмен вы предложите?

Последняя глава — куда смотрит поиск после доминирования трансформеров и почему логика книги переживает любые аббревиатуры.