Связка двух ASUS GX10 может быть оправдана для локального запуска DeepSeek Flash v4, если один узел не вмещает выбранный вариант модели, целевой KV-кэш или нужный уровень параллельной нагрузки. Само наличие двух устройств не гарантирует двукратный прирост скорости одного диалога: результат определяют схема распределения модели, межузловая задержка, инференс-движок, квантизация и профиль запросов.
В доступных для подготовки материалах нет подтверждённых характеристик DeepSeek Flash v4, ASUS GX10, схемы их объединения и результатов бенчмарка. Поэтому нельзя корректно приписывать этой конфигурации конкретные tokens/s, объём памяти, тип интерфейса или поддерживаемый режим распределённого инференса. Перед публикацией новости или принятием решения о покупке нужно сверить первоисточник, точное имя модели, конфигурацию узлов и методику замеров.
Практический смысл такой связки сводится к четырём вопросам: помещается ли модель вместе с рабочим контекстом, как быстро система выдаёт первый токен, сколько токенов генерирует после старта и как ведёт себя при нескольких одновременных запросах. Peak throughput без этих условий мало говорит о реальном пользовательском опыте.
Что важно понять сразу о DeepSeek Flash v4 на двух ASUS GX10
Почему две системы могут быть важнее одного высокого значения tokens/s
Пользователь видит не одну цифру из бенчмарка, а последовательность задержек. Сначала система принимает запрос и обрабатывает промпт. Затем появляется первый токен. После этого начинается потоковая генерация. При RAG-сценарии к истории диалога часто добавляются найденные фрагменты документов, поэтому пауза перед ответом может стать заметнее, чем скорость вывода короткой фразы.
Два узла решают одну из двух задач. Первая: разделить веса и рабочую память одной модели, когда она не помещается на одном устройстве в нужной точности и с нужной длиной контекста. Вторая: поднять две реплики модели и распределять независимые запросы. Во втором случае система получает больше пропускной способности для пользователей или агентов, но отдельный запрос может идти с той же скоростью, что и на одном узле.
Прирост на распределённой модели ограничивает обмен данными между устройствами. Каждый шаг decode может ждать коммуникацию, поэтому дополнительные вычислительные ресурсы способны частично или полностью потерять преимущество на коротких запросах. Для длинного контекста, тяжёлой модели или высокой concurrency ситуация может быть другой.
Какие данные нужно подтвердить до разбора результатов
Любой результат для DeepSeek Flash v4 на двух ASUS GX10 имеет технический смысл только вместе с условиями теста. Минимальный список выглядит так:
- точное название модели, число параметров и архитектура;
- формат весов: исходная точность, FP8, FP4, INT8, INT4, GGUF или иной вариант;
- версия инференс-движка, драйверов и runtime;
- доступная память на каждом узле и фактическое потребление памяти;
- режим работы: разделённая модель, две реплики или разнесённые сервисы;
- длина входного промпта и число выходных токенов;
- batch size, число параллельных запросов и состояние прогрева;
- средняя задержка, хвостовая задержка и метод измерения.
Без этих параметров значение в tokens/s остаётся рекламной цифрой, которую нельзя честно сравнить с другим запуском.
Скорость генерации и prompt eval: почему это разные метрики
Generation throughput: скорость, с которой модель продолжает ответ
Generation throughput, или decode throughput, показывает скорость выпуска новых токенов после начала ответа. Авторегрессионная LLM генерирует продолжение последовательно: следующий токен зависит от предыдущих. Поэтому decode часто чувствителен к производительности вычислений, работе памяти, размеру батча и коммуникационным затратам между узлами.
Метрика особенно заметна при длинных ответах: генерации кода, подготовке документа, разборе логов, работе агента с развёрнутым планом. Для одного короткого вопроса разница между высокой и средней decode-скоростью может быть почти незаметна, если система долго читает входной контекст.
Пиковое значение decode throughput часто получают при крупном batch size и нескольких параллельных потоках. Это полезная характеристика для сервера, но она не равна скорости интерактивного чата с одним пользователем. В обзорах локальных систем полезно разделять prefill и decode, как в разборе производительности GLM-5.2 на 8x GB10.
Prompt eval: как быстро система обрабатывает контекст до первого токена
Prompt eval, часто называемый prefill, описывает обработку входных токенов. В промпт входят инструкция, история чата, контекст репозитория, результаты поиска RAG и сам вопрос. На этом этапе модель строит KV-кэш, который затем использует во время генерации.
Высокая скорость prompt eval сокращает TTFT, time to first token. Для анализа документа на десятки тысяч токенов это может быть важнее рекордного decode. Пользователь сначала ждёт, пока модель прочитает документ, и лишь затем видит начало ответа.
Нельзя выводить TTFT только из prompt eval. На итоговую паузу влияют обработка запроса приложением, очередь, токенизация, загрузка модели, планировщик движка, размер batch и степень конкуренции между сессиями. Корректный тест показывает и скорость prefill, и измеренное время до первого токена.
Какие метрики запросить вместе с заявленными результатами
| Метрика | Что показывает | Условие, без которого цифра мало полезна |
|---|---|---|
| Prompt eval | Скорость обработки входного контекста | Длина промпта, формат KV-кэша, batch size |
| Decode tokens/s | Скорость выпуска ответа после старта | Длина генерации, concurrency, квантизация |
| TTFT | Пауза до первого токена | Прогретый или холодный запуск, очередь, длина промпта |
| P95 или P99 latency | Задержка в неблагоприятных запросах | Число параллельных пользователей и время теста |
| Потребление памяти | Запас под веса, runtime и KV-кэш | Контекст, число активных сессий, формат весов |
Сохраняйте полный лог параметров рядом с результатами. Через несколько недель после обновления движка или драйвера именно он объяснит, почему цифры изменились.
Как два ASUS GX10 участвуют в запуске одной локальной LLM
Разделение модели между узлами: когда оно нужно
Model parallelism делит веса модели или вычисления между несколькими устройствами. Схема нужна, когда модель, выбранная точность или целевой контекст не помещаются в память одного узла. Инференс-движок должен поддерживать этот режим, а его backend должен корректно работать с доступной топологией соединения.
В таком запуске память двух систем не стоит воспринимать как единый бесшовный пул. У каждого процесса остаются свои буферы, служебные данные и ограничения runtime. Между частями модели передаются активации или другие данные, нужные для следующего вычислительного шага. Эта коммуникация попадает в критический путь инференса.
Разделённая модель полезна, когда без второго узла запуск вообще невозможен или когда он открывает рабочий контекст нужной длины. Ускорение одной сессии нужно измерять отдельно. Оно зависит от модели и программного стека.
Две реплики модели: когда важнее параллельные запросы
Репликация означает, что на каждом ASUS GX10 работает отдельный экземпляр модели. Балансировщик направляет запросы на менее занятый узел. Подход подходит для нескольких пользователей, очереди фоновых задач, параллельных агентов и пакетной обработки.
Главное условие простое: веса модели и нужный KV-кэш должны помещаться на каждом устройстве отдельно. Взамен исчезает межузловая коммуникация на критическом пути одного запроса. Эксплуатация обычно проще, а падение одного узла не обязательно останавливает весь сервис.
Для домашнего сервера с двумя независимыми пользователями две реплики иногда практичнее разделённой модели. Для одной большой модели, которая не влезает в память одного узла, такой вариант недоступен.
Почему тип распределения нельзя определять по числу устройств
Два AI-устройства не удваивают скорость одной LLM автоматически. Ускорение определяют поддержка tensor parallelism или pipeline parallelism в движке, формат весов, размер batch, особенности MoE-архитектуры, скорость связи и настройки планировщика.
Есть и третий вариант: один узел обслуживает LLM, второй выполняет embeddings, reranking, распознавание речи, индексирование документов или отдельную модель. Эта схема разгружает основной сервис, но не превращает два устройства в единый ускоритель.
Публикация должна называть фактический режим запуска только при наличии документации или воспроизводимой команды старта. Формулировка «работает на двух системах» сама по себе не раскрывает архитектуру.
Память, KV-кэш и сеть: что проверить перед сборкой двухсистемного стенда
Как оценить память под веса модели и KV-кэш
Планирование памяти начинается с весов. Их объём меняется вместе с форматом: один и тот же чекпойнт в FP16, FP8, INT4 и смешанной квантизации требует разного места. Затем нужен резерв для runtime, активаций, графов вычислений, временных буферов и операционной системы.
KV-кэш хранит представления уже прочитанного контекста. Его объём растёт вместе с длиной истории и количеством одновременных сессий. Модель может успешно запускаться на коротком запросе и завершаться ошибкой памяти при росте контекста или concurrency. Проверять нужно рабочую нагрузку, а не только факт загрузки весов.
До сборки стенда сформируйте три профиля: одиночный чат с коротким контекстом, RAG с целевой длиной входа и параллельная работа с нужным числом сессий. Для каждого профиля зафиксируйте потребление памяти после прогрева. Материал о Qwen3.5 122B и Qwen3 Next на 64 ГБ RAM хорошо иллюстрирует общий компромисс: выбор квантизации меняет и качество, и скорость, и требования к памяти.
Межузловая связность: источник выигрыша или новой задержки
Для разделённой модели сеть становится частью вычислительной архитектуры. Нужны достаточная пропускная способность, низкая и стабильная задержка, корректные настройки интерфейсов и поддержка выбранного backend со стороны движка. Обычное наличие сетевого подключения ничего не говорит о пригодности стенда для интерактивного инференса.
Проверка начинается с фактического пути передачи между узлами. Затем оценивают стабильность под нагрузкой: потеря пакетов, скачки задержки, конкуренция с остальным трафиком и поведение после перезапуска. Для реплик сети нужны в основном для маршрутизации запросов и служебных задач, поэтому её влияние на latency одного ответа заметно меньше.
Короткие decode-запросы особенно чувствительны к лишнему обмену между узлами. При каждом новом токене небольшая задержка способна накапливаться. Поэтому связку нельзя оценивать только по агрегированному throughput.
Программный стек и совместимость версий
Перед запуском проверьте ОС, драйверы, runtime, версию инференс-движка, backend распределённого режима, формат весов и поддержку квантизации. Несовместимость проявляется по-разному: процесс не стартует, модель загружается частично, отключаются быстрые ядра, появляются ошибки коммуникации или резко растёт потребление памяти.
Зафиксируйте конфигурацию в репозитории или отдельном файле. В нём нужны версии пакетов, параметры запуска, переменные окружения, ограничения контекста, формат KV-кэша и способ маршрутизации запросов. Это сократит время диагностики после обновления ПО и позволит повторить бенчмарк на той же конфигурации.
Где высокая скорость генерации и низкая задержка действительно окупаются
RAG и анализ документов: приоритет у обработки длинного промпта
Типовой RAG-запрос проходит несколько этапов: поиск выбирает фрагменты, приложение собирает контекст, LLM читает его и генерирует ответ. Большая часть ощущаемой паузы может приходиться на prefill, особенно при длинной истории, нескольких документах и строгих системных инструкциях.
В таком сценарии измеряйте prompt eval и TTFT на реальном размере контекста. Тест с короткой фразой в 100 токенов не покажет поведение системы при нескольких тысячах токенов из базы знаний. Память под KV-кэш проверяйте одновременно с целевым числом пользователей.
Кодовый ассистент и интерактивный чат: важен баланс TTFT и decode
В редакторе кода ценна быстрая первая реакция: пользователь часто уточняет запрос после первых строк. Дальше нужна достаточная decode-скорость, чтобы патч, объяснение или тест не появлялись слишком медленно. Предсказуемая P95-задержка обычно полезнее рекордного throughput в единичном удачном замере.
Профиль стоит собрать из коротких вопросов по коду, запросов с фрагментами файлов, диалогов с историей и генерации больших блоков. Если модель вмещается на одном узле, дополнительная межузловая коммуникация может ухудшить этот режим вместо ожидаемого ускорения.
Несколько пользователей и агенты: когда нужна пропускная способность
Несколько одновременных пользователей создают очередь. Агентные цепочки добавляют вызовы инструментов, повторные обращения к модели и фоновые этапы. Здесь полезны высокая суммарная производительность, устойчивый scheduler, достаточный запас памяти и контроль хвостовых задержек.
Два ASUS GX10 могут оказаться полезны ради репликации, разделения модели или разнесения сервисов. Выбор зависит от того, что ограничивает систему в замерах: память, decode, prefill, очередь или сеть. Для оценки добавьте тесты с concurrency 1, 2, 4 и значением, близким к ожидаемой реальной нагрузке.
Ограничения двухсистемной схемы: где один мощный сервер может быть рациональнее
Сложность эксплуатации и диагностики
Второй узел добавляет сетевую конфигурацию, согласование версий, мониторинг, маршрутизацию запросов, отдельные журналы и больше сценариев восстановления после сбоя. Для распределённой модели ошибка на одном узле обычно останавливает запрос. Для реплик нужно настроить проверку доступности и корректное перенаправление нагрузки.
Домашний стенд или небольшая команда часто выигрывают от простой схемы, которую легко обновлять и отлаживать. Центральный сервер с достаточной памятью может быть рациональнее, когда ключевыми требованиями остаются предсказуемость, единое администрирование и минимум точек отказа.
Почему короткие запросы не всегда выигрывают от распределения
Короткий запрос несёт мало вычислительной работы. Если часть этой работы требует ожидания второго узла, коммуникационные расходы способны съесть выгоду от дополнительного железа. Эффект зависит от конкретного движка и топологии, поэтому его нельзя предсказать по числу устройств.
Проверьте отдельно запросы с коротким промптом и ответом на 50-100 токенов. Затем повторите тест с длинным контекстом и большой генерацией. Разница между профилями покажет, где распределённая схема приносит результат, а где создаёт лишнюю задержку.
Как выбрать между одним узлом, двумя узлами и серверной конфигурацией
| Вариант | Когда подходит | Что проверить |
|---|---|---|
| Один узел | Модель и KV-кэш помещаются, пользователей немного, критична простота | Запас памяти, TTFT, decode на рабочем контексте |
| Два узла с репликами | Нужны параллельные независимые запросы | Помещается ли модель на каждом узле, балансировка, P95 latency |
| Два узла с разделённой моделью | Одна модель или целевой контекст не влезают на одном устройстве | Поддержка backend, межузловая задержка, расход памяти |
| Серверная конфигурация | Нужны расширяемость, высокая плотность ресурсов и централизованное обслуживание | Стоимость владения, питание, охлаждение, поддержка ПО |
Выбор начинается с модели и нагрузки, а не с красивой цифры на слайде. Для сравнения альтернатив полезен разбор Laguna S 2.1 и DeepSeek V4 Flash по реальным бенчмаркам: качество модели и требования к инфраструктуре стоит оценивать вместе.
Как корректно проверить заявленную производительность перед покупкой
Минимальный набор сценариев для локального LLM-бенчмарка
Проверяйте систему на задачах, близких к реальному использованию. Для каждого теста сохраняйте модель, формат весов, версию движка, параметры запуска, длину входа и выхода, число параллельных запросов и состояние прогрева.
- Короткий чат: небольшой промпт, ответ на 100-300 токенов. Измерьте TTFT и decode.
- Длинный контекст: RAG-пакет или документ целевой длины. Измерьте prompt eval, TTFT и память.
- Длинная генерация: ответ на несколько тысяч токенов. Проверьте стабильность decode и отсутствие роста памяти.
- Параллельная нагрузка: повторите первые три сценария при нескольких одновременных запросах. Зафиксируйте среднюю задержку и P95.
Тесты стоит проводить после прогрева модели и отдельно после холодного старта. Эти состояния дают разный опыт: первый показывает устойчивую работу сервиса, второй важен для эпизодического локального запуска.
Какие результаты считать достаточными для своего сценария
Достаточная производительность зависит от задачи. Для интерактивного чата задайте допустимый TTFT и минимальную decode-скорость, при которой потоковый ответ читается комфортно. Для RAG задайте лимит на обработку целевого объёма контекста. Для команды определите нужное число параллельных сессий и допустимую P95-задержку.
Связка двух ASUS GX10 оправдана, когда замеры на целевой модели показывают преимущество над более простой альтернативой по памяти, задержке или пропускной способности. Если модель уверенно работает на одном узле, запросы короткие, а нагрузка небольшая, второй узел может добавить сложность без заметной пользы. Решение должно опираться на воспроизводимый бенчмарк, а не на одно peak-значение tokens/s.