Сборка домашнего сервера для локальных LLM на недорогих GPU NVIDIA CMP 50HX

Всем привет! Меня зовут Александр Щербаков, я DevOps-инженер в X5 Tech. В одной из своих прошлых публикаций я рассказывал о создании домашних серверов на обычном потребительском «железе». Сегодня мы обсудим, как моя лаборатория эволюционировала до полноценной серверной платформы в сочетании с двумя видеокартами CMP 50HX, каждая из которых располагает 20 ГБ видеопамяти.

Я продолжаю осваивать локальные языковые модели (LLM) и спелю поделиться накопленным опытом: от приобретения специфических ускорителей и тернистого пути первого запуска до тонкой настройки сервера и бенчмарков. Всем, кому интересна эта авантюра, добро пожаловать под кат!

Часть 1. С чего всё началось

Итак, что же представляют собой CMP 50HX? Это майнинговые ускорители NVIDIA на графическом чипе TU102, приходящиеся близкими родственниками RTX 2080 Ti, но со своими архитектурными ограничениями. В базовом исполнении они оснащались 10 ГБ VRAM, а те образцы, о которых пойдет речь, изначально имели урезанный интерфейс PCIe. С подробными характеристиками можно ознакомиться в этой спецификации.

После схывания криптовалютного ажиотажа такие графические адаптеры хлынули на вторичный рынок. Когда я подыскивал подходящие варианты, стандартную десятеразовую модификацию отдавали примерно за 5 тысяч рублей. Однако мне на глаза попалась глубоко модифицированная версия: мастер-энтузиаст допаял недостающие компоненты линий PCIe, благодаря чему карта обрела полноценный интерфейс PCIe 1.1 ×16. Более того, объем видеопамяти был увеличен вдвое — до 20 ГБ. Стоимость составила 16 тысяч рублей за штуку.

В июне я приобрел пару таких ускорителей в расчете на суммарные 40 ГБ VRAM. Разумеется, установка двух графических адаптеров в систему не объединяет их память автоматически в единый массив — распределение модели по устройствам приходится настраивать средствами inference-движка.

Спустя неделю заветная посылка прибыла. Продавец оказался честным: каждая карта действительно обладала 20 ГБ видеопамяти и 16 линиями PCIe.

Однако вскоре я столкнулся с аппаратными ограничениями старой платформы. Мой домашний сервер был построен на базе потребительской материнской платы ASRock B460M Pro4. Она оснащена двумя слотами формата ×16, но электрически они функционируют в режимах ×16 и ×4. Первый слот подключен напрямую к процессору, а второй — через чипсет. Иными словами, наличие двух длинных разъемов вовсе не гарантирует одинаковую пропускную способность для пары видеокарт.

При двухкарточной конфигурации наблюдалось серьезное падение производительности. Причиной тому служила как специфика разводки платы, так и особенности самих чипов CMP, подробно разобранные в этих материалах: статья 1 и статья 2. Если говорить коротко, речь идет об урезанных вычислительных возможностях майнинговых решений по сравнению с полноценными потребительскими GPU на базе TU102.

В ходе первых тестов модели успешно помещались в память одной карты, но по мере заполнения контекстного окна начинались сильные задержки. Если короткие запросы обрабатывались сносно, то длинный диалог заставлял себя ждать.

Я экспериментировал с распределением весов между обоими ускорителями и перебирал 4-, 5- и 6-битные квантования, но желаемого прироста скорости не добился. Что именно выступало главным «бутылочным горлышком» — материнская плата, медленный интерфейс PCIe 1.1 или аппаратные ограничения CMP — тогда по отдельности выяснять не стал.

Первая итерация эксперимента оказалась не столь успешной, чтобы оформлять ее в виде статьи, поэтому черновик отправился в долгий ящик. Тем не менее, сама концепция не была заброшена. Я давно поглядывал в сторону серверного «железа»: мне требовалась плата с обилием полноценных линий PCIe и удаленным администрированием через BMC, чтобы избавиться от необходимости подключать монитор напрямую к серверу. Неудачный старт стал отличным стимулом для апгрейда платформы.

В результате была собрана следующая конфигурация:

• Серверная материнская плата TYAN S8030GM2NE, рассчитанная на процессоры EPYC второго и третьего поколений.

• Процессор AMD EPYC 7K62 (б/у) — 48 физических ядер, 96 потоков с тактовой частотой от 2.6 до 3.3 ГГц.

• Оперативная память DDR4-2133 ECC: восемь планок по 16 ГБ, суммарно 128 ГБ. Модули несли на себе маркировку Huawei и чипы Micron. Были приобретены на вторичном рынке ради предсказуемого происхождения без лишней переплаты.

• Серверный NVMe SSD Samsung форм-фактора 22110 емкостью 4 ТБ, также с пробегом (наработка около 3000 часов). При выборе б/у накопителей критически важно анализировать показатели SMART, объем записанных терабайт и наличие сбоев — ориентироваться исключительно на время работы нельзя.

• Модульный блок питания DeepCool мощностью 1200 Вт — куплен новым.

• Башенный кулер ARCTIC Freezer 4U-M Rev. 2 под сокет SP3 в комплекте с корпусными вентиляторами ARCTIC (два на 140 мм и один на 120 мм).

• Корпус Jonsbo N5. В него идеально поместились все комплектующие, а бонусом появилось 12 отсеков под жесткие диски — лаборатория должна расти.

Пару слов о материнской плате: она располагает пятью слотами PCIe 4.0 ×16, поддерживает восемь каналов памяти и оснащена полноценным BMC-модулем с удаленной консолью. Возможности расширения дисковой подсистемы впечатляют: двенадцать портов SATA реализованы через три разъема Mini-SAS HD, плюс еще два распаяны отдельно. Для домашнего стенда это колоссальный шаг вперед по сравнению с предыдущей платой.

Стоковые вентиляторы в корпусе оказались чрезмерно шумными, поэтому я заменил их на вертушки от ARCTIC. Штатные модели использовали трехпиновое подключение без поддержки PWM, а возможность регулировки оборотов за счет изменения напряжения напрямую зависит от возможностей материнской платы.

Часть 2. Разблокировка карт и первые нормальные результаты

Пока я занимался поиском и закупкой комплектующих на барахолках, на дворе стоял сентябрь 2026 года. В процессе серфинга профильных ресурсов я наткнулся на замечательный репозиторий, содержащий патчи для драйверов NVIDIA под Linux. Этот инструмент снимает часть аппаратных ограничений вычислительной подсистемы и позволяет задействовать режим PCIe Gen2 на поддерживаемых экземплярах CMP 50HX.

Я развернул Proxmox, поднял виртуальную машину, пробросил в нее оба графических ускорителя и накатил патчи. Карты наконец заработали в полную силу, что и побудило меня достать черновик из архива. Специальный демон управления питанием (idle-governor) регулирует P-состояния в моменты простоя: в моей конфигурации энергопотребление каждой карты снизилось с 65 до скромных 15–20 Вт. Ниже я продемонстрирую результаты тестов.

Важно разграничивать понятия: 20 ГБ видеопамяти и 16 линий PCIe мои карты получили благодаря аппаратной модификации, в то время как драйверный патч устраняет программные лимиты. Устанавливать его следует строго по инструкции разработчиков, предварительно убедившись в совместимости ревизии видеокарты и версии драйвера.

Сравнение модифицированной CMP 50HX (20 ГБ) с RTX 2080 Ti (22 ГБ)

Для наглядности сопоставим характеристики с кастомной версией RTX 2080 Ti, обладающей 22 ГБ памяти. Оба устройства базируются на одном кристалле семейства Turing (TU102), однако у CMP урезаны вычислительные блоки и сужена шина памяти. Сама RTX в этих тестах участия не принимала.

Характеристика	RTX 2080 Ti (Mod 22 ГБ)	CMP 50HX (Mod 20 ГБ)	Соотношение CMP к 2080 Ti
Графический чип	TU102	TU102	TU102
CUDA-ядра	4352	3584	82.4%
Tensor-ядра	544	448	82.4%
Шина памяти	352-bit (11 чипов по 2 ГБ)	320-bit (10 чипов по 2 ГБ)	90.9%
Пропускная способность памяти	616 ГБ/с (GDDR6 14 Gbps)	560 ГБ/с (GDDR6 14 Gbps)	90.9%
Интерфейс PCIe	Gen3 ×16 (~15.8 ГБ/с)	Gen2 ×16 (до 8 ГБ/с в одном направлении, теорет.)	Около 51% по пропускной способности PCIe
Лимит энергопотребления	250–260 Вт	225 Вт (штатный лимит по nvidia-smi)

