Eider: кастомный инференс-рантайм для DGX Spark с NVFP4 и свопинг-памятью для MoE

Что такое Eider и почему это важно для владельцев DGX Spark

Eider - это инференс-сервер, написанный с нуля на Rust и CUDA специально под архитектуру SM121 (GB10) в составе DGX Spark. Проект не использует llama.cpp или vLLM в качестве базы, а реализует собственный стек для достижения максимальной производительности на целевом железе NVIDIA.

Две инновации выделяют Eider на фоне аналогов: нативная поддержка формата NVFP4 и механизм экспертной свопинг-памяти для MoE-моделей. Связка этих технологий решает конкретную проблему - запуск больших моделей со смесью экспертов на устройстве с ограниченным объёмом памяти. Практический результат: Eider загружает Step 3.7 Flash целиком, выгружая неактивных экспертов на NVMe-диск, тогда как vLLM и llama.cpp требуют размещения всей модели в оперативной памяти и с этой задачей не справляются.

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

Ключевые возможности Eider: NVFP4 и экспертная свопинг-память

Два технических столпа Eider работают в тандеме: NVFP4 снижает потребление памяти на этапе хранения весов и KV-кеша, а свопинг-память динамически управляет экспертами MoE, подгружая только те, которые реально нужны для текущего токена.

NVFP4: ускорение инференса и сжатие KV-кеша

NVFP4 - 4-битный формат чисел с плавающей запятой, представленный NVIDIA в архитектуре Blackwell (SM121). В отличие от целочисленного INT4, NVFP4 сохраняет плавающую точку, что критически важно для сохранения качества при хранении весов и активаций. Eider использует NVFP4 для двух целей: квантизации весов модели и сжатия KV-кеша.

KV-кеш в NVFP4 даёт двойной выигрыш. Во-первых, размер кеша сокращается в 4 раза по сравнению с FP16 - это означает, что на том же объёме памяти DGX Spark можно обслуживать более длинные контексты. Во-вторых, ядра SM121 имеют аппаратную поддержку операций с NVFP4, что ускоряет вычисление внимания без необходимости декомпрессии в более высокую точность. На практике это транслируется в рост пропускной способности при конкурентных запросах и снижение задержки первого токена для длинных промптов.

Реализация в Eider выполнена через кастомные CUDA-ядра, заточенные под тензорные ядра пятого поколения в GB10. Это исключает оверхед, характерный для универсальных фреймворков, вынужденных поддерживать десятки архитектур GPU.

Экспертная свопинг-память: запуск гигантских MoE на ограниченном железе

Архитектура Mixture of Experts создаёт парадокс памяти: модель может содержать сотни экспертов общим объёмом в сотни гигабайт, но на каждом токене активны лишь 2-8 из них. Традиционные инференс-серверы загружают всех экспертов в память целиком - это требование vLLM и llama.cpp, которое делает невозможным запуск больших MoE на DGX Spark.

Eider реализует механизм отслеживания активности экспертов: при загрузке модели в память помещается только шард с роутером и эмбеддингами, а эксперты подгружаются с NVMe-диска по мере необходимости. Планировщик Eider анализирует выход роутера для каждого токена, определяет, какие эксперты потребуются, и инициирует асинхронную загрузку их весов. Неактивные эксперты выгружаются обратно на диск, освобождая память для следующего шага.

Результат этого подхода наглядно демонстрирует исследование предсказания загрузки экспертов MoE: при точности предсказания 78% можно скрыть латентность PCIe и достичь скорости генерации до 200 токенов/сек. Eider применяет сходную логику, но на уровне NVMe-подсистемы DGX Spark, где пропускная способность достигает 5-7 ГБ/с.

Step 3.7 Flash - эталонный пример. Эта модель насчитывает сотни экспертов, и её полный вес превышает доступную память DGX Spark. vLLM и llama.cpp пасуют: им требуется разместить модель в памяти целиком. Eider загружает Step 3.7 Flash и обслуживает запросы, удерживая в памяти лишь активное подмножество экспертов. Задержка, связанная с подгрузкой с диска, частично компенсируется тем, что загрузка следующего набора экспертов начинается до завершения текущего шага генерации.

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

На момент написания статьи подтверждена работа с четырьмя моделями: Qwen3.6, Agents-A1, Gemma 4 26B-A4B и Nemotron 3 Puzzle. Все они относятся к классу MoE и выигрывают от свопинг-памяти Eider.

• Qwen3.6 - флагманская MoE-модель Qwen с агрессивным распределением экспертов. На DGX Spark через Eider достигает конкурентной скорости генерации без квантизации весов ниже NVFP4.
• Agents-A1 - модель, заточенная под агентные сценарии. Eider обеспечивает низкую задержку первого токена благодаря NVFP4 KV-кешу, что критически важно для интерактивных агентов.
• Gemma 4 26B-A4B - MoE от Google с 26B общих параметров и 4B активных. Идеальный кандидат для свопинга: модель помещается в память DGX Spark почти полностью, а свопинг-память обрабатывает пиковые нагрузки при конкурентных запросах.
• Nemotron 3 Puzzle - модель NVIDIA, архитектурно близкая к тому, подо что проектировался GB10. На Eider показывает нативную производительность без необходимости в проприетарных драйверах NVIDIA для инференса.

Практический сценарий: исследователь запускает сравнение точности агрессивной квантизации с нативным чекпоинтом на DGX Spark, используя Eider для загрузки полновесной MoE-модели без потери точности из-за квантизации. Там, где llama.cpp вынужден применять IQ2_S, Eider держит NVFP4 и сохраняет качество.

