По предоставленным материалам нельзя подтвердить фактического лидера среди DeepSeek V4 Flash, Qwen3.8 Flash Next, Qwen3.8-27B и Qwen3.6-35B-A3B на четырёх DGX Spark. В наборе данных отсутствуют логи, конфигурация стенда, результаты повторных запусков, размеры контекста и показатели latency.
Ориентир около 80 tok/s для DeepSeek V4 Flash имеет смысл только вместе с условиями получения: длиной промпта, режимом thinking, длиной ответа, числом параллельных запросов, схемой TP2 или репликаций и правилом расчёта скорости. Без этих параметров это пиковая цифра, а не универсальная характеристика модели.
Практический вывод пока ограничен методикой: сравнивать модели нужно по устойчивой скорости, p50 и p95 задержки, стоимости токенов рассуждений, работе с длинным контекстом и поведению при параллельной нагрузке. Числовой рейтинг и рекомендации по выбору модели можно опубликовать после получения первичного отчёта или логов пилота.
Что именно сравнивали на четырёх DGX Spark
Модели и сценарии запуска
В заявленном сравнении участвуют четыре модели:
- DeepSeek V4 Flash;
- Qwen3.8 Flash Next;
- Qwen3.8-27B;
- Qwen3.6-35B-A3B.
Эти названия сами по себе не задают порядок производительности. Для честного сравнения нужно зафиксировать формат весов, квантизацию, версию инференс-рантайма, настройки памяти, размер контекста, параметры генерации и режим рассуждений. Изменение одного параметра может поменять результат сильнее, чем разница между двумя моделями.
В доступных материалах нет сведений о том, как именно модели размещали на четырёх DGX Spark. Поэтому нельзя утверждать, что каждый запуск использовал одну и ту же схему. Неизвестно, запускалась ли модель на одном устройстве, распределялась ли через TP2, работала ли в нескольких независимых репликах и применялся ли общий пул памяти.
Для публикации пилота нужна таблица с такими полями:
| Параметр | Что нужно указать |
|---|---|
| Модель | Полное имя и версия чекпойнта |
| Формат весов | Точная прецизионность и тип квантизации |
| Топология | Один DGX Spark, TP2 или независимые реплики |
| Контекст | Число входных токенов и максимальная длина контекста |
| Генерация | Режим thinking, лимит выходных токенов, temperature и другие параметры |
| Нагрузка | Одиночный запрос, несколько клиентов или пакетная обработка |
Материал о локальном агентном сравнении Qwen3.8 Flash Next объясняет, почему итоговый балл нужно связывать с числом запросов, токенами и latency: разбор Qwen3.8 Flash Next и 27B-моделей.
Какие метрики действительно важны
Time to first token, TTFT показывает, сколько пользователь ждёт первый токен. На него влияют загрузка модели, обработка входного промпта и длина контекста.
Prefill описывает скорость обработки входных токенов. Эта метрика особенно важна для RAG, анализа документов и агентных сценариев, где каждый запрос содержит большой набор инструкций и найденных фрагментов.
Decode tok/s показывает скорость генерации уже после обработки промпта. Высокий decode не гарантирует быстрый ответ, если prefill занял много времени или модель сгенерировала длинную цепочку рассуждений.
Полная задержка должна включать обработку входа, генерацию, токены reasoning и служебные операции рантайма. Для пользователя это более полезный показатель, чем отдельный максимум tok/s.
Для серии запусков нужны как минимум среднее значение, медиана, p95 latency и число неудачных прогонов. Среднее показывает общий уровень, медиана защищает от единичных выбросов, а p95 отражает задержку, которую увидит часть пользователей при реальной нагрузке.
DGX Spark DeepSeek V4 Flash: что означает пиковая скорость
Пиковый tok/s против устойчивого результата
Заявление о скорости около 80 tok/s нельзя переносить на любой запрос DeepSeek V4 Flash. Для интерпретации нужны минимум четыре условия: размер входа, размер ответа, режим thinking и схема запуска.
Короткий промпт с небольшим ответом может дать высокий decode-показатель. Длинный документ увеличит время prefill и расход KV-cache. При параллельных запросах отдельный поток может замедлиться, хотя суммарная пропускная способность системы вырастет.
Единичный максимум скрывает разброс. Корректная серия должна включать прогревочные запуски и повторения после прогрева. В отчёте нужно показать:
- минимальную, среднюю и максимальную скорость;
- медиану и p95 полной задержки;
- результаты для короткого и длинного контекста;
- число входных и выходных токенов;
- число неудачных или прерванных запусков;
- поведение при одном и нескольких клиентах.
Похожий вопрос возникает при сравнении DeepSeek V4 Flash на MacBook и двух DGX Spark: преимущество Spark в таком сценарии связано со скоростью, пропускной способностью и доступным контекстом, а не с автоматически большей точностью. Подробный разбор опубликован в статье о сравнении агрессивной квантизации и нативного чекпойнта.
Как thinking меняет стоимость ответа
Thinking меняет сразу несколько параметров ответа. Модель может генерировать больше внутренних токенов, дольше формировать первый видимый токен и увеличивать полную задержку даже при близкой скорости декодирования.
Для сравнения обычного и reasoning-режима нужно записать:
| Показатель | Зачем нужен |
|---|---|
| Токены рассуждений | Показывают дополнительный расход вычислений и длину скрытой части ответа |
| Видимые выходные токены | Позволяют сравнить объём полезного результата |
| TTFT | Показывает задержку до начала ответа |
| Полная latency | Отражает время получения всего результата |
| Decode tok/s | Характеризует скорость генерации после prefill |
Для быстрого чата обычно важны TTFT и полная задержка. Для сложной задачи с кодом или многошагового агента ценность thinking нужно оценивать вместе с качеством результата и числом повторных попыток. В доступных данных нет замеров, которые позволили бы сказать, какой режим DeepSeek V4 Flash выгоднее в конкретном сценарии.
Qwen3.8 Flash Next и Qwen3.8-27B: скорость, контекст и стабильность
Короткий контекст и интерактивный диалог
Для короткого запроса сравнение должно проходить при одинаковых входных и выходных лимитах. Иначе одна модель может выглядеть быстрее из-за короткого ответа или меньшего объёма рассуждений.
Минимальный набор показателей для Qwen3.8 Flash Next и Qwen3.8-27B выглядит так:
| Сценарий | Qwen3.8 Flash Next | Qwen3.8-27B |
|---|---|---|
| Длина входа | Нет данных | Нет данных |
| TTFT | Нет данных | Нет данных |
| Prefill | Нет данных | Нет данных |
| Decode tok/s | Нет данных | Нет данных |
| Полная latency | Нет данных | Нет данных |
| p95 latency | Нет данных | Нет данных |
Без этих значений нельзя корректно назвать одну из моделей лучшей для интерактивного диалога. Быстрый decode может сопровождаться большим TTFT, а низкая задержка первого токена может не привести к меньшему времени получения полного ответа.
Длинный контекст и RAG-нагрузка
Длинный контекст меняет профиль нагрузки. Система сначала обрабатывает большой вход, затем хранит промежуточные состояния в KV-cache и только после этого генерирует ответ. Поэтому показатели короткого промпта не описывают работу с документами, базой знаний или историей агентного диалога.
Для RAG нужно сравнить хотя бы три размера входа, если они предусмотрены первичным отчётом. Для каждого размера фиксируются prefill, TTFT, decode, полная latency, потребление памяти и устойчивость генерации.
Сейчас в материалах нет ни одного измеренного размера контекста для Qwen3.8 Flash Next или Qwen3.8-27B. Нельзя утверждать, какая модель лучше работает с длинными документами, экономнее расходует KV-cache или дольше сохраняет стабильную скорость.
Сравнение Qwen3.5 122B с Qwen3 Next 80B на обычном оборудовании хорошо показывает общий принцип: размер модели и качество ответа не позволяют заранее вывести скорость локального инференса. Ограничения памяти, квантизация и характеристики процессора меняют итоговый результат. Практический пример приведён в тесте Qwen3.5 122B и Qwen3 Next 80B.
Qwen3.6-35B-A3B: где важна не только скорость ответа
Qwen3.6-35B-A3B должна проходить те же прогоны, что и остальные модели. Иначе её результат нельзя поставить в одну таблицу с DeepSeek V4 Flash и двумя версиями Qwen3.8.
В отчёте для этой модели нужно отдельно показать:
- скорость обработки промпта;
- скорость декодирования;
- TTFT и полную latency;
- число токенов reasoning и общий объём ответа;
- потребление памяти при разных контекстах;
- результат при одном и нескольких одновременных запросах.
По имеющимся данным нельзя подтвердить специфический баланс Qwen3.6-35B-A3B между вычислениями, пропускной способностью и расходом памяти. Любое архитектурное объяснение её поведения будет предположением, пока в источнике нет технических характеристик и логов запуска.
TP2 или независимые реплики: как выбрать топологию запуска
Когда TP2 даёт выигрыш
TP2, или tensor parallelism, распределяет вычисления одной модели между двумя устройствами. Такая схема может быть нужна, если модель или выбранный контекст не помещаются на одном DGX Spark. Её польза для задержки зависит от объёма межустройственного обмена, размера batch и характера операции.
Для одиночного запроса TP2 нужно оценивать по полной latency, а не по сумме загрузки устройств. Коммуникационные издержки могут уменьшить выигрыш, особенно при коротком ответе, когда вычислений мало, а синхронизация выполняется регулярно.
Сравнение TP2 имеет смысл только при одинаковых условиях:
- одна модель и один формат весов;
- одинаковая длина входа и ответа;
- одинаковый режим thinking;
- одинаковый размер batch;
- одинаковое число повторов;
- зафиксированная схема сетевого обмена.
В доступном наборе данных нет замеров TP2 на четырёх DGX Spark, поэтому конкретный порог, при котором эта схема становится выгоднее, не установлен.
Когда выгоднее независимые реплики
Независимые реплики запускают отдельный экземпляр модели на каждом доступном устройстве. Такой вариант может увеличить суммарную пропускную способность, когда есть несколько независимых запросов, но он не ускоряет один запрос автоматически.
Для сравнения реплик нужны тесты с двумя, четырьмя и большим числом параллельных клиентов, если стенд это поддерживает. В таблице должны быть суммарные tok/s, средняя latency, p95 latency, длина очереди и доля ошибок.
TP2 и репликация отвечают на разные вопросы. TP2 помогает обслужить одну крупную модель или запрос с большим потреблением памяти. Реплики подходят для параллельных пользователей и пакетной обработки, если каждый экземпляр модели помещается на выделенном устройстве.
Почему one-run score без контекста почти бесполезен
Минимальная воспроизводимая методика
Публикация одного максимального значения не даёт читателю способа проверить результат. Для воспроизводимости отчёт должен содержать:
- модель, версию чекпойнта, формат весов и квантизацию;
- версии драйверов, инференс-рантайма и библиотек;
- топологию запуска и сетевую схему;
- размер входного и выходного контекста;
- режим thinking и параметры генерации;
- число прогревочных и измерительных запусков;
- число параллельных клиентов и размер batch;
- формулы расчёта tok/s, TTFT и полной latency;
- среднее, медиану, p95 и правила обработки выбросов;
- температурный режим и признаки thermal throttling.
Одинаковый промпт нужен для парного сравнения, но одного промпта недостаточно для вывода о рабочей производительности. В тестовый набор следует включить короткие вопросы, длинные документы, RAG-контекст, генерацию кода и несколько параллельных запросов.
Какие выводы нельзя делать по этим тестам
По предоставленному Research Pack нельзя подтверждать:
- лидера по скорости среди четырёх моделей;
- преимущество DeepSeek V4 Flash при значении около 80 tok/s;
- выигрыш TP2 перед независимыми репликами;
- лучшую модель для длинного контекста или RAG;
- влияние thinking на число токенов и полную задержку;
- устойчивость любой конфигурации при многопользовательской нагрузке.
Результаты пилота нельзя переносить на другие стенды без оговорок. Версия рантайма, драйверы, формат весов, квантизация, температура, размер batch и сетевой обмен способны изменить показатели.
Практический выбор: модель и режим под конкретную задачу
Пока первичные замеры не предоставлены, корректная матрица выбора выглядит как набор условий для проверки, а не как рейтинг:
| Задача | Что сравнивать | Что пока нельзя утверждать |
|---|---|---|
| Быстрый чат | TTFT, p50 полной latency, decode tok/s на коротком контексте | Какая модель быстрее без данных по одинаковому промпту |
| Сложное reasoning | Токены thinking, полную latency, качество и число повторных попыток | Что thinking всегда оправдывает дополнительное время |
| Длинные документы | Prefill, TTFT, KV-cache и p95 при нескольких размерах контекста | Какая модель лучше переносит длинный контекст |
| RAG | Скорость обработки найденных фрагментов, стабильность и точность ответа | Что высокий decode означает лучший результат в RAG |
| Кодогенерация | Полную latency, число итераций агента и устойчивость длинной задачи | Что один короткий запрос описывает работу агента |
| AI-агенты | Суммарное время цепочки, токены reasoning и число обращений к инструментам | Что скорость одного ответа равна скорости всего сценария |
| Несколько пользователей | Суммарный throughput, очередь и p95 при параллельных запросах | Что TP2 лучше реплик без теста насыщения |
| Пакетная обработка | Устойчивый throughput, размер batch и долю ошибок | Что пиковый tok/s сохранится на серии задач |
Для одиночного интерактивного запроса следует искать низкую полную latency. Для длинного документа приоритет смещается к prefill, TTFT и расходу KV-cache. Для нескольких пользователей важнее суммарная пропускная способность и p95, чем скорость одного потока.
Пока нет первичных измерений, выбор конкретной модели из этого списка был бы необоснованным. Публикация должна сначала заполнить матрицу одинаковыми прогонами, затем связать каждую рекомендацию с измеренным показателем.
Итоги тестов DGX Spark
Заявленный ориентир около 80 tok/s для DeepSeek V4 Flash нельзя считать универсальным результатом без контекста, режима генерации и описания нагрузки. Это потенциальный пиковый показатель, условия которого нужно подтвердить логами.
По Qwen3.8 Flash Next, Qwen3.8-27B и Qwen3.6-35B-A3B в предоставленных материалах нет числовых замеров. Поэтому нельзя достоверно назвать лидера по устойчивой скорости, длинному контексту, thinking или многопользовательской нагрузке.
TP2 стоит выбирать для крупного одиночного запроса или модели, которая не помещается на одном устройстве, после проверки межустройственного обмена и полной latency. Независимые реплики нужно проверять на параллельной нагрузке, где важны очередь, p95 и суммарный throughput.
Для воспроизводимого отчёта нужны первичный текст пилота, логи запусков, конфигурация четырёх DGX Spark, версии драйверов и рантайма, формат весов, параметры контекста, режим thinking, число повторов и результаты для разных уровней параллелизма. Без этого статья может корректно объяснить методику, но не имеет основания выдавать числовой рейтинг моделей.