Конфигурация тестовой виртуальной машины

Параметр	Текущая ВМ для бенчмарков
Процессор (vCPU)	AMD EPYC 7K62 (8 потоков)
Оперативная память	16 GiB
GPU 0	CMP 50HX, 20480 MiB, PCIe Gen2 ×16
GPU 1	CMP 50HX, 20480 MiB, PCIe Gen2 ×16
Видеодрайвер	NVIDIA 610.43.03 с патчами (установка через DKMS)
Управление питанием	cmp-idle-governor.service

Внутри виртуальной машины я развернул Docker-окружение и запустил BeeLlama.cpp — специализированный форк llama.cpp, оптимизированный для ускорения инференса. В таблице выше фигурируют 8 vCPU и 16 GiB RAM. На этапе первичных замеров ВМ выделялось 16 vCPU и 32 GiB, поэтому старые отчеты и контрольные прогоны подписаны отдельно.

Справочная терминология

Чтобы избежать путаницы в дальнейшем: prefill — стадия первичной обработки входного текста, decode — этап генерации новых токенов. В тестах с динамически растущим контекстом значительная часть входящего промпта уже кеширована, а метрика grow prefill отражает обработку лишь вновь добавленного фрагмента. Следовательно, по ней нельзя судить о времени первоначальной загрузки документа с нуля.

Размеры контекста выражаются в токенах: 32K эквивалентно 32768, а 256K — 262144. Значение 260000 находится чуть ниже максимального предела окна. Потребление видеопамяти фиксируется через nvidia-smi в мебибайтах (MiB), где 1024 MiB равны 1 GiB. Учитывается объем VRAM, зарезервированный серверным процессом, а не размер весов модели на диске.

Часть 3. Тестирование языковых моделей

Конфигурационные файлы, скрипты запуска и сырые данные тестов выложены в моем репозитории на GitLab. Ознакомление стоит начать с инструкции в current/README.md, где подготовлены шаблоны Compose и примеры .env для каждой модели. Наборы бенчмарков находятся в директории benchmarks/README.md, а сводные таблицы сведены в BENCHMARKS.md.

Изначально модели запускались в базовом режиме, после чего активировалась функция Multi-Token Prediction (MTP). Суть технологии проста: компактный модуль предсказания генерирует гипотетическое продолжение, а основная нейросеть валидирует его за один проход. Если прогнозы подтверждаются, скорость генерации заметно возрастает. Однако верификация тоже требует ресурсов, поэтому оптимальную глубину MTP пришлось подбирать экспериментально.

Qwen3.8-27B IQ4_NL: первые замеры на одиночной карте

Базовый режим (без MTP)

• Контекстное окно сервера: 131208 (чуть более 128K)

• KV Cache: квантование q4_0 / q4_0

• Занято VRAM: 18223 MiB / 20480 MiB (свободный остаток: 2257 MiB)

• Все пять контрольных точек пройдены без ошибок. В этом и последующих тестах с IQ4_NL контекст заполнялся повторяющейся последовательностью токенов. Подобный стресс-тест наглядно демонстрирует деградацию производительности по мере заполнения кеша (при работе с реальными документами показатели могут отличаться).

Фактический контекст	Grow prefill (ток/с)	Decode (ток/с)
4096	116.62 (весь промпт)	26.47
32768	541.01	20.81
65536	396.59	16.90
98304	308.73	14.06
131072 (128K)	252.46	12.14

С активированным MTP: draft-n-max 1

Фактический контекст	Без MTP (ток/с)	С MTP (ток/с)	Прирост производительности
4096	26.47	41.61	+57.2%
32768	20.81	33.45	+60.7%
65536	16.90	27.48	+62.6%
98304	14.06	23.28	+65.6%
131072 (128K)	12.14	20.21	+66.5%

