Глава 217: Аппаратно-ориентированный поиск нейронных архитектур (Hardware-Aware NAS)

1. Введение

Поиск нейронных архитектур (NAS) трансформировал подход к проектированию моделей глубокого обучения, автоматизируя то, что раньше было кропотливым ручным процессом. Однако традиционный NAS оптимизирует только точность, создавая архитектуры, которые могут быть непрактичны для развёртывания на реальном оборудовании. В высокочастотной торговле (HFT) модель, достигающая рекордной точности предсказаний, но неспособная выполнить инференс за 10 микросекунд, бесполезна. В периферийных приложениях для розничной торговли модель, превышающая доступную память, столь же бесполезна.

Аппаратно-ориентированный NAS решает эту проблему путём совместной оптимизации точности и аппаратной эффективности. Вместо того чтобы искать наиболее производительную архитектуру и затем пытаться сжать её для целевого оборудования, аппаратно-ориентированный NAS включает аппаратные ограничения непосредственно в целевую функцию поиска. Результат — архитектура, которая рождается эффективной: она соответствует требованиям по задержке (SLA), помещается в бюджет памяти и максимизирует точность в рамках этих ограничений.

Для алгоритмической торговли этот подход является трансформационным. Различные торговые стратегии развёртываются на совершенно разном оборудовании: FPGA-системы для субмикросекундной HFT, GPU-кластеры для пакетной оптимизации портфелей и мобильные CPU для розничных торговых приложений. Каждая аппаратная платформа накладывает свои ограничения на архитектуру модели. Аппаратно-ориентированный NAS позволяет систематически находить оптимальную архитектуру для каждого сценария развёртывания.

В этой главе рассматриваются математические основы аппаратно-ориентированного NAS, исследуются аппаратно-специфичные аспекты для торговли, описываются реализации, адаптированные из MnasNet, EfficientNet и FBNet, а также приводится полная реализация на Rust с интеграцией рыночных данных Bybit.

2. Математические основы

2.1 Задержка как дифференцируемое ограничение

Ключевая инновация аппаратно-ориентированного NAS — включение аппаратных метрик непосредственно в целевую функцию оптимизации. Определим пространство поиска формально.

Для пространства поиска архитектур $\mathcal{A}$ традиционный NAS решает задачу:

$$a^* = \arg\max_{a \in \mathcal{A}} \text{ACC}(a)$$

где $\text{ACC}(a)$ — точность валидации архитектуры $a$. Аппаратно-ориентированный NAS преобразует это в задачу с ограничениями или многокритериальную задачу:

$$a^* = \arg\max_{a \in \mathcal{A}} \text{ACC}(a) \quad \text{при условии} \quad \text{LAT}(a) \leq T$$

где $\text{LAT}(a)$ — задержка архитектуры $a$ на целевом оборудовании, а $T$ — бюджет задержки.

2.2 Таблицы поиска задержек

Прямое измерение задержки во время поиска чрезмерно дорого. Вместо этого мы строим таблицы поиска задержек (LUT), которые сопоставляют каждую кандидатную операцию с её измеренной задержкой на целевом устройстве. Для нейронной сети из $L$ слоёв, каждый с операцией $o_i$ и входными размерностями $d_i$, общая задержка аппроксимируется как:

$$\text{LAT}(a) = \sum_{i=1}^{L} \text{LUT}(o_i, d_i)$$

Эта декомпозиция предполагает последовательное выполнение, что справедливо для большинства конвейеров инференса. Для архитектур с параллельными ветвями берётся максимум по параллельным путям:

$$\text{LAT}{\text{parallel}}(a) = \max{p \in \text{paths}} \sum_{i \in p} \text{LUT}(o_i, d_i)$$

Подход LUT делает задержку дифференцируемой относительно архитектурных выборов. Если мы параметризуем архитектуру с помощью непрерывной релаксации (как в DARTS), где $\alpha_{i,j}$ — вес операции $j$ в слое $i$, ожидаемая задержка становится:

