Как развернуть LLM локально за два дня: пошаговый кейс на DGX Spark и vLLM

Инженер, стоявший за этим пилотом, честно признаёт: теорию он знал давно, а вот сквозной путь от файлов модели до рабочего пользовательского сценария прошёл впервые. За два дня команда подняла две локальные LLM на двух DGX Spark, развернула отдельную модель распознавания речи (ASR, автоматическое распознавание речи) на мини-ПК с AMD GPU и подключила всё к мультиагентной платформе «Искра». Результат стал инженерным кейсом, где видны реальные узкие места. Ниже по шагам, что именно делать, на чём спотыкаться и как не потерять дни на ошибках, которые выглядят мелкими.

Что понадобится?

• Серверы с GPU. В пилоте использовались два NVIDIA DGX Spark (ARM64, архитектура Grace Blackwell, 128 ГБ согласованной памяти CPU и GPU). Для ASR задействован мини-ПК Beelink с AMD Radeon 8060S
• Runtime для LLM. vLLM, фреймворк, который поднимает OpenAI-совместимый HTTP-сервер. Приложение вызывает локальные модели через привычный /v1/chat/completions, не требуя отдельной интеграции под каждый runtime
• Модели. Основная LLM: Qwen3.8-27B-FP8. Быстрая LLM: Qwen3.6-35B-A3B-NVFP4. ASR: Qwen3-ASR-1.7B
• Среда для AMD-контура. WSL2 (подсистема Windows для Linux) плюс ROCm (аналог CUDA для видеокарт AMD)
• Оркестрация. Мультиагентная платформа «Искра», к которой подключаются все три вычислительных сервиса
• Время. Два полных рабочих дня на пилот, включая диагностику и откат неудачных оптимизаций

Архитектура пилота: три сервиса за одним API

Схема, которую собрали, выглядит так: пользователь обращается к платформе «Искра», та оркестрирует агентов (ИИ-агент, программа, самостоятельно выполняющая цепочку действий) и маршрутизирует запросы на три endpoint (точки подключения):

• Основная LLM на DGX Spark №1 для сложных пользовательских задач
• Fast LLM на DGX Spark №2 для служебных и простых запросов
• ASR API на Beelink с AMD Radeon в WSL2 для транскрибации аудио и видео

Ключевое архитектурное решение: vLLM отдаёт стандартизированный OpenAI-совместимый контракт. Это отделяет приложение от конкретной реализации инференса (инференс, выполнение уже обученной модели на входных данных). Модель, квантизацию (способ сжатия весов для экономии памяти) или параметры сервера можно менять за границей API, не переписывая агентный слой.

Но совместимый endpoint не гарантирует совместимого поведения. Особенно в потоковой выдаче (streaming) и tool calling (вызов внешних функций моделью). Об этом ниже.

Пошаговая инструкция

1. Соберите матрицу совместимости, прежде чем скачивать веса

Первая проверка не «помещается ли модель в память», а полная матрица:

• Архитектура CPU (в случае DGX Spark это ARM64)
• Поколение GPU и его возможности
• Версия CUDA или ROCm и драйвера
• Поддержка конкретной квантизации (FP8, FP4) в выбранном runtime
• Наличие нужных вычислительных ядер (kernels) в runtime
• Формат весов и chat template (шаблон, по которому runtime формирует диалог из сообщений)
• Архитектура контейнерного образа

Для AMD-контура в WSL2 существует отдельный путь установки и своя матрица совместимости. Переносить CUDA-инструкции на такой узел бессмысленно.

2. Разверните воспроизводимые контейнеры

Модель в репозитории это набор артефактов: веса, конфигурация архитектуры, токенизатор (программа, разбивающая текст на единицы, понятные модели), chat template, иногда дополнительный код модели, метаданные квантизации. Сами по себе они не принимают HTTP-запросы, не ограничивают параллелизм, не пишут метрики и не восстанавливаются после перезагрузки.