На предельных 131072 токенах скорость генерации с MTP составила 20.21 токена/с против 12.14 в базовом режиме, что обеспечило прирост примерно на 66.5%. Для одиночной видеокарты результат оказался вполне приемлемым.

Qwen3.6-35B-A3B: оценка IQ4_NL на одной и двух картах

Модель: Qwen3.6-35B-A3B-UD-IQ4_NL.gguf

Перед нами архитектура Mixture of Experts (MoE): суммарный объем модели составляет около 35 млрд параметров, однако на обработку каждого токена привлекается лишь небольшая их часть. Конфигурация включает 40 основных слоев, 256 маршрутизируемых экспертов (из которых для каждого токена активируются восемь) и один общий эксперт. Посмотрим, как это отражается на скорости и потреблении памяти.

Короткий прогон: 1 и 2 GPU, с MTP и без него

Режим / Конфигурация	VRAM GPU 0	VRAM GPU 1	Decode (ток/с)	Успешность драфтов	Cold prefill (ток/с)
1 GPU Base (без MTP)	17513 MiB	0 MiB	93.36 ± 0.12	—	1375.37
1 GPU MTP (depth 1)	17681 MiB	0 MiB	120.32 ± 0.02	96.9% (186/192)	1228.41
2 GPU Base (split-mode layer)	8789 MiB	9049 MiB	93.38 ± 0.02	—	1372.99
2 GPU MTP (split-mode layer)	8825 MiB	9239 MiB	118.01 ± 0.17	96.9% (186/192)	1231.01

Результаты для квантования IQ4_NL

В коротком тесте на единственном ускорителе модель выдала 93.36 токена/с без MTP и 120.32 с активированным предиктивным модулем. Доля принятых предсказаний составила 96.9% (186 из 192).

С включенным MTP занятый объем VRAM составил 17681 MiB из доступных 20480 MiB, оставив в резерве 2799 MiB. Таким образом, для коротких сценариев одной карты вполне достаточно.

В двухкарточной конфигурации распределение памяти составило 8825 и 9239 MiB соответственно. Производительность зафиксирована на уровне 118.01 токена/с, что практически идентично показателю одиночной карты. Посмотрим, как проявится этот запас по памяти при масштабировании контекста.

IQ4_NL: стресс-тест с нарастающим контекстом

Две GPU: масштабирование до 260000 токенов (split-mode layer)

Контекст (токены)	Без MTP (ток/с)	С MTP (ток/с)	Прирост MTP	Принято драфтов	Grow prefill (ток/с)	VRAM GPU 0 / GPU 1
32768 (32K)	68.19	94.60	+38.7%	100% (31/31)	482.8	10988 / 11222 MiB
65536 (64K)	52.67	79.78	+51.5%	100% (31/31)	1770.5	11035 / 11412 MiB
131072 (128K)	36.39	60.94	+67.5%	100% (31/31)	1184.5	11210 / 11805 MiB
196608 (192K)	27.52	49.33	+79.3%	100% (31/31)	816.4	11390 / 12180 MiB
260000 (~253.9K)	22.32	41.64	+86.6%	100% (31/31)	623.4	11650 / 12893 MiB

В этой серии испытаний эффективность MTP возрастает пропорционально заполнению контекста: прирост поднимается с 38.7% на 32768 токенах до внушительных 86.6% на 260000 токенах, обеспечивая скорость генерации на уровне 41.64 токена/с.

Одна GPU: масштабирование до 192000 токенов

Контекст (токены)	Без MTP (ток/с)	С MTP (ток/с)	Прирост MTP	Принято драфтов	Grow prefill (ток/с)	VRAM GPU 0 (из 20480 MiB)
4096 (4K)	90.37	116.48	+28.9%	100% (31/31)	~1300	17680 MiB
32768 (32K)	66.51	95.84	+44.1%	100% (31/31)	1843.1	18120 MiB
65536 (64K)	50.72	78.83	+55.4%	100% (31/31)	1267.4	18590 MiB
131072 (128K)	34.54	59.62	+72.6%	100% (31/31)	844.4	19180 MiB
192000 (187.5K)	26.62	48.38	+81.7%	100% (31/31)	589.4	19765 MiB (остаток 715 MiB)