$$\mathbb{E}[\text{LAT}(a)] = \sum_{i=1}^{L} \sum_{j=1}^{|\mathcal{O}|} \frac{\exp(\alpha_{i,j})}{\sum_k \exp(\alpha_{i,k})} \cdot \text{LUT}(o_j, d_i)$$

Это полностью дифференцируемо по $\alpha$, что позволяет использовать градиентную оптимизацию.

2.3 Подсчёт FLOPs

Операции с плавающей запятой (FLOPs) предоставляют аппаратно-независимую оценку вычислительной стоимости. Для распространённых операций:

• Свёртка: $\text{FLOPs} = 2 \times H_{out} \times W_{out} \times K^2 \times C_{in} \times C_{out}$
• Глубинная свёртка: $\text{FLOPs} = 2 \times H_{out} \times W_{out} \times K^2 \times C$
• Полносвязный слой: $\text{FLOPs} = 2 \times C_{in} \times C_{out}$
• Внимание (self-attention): $\text{FLOPs} = 4 \times n^2 \times d + 2 \times n \times d^2$

Для торговых моделей временных рядов длина последовательности $n$ особенно важна. Модели на основе внимания масштабируются квадратично по $n$, что делает их дорогими для длинных окон наблюдения.

2.4 Многокритериальная оптимизация

Вместо жёсткого ограничения можно искать весь фронт Парето точности и задержки с учётом памяти. Решение $a$ доминирует $a’$, если $a$ не хуже $a’$ по всем критериям и строго лучше хотя бы по одному.

Скаляризованная целевая функция объединяет несколько критериев с весами:

$$\mathcal{L}(a) = \text{ACC}(a) \times \left[\frac{\text{LAT}(a)}{T}\right]^{w_1} \times \left[\frac{\text{MEM}(a)}{M}\right]^{w_2}$$

где $T$ и $M$ — целевая задержка и память, а $w_1, w_2 < 0$ — штрафные веса. MnasNet использует $w_1 = -0.07$ как мягкий штраф, который деградирует плавно, а не навязывает жёсткую границу.

2.5 Оценка объёма памяти

Потребление памяти при инференсе имеет два компонента:

$$\text{MEM}(a) = \text{MEM}{\text{params}}(a) + \text{MEM}{\text{activations}}(a)$$

Память параметров вычисляется просто:

$$\text{MEM}{\text{params}} = \sum{i=1}^{L} |\theta_i| \times b$$

где $|\theta_i|$ — количество параметров в слое $i$, а $b$ — байт на параметр (4 для FP32, 2 для FP16, 1 для INT8).

Память активаций зависит от порядка выполнения:

$$\text{MEM}{\text{activations}} = \max{i} \left( \text{size}(x_i) + \text{size}(x_{i+1}) \right) \times b$$

Для торговых моделей, развёрнутых на устройствах с ограниченной памятью, этот анализ определяет, является ли архитектура реализуемой.

3. Аппаратные платформы

3.1 FPGA для высокочастотной торговли

FPGA являются золотым стандартом для HFT, обеспечивая субмикросекундную задержку инференса с детерминированным временем. Аппаратно-ориентированный NAS для FPGA должен учитывать:

• Арифметика с фиксированной точкой: Реализации на FPGA обычно используют INT8 или представления с фиксированной точкой. Пространство поиска должно включать операции с учётом квантования.
• Ограничения параллелизма: FPGA имеют ограниченное количество DSP-блоков и BRAM. Архитектура должна помещаться в эти ресурсные бюджеты.
• Глубина конвейера: Более глубокие конвейеры увеличивают пропускную способность, но и задержку. Для HFT мы оптимизируем задержку, а не пропускную способность.
• Поддержка операций: Не все операции эффективно реализуемы на FPGA. Следует избегать операций с динамическими формами или сложными нелинейностями.

