Для конфигурации HP Z8 G4 с 512 ГБ RAM, RTX 3090 и RTX 5060 16 ГБ короткий ответ такой: если вам нужны крупные MoE-модели с выгрузкой части тензоров в системную память и вы работаете за себя одного, llama.cpp остаётся более предсказуемым вариантом. Если болит другое, а именно ожидание по месяцы, пока свежая архитектура доедет до llama.cpp, главный довод за vLLM в силе: официальная поддержка многих новых моделей появляется почти сразу после релиза.
Прирост скорости при этом не обязателен. Автор обсуждения прямо говорит: ускорения ему не нужно, достаточно, чтобы vLLM работал примерно с той же скоростью, что и llama.cpp, лишь бы работал. Это меняет логику выбора: гонка за токенами в секунду уходит на второй план, на первый выходят поддержка моделей, стабильность и время, потраченное на настройку.
Почему выбор между llama.cpp и vLLM снова стал актуален
Крупные MoE-модели вернули к жизни спор, который казался закрытым. Схема «много экспертов, мало активных параметров на токен» даёт качество большой модели при меньшем объёме вычислений на токен, но суммарный набор весов остаётся большим: полностью в 24 ГБ RTX 3090 и 16 ГБ RTX 5060 он не помещается, поэтому часть тензоров уходит в системную память. Пользователь с рабочей станцией HP Z8 G4 (512 ГБ RAM, RTX 3090 и RTX 5060 16 ГБ) формулирует задачу ровно так: крупные MoE-модели с выгрузкой части тензоров в RAM, только для собственного использования. Обсуждение на r/LocalLLaMA.
llama.cpp годами был стандартом домашнего запуска: стартует и на чистом CPU, и на одной видеокарте, и с частичной загрузкой слоёв. В отдельном материале показано, как llama.cpp поднимает большие модели на обычном CPU и какие кванты для этого подходят.
Второе изменение заметнее для тех, кто охотится за свежими архитектурами: темп релизов. Многие новые локальные модели поддерживаются в официальном vLLM в «день 0», тогда как для llama.cpp иногда уходит несколько месяцев. Это наблюдение одного пользователя, а не итог независимого тестирования, но проверить его легко: возьмите интересующую модель и посмотрите, есть ли она в текущих релизах обоих движков. Разница в сроках и есть предмет выбора.
Ключевое отличие: скорость добавления поддержки новых моделей
Для одиночного пользователя поддержка означает простую вещь: можно ли вообще запустить то, что вышло на этой неделе. Здесь vLLM опережает llama.cpp по времени. Автор треда на r/LocalLLaMA описывает это как ключевую причину интереса к переходу: многие новые локальные модели появляются в официальном vLLM в день релиза, а в llama.cpp адаптация иногда занимает месяцы.
Что это даёт на практике. Если вы пробуете каждую новую MoE-модель, ожидание превращается в простой железа: 512 ГБ RAM и две карты стоят без дела, пока нужная архитектура не доедет до привычного движка. Если вы годами работаете с двумя-тремя моделями, разница в сроках почти не ощущается, и переезд теряет смысл.
Оговорка, которую легко упустить: поддержка в коде и рабочий запуск на вашей конфигурации это разные вещи. Наличие модели в репозитории движка не гарантирует, что она поедет на двух разных потребительских картах с выгрузкой в системную память, а для гибридного режима на HP Z8 G4 это половина успеха.
Пример DeepSeek-V4-Flash-Vision-Exp: что даёт поддержка «день 0»
Карточка модели описывает DeepSeek-V4-Flash-Vision-Exp как первую экспериментальную мультимодальную модель в семействе DeepSeek-V4: она построена на архитектуре DeepSeek-V4-Flash, к которой добавили визуальные модули и продолжили обучение. Референсная реализация инференса покрывает визуальный энкодер и aligner, DFlash attention, MoE, Hyper-Connections и прямой проход DSpark. Карточка DeepSeek-V4-Flash-Vision-Exp на Hugging Face.
Там же приведена команда запуска через vLLM на одном узле из четырёх GB300. Для SGLang описан запуск с включением DSpark через --speculative-algorithm DSPARK, при этом отдельный --speculative-draft-model-path не нужен: целевые и черновые веса берутся из одного чекпоинта. Инструкции по запуску в карточке модели.
Четыре GB300 в примере и две потребительские карты в HP Z8 G4 это разные весовые категории, поэтому команду из карточки нельзя переносить напрямую. Смысл примера в другом: архитектура с визуальным энкодером, MoE и спекулятивным декодированием получила рабочий рецепт запуска быстро. Как похожий сценарий выглядит на потребительских картах, показывает кейс DeepSeek V4 Flash на двух RTX 4090 со 105 t/s.
Гибридный инференс: как vLLM и llama.cpp работают с выгрузкой тензоров в RAM
На паре карт с 24 и 16 ГБ крупная MoE-модель целиком не помещается, поэтому важнее другое: насколько дорого обходится выгрузка. llama.cpp разрабатывался с расчётом на такие конфигурации, vLLM вырос из серверного GPU-инференса, где вся модель живёт в памяти ускорителей. Разница подходов видна на деталях.
Распределение по слоям в llama.cpp: плюсы и ограничения
Когда модель не влезает в память одной видеокарты, llama.cpp распределяет её между несколькими. Первый режим это разделение по слоям: разные части модели стоят на разных картах, одна обработала свои слои, передала результат следующей, та обработала свои и так далее. Второй режим работает иначе: одна крупная математическая операция делится сразу между несколькими GPU, они одновременно считают разные части матрицы и обмениваются промежуточными результатами. Описание обоих режимов в статье на Хабре.
Ограничение, которое стоит держать в голове: без прямого обмена данными между картами (NVLink, peer-to-peer) передача идёт через системную память. Путь такой: первая карта читает блок из своей видеопамяти, гонит его через контроллер PCIe и корневой комплекс в RAM, после чего тот же блок уходит во вторую карту. Ради одной передачи между GPU выполняются две. В тесте на конкретной системе такой маршрут дал эффективную скорость около 1,60 ГБ/с. Данные измерения и разбор маршрута.
Цифра получена на другой конфигурации и не переносится автоматически на HP Z8 G4 с RTX 3090 и RTX 5060, но порядок величины объясняет главное: скорость гибридного инференса упирается в шину и память, а не в вычислительные блоки. Что уже подтверждено для гибридного инференса llama.cpp через RPC, CUDA, CPU backend и tensor-split, а также где проходят границы возможностей, разобрано в материале о CPU, RAM и гибридных направлениях в llama.cpp.
Поддержка выгрузки в vLLM: текущее состояние
Публичных данных, которые показывали бы паритет vLLM и llama.cpp по эффективности выгрузки в CPU-память, в разобранных источниках нет. Это не значит, что выгрузки нет вообще: механизмы и их поведение меняются от версии к версии, поэтому смотреть нужно документацию конкретного релиза и проверять всё на своей конфигурации.
Практический вывод для владельца 512 ГБ системной памяти: объём RAM сам по себе скорость не даёт. Движок должен уметь не просто выгрузить тензоры, но и не потерять производительность на каждом сгенерированном токене. Проверка одна: взять модель, которая уже стабильно работает в llama.cpp, и прогнать её в vLLM на том же промпте и той же длине контекста.
Производительность: нужен ли прирост скорости при переходе на vLLM
В том же обсуждении критерий сформулирован без амбиций: ускорение не требуется, достаточно сопоставимой скорости при условии, что решение работает. Такой подход снимает половину споров о бенчмарках, но оставляет вопрос о факторах, которые определяют разницу на гибридном инференсе.
Скорость здесь задают пропускная способность PCIe, наличие или отсутствие прямого обмена между картами, менеджмент памяти и качество оптимизаций под конкретную архитектуру GPU. Две карты разных поколений без прямого канала обмена почти всегда будут медленнее одной карты с тем же суммарным объёмом памяти.
vLLM силён в другом: continuous batching, PagedAttention и планировщик дают заметный выигрыш на prefill длинных промптов и при нескольких одновременных запросах. Разбор архитектуры батчинга и честного бенчмарка объясняет, почему выигрыш проявляется именно там. Для одиночного пользователя часть преимущества не реализуется, батчить нечего. Но длинный контекст всё равно упирается в prefill, поэтому на больших промптах разница может стать заметной.
Развёртывание: Docker под Windows или полноценный Linux
Автор задаёт вопрос прямо: Docker под Windows или полная установка Linux. Формулировка вопроса в исходном треде. Готового ответа в обсуждении нет, поэтому выбор стоит строить на компромиссах конкретной системы, а не на обещаниях.
Docker под Windows: плюсы и подводные камни
Linux-контейнеры в Windows работают через WSL2, а GPU внутрь контейнера пробрасывается драйвером NVIDIA с поддержкой WSL. Что проверить до переезда на этот вариант:
- доступен ли внутри WSL2 весь объём RAM или виртуальная среда получила меньшую квоту, лимиты WSL2 задаются в конфигурационном файле .wslconfig;
- видят ли контейнеры обе видеокарты и в том ли порядке, который вам нужен;
- как ведёт себя ввод-вывод при чтении весов с диска, если модель грузится с SSD;
- совпадают ли версии драйвера и CUDA с требованиями вашей сборки vLLM.
Плюс варианта очевиден: Windows остаётся основной системой, переставлять ничего не нужно. Минус тоже: лишний слой виртуализации, который придётся держать в голове при отладке проброса GPU и работы с большими объёмами памяти.
Полноценный Linux: когда стоит переходить
Нативная установка убирает слой виртуализации: драйверы, CUDA и сам движок работают напрямую с железом, а поведение системы проще предсказать при работе с сотнями гигабайт RAM. Для сценария, где модель постоянно выгружает тензоры в память, предсказуемость важнее экономии времени на переустановку.
Для HP Z8 G4 с двумя GPU в Linux проще настроить порядок карт и развести нагрузку между ними, а также повторяемо воспроизводить окружение, если вы планируете жить на vLLM долго. Если же переустановка не входит в планы, Docker под Windows с WSL2 остаётся рабочим компромиссом при условии, что проброс GPU и доступ к памяти проверены заранее.
Общий алгоритм выбора движка и железа под новую модель, с тремя уровнями конфигураций и сравнением llama.cpp, vLLM и SGLang, собран в руководстве о подборе железа и движка под новую LLM.
Совместимость с двумя разными GPU: RTX 3090 и RTX 5060
RTX 3090 и RTX 5060 16 ГБ относятся к разным поколениям (Ampere и Blackwell), у них разный объём памяти и потенциально разные требования к версиям CUDA в рамках одного процесса. Однородная пара карт всегда проще: меньше поводов для ошибок драйвера и расхождений в ядрах вычислений.
llama.cpp даёт ручное управление распределением по слоям, и это помогает развести нагрузку между картами разного размера: карта с большей памятью получает больше слоёв, остаток уходит в RAM. В vLLM работа с неоднородными GPU может быть ограничена, поэтому проверять нужно на своей сборке и своей версии драйвера, а не по общим обещаниям.
Отсутствие прямого обмена между картами бьёт по скорости: путь GPU 0 в RAM и затем в GPU 1 выполняет две передачи ради одной, и в тесте на конкретной системе это дало около 1,60 ГБ/с. Замеры маршрута через системную память.
Практическая тактика для такой пары карт: нагружать 24 ГБ RTX 3090 плотнее, остаток отдавать в 512 ГБ RAM, а после запуска сверять по логам, сколько слоёв реально оказалось на каждой карте. Ожидания стоит держать скромными: две разные карты без прямого обмена не дадут скорости одной большой.
Практические шаги перехода с llama.cpp на vLLM
- Проверьте поддержку нужной MoE-модели в текущем релизе vLLM. Если она там есть, а в llama.cpp ещё нет, это уже достаточная причина для теста.
- Выберите окружение: Docker под Windows через WSL2, если переустановка не входит в планы, или нативный Linux, если важна предсказуемость при больших объёмах памяти.
- Приведите в порядок драйверы и CUDA. Для двух карт разных поколений это самый частый источник проблем.
- Настройте выгрузку в CPU-память так, как требует ваша версия vLLM, и убедитесь, что параметры действительно применились, а не остались в дефолте.
- Прогоните модель, которая уже работает в llama.cpp, на том же промпте и сравните скорость, потребление RAM и поведение на длинном контексте.
- Если результат не устроил, посмотрите SGLang: для DeepSeek-V4-Flash-Vision-Exp в карточке модели описан запуск с DSpark через
--speculative-algorithm DSPARK. Остаться на llama.cpp тоже нормальный вариант, если самые свежие модели вам не критичны.
Ожидания по итогам перехода: vLLM не обязан ускорять генерацию. Он покупает другое, а именно скорость появления поддержки новых архитектур и возможность запустить модель на этой неделе, а не через полгода.
Итог: что выбрать в 2026 году
Расклад для HP Z8 G4 с 512 ГБ RAM, RTX 3090 и RTX 5060 16 ГБ такой. Если нужны свежие MoE-модели сразу после релиза и есть готовность разбираться с настройкой, переход на vLLM оправдан: именно поддержка моделей в «день 0» даёт основной выигрыш. Если приоритет это стабильность, предсказуемая работа гибридного инференса с выгрузкой в RAM и минимум времени на отладку, llama.cpp остаётся рабочим выбором.
Практичный старт: поднять vLLM в отдельном окружении, прогнать одну модель, уже проверенную в llama.cpp, и решать по факту, а не по обещаниям. Ситуация в 2026 году меняется быстро, поэтому вывод стоит пересматривать при каждом крупном релизе движка и при выходе модели, которая вам действительно нужна.