Одиночная карта или связка из двух?

На 32768 токенах с включенным MTP одиночный ускоритель выдал 95.84 токена/с, а тандем из двух карт — 94.60 токена/с (практически паритет). Вторая видеокарта выступает в первую очередь гарантом достаточного объема памяти под длинный контекст, а не средством линейного ускорения генерации одного ответа.

На одной карте мне удалось дойти до 192000 токенов, причем в резерве оставалось всего 715 MiB. В двухкарточной системе на 260000 токенах было занято 11650 и 12893 MiB, что оставляло куда более комфортный запас. Мониторить необходимо обе карты, поскольку избыток памяти на первой не спасет от краша при переполнении второй.

Qwen3.6-35B-A3B: более плотное квантование Q6_K

Модель: Qwen3.6-35B-A3B-UD-Q6_K.gguf

Варианты развертывания:

• 2 GPU: полный выгруз всех слоев в видеопамять (-ngl 99, split-mode layer). С активированным MTP занято 14411 и 14595 MiB из 20480 MiB на каждом устройстве.

• 1 GPU: гибридный режим, часть слоев на видеокарте (-ngl 25), остальное выгружено в системную RAM.

Q6_K: сравнение полного GPU-оффлоада и гибридной схемы

Режим / Конфигурация	VRAM GPU 0	VRAM GPU 1	RAM	Decode (ток/с)	Принято драфтов	Cold prefill (ток/с)
2 GPU MTP (split-mode, ngl 99)	14411 MiB	14595 MiB	~2.5 GiB	116.16	96.9% (186/192)	1173.88
2 GPU Base (split-mode, ngl 99)	14375 MiB	14405 MiB	~2.5 GiB	90.56	—	1305.99
1 GPU MTP (hybrid ngl 25)	17413 MiB	0 MiB	~13.0 GiB	42.93	96.9% (186/192)	210.28
1 GPU Base (hybrid ngl 25)	17273 MiB	0 MiB	~12.5 GiB	29.03	—	221.72

Сравнение вариантов IQ4_NL и Q6_K

Метрика / Конфигурация	IQ4_NL (4-bit)	Q6_K (6-bit)	Выводы и разница
2 GPU + MTP (Decode)	118.01 ток/с	116.16 ток/с	Q6_K медленнее всего на ~1.6%
2 GPU Base (Decode)	93.38 ток/с	90.56 ток/с	Q6_K отстает примерно на 3.0%
VRAM (GPU 0 / GPU 1) с MTP	8825 / 9239 MiB	14411 / 14595 MiB	Оба кванта целиком помещаются в VRAM двух карт
1 GPU + MTP (Decode)	120.32 ток/с	42.93 ток/с	Гибридный режим с RAM проседает в 2.8 раза
1 GPU Base (Decode)	93.36 ток/с	29.03 ток/с	Гибридный режим без MTP медленнее в 3.2 раза

Практические выводы для моей системы

В случае с одной картой модель в квантовании IQ4_NL помещалась в память полностью и в коротком тесте с MTP выдавала 120.32 токена/с. Гибридная конфигурация для Q6_K с -ngl 25 показывала скромные 29.03 токена/с без MTP и 42.93 с ним.

Однако при задействовании двух карт модель Q6_K целиком уместилась в видеопамять. Скорость генерации с MTP составила 116.16 токена/с против 118.01 у IQ4_NL — разница минимальна (около 1.6%). Именно ради этого и затевался второй ускоритель: возможность использовать более качественное квантование без ущерба для скорости за счет отказа от вычислений на CPU.

Qwen3.6-35B-A3B Q6_K_XL: тестирование на сверхдлинных промптах

Для следующего этапа тестов я взял вариант UD-Q6_K_XL от команды Unsloth и зафиксировал размер контекстного окна на отметке 262144 токена. Суффикс XL (Extra Large) подразумевает расширенное квантование: при базовой 6-битной схеме ключевые веса сохраняются в повышенной точности для минимизации потерь качества. Точное наименование файла и хеш-сумма SHA256 приведены в файле MODELS.md.