Рекомендуемое пространство поиска для FPGA: малые свёртки (1x1, 3x3), глубинно-разделяемые свёртки, активации ReLU (не GELU и не Swish), и пропускные соединения с фиксированной топологией.

3.2 GPU для пакетного инференса

GPU-системы для торговли выполняют пакетный инференс для оптимизации портфелей, управления рисками и среднечастотных стратегий. Ключевые аспекты:

• Эффективность пакетов: Загрузка GPU значительно улучшается с увеличением размера пакета. Архитектура должна содержать хорошо параллелизуемые операции.
• Пропускная способность памяти: Производительность GPU часто ограничена памятью. Архитектуры должны максимизировать арифметическую интенсивность (FLOPs на переданный байт).
• Использование тензорных ядер: Современные GPU имеют специализированное оборудование для матричных умножений с определёнными размерностями (кратными 8 для FP16, 16 для INT8). Размерности архитектуры должны соответствовать этим требованиям.
• Накладные расходы на запуск ядер: Множество мелких операций создают накладные расходы на запуск ядер. Предпочтительны меньшее количество более крупных операций.

3.3 CPU/мобильные устройства для розничной торговли

Розничные торговые приложения работают на разнообразном оборудовании — от высокопроизводительных ноутбуков до бюджетных смартфонов. Ограничения включают:

• Однопоточная производительность: Многие мобильные устройства имеют ограниченную многопоточность. Архитектуры не должны предполагать высокий параллелизм.
• Иерархия кэша: Операции должны демонстрировать хорошую пространственную и временную локальность.
• Энергопотребление: Устройства с батарейным питанием требуют энергоэффективных архитектур.
• Размер модели: Ограничения магазинов приложений и время загрузки ограничивают общий размер модели, обычно до 10 МБ.

4. Торговые приложения

4.1 Соблюдение строгих SLA по задержке

В производственных торговых системах SLA по задержке не подлежат обсуждению. Модель, которая иногда превышает бюджет задержки, может вызвать пропущенные сделки, устаревшие сигналы или нарушение регуляторных требований. Аппаратно-ориентированный NAS предоставляет архитектуры с предсказуемой, ограниченной задержкой.

Например, система маркет-мейкинга с бюджетом решения 50 микросекунд может выделить 20 микросекунд на вычисление признаков, 20 микросекунд на инференс модели и 10 микросекунд на формирование ордера. Поиск NAS ограничивает задержку модели до 20 микросекунд на целевой FPGA.

4.2 Архитектуры для развёртывания на FPGA

Традиционный NAS может обнаружить архитектуру, использующую операции, невозможные или чрезвычайно дорогие на FPGA (например, большие матричные умножения, динамическую маршрутизацию, softmax по большим размерностям). Ограничивая пространство поиска FPGA-совместимыми операциями и используя FPGA-специфичные таблицы задержек, мы гарантируем, что обнаруженные архитектуры непосредственно синтезируемы.

Архитектурные паттерны, хорошо работающие на FPGA для торговли:

• Узкие, глубокие конвейеры с малыми свёртками
• Бинарные или тернарные сети весов для экстремальной пропускной способности
• Пропускные соединения с фиксированной топологией (без динамической маршрутизации)
• Функции активации на основе таблиц поиска

4.3 Модели с ограничением памяти для периферийной торговли

Периферийные торговые устройства (со-размещённые серверы, встроенные системы вблизи бирж) часто имеют строгие ограничения памяти. Модель, потребляющая 2 ГБ памяти, может быть непрактичной, когда устройство имеет всего 4 ГБ, разделённых с операционной системой, потоками данных и системой управления ордерами.

Аппаратно-ориентированный NAS с ограничениями памяти находит архитектуры, которые:

• Используют параметрически эффективные операции (глубинно-разделяемые свёртки, групповые свёртки)
• Минимизируют пиковую память активаций через топологию архитектуры
• Позволяют разделять веса между временными шагами
• Поддерживают агрессивное квантование без деградации точности

5. Адаптированные подходы для торговли

