llama.cpp RPC: модель на нескольких компьютерах без открытого порта

Что делает RPC и когда его не выбирать

RPC здесь — не HTTP API для клиентского приложения. Главный процесс llama-cli либо llama-server соединяется с отдельными ggml-rpc-server на других машинах и использует их вычислительные устройства. Для этого и удалённые узлы, и главный процесс собираются с GGML_RPC=ON. По описанию разработчиков передаются вычисления, веса модели и KV-кэш; распределение между локальными и удалёнными устройствами по умолчанию учитывает доступную память, а не гарантирует равную нагрузку. s1 s4 s5

Не выбирайте этот путь для обработки рабочих документов, персональных данных, клиентов в общей сети и любой среды, где к порту могут обратиться чужие узлы. Исходный RPC README запрещает публичную сеть и чувствительное окружение; отдельная политика безопасности рекомендует не использовать RPC вовсе, если нельзя обеспечить безопасную изоляцию. В опубликованном advisory описана удалённая эксплуатация старого RPC-кода при доступе к TCP-порту. Указанная там граница затронутых сборок <= b7991 не означает, что v0.5.0 проверена Modelium на отсутствие иных ошибок или пригодна для продакшена. s1 s2 s8

Если цель — просто запуск одного GGUF-файла, используйте обычный llama.cpp на одной машине. Для нескольких одновременных клиентов или моделей не путайте RPC с роутером llama-server: это разные функции. s5

Как подготовить тестовый контур

Понадобятся основной компьютер, хотя бы один тестовый узел с доверенным доступом по SSH, выделенные ресурсы CPU/GPU, совместимый GGUF-файл и одинаковый исходный код llama.cpp на всех узлах. Для сравнимости в этом примере используется стабильный тег v0.5.0, указывающий на commit 7fe450e19305b828c199d602c23a8337aaa1f03b; это дата проверки материала, не обещание совместимости любых других версий. GPU-сборка зависит от драйвера и toolkit конкретной платформы. s1 s3 s6

Не передавайте реальные документы или секреты в этот опыт. Сетевое правило должно оставлять RPC-порт доступным только внутри каждой машины; SSH входить должен лишь с контролируемого основного узла. Туннель шифрует транспорт по выбранному маршруту, но не устраняет дефекты RPC-кода и не делает чужой сервер доверенным. Это защитное условие редакции, а не функция, которую мы проверили на стенде. s1 s2 s7

Как собрать обе стороны по документации

На каждом узле получите одну и ту же ревизию исходников, затем настройте сборку. Пример CPU-сборки; для CUDA документация RPC добавляет -DGGML_CUDA=ON, если соответствующий toolkit уже установлен. s1 s3

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout 7fe450e19305b828c199d602c23a8337aaa1f03b
cmake -S . -B build -DGGML_RPC=ON
cmake --build build --config Release

Это команды из способа сборки проекта и RPC-настройки, сведённые в один воспроизводимый пример; Modelium не проверял их исполнением. На основном компьютере сначала убедитесь, что обычный build/bin/llama-cli загружает выбранный локальный GGUF без RPC. Укажите путь к своему проверенному файлу, а не выдуманный идентификатор модели. Формат GGUF обязателен для llama.cpp; источник весов, лицензию и происхождение кванта проверяйте отдельно. Размер файла не равен требуемым RAM или VRAM: контекст и KV-кэш тоже используют память. s1 s4 s6

Как соединить узлы, не публикуя RPC-порт

На удалённой тестовой машине запустите RPC-сервер с привязкой к loopback. Исходный код v0.5.0 задаёт 127.0.0.1:50052 по умолчанию; в документации RPC приведён такой же endpoint. Не меняйте --host на 0.0.0.0 ради удобства. Запись CUDA0 в примере документации не означает, что GPU с таким именем есть на вашем узле: без ускорителя сервер может выставить CPU. s1 s7

./build/bin/ggml-rpc-server --host 127.0.0.1 --port 50052

