Большая LLM на маленькой видеокарте. KTransformers на RTX 5060 Ti 16 ГБ - впихнуть не впихуемое

Железо

16 ГБ VRAM - это не про «запустить всё на видеокарте». Это про умный оффлоад: что-то на GPU, что-то на CPU, что-то на диске. И вот тут KTransformers реально вывозит.

Почему KTransformers, а не всё остальное

Если коротко - KTransformers (sglang-kt + kt-kernel) умеет то, чего не умеют классические движки: динамическое распределение экспертов MoE-моделей между GPU и CPU.

Сначала я гонял эту же модель на llama.cpp - и вот тут самое интересное. Она распределяет экспертов по-другому: кладёт в VRAM «каких попало», по номерам слоёв, а не по частоте использования. То есть какие эксперты реально нужны роутеру - она не знает и не пытается узнать. Наработки с ротацией горячих экспертов там вроде есть, но пока сырые и толком не работают. KTransformers - это ровно тот случай, когда настройка по-умному даёт +50-100% к скорости.

У MoE-модели (например, Qwen3.6-35B) есть 256 «экспертов» - маленьких нейросетей, из которых для каждого токена роутер выбирает только 8-10 активных. Вся модель 35B, но активно работают только ~3B. Именно поэтому её вообще реально гонять на домашнем железе.

Вопрос - где держать экспертов. Грубо:

• Uniform / статично: при старте кладём N первых экспертов в VRAM и не трогаем. Просто, но не оптимально - роутер может дёргать экспертов, которые лежат на CPU.
• Frequency + dynamic update: KTransformers следит, какие эксперты реально часто вызывает роутер, и подгружает их на GPU по мере работы, вытесняя неиспользуемых. Горячие эксперты накапливаются в VRAM. Вот это - то, ради чего всё затевалось.

Важно: динамика включается флагом --kt-enable-dynamic-expert-update и стратегией --kt-expert-placement-strategy frequency. Без них вы получите скучную статичную раскладку и не поймёте, зачем вообще мучились с KTransformers.

Какая модель

Остановился на Qwen3.6-27B-A3B-Coder. Это не официальная Qwen3.6-27B (она dense), а community-вариант: из Qwen3.6-35B-A3B через expert pruning (по «карте компетенций» кода) вырезали лишних экспертов - получилось 27B при тех же 3B активных. Код держит уровень учителя, а весит меньше.

KTransformers использует две копии модели: safetensors (оригинальные веса, из них берутся GPU-слои) и GGUF (для CPU-экспертов через LLAMAFILE backend). Обе нужно скачать - это ~74 ГБ суммарно.

Грабля 1: PyTorch под CUDA 12.8

RTX 5060 Ti - Blackwell (sm_120), нужен CUDA ≥ 12.8 и соответствующий PyTorch. Ставим явно из индекса cu128:

python3 -m venv /opt/ktrans/venv
/opt/ktrans/venv/bin/pip install torch --index-url https://download.pytorch.org/whl/cu128
/opt/ktrans/venv/bin/pip install kt-kernel sglang-kt

Грабля 2: CuDNN и ninja

sglang ругался на старый CuDNN и требовал ninja для JIT-компиляции KV-кэш ядра. Без ninja сервер падал с FileNotFoundError: 'ninja' при первом запросе.

/opt/ktrans/venv/bin/pip install nvidia-cudnn-cu12==9.16.0.29
sudo apt install -y ninja-build

Грабля 3: triton backend обязателен

Для гибридных GDN-моделей на Blackwell sglang без явного указания падает с AssertionError про hybrid. Лечится одной опцией:

--attention-backend triton

Квантование: почему Q6_K_L, а не CD-IQ4_K_M

Тут я словил самую противную граблю. Автор модели рекомендует CD-IQ4_K_M (~16 ГБ) как оптимальный квант с полным код-качеством. Я его скачал, запустил - и модель начала выдавать мусор:

"matched_stop": "NaN happened"

Численная нестабильность на Blackwell. IQ4-семейство на sm_120 глючит - это не баг модели, а проблема CUDA-ядер. Перешёл на Q6_K_L (21 ГБ, imatrix) - работает стабильно, качество даже лучше. Вывод: на 5060 Ti берите Q6 или выше, IQ-кванты не трогайте.

Память: что и где живёт

Гибридная модель хранит два типа «памяти контекста» - это важно понимать:

KV и Mamba-кэши выделяются сразу на максимум контекста при старте (не растут по мере беседы). Если сервер поднялся без OOM - дальше он стабилен, длинный диалог нагрузку не добавит.

Только не складывайте цифры из таблицы - в сумме выйдет больше VRAM, чем есть. Это выделенные максимумы: кэши и часть тензоров живут в VRAM не целиком, что не помещается - sglang сбрасывает в RAM. Поэтому реально занято ~12 ГБ из 16.3, и свободных остаётся ~4 ГБ.