5.1 Подход MnasNet

MnasNet использует контроллер на основе обучения с подкреплением для сэмплирования архитектур, оценивает их на реальном оборудовании и оптимизирует скаляризованную целевую функцию точности и задержки. Для торговли мы адаптируем это следующим образом:

• Замена точности на ImageNet торгово-специфичными метриками (коэффициент Шарпа, точность прогноза P&L)
• Использование таблиц задержек торгового оборудования вместо измерений на мобильных телефонах
• Добавление памяти как дополнительного критерия
• Ограничение пространства поиска операциями, поддерживаемыми целевым торговым оборудованием

5.2 Составное масштабирование EfficientNet

Идея EfficientNet состоит в том, что ширина, глубина и разрешение должны масштабироваться совместно с использованием составного коэффициента. Для торговых моделей временных рядов мы адаптируем размерности масштабирования:

• Глубина: Количество слоёв временной обработки
• Ширина: Количество каналов (размерность признаков)
• Разрешение: Длина входной последовательности (окно наблюдения)

Правило составного масштабирования $d = \alpha^\phi$, $w = \beta^\phi$, $r = \gamma^\phi$ при условии $\alpha \cdot \beta^2 \cdot \gamma^2 \approx 2$ предоставляет принципиальный способ масштабирования моделей вверх или вниз для соответствия аппаратным бюджетам.

5.3 Дифференцируемый поиск FBNet

FBNet делает поиск полностью дифференцируемым с помощью трюка Gumbel-Softmax, позволяя градиентную оптимизацию архитектуры. Это значительно быстрее поиска на основе RL. Для торговых приложений:

• Дифференцируемая формулировка позволяет прямой поток градиентов от функции потерь задержки к параметрам архитектуры
• Поиск завершается за часы, а не за дни
• Отжиг температуры постепенно заостряет распределение архитектуры от мягкой смеси к жёсткому выбору

6. Описание реализации (Rust)

Наша реализация на Rust предоставляет полный фреймворк аппаратно-ориентированного NAS для торговых моделей. Ключевые компоненты:

6.1 Аппаратные профили

Мы определяем аппаратные профили, которые описывают характеристики задержки каждого целевого устройства. Каждый профиль содержит таблицу поиска, сопоставляющую кортежи (операция, размер_входа, размер_выхода) с измеренными значениями задержки.

pub struct HardwareProfile {
    pub name: String,
    pub device_type: DeviceType,
    pub latency_table: HashMap<OpSpec, f64>,
    pub memory_budget_bytes: u64,
    pub peak_flops: f64,
}

6.2 Представление архитектуры

Архитектуры представлены как последовательности спецификаций слоёв, каждая из которых определяет тип операции, входные/выходные размерности и дополнительные параметры:

pub struct Architecture {
    pub layers: Vec<LayerSpec>,
}

pub struct LayerSpec {
    pub op: OpType,
    pub in_channels: usize,
    pub out_channels: usize,
    pub kernel_size: usize,
    pub stride: usize,
    pub use_skip: bool,
}

6.3 Многокритериальный поиск

Процедура поиска оценивает кандидатные архитектуры по точности (оценённой через прокси-задачу), задержке (из таблиц поиска) и памяти (вычисленной аналитически). Она поддерживает фронт Парето недоминируемых решений:

pub fn search(
    search_space: &SearchSpace,
    hardware: &HardwareProfile,
    latency_budget: f64,
    num_iterations: usize,
) -> Vec<(Architecture, Metrics)> { ... }

6.4 Интеграция с Bybit

Мы получаем реальные рыночные данные через публичный API Bybit для использования в качестве обучающих данных при оценке кандидатных архитектур:

pub async fn fetch_bybit_klines(
    symbol: &str,
    interval: &str,
    limit: usize,
) -> Result<Vec<Candle>> { ... }

Полная реализация доступна в rust/src/lib.rs с торговым примером в rust/examples/trading_example.rs.

