PyTorch надоел? Пора писать свой инференс-движок
Вы когда-нибудь запускали MoE-модель и думали: "Боже, сколько же лишнего кода здесь работает?" PyTorch, Transformers, Hugging Face — целый зоопарк зависимостей, который съедает половину VRAM еще до загрузки весов. А если нужна максимальная производительность? Жди месяц, пока оптимизации дойдут до основного репозитория.
cuda-nn — это ответ на вопрос "А что если отказаться от всего этого?" Движок написан с нуля на Rust, Go и нативных CUDA ядрах. Никакого PyTorch. Никакого Python. Только металл и математика.
Не ищите здесь удобства. cuda-nn — инструмент для тех, кто готов пожертвовать комфортом ради каждого дополнительного токена в секунду. Если вы привыкли к одной команде pip install, вам здесь будет больно.
Что умеет эта штука?
На бумаге — все то же самое, что и обычные фреймворки. На практике — совершенно другой уровень контроля.
- Поддержка MoE архитектур — настоящих, а не эмуляции через PyTorch. Эксперты загружаются только когда нужны
- MQA (Multi-Query Attention) — оптимизированные ядра для современных архитектур
- Смешанная точность — FP16, BF16, даже экспериментальный MXFP4 (если вы прочитали нашу статью про MoE на RTX 4090, то знаете, о чем речь)
- Потоковая обработка — генерация без остановок, пока хватает памяти
- Мультиязычность API — Rust для ядра, Go для сервера, C-совместимый интерфейс для всего остального
Сравнение: что вы теряете и что получаете
Давайте честно — зачем отказываться от проверенных инструментов?
| Критерий | PyTorch + Transformers | cuda-nn |
|---|---|---|
| VRAM на 6.9B MoE | ~14 ГБ (с оптимизациями) | ~11 ГБ |
| Токенов/сек (RTX 4090) | 45-60 | 70-85 |
| Время до первого токена | 2-3 секунды | ~0.8 секунды |
| Поддержка моделей | Почти все | Только совместимые архитектуры |
| Порог вхождения | Низкий | Высокий (нужно знать CUDA) |
Разница в 20-30 токенов в секунду — это не "немного лучше". Это разница между "можно пользоваться" и "приятно пользоваться". Особенно если вы запускаете модели на слабом железе, как в нашем гайде по Granite 4 Small.
Как это работает изнутри
Архитектура похожа на слоеный пирог, где каждый слой написан на подходящем языке.
1 Ядро на Rust
Rust отвечает за управление памятью и оркестрацию вычислений. Все веса модели живут здесь. Rust выбрали не для моды — его система владения гарантирует отсутствие гонок данных при асинхронной загрузке экспертов MoE.
2 CUDA ядра
Кастомные, ручной оптимизации. Особенно интересно реализовано MQA — вместо стандартного подхода с тремя матрицами Q, K, V используется одна общая для ключей и значений. Это экономит не только память, но и время на синхронизацию.
Если вы думаете о написании своих CUDA ядер, посмотрите нашу статью "Кастомные CUDA ядра для обучения LLM". Там есть важные предостережения.
3 HTTP-сервер на Go
Легковесный, с минимальной задержкой. Go выбрали за его goroutines — идеально подходят для обработки множества одновременных запросов к модели. Сервер общается с Rust-ядром через C FFI.
Сценарии использования: кому это нужно?
cuda-nn не для всех. Это специализированный инструмент.
- Встраивание в production-системы — когда нужен максимальный контроль над ресурсами
- Исследовательские проекты — где нужно тестировать новые архитектуры без оглядки на совместимость
- Облачные провайдеры — которые хотят обслуживать больше пользователей на одном GPU (помните наш GPU Rental Price Tracker? Вот для таких случаев)
- Владельцы нестандартного железа — например, тех, кто собирает фермы из трех GTX 1070
Подводные камни, о которых молчат
Все звучит прекрасно, пока не попробуешь сам.
Конвертация моделей — отдельный ад. Форматы весов, которые прекрасно работают в PyTorch, нужно перепаковывать в бинарный формат cuda-nn. Инструменты для этого есть, но они сырые.
Отладка CUDA ядер — это отдельная история. Когда ваша модель внезапно начинает генерировать абракадабру, причину искать придется долго. Никаких удобных отладчиков PyTorch, только printf и надежда.
И самое главное — сообщество. Вернее, его почти полное отсутствие. Если у вас проблема с Transformers, за час найдете ответ. С cuda-nn — готовьтесь разбираться в исходниках сами.
Альтернативы: что делать, если cuda-nn слишком сложно
Не готовы к такому уровню погружения? Есть варианты попроще.
- llama.cpp — золотой стандарт для запуска на CPU/GPU, но с MoE пока проблемы
- vLLM — отличная производительность, но требует Python окружения
- TGI (Text Generation Inference) — решение от Hugging Face, баланс между удобством и скоростью
- ExLlamaV2 — если нужна максимальная скорость на конкретных архитектурах
Каждый из этих инструментов решает свою задачу. cuda-nn — для тех, кому не подходит ни один из готовых вариантов.
Будущее: куда движется проект
Сейчас cuda-nn — инструмент для энтузиастов. Но тренд очевиден: все больше проектов уходят от монолитных фреймворков к специализированным движкам.
Что будет дальше? Вероятно, появление более удобных инструментов конвертации. Возможно — поддержка большего количества архитектур. Но главное — оптимизации под конкретное железо. Не просто "работает на CUDA", а "работает максимально быстро на Ada Lovelace" или "оптимизировано под H100".
Пока же cuda-nn остается доказательством концепции: можно обойтись без гигабайтового стека зависимостей. Можно писать инференс-движки с нуля. И можно получать производительность, которая заставляет задуматься: "А не слишком ли мы привыкли к удобству?"
Попробуйте, если не боитесь. Или просто следите за проектом — он показывает, куда движется вся индустрия inference. В сторону минимализма, контроля и скорости. Даже если сегодня это выглядит как решение для сумасшедших.
