Коротко: гибридный llama.cpp уже реален, но не каждый CPU/RAM PR можно считать готовой функцией
В llama.cpp описан рабочий гибридный сценарий с двумя RPC server: один узел использует CUDA GPU, второй работает через CPU backend. Оба подключаются к llama-server, после чего модель распределяется между доступными ресурсами.
Для такого запуска применяют tensor-split: GPU стараются заполнить доступной VRAM, а оставшуюся часть нагрузки и размещения переносят на CPU/RAM. Это помогает запустить модель, которая не помещается в память одной видеокарты, но не обещает одинаковую скорость для всех GGUF, CPU и GPU.
С направлениями dot product, batch decode, NUMA, загрузкой MoE-экспертов с Disk, удержанием горячих экспертов в RAM и снижением пика RAM нужно аккуратнее. В доступных материалах нет подтверждённых результатов, статусов PR или воспроизводимых замеров по этим темам. Их разумно считать картой наблюдения, а не набором уже готовых возможностей.
Почему llama.cpp CPU-only и системы с дефицитом VRAM остаются важной задачей
Локальный инференс упирается сразу в несколько ресурсов: объём VRAM, системную RAM, пропускную способность памяти, тип квантования, backend и способ размещения весов. Модель может занимать приемлемый объём после старта, но оказаться неудобной из-за медленной генерации или проблем при загрузке.
llama.cpp давно интересен владельцам обычных ПК именно благодаря CPU-пути и GGUF-квантованию. Базовый контекст проекта, сильные стороны запуска на процессоре и его ограничения разобраны в материале о том, как llama.cpp сделал большие модели доступнее на CPU.
Когда одной VRAM не хватает, а от локальной модели отказываться не хочется
GPU с ограниченной VRAM может ускорять часть работы, а CPU/RAM дают дополнительное пространство для размещения весов. Цена такого подхода - более сложная топология и зависимость от передачи данных между устройствами. Скорость будет зависеть от конкретной модели, квантования, CPU, GPU, памяти и backend.
Гибридный запуск полезен в ситуации, когда целевая модель не помещается в видеопамять, но в системе достаточно RAM и пользователь готов проверить стабильность на своей конфигурации. Он не превращает системную память в эквивалент быстрой VRAM.
Почему CPU-only и hybrid - это разные сценарии, а не две шкалы одной настройки
В режиме CPU-only CPU backend выполняет основную работу сам. В hybrid-конфигурации вычисления и размещение распределяются между несколькими ресурсами, например CUDA GPU и CPU backend через RPC server.
Выбор между этими путями зависит от железа и нужной модели. Для компактного GGUF CPU-only может оказаться проще в настройке. Для модели, которой не хватает VRAM одной карты, гибридная схема даёт шанс на локальный запуск при условии совместимости.
Подтвержденная схема: llama.cpp распределяет модель между CUDA GPU и CPU backend через RPC
В описанном пользовательском кейсе были подняты два RPC server: один с CUDA GPU, второй с CPU backend. Затем адреса обоих узлов добавили в llama-server, и модель корректно разделилась между ними.
Что делает RPC server в такой конфигурации
RPC server предоставляет llama-server вычислительный ресурс отдельного backend или удалённого узла. В рассмотренной схеме он связывает CUDA-узел с CPU-узлом, чтобы запуск использовал оба ресурса.
Такой подход полезен и для одной машины с разными backend, и для разнесённых устройств. Вторая ситуация сильнее зависит от соединения между узлами, задержек и поведения конкретной модели.
Какую роль играет llama-server
llama-server в этой конфигурации выступает управляющей точкой: он получает подключённые RPC-узлы и использует их при распределении модели. Его не стоит путать с самими RPC server: сервер инференса координирует запуск, а RPC-узлы предоставляют CPU или CUDA-ресурсы.
Материалы подтверждают сам факт такого распределения в одном сценарии. Они не дают универсальной команды запуска, полного перечня совместимых моделей или гарантии для другой версии llama.cpp.
Tensor-split: как отдать GPU максимум доступной VRAM, а остаток вынести на CPU
Участник обсуждения использовал tensor-split с понятной целью: заполнить GPU доступной VRAM и перенести остаток на другие CPU backend. Для владельца видеокарты с малой памятью это практичнее, чем пытаться уместить весь GGUF на GPU любой ценой.
Tensor-split описывает стратегию распределения нагрузки и размещения. Он не гарантирует одинаковую производительность на Mistral, Mixtral, плотных моделях и MoE-моделях. Перед рабочим запуском нужно проверять конкретный GGUF и его квантование.
Что этот hybrid-подход дает на практике, а где начинаются компромиссы
Главная польза гибридной схемы - расширение доступного объёма памяти для локального запуска. Это особенно заметно, когда GPU подходит по вычислительной мощности, но её VRAM не хватает для полной загрузки желаемой модели.
Компромисс связан с передачей данных и различием производительности CPU и GPU. Добавление RAM помогает разместить часть весов, но не убирает затраты на доступ к ним. Сопоставимых измерений latency, tokens/s или скорости загрузки для этой схемы в доступных материалах нет.
Кому имеет смысл смотреть в сторону GPU + CPU/RAM
- Владельцу GPU, чья VRAM не вмещает нужный GGUF.
- Пользователю с достаточным запасом системной RAM.
- Разработчику, для которого возможность держать модель локально важнее простоты single-device-конфигурации.
- Энтузиасту, готовому проверить свою модель, квантование и backend до переноса рабочего сценария.
Практические результаты гибридных сборок сильно зависят от состава железа. Пример с большой CPU/RAM-конфигурацией и несколькими RTX 3060 приведён в разборе 3-битной GLM 5.2 на CPU/GPU-системе, но его цифры нельзя переносить на RPC-схему с другой моделью.
Почему наличие CPU и RAM не гарантирует беспроблемную загрузку
Распределённая загрузка зависит от структуры модели, формата GGUF, квантования и поведения backend. Успешный запуск одной модели подтверждает лишь конкретный кейс, а не совместимость всего семейства.
Контраст между Mistral и Mixtral в рассмотренном обсуждении хорошо показывает риск: одна модель была распределена и выполнена, другая зависла ещё до инференса, на этапе загрузки tensors.
Совместимость нужно проверять по конкретной модели: пример Mistral и Mixtral
Единичные отчёты полезны как ориентир для диагностики. Их нельзя превращать в таблицу официальной поддержки без повторяемых тестов на нескольких конфигурациях.
Что удалось запустить: mistral-7b-instruct-v0.1.Q4_K_M.gguf
В описанном сценарии mistral-7b-instruct-v0.1.Q4_K_M.gguf удалось распределить между CUDA RPC server и CPU backend, а затем выполнить. Это подтверждает, что сама схема GPU + CPU через llama-server может работать на конкретной модели.
Факт не даёт оснований ожидать такой же результат с другим размером модели, другой квантизацией или MoE-архитектурой. Даже близкие по названию сборки могут вести себя по-разному при загрузке и распределении тензоров.
Где загрузка остановилась: Mixtral8x7B Q4_K_M и этап loading tensors
Для Mixtral8x7B Q4_K_M пользователь сообщал о зависании на этапе loading tensors. При этом соединения с удалёнными клиентами разрывались.
Причина этого поведения, его повторяемость и связь с конкретным backend в доступном материале не установлены. Было бы ошибкой объявить Mixtral несовместимой с llama.cpp или объяснить сбой нехваткой RAM без журналов, версии кода и параметров запуска.
Минимальный чек-лист перед переходом на распределенный запуск
- Проверить точное имя GGUF-модели и квантование.
- Убедиться, что CUDA backend и CPU backend доступны на нужных узлах.
- Проверить подключение каждого RPC server к llama-server.
- Отследить, проходит ли запуск этап
loading tensors. - Сохранить журналы llama-server и удалённых клиентов при сбое.
- Проверить целевую MoE-модель отдельно: успешный старт меньшего GGUF ничего не доказывает для неё.
CPU, RAM, Disk и MoE: карта направлений, за которыми стоит следить в 2026
Эти темы важны для CPU-only систем, домашних серверов с ограниченной VRAM и пользователей больших MoE-моделей. Однако во входных материалах нет прямых деталей по готовому коду, статусам PR и измерениям для dot product, batch decode, NUMA, потоковой работы MoE с Disk, удержания экспертов в RAM или снижения пика RAM.
Правильная трактовка здесь простая: направление может быть технически перспективным, но планировать сборку стоит только после появления первичных данных, тестов и понятного статуса изменений.
Dot product и batch decode: почему CPU-изменения влияют на ощущение скорости
Dot product, скалярное произведение векторов, лежит в основе матричных вычислений LLM. Даже небольшие изменения в этом низком уровне могут отражаться на CPU-инференсе, если код затрагивает часто вызываемые участки вычислительного графа.
Batch decode относится к обработке нескольких последовательностей или запросов. Его поведение важно для сервера с параллельными пользователями и для агентных задач, где запросы приходят одновременно.
В доступном материале упомянуто техническое обсуждение matrix dot product в ggml_compute_forward_mul_mat_one_chunk. Итогового вывода о приросте, готовом пользовательском сценарии или состоянии изменений там нет.
NUMA: когда многоядерный CPU и несколько сокетов становятся отдельной проблемой
NUMA означает, что стоимость доступа к памяти может различаться в зависимости от процессорного узла, который обслуживает эту память. На многосокетной машине или системе с несколькими NUMA-узлами это влияет на работу с большими весами и KV-кэшем.
Для CPU-only и CPU/RAM-гибрида тема особенно чувствительна: процессор может иметь много ядер, а данные при этом лежат в менее удобной для части ядер памяти. В предоставленных материалах нет подтверждения конкретного NUMA PR, его статуса или эффекта в llama.cpp.
MoE на Disk и горячие эксперты в RAM: привлекательная идея с высокой ценой проверки
MoE-модель содержит набор экспертов, из которых для обработки токенов выбирается лишь часть. Идея подгружать экспертов с Disk или держать чаще используемых экспертов в RAM нацелена на снижение объёма постоянно занятой памяти.
Польза такого подхода зависит от того, какие эксперты запрашиваются, как устроен кэш, насколько быстрый накопитель установлен в системе и как часто данные приходится перемещать. Во входных материалах нет подтверждения готового механизма для llama.cpp, алгоритма кэширования, требований к накопителю или практических результатов.
Снижение пикового RAM при загрузке: важнее, чем кажется для больших GGUF
Постоянное потребление памяти после старта и максимум RAM во время загрузки - разные величины. Модель может формально помещаться в системную память, но упираться в кратковременный пик при подготовке тензоров.
Для вывода о снижении такого пика нужны ссылка на конкретный PR, статус попадания в основную ветку, затронутые форматы, версия llama.cpp и воспроизводимые замеры. Этих данных в доступном пакете нет.
Как читать open PR по llama.cpp и не строить конфигурацию на обещаниях
Open PR, техническое обсуждение и изменение в релизе имеют разную ценность для пользователя. Смешивание этих статусов приводит к типичной ошибке: сборку планируют под функцию, которая ещё меняется, не прошла тесты или не вошла в используемую версию llama.cpp.
Три статуса, которые нельзя смешивать: идея, open PR и изменение в релизе
- Идея или обсуждение: описывает возможный подход и не подтверждает доступность кода.
- Open PR: содержит изменения, которые могут поменяться, получить замечания или не попасть в основную ветку.
- Изменение в релизе или конкретном коммите: доступно для проверки, но всё ещё требует теста на целевой модели и железе.
Похожая осторожность нужна при оценке распределённого инференса. В разборе кластеризации Ryzen AI Halo показано, что RPC-связь способна стать ограничением производительности. Это другой сценарий и другое железо, но сам принцип переносится: несколько устройств не складывают скорость автоматически.
Какие доказательства нужны для заявлений о скорости, памяти и совместимости
- Точная конфигурация CPU, GPU, RAM и накопителя.
- Название модели, формат GGUF и квантование.
- Версия или commit llama.cpp.
- Параметры запуска и используемые backend.
- Тип нагрузки: prefill, decode, длина контекста, число параллельных запросов.
- Измерения, журналы ошибок и ограничения теста.
Без этих данных нельзя честно сравнить CPU-only, GPU + CPU/RAM и возможный disk-oriented подход. Один удачный запуск доказывает работоспособность конкретной связки, но не заменяет бенчмарк.
Вывод: что делать владельцу CPU-only ПК и участнику poor GPU club
Владельцу CPU-only ПК стоит следить за темами dot product, batch decode, NUMA и пикового RAM, но ориентироваться на подтверждённые изменения в своей версии llama.cpp и на замеры для похожего железа. Пока таких данных нет, обещать заметный прирост нельзя.
Пользователю одной GPU с ограниченной VRAM уже можно изучать hybrid-схему через RPC server, CUDA backend, CPU backend и tensor-split. Начинать следует с точной целевой GGUF-модели, а не с предположения, что любая LLM распределится так же, как mistral-7b-instruct-v0.1.Q4_K_M.gguf.
Для MoE и Disk-подходов разумнее занять выжидательную позицию. Потоковая подгрузка экспертов и удержание горячих экспертов в RAM выглядят логичным направлением для машин с дефицитом VRAM, но в доступных материалах нет достаточных данных, чтобы собирать систему под эти возможности уже сейчас.