На основном компьютере откройте отдельный SSH-туннель к каждому удалённому узлу. Следующие адреса и имена — шаблон для вашей тестовой сети, не реальные серверы Modelium. Каждый туннель занимает свой локальный порт; если узел один, нужна только первая строка. s1 s7

ssh -N -L 127.0.0.1:15052:127.0.0.1:50052 user@host-a
ssh -N -L 127.0.0.1:15053:127.0.0.1:50052 user@host-b

Команды SSH выполняйте в отдельных сессиях. Если ваш SSH-клиент или политика узла не разрешают local forwarding, остановитесь и не заменяйте туннель публичной привязкой RPC. Проверка на основной машине: локальные порты должны слушать только 127.0.0.1, на удалённых узлах RPC — тоже только 127.0.0.1; закрытые ACL проверяются отдельно. Без этих условий к шагу запуска не переходите. SSH-туннель и эта проверка — предложенная редакцией схема снижения экспозиции, не официальный безопасный deployment pattern llama.cpp. s1 s2 s7

Как проверить распределённый ответ

Сначала на основном узле запишите базовый ответ и время для того же GGUF, промпта и параметров без --rpc. После этого используйте локальные адреса SSH-туннелей; флаг --rpc документирован как список host:port через запятую, а --n-gpu-layers управляет выгрузкой слоёв на устройства. Замена документированных удалённых адресов на локальные tunnel-endpoints — составной пример, который Modelium не исполнял. s1 s4

./build/bin/llama-cli -m ./model.gguf --single-turn -p 'Ответь одним словом: готово?' --rpc 127.0.0.1:15052,127.0.0.1:15053 --n-gpu-layers 99

Для одного узла удалите второй адрес. Проверьте не только текст ответа: сохраните stdout и stderr главного процесса, логи обоих RPC-серверов, список обнаруженных устройств и время загрузки модели. Без журналов offload ответ мог прийти только с локального устройства; одно слово в ответе не доказывает ни распределения, ни корректности. --list-devices позволяет посмотреть доступные устройства. Затем повторите идентичный тест без RPC и сравните время загрузки и генерации на собственных данных. s1 s4

По документации RPC веса и KV-кэш распределяются пропорционально доступной памяти; --tensor-split задаёт ручные пропорции для распределения данных между устройствами. Не применяйте произвольное значение «пополам»: порядок и число обнаруженных устройств должны быть подтверждены логами. TCP-соединение может стать узким местом; документация описывает локальный кэш и RDMA, но включать кэш или RDMA до базовой проверки не нужно. Ускорение, минимальные требования памяти и надёжность разных сочетаний CPU/GPU Modelium не измерял. s1 s4

Если нужен HTTP API для тестового клиента, llama-server также принимает --rpc; его HTTP-слой имеет собственные параметры и /health. Не выводите HTTP-порт или RPC-порт в недоверенную сеть; проверка /health говорит о готовности HTTP-сервера, а не о защищённости RPC и не о том, что задействованы оба удалённых устройства. s2 s5

Что делать, если опыт не удался

• Нет соединения: проверьте, работает ли RPC-процесс на удалённой машине, подняты ли оба туннеля, и слушают ли ожидаемые loopback-порты. Открывать 50052 наружу нельзя. s1 s7
• Не видно GPU: сначала проверьте сборку нужного backend, доступность драйвера и --list-devices; без ускорителей RPC-документация показывает CPU fallback. s1 s3 s4
• Не помещается модель: уменьшайте модель или контекст, проверяйте реальное потребление на каждом узле; размер GGUF-файла не даёт достаточного расчёта. s1 s4 s6
• Не быстрее одного компьютера: отдельно сравните время загрузки, скорость генерации и сетевые задержки; дополнительные узлы не являются автоматическим ускорителем. Для начала вернитесь к локальному запуску и выбору GGUF. s1

После опыта остановите оба RPC-процесса и SSH-туннели. Для задачи с чувствительными данными или корпоративным доступом не переносите этот прототип в работу по инерции: заново выбирайте архитектуру, изоляцию и границы доверия по собственной модели угроз. s1 s2