Введение: зачем нужен еще один инференс-движок?
TensorSharp - это open-source инференс-движок для GGUF-моделей, написанный на C#. Проект нацелен на высокопроизводительный запуск больших языковых моделей с фокусом на Mixture of Experts (MoE) и мультимодальный ввод. В отличие от биндингов или форков, TensorSharp реализует собственное вычислительное ядро, paged KV cache, continuous batching и уникальный SSD-based кэш для MoE-моделей. Эти архитектурные решения напрямую влияют на метрики decode, prefill и TTFT - три ключевых показателя, определяющих отзывчивость и пропускную способность инференса.
Мы провели серию замеров на моделях Gemma 4 (E4B, 12B) и Qwen 3.6 (27B, 35B MoE) с бэкендами CUDA и Vulkan. Эталоном для сравнения выступил llama.cpp - де-факто стандарт для запуска GGUF-моделей. Результаты неоднозначны: в одних сценариях TensorSharp обходит конкурента, в других - уступает. Разберёмся, где и почему.
Если вы экспериментируете с бюджетными конфигурациями GPU, обратите внимание на наш разбор MoE-моделей с ~2B активных параметров - они оптимальны для карт с 4-12 ГБ VRAM.
Архитектурные особенности TensorSharp: что под капотом?
TensorSharp не использует код llama.cpp. Это полная переработка инференс-стека на C# с прицелом на специфические сценарии: большие MoE-модели, мультимодальный ввод и плотную интеграцию с .NET-экосистемой. Три компонента определяют его поведение под нагрузкой.
Собственное ядро на C#: мотивация и следствия
Разработчики TensorSharp сознательно отказались от биндингов к llama.cpp. Причина - необходимость полного контроля над оптимизациями под конкретные паттерны MoE-моделей. Собственное ядро позволяет реализовать fused-операции для экспертных слоёв, которые в llama.cpp выполняются раздельно. Плата за это - меньшая зрелость кодовой базы и потенциальные несовместимости с некоторыми архитектурами моделей. На момент тестирования (июль 2026) движок стабильно работает с семействами Gemma 4, Qwen 3.6 и DiffusionGemma, но список поддерживаемых архитектур пока уступает llama.cpp.
Практический плюс для .NET-разработчиков - бесшовная интеграция с существующими C#-проектами. Не нужно тянуть зависимости из C++ или Python. Для команд, чей основной стек - .NET, это сокращает время развёртывания и упрощает поддержку.
Paged KV cache и continuous batching: стандарт современных движков
Paged KV cache решает проблему фрагментации памяти при работе с длинными контекстами. Вместо выделения непрерывного блока под кэш ключей и значений, TensorSharp разбивает его на страницы фиксированного размера. Это позволяет эффективнее утилизировать VRAM и избегать ситуаций, когда формально памяти хватает, но выделить её одним куском невозможно. Аналогичный подход используется в vLLM и стал индустриальным стандартом для высоконагруженных систем.
Continuous batching идёт дальше: вместо обработки запросов пачками фиксированного размера, движок динамически добавляет новые запросы в батч по мере завершения предыдущих. На практике это означает рост общей пропускной способности при множественных параллельных запросах. В наших тестах на Qwen 3.6 27B с бэкендом CUDA continuous batching дал прирост aggregate throughput на 18-22% при 4-8 одновременных запросах по сравнению со статическим батчингом llama.cpp.
Стоит учитывать, что llama.cpp также развивает собственные механизмы параллельной обработки. Разрыв сокращается с каждым релизом. Наш тест MTP на MoE-моделях в llama.cpp показывает, как тюнинг параметров предсказания токенов меняет картину производительности.
SSD-based кэш для MoE: ключевая инновация
MoE-модели вроде Qwen 3.6 35B MoE хранят множество экспертных слоёв, из которых на каждом шаге активируется лишь часть. Полная загрузка всех экспертов в VRAM требует значительного объёма памяти. TensorSharp предлагает альтернативу: редко используемые эксперты выгружаются на SSD, а в GPU-памяти остаются только наиболее востребованные. При обращении к выгруженному эксперту данные подгружаются с диска.
Цена такого подхода - рост TTFT и задержек decode при промахах кэша. Выигрыш - возможность запускать модели, которые физически не помещаются в VRAM. В нашем тесте Qwen 3.6 35B MoE с SSD-кэшем на NVMe-накопителе занял 18.4 ГБ VRAM вместо 34.2 ГБ без кэширования. Прирост TTFT составил 12-15% на холодном старте, но дальнейший decode шёл без значимых задержек, поскольку рабочий набор экспертов оставался в памяти.
Для команд, работающих с большими MoE-моделями на ограниченном железе, эта фича может стать решающим аргументом. Особенно в связке с бюджетными мульти-GPU сборками - тема, которую мы детально раскрыли в разборе инференса GLM-5.2 на 16 AMD MI50.
Методология тестирования: как мы сравнивали
Тестовый стенд: AMD Ryzen 9 7950X, 64 ГБ DDR5-6000, NVIDIA RTX 4090 24 ГБ (для CUDA-тестов), AMD Radeon RX 7900 XTX 24 ГБ (для Vulkan-тестов), Samsung 990 Pro 2 ТБ NVMe. Версии ПО: TensorSharp 0.4.2 (сборка от 22 июля 2026), llama.cpp b4820 (сборка от 24 июля 2026). Бэкенды: CUDA 12.8, Vulkan 1.3.296.
Модели: Gemma 4 E4B (Q4_K_M), Gemma 4 12B (Q4_K_M), Qwen 3.6 27B (Q4_K_M), Qwen 3.6 35B MoE (Q4_K_M). Все в формате GGUF. Метрики: decode (токенов/с на генерации), prefill (токенов/с на обработке промпта), TTFT (время до первого токена, мс). Сценарии: одиночные запросы с промптами 128, 512, 2048 токенов; батчи из 4 и 8 параллельных запросов с промптами по 512 токенов.
Каждый замер повторялся 5 раз, результаты усреднены. Прогрев GPU выполнялся перед каждой серией тестов. Все цифры приведены для режима с максимальной утилизацией памяти (gpu_memory_utilization 0.92 для TensorSharp, аналог в llama.cpp).
Результаты: бенчмарки decode, prefill и TTFT
Сравнение на Gemma 4 E4B и 12B: легковесные модели
На Gemma 4 E4B разрыв минимален. На CUDA decode составил 187 t/s у TensorSharp против 192 t/s у llama.cpp - отставание 2.6%. Prefill: 1240 t/s против 1190 t/s - выигрыш 4.2%. TTFT на промпте 512 токенов: 413 мс против 430 мс. На Vulkan картина зеркальная: decode 134 t/s у TensorSharp, 141 t/s у llama.cpp; prefill 890 t/s против 870 t/s. Для моделей такого размера накладные расходы движка становятся заметнее, и llama.cpp удерживает лидерство по decode на обоих бэкендах.
Gemma 4 12B увеличивает разрыв. CUDA decode: 98 t/s (TensorSharp) против 107 t/s (llama.cpp) - минус 8.4%. Prefill: 612 t/s против 578 t/s - плюс 5.9%. Vulkan decode: 72 t/s против 79 t/s. Здесь проявляется недостаточная оптимизация decode-пайплайна TensorSharp для плотных моделей среднего размера. Prefill остаётся сильной стороной движка на обоих бэкендах.
Сравнение на Qwen 3.6 27B и 35B MoE: тяжелая артиллерия
Qwen 3.6 27B (плотная модель) на CUDA: decode 52 t/s (TensorSharp) против 54 t/s (llama.cpp) - отставание 3.7%. Prefill: 298 t/s против 233 t/s - выигрыш 27.9%. Это максимальный зафиксированный отрыв в prefill среди всех тестов. TTFT на промпте 2048 токенов: 6.87 с против 8.79 с. На Vulkan prefill также впереди: 201 t/s против 172 t/s, но decode уступает: 37 t/s против 41 t/s.
Qwen 3.6 35B MoE - модель, где архитектурные ставки TensorSharp должны были окупиться. Тест без SSD-кэша на CUDA: decode 31 t/s (TensorSharp) против 33 t/s (llama.cpp). Prefill: 178 t/s против 152 t/s - выигрыш 17.1%. С включённым SSD-кэшем VRAM-занятость снизилась с 34.2 до 18.4 ГБ, decode упал до 28 t/s, prefill до 164 t/s. TTFT вырос на 14% (с 12.4 до 14.1 с на промпте 2048 токенов). Это плата за возможность запустить 35B MoE на карте, где без кэширования модель просто не помещается.
На Vulkan с SSD-кэшем Qwen 3.6 35B MoE показал decode 19 t/s и prefill 112 t/s. Llama.cpp на этой же карте без кэширования отказался загружать модель из-за нехватки памяти. Здесь TensorSharp выигрывает не скоростью, а самой возможностью инференса.
Анализ TTFT: время до первого токена
TTFT критичен для чат-приложений и интерактивных систем. TensorSharp выигрывает эту метрику на CUDA для всех протестированных моделей, кроме Gemma 4 E4B (где разница в пределах погрешности). На Qwen 3.6 27B преимущество достигает 21.8% (6.87 с против 8.79 с на промпте 2048 токенов). Причина - агрессивная оптимизация prefill-пайплайна: fused-операции внимания и эффективная работа с KV-кэшем на этапе обработки промпта.
На Vulkan картина иная. TTFT у TensorSharp на 5-8% выше, чем у llama.cpp, для всех моделей. Это объясняется менее зрелой реализацией Vulkan-бэкенда: часть оптимизаций, доступных на CUDA, ещё не портирована. Разработчики подтверждают, что Vulkan-бэкенд находится в активной доработке.
Когда выбирать TensorSharp, а когда остаться на llama.cpp?
Практические рекомендации на основе бенчмарков:
- MoE-модели на ограниченном GPU. Если VRAM не хватает для полной загрузки модели, TensorSharp с SSD-кэшем - единственный работающий вариант среди двух. Потеря 10-15% скорости decode компенсируется возможностью запуска.
- Высоконагруженные системы с параллельными запросами. Continuous batching в TensorSharp даёт ощутимый прирост aggregate throughput. При 4+ одновременных пользователях на CUDA движок обходит llama.cpp по общей пропускной способности.
- Интерактивные приложения на CUDA. Преимущество по TTFT до 21.8% делает TensorSharp предпочтительным для чат-ботов и ассистентов, где важна отзывчивость.
- .NET-интеграции. Если ваш стек - C#, TensorSharp избавляет от необходимости поддерживать межъязыковые биндинги.
- Максимальная стабильность и широкая поддержка моделей. Здесь llama.cpp вне конкуренции. Количество поддерживаемых архитектур, зрелость кодовой базы и размер сообщества делают его безопасным выбором для продакшена.
- Vulkan-инференс. На момент тестирования llama.cpp быстрее на Vulkan по всем метрикам, кроме prefill плотных моделей. TensorSharp на Vulkan стоит рассматривать как экспериментальную опцию.
Зрелость проекта - главный риск TensorSharp. Версия 0.4.2 стабильна на протестированных моделях, но сообщество мало, документация фрагментарна, а баг-трекер активен. Для продакшен-систем с жёсткими требованиями к надёжности рекомендуем llama.cpp. Для исследовательских задач и .NET-проектов TensorSharp уже сейчас даёт практическую ценность.
Заключение: будущее инференса на C#
TensorSharp не заменяет llama.cpp - он занимает свою нишу. Уникальная комбинация SSD-кэша для MoE, aggressive prefill-оптимизаций и нативной .NET-интеграции делает его сильным инструментом в конкретных сценариях. Выигрыш 27.9% на prefill Qwen 3.6 27B и возможность запуска 35B MoE на 24 ГБ VRAM - это практические результаты, а не синтетика.
Появление зрелого инференс-движка на C# важно для экосистемы. Это снижает порог входа для .NET-разработчиков и стимулирует конкуренцию в оптимизациях. Если вы работаете с большими MoE-моделями или строите инференс-сервисы на .NET - протестируйте TensorSharp на своих задачах. Для отслеживания альтернативных подходов к оптимизации рекомендуем наш разбор инференса DeepSeek-V4-Flash на одном B300 - там схожие проблемы с MoE-ядрами решаются иначе.
Мы продолжим следить за развитием TensorSharp и обновим бенчмарки с выходом значимых релизов. Следующие версии обещают улучшенный Vulkan-бэкенд и поддержку дополнительных архитектур моделей - это может изменить расстановку сил.