Распределение VRAM при заполнении окна на 256K:

• GPU 0: 17945 MiB / 20480 MiB (свободный остаток: 2535 MiB)

• GPU 1: 19487 MiB / 20480 MiB (свободный остаток: 993 MiB)

• Суммарное потребление: 37432 MiB из 40960 MiB.

Q6_K_XL: результаты софт-тестов с MTP

Использовались параметры: draft-n-max 2, temperature 0.6, top_p 0.95, top_k 20, min_p 0 с активным блоком рассуждений (reasoning). На каждом шаге генерировался ответ длиной 400 токенов, полностью уходивший на цепочку рассуждений. Из-за особенностей логирования скрипта названия шагов (4K–250K) незначительно расходились с реальной длиной входящего текста, поэтому во втором столбце зафиксирован точный объем промпта по счетчикам сервера.

Метка шага	Реальный вход, токены	Prefill суффикса (ток/с)	Время префилла (с)	Decode (ток/с)	Драфты: предл. / принат.	Доля принятых	VRAM (GPU 0 / GPU 1)
4K Baseline	5221	1991.1	2.26 с	98.0	353 / 222	62.9%	17943 / 19487
32K Context	41409	1702.5	21.56 с	86.3	330 / 234	70.9%	17943 / 19487
64K Context	82909	1225.0	34.30 с	70.7	336 / 231	68.8%	17945 / 19487
128K Context	165909	853.2	97.89 с	54.0	331 / 233	70.4%	17945 / 19487
192K Context	248909	603.4	138.40 с	42.9	333 / 232	69.7%	17945 / 19487
250K Maximum	244925	576.5	137.95 с	42.4	341 / 228	66.9%	17945 / 19487

Ornith-1.5-35B-A3B: запуск квантования Q6_K на двух GPU

Модель: Ornith-1.5-35B-Q6_K.gguf

Архитектурно Ornith близка к предыдущей MoE: те же ~35 млрд параметров, из которых активны около 3 млрд на токен. В GGUF-версии задействовано 40 основных слоев (30 типа DeltaNet и 10 классического внимания), а также встроенный MTP-блок. Модель проверялась отдельно со своими весами и конфигами.

Максимальное контекстное окно сервера: 262144 токена (полноценные 256K).

Параметры инференса: —split-mode layer —flash-attn on —cache-type-k q4_0 —cache-type-v q4_0 —spec-type draft-mtp —spec-draft-n-max 2

Распределение памяти при заполненном до 262144 токенов окне

• GPU 0: 17577 MiB / 20480 MiB (свободный остаток: 2903 MiB / ~2.84 GiB)

• GPU 1: 17837 MiB / 20480 MiB (свободный остаток: 2643 MiB / ~2.58 GiB)

• Суммарный свободный буфер составляет 5546 MiB (~5.42 GiB). В ходе этой серии тестов ошибок нехватки памяти не фиксировалось.

Ornith: стресс-тест заполнения контекста (draft-n-max 2)

Контекст (токены)	Grow prefill (ток/с)	Время префилла (с)	Decode (ток/с)	Драфты Предл. / Принят.	Доля принятых
32768 (32K)	824.14	39.76 (весь вход)	118.12 ± 0.11	84 / 84	100.0% (84/84)
65536 (64K)	1706.15	19.13	100.37 ± 0.04	84 / 84	100.0% (84/84)
131072 (128K)	1151.68	56.79	77.49 ± 0.02	84 / 84	100.0% (84/84)
196608 (192K)	796.03	82.17	63.19 ± 0.01	84 / 84	100.0% (84/84)
256K	610.01	103.71	53.42 ± 0.03	84 / 84	100.0% (84/84)

Анализ результатов Ornith

В данном бенчмарке скрипт циклически повторял единичный токен-id, после чего трижды запускал генерацию 128 токенов поверх уже прогретого кеша. Знак ± отражает разброс скорости между этими тремя прогонами (стандартное отклонение). Верхняя граница в таблицах обозначена как 256K исходя из лимита сервера, хотя реальный размер входного промпта составлял 260000 токенов. Все 84 предложенных предиктивным модулем токена были успешно приняты, однако столь синтетическая нагрузка не позволяет оценивать смысловое качество ответов.