Минимальный контур сервиса:

артефакты модели
+ совместимый runtime
+ GPU-драйвер и вычислительный стек
+ HTTP API / streaming / auth
+ healthcheck / логи / restart policy
= сервис, который можно подключать к приложению

Веса выносите в постоянное хранилище. Серверы получают API-аутентификацию, healthcheck (автоматическую проверку работоспособности) и политику перезапуска.

3. Настройте безопасность API с оговоркой

Встроенный API-ключ в vLLM защищает не все endpoint. В официальной документации vLLM прямо рекомендуется учитывать это при публикации сервера и при необходимости ставить его за reverse proxy (промежуточный сервер, закрывающий прямой доступ к сервису). «Есть ключ» и «поверхность сервиса закрыта» не одно и то же.

4. Рассчитайте память правильно: веса это только начало

Грубая формула потребления:

память процесса ≈ веса модели
  + KV-кэш
  + рабочие буферы и графы
  + служебные структуры runtime
  + память других процессов

KV-кэш (кэш ключей и значений, где модель хранит контекст диалога) зависит от архитектуры модели, длины контекста, числа одновременных последовательностей и типа данных. Рабочая память меняется с настройками prefill, CUDA graphs и конкретными вычислительными ядрами.

Поэтому вопрос «влезет ли модель?» неполон. Спрашивайте иначе:

• С каким максимальным контекстом она поместится?
• Сколько запросов сможет выполнять одновременно?
• Какой запас останется системе?
• Не появятся ли вытеснения KV-кэша?
• Что произойдёт при двух длинных запросах сразу?

В пилоте начальная конфигурация работала с окном 32 тысячи токенов (токен, минимальная единица текста для модели, примерно три четверти слова). Для реальных агентных сценариев потребовалось расширить контекст до 256 тысяч токенов, и это пришлось «оплачивать» снижением параллелизма.

5. Подключите к оркестратору и проверьте потоковую выдачу и tool calling

Самая коварная зона. OpenAI-совместимый endpoint не означает, что streaming и tool calling (когда модель вызывает внешние функции, например поиск или калькулятор) будут вести себя идентично облачному API OpenAI. В пилоте именно здесь обнаружились расхождения, которые потребовали отдельной отладки на стороне платформы «Искра».

Что делать с этим прямо сейчас, по ролям

Автору Дзена и копирайтеру. Если вы присматриваетесь к локальным моделям для генерации текстов, учитывайте: развернуть LLM локально можно и на потребительском железе с одной видеокартой, но агентные сценарии с длинным контекстом потребуют серверного класса. Для экспериментов с короткими промптами подойдёт и домашняя машина с 16 ГБ видеопамяти, но без иллюзий про «замену ChatGPT».

Маркетологу. Локальный контур означает, что данные не уходят за периметр компании. Для задач, связанных с обработкой клиентских обращений, персональных данных или внутренних документов, это может быть единственный допустимый вариант. Из доступных в РФ облачных аналогов: YandexGPT и GigaChat через API, но они не дают контроля над размещением данных на уровне «железо стоит в нашей серверной».

Предпринимателю и техническому руководителю в РФ. DGX Spark доступен в России через партнёров NVIDIA. vLLM работает с открытыми моделями (моделями с доступными весами), поэтому не зависит от санкционных ограничений на API. Главный вопрос не «какую модель взять», а «кто в команде пройдёт путь от матрицы совместимости до стабильного сервиса». Закладывайте два-три дня инженерной работы на пилот и отдельно время на нагрузочное тестирование.

Локальная LLM, запущенная и отвечающая на простой промпт, это примерно 20% пути. Остальные 80% лежат в инженерии сервиса: памяти, безопасности, потоковой выдаче и поведении под нагрузкой. Кто пройдёт этот путь до конца, получит инфраструктуру, которая не зависит ни от чужого облака, ни от чужих правил.