Ключевая настройка памяти: mem-fraction-static

Вот тут я прошёл через весь диапазон значений, чтобы вы не делали то же самое. Логика «поставлю побольше - больше места под экспертов» оказалась неверной:

Почему так: при большом mem-fraction sglang агрессивно резервирует VRAM под внутренние буферы (cuda graph, промежуточные тензоры), и свободного места под динамических экспертов остаётся меньше. При 0.72 - пул поменьше, зато свободных гигов больше. Ниже 0.70 опускаться нельзя: одна модель занимает ~10 ГБ, а 0.70 × 16.3 = 11.4 ГБ - на кэши и буферы почти ничего не остаётся, сервер просто не стартует.

--mem-fraction-static 0.72

Сколько экспертов реально влезает в VRAM

Один эксперт в Q6 занимает ~2.4 МБ. В свободные 4.11 ГБ помещается ~1700 экспертов. Но поставив «на максимум» (--kt-num-gpu-experts 40 = 1600 экспертов), я словил OOM - модель съела 14.9 ГБ и упала:

torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 18.00 MiB

Подбором остановился на 20 экспертов на слой = 800 в VRAM. Это в 10 раз больше, чем дефолтные 80, и при этом стабильно:

--kt-num-gpu-experts 20 --kt-expert-placement-strategy frequency --kt-enable-dynamic-expert-update

Теперь роутер в большинстве случаев попадает в экспертов, которые уже на GPU. Отсюда и рост скорости: ~15 токенов/с на дефолтной раскладке до ~30 после настройки - те самые +100%, о которых говорил выше.

Почему нельзя скинуть KV-кэш в оперативку

Логичный вопрос: освободить VRAM под экспертов, выкинув KV-кэш в RAM. В sglang за это отвечает HiCache (--enable-hierarchical-cache). И вот тут гибридные модели подставили:

ValueError: HiRadixCache only supports MHA and MLA yet

HiCache умеет иерархический кэш только для чистого attention (MHA/MLA). А у Qwen3.6 - Gated DeltaNet (линейное внимание), которое HiCache не умеет адресовать. Так что KV остаётся в VRAM, и это не баг, а архитектурное ограничение. Чтобы KV уехал в RAM, нужна модель с классическим attention (например, Qwen3-30B-A3B) - но у неё знания постарше. Компромисс.

Размышления и тулзы: два парсера, без которых беда

Модель думающая (Qwen3-style, выдаёт <think>...</think>). Без правильного парсера размышления лезут прямо в ответ текстом:

User is just greeting again, keep it brief.
</think>
Привет!

Лечится парсером - размышления уходят в отдельное поле, в UI остаётся чистый ответ:

--reasoning-parser qwen3-thinking

Вторая грабля - тулзы. Модель вместо структурированного вызова функции выдавала текстом <tool_call>. Для coding-модели есть свой парсер:

--tool-call-parser qwen3_coder

Итоговый запуск

Полная команда (у меня она в systemd-сервисе):

/opt/ktrans/venv/bin/python -m sglang.launch_server \
  --host 0.0.0.0 --port 8080 \
  --model /models/qwen3.6-27b-a3b-coder-safetensors \
  --kt-weight-path /models/qwen3.6-27b-a3b-coder/Qwen3.6-27B-A3B-Coder-Q6_K_L.gguf \
  --kt-cpuinfer 6 --kt-threadpool-count 1 \
  --kt-num-gpu-experts 20 \
  --kt-expert-placement-strategy frequency \
  --kt-enable-dynamic-expert-update \
  --kt-method LLAMAFILE \
  --attention-backend triton \
  --trust-remote-code \
  --mem-fraction-static 0.72 \
  --max-running-requests 1 --max-total-tokens 131072 \
  --reasoning-parser qwen3-thinking \
  --tool-call-parser qwen3_coder

Что в итоге

RTX 5060 Ti 16 ГБ + KTransformers + Qwen3.6-27B-A3B-Coder Q6_K_L - рабочая связка для Битрикс-разработчика. 30 токенов/с, 800 экспертов в VRAM, думает и вызывает тулзы, локально и бесплатно. Не серебряная пуля, но рутину реально ускоряет.

Честно говоря, текущая модель для меня - это скорее разведка боем: изучить вопрос, обкатать движок, подготовить машину, чтобы потом не мучиться с настройкой. Уже заказал дополнительные планки ОЗУ (до 64 ГБ), и как только они приедут - пойдут модели посерьёзнее: Ornith-35B, Qwen3.6-35B, а при 96-128 ГБ и Qwen3.5-122B. Тогда и KV-кэш можно будет вынести в оперативку (на MHA-моделях), и контекст разогнать подлиннее. А пока пусть эта 27B отрабатывает своё.