7. Интеграция данных Bybit

Реализация получает данные OHLCV через V5 API Bybit для использования при оценке архитектур. Конвейер данных:

1. Получение: Загрузка данных kline для BTCUSDT (или любого символа) через публичный REST API
2. Предобработка: Нормализация цен с использованием скользящих z-оценок, вычисление технических признаков (доходности, волатильность, моментум)
3. Оценка: Использование предобработанных данных в качестве входных данных для кандидатных архитектур для оценки прокси-точности
4. Ранжирование: Комбинирование оценки точности с метриками задержки и памяти для многокритериального ранжирования

Интеграция с Bybit позволяет оценивать архитектуры на реалистичных торговых данных, а не на синтетических бенчмарках, обеспечивая обобщаемость обнаруженных архитектур на реальные рыночные условия.

Данные из Bybit получаются через эндпоинт:

GET https://api.bybit.com/v5/market/kline?category=linear&symbol=BTCUSDT&interval=15&limit=200

Это предоставляет 200 свечей 15-минутных данных бессрочных фьючерсов BTCUSDT, достаточных для оценки качества архитектуры на прокси-задаче.

8. Ключевые выводы

1. Аппаратная осведомлённость необходима для производственных торговых моделей. Модель, неспособная соблюсти SLA по задержке, бесполезна независимо от точности. Аппаратно-ориентированный NAS встраивает эти ограничения в процесс поиска, а не рассматривает их как последующую задачу.

2. Таблицы поиска задержек делают аппаратные метрики дифференцируемыми. Предварительно измеряя задержки операций на целевом оборудовании, мы можем включить задержку в градиентную оптимизацию, значительно ускоряя поиск.

3. Различное оборудование требует различных архитектур. Оптимальная архитектура для FPGA-based HFT совершенно не похожа на оптимальную архитектуру для пакетного инференса на GPU. Аппаратно-ориентированный NAS систематически находит правильную архитектуру для каждой платформы.

4. Многокритериальная оптимизация выявляет границу точности и эффективности. Вместо единственной “лучшей” архитектуры мы обнаруживаем весь фронт Парето, позволяя практикам выбрать правильный компромисс для конкретных ограничений развёртывания.

5. FLOPs сами по себе недостаточны. FLOPs коррелируют с задержкой, но не определяют её. Паттерны доступа к памяти, параллелизм на уровне операций и аппаратно-специфичные оптимизации — всё это влияет на реальную производительность. Таблицы поиска учитывают эти эффекты.

6. Торгово-специфичные адаптации необходимы. Стандартные подходы NAS, разработанные для компьютерного зрения, должны быть адаптированы для торговых данных временных рядов: другие входные размерности, другие метрики точности (коэффициент Шарпа, точность прогноза), другие аппаратные платформы (FPGA, со-размещённые серверы).

7. Составное масштабирование обеспечивает принципиальный подбор размера модели. Составное масштабирование EfficientNet хорошо адаптируется к торговым моделям, предоставляя систематический способ обмена ёмкости модели на аппаратную эффективность по размерностям глубины, ширины и длины последовательности.

8. Rust обеспечивает необходимые характеристики производительности. Реализация на Rust гарантирует, что фреймворк NAS вносит минимальные накладные расходы, а обнаруженные архитектуры могут быть эффективно развёрнуты в торговых системах, чувствительных к задержке.

9. Валидация на реальных рыночных данных критически важна. Оценка архитектур на синтетических данных может привести к обнаружению архитектур, которые не работают на реальных рыночных данных. Интеграция с биржами, такими как Bybit, обеспечивает реалистичные условия оценки.

10. Область быстро развивается. Методы аппаратно-ориентированного NAS продолжают совершенствоваться с появлением новых подходов для универсальных сетей (once-for-all), прокси нулевой стоимости и аппаратно-ориентированного обучения. Отслеживание этих разработок необходимо для поддержания конкурентного преимущества в алгоритмической торговле.