Что именно заявил TensorSharp: цифры и контекст теста
Разработчик открытого движка инференса TensorSharp опубликовал результаты запуска DeepSeek V4.1 Flash в формате GGUF на конфигурации из восьми GPU NVIDIA A40. Тест шёл с layer split, F16 KV-кэшем и настроенным контекстом 65 536 токенов.
В квантовании Q2_K модель выдаёт 40,3-40,7 токена в секунду на одиночном запросе и 533-539 tok/s на префилле. В Q4_K_M результат скромнее: 31-32,5 tok/s на декоде и 451,8-492,1 tok/s на префилле.
Оговорка, без которой числа читаются неправильно: это замеры самого проекта, а не независимый бенчмарк. Сравнения с llama.cpp, vLLM или другим движком в отчёте нет. Паритет по качеству модели и численной точности не подтверждён, батчинг может влиять на генерируемый вывод. Ниже разбираем, что стоит за цифрами, какие оптимизации их дали и где заканчивается подтверждённая фактура.
Для тех, кто не читает инференс-отчёты ежедневно: префилл - это обработка входного текста, декод - генерация ответа токен за токеном. Префилл распараллеливается по всем токенам промпта, поэтому считается сотнями токенов в секунду, декод идёт последовательно и измеряется десятками. Складывать или напрямую сравнивать эти два числа между собой бессмысленно.
Ключевые числа в одной таблице
Автор приводит диапазоны, а не единичный замер, поэтому небольшой разброс между прогонами ожидаем. Основные параметры отчёта сведены ниже.
| Параметр | Q2_K | Q4_K_M |
|---|---|---|
| Декод, одиночный запрос | 40,3-40,7 tok/s | 31-32,5 tok/s |
| Префилл | 533-539 tok/s | 451,8-492,1 tok/s |
| Таблицы Engram, около 60 ГиБ | удерживаются на GPU | остаются в оперативной памяти |
| Батчевый декод, четыре запроса | данных в отчёте нет | примерно двукратный прирост |
| Контекст теста и KV-кэш | 65 536 токенов, F16 | 65 536 токенов, F16 |
| Распределение по GPU | layer split, 8× A40 | layer split, 8× A40 |
Разница в декоде между схемами квантования упирается в размещение таблиц Engram: в Q2_K они остаются на GPU, в Q4_K_M уезжают в системную память. Разбор этой зависимости ниже, в разделе про память и скорость.
Почему это замеры проекта, а не бенчмарк
TensorSharp - открытый движок, и замеры сделала команда, которая его разрабатывает. Для инференс-проектов это обычная практика, но статус у таких цифр другой: нет независимого воспроизведения на стороннем железе, нет прогона того же GGUF-файла в альтернативном движке, нет отчёта о качестве ответов на стандартных задачах.
Держать в голове стоит три вещи. Первая: 40 tok/s и 32 tok/s ничего не говорят о том, насколько корректные ответы выдаёт модель в этих квантованиях. Вторая: батчевый декод, который ускоряет обработку, может менять вывод. Третья: префилл и декод измеряются по-разному, и смешивать эти числа в одном сравнении нельзя. Как аккуратно разделять prefill и decode и какие метрики смотреть, разобрано в материале про Qwen 3.8 27B на одной RTX 5090.
Конфигурация 8× A40: что в ней важно для локального запуска
Восемь NVIDIA A40 дают 384 ГБ видеопамяти: по 48 ГБ GDDR6 на карту. Для модели уровня DeepSeek V4.1 Flash в GGUF это запас, которого хватает на длинный контекст и на удержание крупных таблиц в VRAM. У A40 нет NVLink, обмен между картами идёт через PCIe. Этот факт определяет выбор стратегии распределения и объясняет результат сравнения с tensor parallelism ниже.
Зачем F16 KV-кэш и контекст 65 536 токенов
KV-кэш хранит ключи и значения внимания для всех токенов, которые модель уже видела. Чем длиннее контекст и чем больше параллельных запросов, тем больше памяти он занимает. F16 даёт половину точности float32 при вдвое меньшем объёме: компромисс в пользу качества на длинных диалогах и на коде. Более агрессивные схемы кэша экономят VRAM, но в этом тесте их не использовали.
65 536 токенов - выбранный режим теста, а не максимум модели. При другой длине контекста цифры tok/s будут другими, а разбивки по длинам в отчёте нет. То есть нельзя взять 40,3 tok/s и обещать те же значения на 16K или на 128K.
Layer split без NVLink: что это значит на практике
Layer split распределяет слои модели по картам целиком: один слой живёт на одной GPU. Обмен между устройствами происходит на границах слоёв, то есть относительно редко. Tensor parallelism работает иначе: режет матрицы внутри слоя и требует синхронизации активаций после каждого сегмента. Без NVLink такая синхронизация идёт по PCIe, а это узкое место.
Практический вывод для сборок без NVLink: число GPU перестаёт автоматически конвертироваться в скорость. Решает не столько количество карт, сколько объём трафика между ними на каждый сгенерированный токен.
Q2_K против Q4_K_M: где проходит граница по памяти и скорости
Q2_K и Q4_K_M - схемы квантования GGUF с разной битностью весов. Первая укладывает параметры примерно в 2 бита, вторая около 4 бит. Меньше бит означает меньше памяти и меньше трафика при чтении весов, и обычно это оплачивается потерями качества. В отчёте TensorSharp паритет по качеству между схемами не подтверждён, поэтому заявлять, что Q2_K «не хуже» Q4_K_M, оснований нет.
По декоду Q2_K быстрее: 40,3-40,7 против 31-32,5 tok/s. По префиллу разрыв меньше: 533-539 против 451,8-492,1 tok/s. Причина разницы в первую очередь в размещении таблиц Engram, а уже потом в числе бит на вес.
Что такое таблицы Engram и почему они решают
Engram - крупные таблицы в архитектуре модели, которые суммарно занимают около 60 ГиБ в квантованном виде. Если они лежат на GPU, декод идёт без постоянных обращений к системной памяти. Если таблицы остаются в RAM, каждый шаг декода тянет данные по PCIe, и скорость упирается в пропускную способность шины, а не в вычислительную мощность карт.
Это различие и разделяет два режима из отчёта: в Q2_K 60 ГиБ таблиц удерживаются на GPU, в Q4_K_M большие таблицы Engram остаются в оперативной памяти. Практический смысл для тех, кто повторяет сборку: сначала считайте, влезают ли таблицы в суммарную VRAM, и только потом выбирайте битность. Схема оценки бюджета памяти и выбора между Q4_K_M и более агрессивными квантами разобрана в статье про Qwen3.8-27B в true Q4_K_M на RTX 5080.
Батчевый декод: двукратный прирост на четырёх запросах
Для Q4_K_M в отчёте указаны три доработки: автоматический прогрев, более плотный бюджет VRAM и батчевый декод. Вместе они дали примерно двукратный прирост на четырёх параллельных запросах. Точных значений tok/s по батчингу в исходных данных нет, есть только оценка кратности.
Батчинг меняет профиль нагрузки: карты загружаются ровнее, но генерируемый вывод при этом может отличаться от одиночного режима. Как выглядит поведение движка в насыщенном батче и почему пиковые цифры расходятся с ожиданиями, разобрано в кейсе оптимизации DeepSeek-V4-Flash на одном B300.
Оптимизации TensorSharp: от 570 разрывов графа к 8
Автор перечисляет три ключевые правки. Первая: удержание ~60 ГиБ квантованных таблиц Engram на GPU. Вторая: унификация бэкенда на каждом ускорителе, то есть единый набор ядер и один путь исполнения на всех восьми картах. Третья: сокращение числа разрывов графа декода примерно с 570 до 8.
Разрыв графа - ситуация, когда вычисление прерывается и управление передаётся между бэкендами или устройствами. Каждый такой переход стоит накладных расходов: синхронизация, переключение контекста, потеря возможностей слить операции в один вызов. 570 разрывов на цикл декода - это сотни мелких пауз на каждый токен. Восемь почти незаметны. Унификация бэкенда убирает часть переключений, удержание таблиц в VRAM убирает обращения к памяти.
Оговорка: это внутренние решения TensorSharp. Эффект тех же приёмов в llama.cpp или vLLM не измерялся, и переносить цифру 570 → 8 на другой движок нельзя.
Автоматический прогрев и бюджет VRAM
Автоматический прогрев заранее поднимает нужные веса и таблицы в память, чтобы первый и последующие запросы не упирались в подкачку. Плотный бюджет VRAM означает более точное распределение памяти между весами, KV-кэшем и рабочими буферами: чем меньше остаётся неиспользованных резервов, тем больше слоёв и таблиц живёт на GPU. В отчёте эти доработки указаны как часть оптимизаций для Q4_K_M, конкретные значения бюджета не приводятся.
Layer split против tensor parallelism: почему больше параллелизма не значит быстрее
Ключевой факт из отчёта: на системе без NVLink layer split обошёл экспериментальный tensor parallelism для routed-MoE. Скорость составила 31-32,5 tok/s против 21,4-22 tok/s. Рост параллелизма на этой сборке дал не ускорение, а просадку почти в полтора раза.
Причина в характере обмена. Layer split передаёт данные между картами на границах слоёв. Tensor parallelism для routed-MoE дробит вычисления внутри слоя, и эксперты, разложенные по разным GPU, требуют постоянного обмена активациями. Через PCIe этот обмен становится основным ограничением, и чем больше карт участвует в одном слое, тем больше трафика.
Вывод ограничен конкретной моделью и конкретной конфигурацией. Переносить его на другие архитектуры без собственных замеров нельзя: у моделей с другой структурой экспертов и другим соотношением вычислений к обмену картина может отличаться.
Когда tensor parallelism всё же оправдан
Общее соображение, не результат этого теста: при наличии NVLink или NVSwitch пропускная способность межкарточного канала кратно выше PCIe, и синхронизация активаций перестаёт быть узким местом. Тогда tensor parallelism может выигрывать, особенно если слой или группа экспертов не помещается в память одной карты. Замеров на системе с NVLink в отчёте TensorSharp нет, поэтому это контекст для планирования, а не подтверждённый вывод.
Что эти цифры не доказывают: ограничения теста
Список ограничений прямой. Замеры сделаны самим проектом. Сравнения с другим движком нет. Паритет по качеству модели и численной точности не подтверждён. Батчинг может влиять на генерируемый вывод. Условия теста заявлены (layer split, F16 KV-кэш, контекст 65 536 токенов, четыре параллельных запроса), но не разложены по сценариям: отдельного замера на коротком контексте, на длинном, на одном запросе и на батче в отчёте нет.
Строить на этих данных решение «покупать восемь A40» нельзя. Цифры показывают, чего добилась конкретная команда на конкретной сборке, и не описывают нижнюю границу производительности для того же железа в другом движке.
Почему нельзя переносить tok/s на другие модели
Скорость декода зависит от архитектуры модели, объёма таблиц Engram, схемы квантования, длины контекста, числа параллельных запросов и пропускной способности памяти. Замер на одной модели в одной конфигурации не даёт прогноза для другой. Это стандартное ограничение любого инференс-отчёта. Как сравнивать прогоны между собой по p50 и p95, а не по пиковому tok/s, разобрано в разборе тестов DeepSeek V4 Flash и Qwen3.8 на четырёх DGX Spark.
Стоит ли повторять такую сборку: практический вывод
Восемь A40 - это 384 ГБ VRAM, отдельная инфраструктура, охлаждение, питание и время на настройку распределения. Для одиночных задач и небольших нагрузок аренда GPU или API обычно дешевле и проще: не нужно разбираться с размещением таблиц, батчингом и разрывами графа. Локальная сборка имеет смысл, если нужен контроль над данными, длинный контекст и предсказуемые затраты на длинной дистанции. Цены в отчёте не приводятся, и считать окупаемость по чужим цифрам смысла нет.
Для повторения стоит дождаться оригинального отчёта TensorSharp с деталями: версиями, коммитами и точными параметрами запуска. Без них собственные замеры будут сравниваться с неизвестно чем.
Что проверить перед повторением теста
- Версия TensorSharp и коммит сборки.
- Версия GGUF-файла модели и его источник.
- Схема квантования: Q2_K, Q4_K_M или другая.
- Где размещены таблицы Engram: на GPU или в RAM.
- Длина контекста и тип KV-кэша.
- Число параллельных запросов при замере.
- Наличие NVLink между картами.
Без этих семи пунктов сравнение с опубликованными 40,3-40,7 и 31-32,5 tok/s некорректно. С ними это уже воспроизводимый тест, а не пересказ чужого результата.