OpenAI-совместимый API и мультисессионный планировщик

Eider предоставляет HTTP-сервер с эндпоинтами, совместимыми с OpenAI API: /v1/chat/completions, /v1/completions, /v1/models. Это означает drop-in замену для любого приложения, работающего через openai-python или аналогичные клиенты. Никаких изменений в коде не требуется - достаточно указать хост Eider вместо api.openai.com.

Мультисессионный планировщик распределяет ресурсы между параллельными запросами. В отличие от наивного round-robin, планировщик Eider учитывает состояние свопинг-памяти: если эксперт, нужный сессии A, уже загружен для сессии B, загрузка не дублируется, а сессия A получает готовые веса из памяти. Это снижает задержку при конкурентной нагрузке и увеличивает общую пропускную способность сервера.

Пример отправки запроса к Eider через Python:

from openai import OpenAI

client = OpenAI(
    base_url="http://dgx-spark.local:8080/v1",
    api_key="not-needed"
)

response = client.chat.completions.create(
    model="step-3.7-flash",
    messages=[
        {"role": "user", "content": "Объясни архитектуру MoE"}
    ],
    max_tokens=512
)
print(response.choices[0].message.content)

Для сценариев с высокими требованиями к пропускной способности Eider поддерживает continuous batching - динамическое добавление и удаление запросов из батча без остановки генерации. Это стандартная практика для production-инференса, реализованная здесь с учётом специфики свопинг-памяти.

Архитектура Eider: Rust, CUDA и ставка на SM121

Выбор Rust для хостовой части продиктован тремя факторами. Безопасность памяти без сборщика мусора исключает целый класс багов, критичных для сервера, работающего 24/7. Асинхронная модель tokio позволяет эффективно управлять тысячами конкурентных соединений при минимальном потреблении CPU. Нулевая стоимость абстракций означает, что код на Rust работает на уровне C++, но с гарантиями безопасности на этапе компиляции.

CUDA-ядра Eider написаны под конкретную архитектуру SM121. Это принципиальное отличие от llama.cpp, который использует универсальные ядра, работающие на всём от GTX 1060 до H100. Универсальность llama.cpp - его сила, но и ограничение: ядра не могут использовать специфичные инструкции SM121, включая аппаратное ускорение NVFP4. Eider задействует тензорные ядра пятого поколения, инструкции для работы с FP4 и оптимизированные пути доступа к shared memory GB10.

vLLM написан на Python с CUDA-ядрами, что создаёт два узких места: GIL (Global Interpreter Lock) ограничивает параллелизм на CPU, а слой Python-CUDA добавляет задержку при каждом вызове ядра. Eider на Rust вызывает CUDA-ядра напрямую через FFI, исключая прослойку интерпретатора. На практике это даёт снижение задержки на 10-15% при обработке одиночных запросов и более ровную кривую пропускной способности под нагрузкой.

Стоит упомянуть разбор производительности GLM-5.2 на 8× GB10, где детально показано, как архитектура SM121 раскрывается при кастомной оптимизации инференса. Eider идёт тем же путём, но для одночиповой конфигурации DGX Spark.

Сравнение с vLLM и llama.cpp: когда Eider незаменим

Прямое сравнение трёх инференс-серверов в контексте DGX Spark выявляет чёткую специализацию каждого.

Сценарий, где Eider незаменим - запуск большой MoE-модели на одном DGX Spark без потери точности. vLLM и llama.cpp требуют либо полного размещения модели в памяти (невозможно для Step 3.7 Flash), либо агрессивной квантизации, которая снижает качество. Eider обходит оба ограничения через свопинг-память.

Честные ограничения Eider: сообщество пока невелико, проект находится в активной разработке, возможны нестабильности при обновлении. Привязка к GB10 означает, что Eider не заработает на A100 или H100 - это осознанная плата за оптимизацию. Некоторые фичи vLLM, включая PagedAttention с продвинутым управлением памятью, в Eider не реализованы - вместо них используется собственный аллокатор, заточенный под свопинг экспертов.

Для тех, кто выбирает между облаком и локальным запуском, полезно изучить опыт Databricks с открытыми моделями: затраты на инференс открытых весов могут быть в 4 раза ниже проприетарных API при сопоставимом качестве. Eider снижает входной порог для такого сценария, позволяя использовать DGX Spark вместо облачного GPU.

Ограничения и дорожная карта проекта

Текущие ограничения Eider важно оценить до внедрения в рабочий пайплайн. Поддержка ограничена архитектурой GB10 (DGX Spark) - на других GPU проект не запустится. Список поддерживаемых моделей насчитывает четыре позиции, и добавление новой модели требует ручной адаптации конфигурации экспертов и тестирования. Отсутствует поддержка PagedAttention - управление KV-кешем реализовано через собственный аллокатор, который оптимизирован под NVFP4, но менее гибок в сценариях с разнородными длинами последовательностей.

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

Практическая рекомендация: Eider стоит рассматривать как специализированный инструмент для конкретного сценария - запуск больших MoE-моделей на DGX Spark. Для стандартных dense-моделей или работы на другом железе vLLM и llama.cpp остаются более зрелыми и универсальными решениями. Если же задача требует загрузки Step 3.7 Flash или аналогичной по размеру MoE-модели на одном DGX Spark, альтернатив Eider на текущий момент нет.

Подписаться на канал