В сравнении GLM-5.3-Flash в формате GGUF рантаймы llama.cpp и TensorSharp показали почти одинаковую скорость prefill. На decode TensorSharp оказался примерно вдвое быстрее. Разрыв объясняют повторным использованием скомпилированного графа и CUDA capture, которые сокращают служебные расходы при последовательной генерации токенов.
Результат особенно заметен в длинных ответах, многошаговых агентных сценариях, локальном кодинге и длительных диалогах. Он не означает двукратного ускорения всего inference-пайплайна: обработка входного контекста у двух движков близка, поэтому итоговая разница зависит от соотношения prefill и decode. Сравнение проводилось при warm cache, включенном Flash-Attention и одинаковом n_ubatch.
Короткий ответ: где TensorSharp выигрывает у llama.cpp
Prefill почти на одном уровне, decode заметно быстрее
Prefill обрабатывает уже готовый prompt: модель читает входную последовательность, строит промежуточные представления и заполняет KV cache. Decode запускается после этого и генерирует ответ токен за токеном, причем каждый новый токен зависит от предыдущих.
В описанном тесте разница между llama.cpp и TensorSharp на prefill оказалась небольшой. Это ожидаемо для крупной пакетной обработки, где GPU получает достаточно работы, а оба рантайма используют аппаратные оптимизации и Flash-Attention.
На decode картина изменилась. TensorSharp показал примерно двукратное преимущество. При коротком ответе пользователь может заметить его слабо, поскольку значительную часть задержки занимает обработка prompt. При генерации длинного текста, программного кода или серии ответов внутри агента разница накапливается с каждым токеном.
Что именно означает результат для пользователя
TensorSharp выглядит привлекательнее для сценариев, где модель долго генерирует ответ после приема контекста. К таким нагрузкам относятся:
- многошаговые AI-агенты;
- локальные coding-сессии с большим числом последовательных действий;
- длинные ответы и генерация документов;
- диалоги, в которых модель постоянно сохраняет большой KV cache;
- локальные AI-системы на нескольких GPU, где каждый лишний служебный расход заметно влияет на итоговую скорость.
Для больших документов, RAG-запросов и частых коротких ответов важнее может оказаться prefill и время до первого токена. Здесь преимущество TensorSharp не следует оценивать по показателю decode в отрыве от общей задержки.
Почему GLM-5.3-Flash особенно интересна для такого сравнения
GLM-5.3-Flash описывают как мультимодальную модель, ориентированную на эффективное программирование и длинные агентные задачи. Ее профиль хорошо подходит для теста inference-движков: модель должна работать с большими контекстами, выполнять сложные цепочки операций и сохранять приемлемую скорость генерации.
В описаниях семейства GLM-5.3 упоминается гибридная архитектура с разреженным и линейным attention. Такой подход помогает обрабатывать длинный контекст с меньшими вычислительными затратами, но создает неоднородную нагрузку для GPU. Runtime должен эффективно выполнять крупные матричные операции, маршрутизацию токенов и множество небольших обращений к данным.
MoE: много параметров, но не все активны одновременно
MoE, или Mixture of Experts, разделяет модель на набор экспертов. Для каждого токена механизм routing выбирает часть экспертов, поэтому в конкретном шаге участвует лишь доля всех параметров.
В опубликованной конфигурации GLM-5.3 Int4-Int8Mix указаны 743 млрд общих параметров и около 40 млрд активных параметров MoE. Для оценки скорости это различие принципиально. Объем файла модели и требования к памяти не дают точного ответа на вопрос о скорости генерации: runtime должен учитывать активные эксперты, обмен данными и способ распределения слоев между GPU.
MoE повышает требования к планировщику операций. После выбора экспертов токены нужно направить в соответствующие блоки, выполнить вычисления и собрать результат обратно. На каждом decode-шаге объем работы для одного токена небольшой, поэтому стоимость маршрутизации и отдельных запусков kernels становится заметной.
Hybrid attention и длинный контекст
Сочетание sparse attention и linear attention меняет поведение модели по мере роста context depth. Короткий prompt и запрос на десятки тысяч токенов создают для GPU разные профили нагрузки.
В материалах по GLM-5.3 Int4-Int8Mix attention переводится в FP8 вместо BF16. Это уменьшает footprint и освобождает место под KV pool. Для serving длинных контекстов такой подход помогает эффективнее расходовать память, однако сам по себе не гарантирует линейную скорость decode.
В MoE-конфигурациях квантуются прежде всего крупные экспертные блоки. Routing, indexer и head могут оставаться в более высокой точности. Такой баланс сохраняет качество критичных операций, но оставляет runtime задачу быстро организовывать смешанный набор вычислений для каждого токена.
Как читать benchmark GLM-5.3-Flash GGUF
Этот результат стоит воспринимать как практическое сравнение двух движков в одинаковых условиях. Он показывает поведение конкретной модели в конкретной конфигурации, а не универсальный рейтинг inference-рантаймов.
Для более широкого контекста полезно сопоставить его с отдельным сравнением TensorSharp и llama.cpp на моделях Gemma 4 и Qwen 3.6, где отдельно измерялись prefill, decode и TTFT: практический разбор производительности TensorSharp на CUDA и Vulkan.
Почему одинаковый n_ubatch важен
Параметр n_ubatch задает размер микропакета, который runtime обрабатывает за один проход. Он влияет на загрузку GPU, потребление памяти, пропускную способность и задержку.
Если запускать llama.cpp и TensorSharp с разными значениями n_ubatch, результат может отражать различия в настройках, а не преимущества самого движка. Одинаковый параметр делает сравнение корректнее: оба рантайма получают близкий баланс между размером вычислительной порции и служебными расходами.
При этом одинаковый n_ubatch не устраняет все различия. На итог влияют распределение слоев по GPU, версия backend, реализация kernels, объем доступной памяти и параметры квантования.
Зачем учитывать warm cache
Warm cache означает, что тест выполняется после подготовки основных структур и прогрева вычислительного пути. Время первой компиляции, загрузки и первоначальной инициализации не смешивается с устойчивой скоростью повторных шагов.
Это условие особенно важно для decode. Если TensorSharp повторно использует скомпилированный граф, эффект проявляется после подготовки этого графа. Такой замер хорошо описывает длинную сессию или стабильную серверную нагрузку, но не показывает полную цену холодного старта.
Для пользовательского приложения полезно измерять оба режима: время запуска и скорость после прогрева. Сервис с редкими запросами может сильнее зависеть от инициализации, тогда как постоянно работающий локальный сервер быстрее окупает подготовительные расходы.
Prefill и decode: две разные задачи для GPU
Что происходит на этапе prefill
Во время prefill модель получает prompt целиком или крупными порциями. Она обрабатывает входную последовательность, вычисляет представления токенов и записывает ключи и значения attention в KV cache.
Такой режим лучше использует параллелизм GPU. В вычислениях участвует много токенов, матричные операции получают крупные размеры, а стоимость отдельных запусков kernels распределяется по большому объему работы.
Поэтому llama.cpp и TensorSharp могут показывать близкий prefill даже при различиях во внутренней организации графа. Flash-Attention уменьшает объем промежуточных обращений к памяти, а крупный prompt создает достаточно плотную нагрузку для обоих движков.
На практике prefill определяет задержку до первого токена. Для RAG-системы с большим документом, длинной системной инструкцией или историей диалога этот этап может занимать значительную часть полного времени ответа.
Почему decode чувствительнее к накладным расходам
Decode работает иначе. На каждом шаге модель получает новый токен, обращается к уже накопленному KV cache и вычисляет следующий. Шаги идут последовательно, поэтому параллелизм ограничен зависимостью между токенами.
Объем полезной работы на одной итерации меньше, чем при обработке длинного prompt. На этом фоне заметнее становятся запуск kernels, планирование операций, синхронизация и передача небольших блоков данных.
Если runtime заранее подготовил повторяющуюся последовательность вычислений, каждая итерация тратит меньше времени на служебные действия. Поэтому одинаковый prefill может сочетаться с большим разрывом на decode.
Откуда берется двукратное преимущество TensorSharp на decode
Повторное использование скомпилированного графа
При последовательной генерации структура вычислений во многом повторяется. Меняется состояние KV cache и входной токен, но общий порядок операций остается близким.
TensorSharp использует повторное обращение к скомпилированному графу. Runtime заранее готовит представление вычислений, а затем применяет его на следующих decode-шагaх. Это снижает долю работы, которая не создает новый токен напрямую: повторную подготовку операций, согласование структуры графа и часть служебного планирования.
На prefill граф обычно работает с меняющимися размерами и крупными пакетами, поэтому повторное использование не обязательно дает такой же эффект. Decode, напротив, состоит из длинной серии похожих шагов и лучше подходит для фиксации вычислительного пути.
Что дает CUDA capture
CUDA capture позволяет зафиксировать последовательность GPU-команд и затем воспроизводить ее с меньшими накладными расходами. Для регулярного decode это полезно: вместо повторной подготовки близкого набора команд GPU получает заранее записанный путь выполнения.
Эффект зависит от стабильности shapes, состояния cache и конкретного CUDA backend. Если длина последовательности, размер батча или набор операций часто меняются, захваченный граф может потребовать перестройки. Тогда преимущество сокращается или исчезает.
В описанном сравнении CUDA capture вместе с повторным использованием скомпилированного графа объясняет примерно двукратный разрыв TensorSharp на decode. Это техническое объяснение измеренного результата, а не обещание такого же коэффициента для любой модели, версии драйвера или GPU.
Почему на длинном контексте decode может проседать не линейно
Цепочка небольших операций важнее простого объема памяти
Рост context depth увеличивает объем данных, к которым обращается модель. При этом скорость может снижаться скачком, а не плавно пропорционально длине контекста.
В обсуждениях llama.cpp описан отдельный кейс на другой модели и платформе: на коротких prompt decode держался примерно на уровне 19-21 токена в секунду, а после глубины около 1024 токенов падал примерно до 6 токенов в секунду и ниже. При глубине 45K в том же отчете приводилось значение около 4,6 токена в секунду.
Эти цифры не относятся напрямую к основному сравнению GLM-5.3-Flash. Они показывают тип поведения, который нужно учитывать при тестах long context.
Резкий провал связывали с цепочкой sparse attention, QSA indexer и небольших per-token gather operations. Память при этом оставалась в нормальном состоянии, поэтому причина не сводилась к swap, переполнению VRAM или thrashing.
Почему MoE и routing усложняют профиль нагрузки
В MoE каждый токен проходит через выбранный набор экспертов. Runtime должен выполнить routing, найти нужные блоки, организовать обращения к памяти и собрать результаты. При длинном контексте такие операции повторяются для каждого нового токена на фоне растущего KV cache.
Смешанная точность добавляет еще один фактор. Крупные experts могут храниться в Int4, dense-части и attention, в Int8, а routing, indexer и head оставаться в полной точности. Такая схема уменьшает размер весов, но не удаляет небольшие служебные операции из критического пути decode.
Для движка это означает необходимость хорошо работать с неоднородной нагрузкой. Теоретическая экономия от разреженности может частично теряться, если GPU тратит много времени на последовательность коротких обращений к данным.
Prefill тоже зависит от глубины контекста
Длинный контекст влияет на обе стадии inference. Prefill должен обработать новые входные токены и заполнить соответствующие структуры KV cache, поэтому его скорость тоже может снижаться с ростом глубины.
Разница состоит в характере симптома. Для prefill чаще растет время обработки входа и задержка до первого токена. Для decode пользователь видит скорость последующей генерации, а резкий спад generation rate способен сделать длинную сессию заметно менее удобной.
При сравнении рантаймов нужно фиксировать глубину контекста и измерять обе метрики. Один движок может быстрее принимать большие prompt, другой, как в описанном тесте, эффективнее генерировать длинный ответ.
Кому есть смысл выбирать TensorSharp, а кому достаточно llama.cpp
Длинные ответы, агенты и локальные AI-системы
TensorSharp стоит рассматривать для CUDA-конфигураций, где главная нагрузка приходится на длительный decode. Примером служит coding-агент: он получает задачу, читает файлы, формирует план, пишет код, анализирует результат и запускает следующий шаг. Каждый этап может требовать нового ответа, поэтому ускорение последовательной генерации сокращает суммарное время цикла.
Похожая картина возникает в длинных диалогах и при генерации больших документов. Если prompt уже находится в KV cache, дальнейшее время в основном зависит от скорости decode. Здесь двукратная разница может ощущаться сильнее, чем близкие показатели prefill.
TensorSharp интересен и владельцам локальных AI-серверов с несколькими GPU, но переносить результат на такую систему нужно через собственный замер. Распределение слоев, межGPU-обмен и доступная пропускная способность могут изменить соотношение между рантаймами.
Практические особенности TensorSharp и его поведение на CUDA и Vulkan разобраны в отдельном сравнении GGUF-инференс-движков.
Когда важнее ускорить prefill
llama.cpp может оставаться рациональным выбором, если рабочий процесс состоит из больших входных данных и коротких ответов. Это типично для RAG, суммаризации документов, проверки больших системных инструкций и запросов, где пользователю нужен один короткий результат.
В таких сценариях важнее время до первого токена и общая задержка запроса. Примерная формула выглядит так: полное время ответа складывается из prefill, паузы до первого токена и последующего decode. Ускорение последней части не компенсирует медленную обработку огромного prompt, если ответ состоит из нескольких токенов.
llama.cpp сохраняет практическую ценность как универсальный ориентир для запуска GGUF. При выборе в его пользу могут работать зрелость экосистемы, широкий охват backend и предсказуемое поведение в конфигурациях, где TensorSharp не тестировался.
Для многGPU-сценариев с GLM полезно учитывать и сетевые, и программные узкие места. Отдельный разбор запуска GLM-5.2 на 16 AMD MI50 показывает, насколько сильно итоговую скорость могут определять RPC, распределение модели, память и поведение backend: тесты GLM на многопроцессорной конфигурации.
Ограничения сравнения и что нужно проверить перед переносом результата
Какие параметры меняют итоговый benchmark
Перед собственным сравнением нужно зафиксировать:
- точную версию GLM-5.3-Flash и формат GGUF;
- уровень квантования и параметры сборки модели;
- CUDA backend и версии программного стека;
- модель GPU и объем доступной VRAM;
- число GPU и распределение слоев;
- размер контекста и текущую глубину сессии;
- значение
n_ubatch; - состояние cache, cold или warm;
- режим Flash-Attention;
- отдельные значения prefill, TTFT и decode.
Сравнивать нужно одинаковые сценарии. Для prefill подойдет набор prompt с фиксированной длиной. Для decode нужен одинаковый контекст, одинаковая длина ответа и одинаковый режим потоковой генерации. Иначе максимальный показатель токенов в секунду может скрыть реальную задержку для пользователя.
Платформа тоже меняет результат. Специализированные kernels для CUDA, Vulkan, ROCm или Metal используют разные пути выполнения. Даже внутри одной категории GPU оптимальные параметры Flash-Attention могут отличаться между поколениями устройств.
Итог: выбирать нужно под профиль нагрузки
В описанной конфигурации TensorSharp примерно вдвое быстрее llama.cpp на decode GLM-5.3-Flash. Преимущество связывают с повторным использованием скомпилированного графа и CUDA capture. На prefill рантаймы показывают близкие результаты.
TensorSharp логичнее проверять там, где модель долго генерирует ответ, работает внутри агента или обслуживает серию последовательных запросов. llama.cpp остается сильным вариантом для универсального запуска GGUF, больших входных prompt и систем, где важны совместимость и широкий выбор backend.
Перед переносом результата на другой компьютер нужно повторить benchmark с тем же квантованием, размером контекста, n_ubatch, режимом Flash-Attention и состоянием cache. Показатель decode дает полезный ориентир, но окончательный выбор определяет профиль нагрузки: объем prefill, длительность генерации, частота запросов и конфигурация GPU.