На последней контрольной точке скорость составила 53.42 токена/с. Полная генерация блока из 128 токенов при готовом кеше занимала в среднем 3.11 секунды. Важно подчеркнуть: это не время первичного чтения всего промпта с нуля и не задержка до выдачи первого токена (TTFT).

Ornith: увеличение глубина MTP с 2 до 3

Следующим шагом я увеличил глубину генерации предиктивных токенов до 3. Условия тестирования остались прежними: три повтора на каждый шаг, генерация по 128 токенов. В двух крайних столбцах приведено суммарное время от отправки запроса до получения готового ответа. Поскольку эти замеры проводились в разные дни, ниже я приведу результаты повторной верификации.

Контекст, токены	Decode, depth 2 (ток/с)	Decode, depth 3 (ток/с)	Прирост скорости	Принято, depth 2	Принято, depth 3	Время ответа 128 ток. (depth 2)	Время ответа 128 ток. (depth 3)
32768 (32K)	118.12 ± 0.11	126.75 ± 0.24	+7.30%	100.0% (84/84)	92.1% (93/101)	1.24 с	1.16 с
65536 (64K)	100.37 ± 0.04	116.28 ± 0.03	+15.85%	100.0% (84/84)	100.0% (95/95)	1.51 с	1.33 с
131072 (128K)	77.49 ± 0.02	91.47 ± 0.15	+18.04%	100.0% (84/84)	100.0% (95/95)	2.05 с	1.79 с
196608 (192K)	63.19 ± 0.01	75.53 ± 0.08	+19.53%	100.0% (84/84)	100.0% (95/95)	2.58 с	2.26 с
256K	53.42 ± 0.03	64.46 ± 0.15	+20.67%	100.0% (84/84)	100.0% (95/95)	3.11 с	2.71 с

На длинных промптах глубина предсказания 3 продемонстрировала себя с лучшей стороны: 64.46 против 53.42 токена/с на 260000 токенах. Повторные тесты на актуальной конфигурации виртуальной машины подтвердили схожие показатели — 64.32 и 53.38 токена/с. Однако на коротком входе (4096 токенов) третий уровень глубины проиграл: 117.54 против 138.27 токена/с. Универсального «серебряного пули» здесь нет, настройки требуют адаптации под задачи.

Итоги и выводы

Я давно планировал углубиться в локальный инференс и получить солидный объем видеопамяти без астрономических затрат. Покупать ускорители Tesla V100 не хотелось: архитектура Volta ограничена поддержкой максимум CUDA 12.x, а платы с интерфейсом SXM2 потребовали бы сложных манипуляний с переходниками и кастомным охлаждением. Обнаруженный репозиторий с патчами для разблокировки CMP пришелся как нельзя кстати. Модифицированные ускорители CMP 50HX оказались отличным фундаментом для домашней лаборатории, причем входить в проект можно постепенно — начиная с одной карты. Та же Qwen3.6-35B-A3B в квантовании IQ4_NL целиком помещается в рамки одного устройства.

В качестве практического применения я решил развернуть инфраструктуру уровня production Kubernetes поверх Proxmox с помощью Terraform. Одинаковую задачу я поручил моделям Ornith и Qwen3.8-27B. В этом сценарии Qwen проявила себя лучше: с ней удалось справиться примерно за полтора часа, тогда как с Ornith на это ушло около 2,5 часов.

В планах — написание собственных автономных агентов и их оркестрация в Kubernetes. Параллельно хочу изучить Agent Substrate — развивающийся open-source проект для изоляции агентных сред исполнения поверх K8s. Инструмент пока сыроват, но для экспериментов в домашней лаборатории представляет огромный интерес.

При подготовке этой публикации использовались следующие материалы и источники:

• Репозиторий Xrip с патчами для разблокировки CMP50/90HX: https://github.com/xrip/cmp50hx-unlock

• Профильные статьи на SE7ENе: статья 1 и статья 2

• ChatGPT и Antigravity, оказавшие неоценимую помощь в бенчмарках, сборе информации и подготовке конфигурационных файлов для моего личного репозитория

 

Источник