Гайды

Как запустить llama.cpp на двух видеокартах

16 октября 2026 · 13 минут чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

Материал редакции Зерокодера. Счёт по выдаче снят собственным прогоном 16 октября 2026 года; цитаты источников приведены дословно. Обновлено: октябрь 2026.

Как запустить llama.cpp на двух видеокартах: соберите бинарник с поддержкой нужного backend, проверьте устройства командой --list-devices, оставьте режим layer по умолчанию и задайте -ngl так, чтобы веса и KV-cache поместились в суммарную VRAM. Дальше разберём флаги, режимы, память и типовые ошибки. Мы скачали подборку результатов веб-поиска по запросу «Как запустить llama.cpp на двух видеокартах»: текст отдали 6 из 10.

Актуальные multi-GPU флаги в ggml-org

Документация проекта llama.cpp описывает запуск на нескольких GPU через набор CLI-флагов, одинаковых для llama-cli, llama-server и большинства бинарников. В руководстве на GitHub перечислены режимы разделения, управляющие ими аргументы, ограничения и готовые рецепты для llama-cli и llama-server. Тот же текст воспроизведён в зеркале на Hugging Face, где указана ссылка на репозиторий ggml-org/llama.cpp.

Ключевые флаги, которые нужно знать перед первым запуском:

• -sm / --split-mode — режим разделения: none, layer, tensor. Значение по умолчанию — layer.
• -ts / --tensor-split — пропорции распределения модели по GPU, например 3,1.
• -mg / --main-gpu — индекс единственного GPU в режиме none.
• -ngl / --n-gpu-layers — сколько слоёв держать в VRAM; значения 999 или all отправляют на GPU всё возможное.
• -dev / --device — список устройств, которые llama.cpp может использовать.
• --list-devices — вывод доступных устройств и их памяти.
• -fa / --flash-attn — режим flash attention, обязателен для tensor и квантованного V-cache.
• -ctk / --cache-type-k и -ctv / --cache-type-v — типы KV-cache для K и V.
• -fit / --fit — автоподгонка незаданных аргументов под память устройства.

Порядок действий для двух карт:

1. Соберите llama.cpp с поддержкой вашего backend (CUDA, ROCm, Vulkan или другого).
2. Запустите llama-cli --list-devices и запишите имена устройств.
3. Оставьте -sm layer и запустите модель с -ngl all.
4. Если карты разной ёмкости, добавьте -ts с пропорциями.
5. Проверьте распределение по логам загрузки.

Переменная окружения CUDA_VISIBLE_DEVICES управляет тем, какие GPU видит CUDA backend. Флаг --device выбирает устройства из уже видимых и работает для любого backend. Для двух карт удобно сначала ограничить видимость, а затем явно указать порядок через --device, поскольку значения -ts следуют порядку устройств в этом флаге.

Внутренняя ссылка по теме серверной части: llama.cpp API: как запустить llama-server и подключиться.

Поддерживаемые backend и ограничения

Документация llama.cpp описывает режимы разделения с разной степенью зрелости. Режим layer — самый совместимый вариант для нескольких GPU. Режим tensor помечен как экспериментальный: код менее зрелый, чем pipeline parallelism, а хорошая производительность ожидается на нескольких NVIDIA GPU с CUDA backend, для других конфигураций гарантий нет.

Сравнение режимов:

Разница между layer и tensor описана в документации так: pipeline-parallel запускает разные слои на разных GPU и обрабатывает токены последовательно через конвейер, что минимизирует пересылки между GPU, но требует много токенов для хорошего масштабирования. Tensor-parallel делит каждый слой между GPU и делает несколько cross-GPU редукций на слой, что распараллеливает любую нагрузку, но сильнее упирается в скорость межсоединения. Pipeline максимизирует пропускную способность батча, tensor минимизирует задержку.

Ограничения tensor:

• Не реализован для всех архитектур. Ошибка «LLAMA_SPLIT_MODE_TENSOR not implemented for architecture ‘…’» возникает на MoE и гибридных моделях (Grok, MPT, OLMoE, DeepSeek2, GLM-DSA, Nemotron-H, Nemotron-H-MoE, Granite-Hybrid, LFM2-MoE, Minimax-M2, Mistral4, Kimi-Linear, Jamba, Falcon-H1), на state-space и RWKV-подобных (Mamba, Mamba2 и гибриды Mamba-attention), а также на PLAMO2, MiniCPM3, Gemma-3n, OLMo2, BitNet, T5.
• --flash-attn off или --flash-attn auto, разрешающийся в off при отсутствии поддержки, — жёсткая ошибка.
• Типы KV-cache обязаны быть неквантованными: f32, f16 или bf16. Квантованный KV-cache не реализован, попытка его использовать даёт ошибку.
• --fit не поддерживается с tensor; размер контекста может потребоваться задать вручную через --ctx-size.
• Конфигурацию рекомендуется помечать как экспериментальную в своих инструментах и проверять качество вывода перед развёртыванием.

Для двух карт разумный старт — layer. Режим tensor включают, когда нужна минимальная задержка генерации и обе карты — NVIDIA с CUDA.

Память весов и KV-cache

Память на двух GPU делится между весами модели и KV-cache. В режиме layer KV-cache слоя l живёт на той GPU, которая владеет слоем l, то есть кэш распределяется вместе со слоями. В режиме tensor и веса, и KV делятся между участвующими GPU через абстракцию «meta device».

Флаг -ngl задаёт максимальное число слоёв в VRAM. Значения 999 или all отправляют на GPU всё возможное. По умолчанию -ngl равен auto.

Флаг -ts управляет долями модели на каждой карте. Если его опустить, layer и row используют автоматическое разделение пропорционально памяти, а tensor делит сегменты поровну. При 3,1 на двух GPU первая карта получает 75 %, вторая — 25 %. Пропорции нормализуются: -ts 3,1 эквивалентно -ts 75,25. Значения следуют порядку в --device.

Типы KV-cache задаются флагами -ctk и -ctv. По умолчанию оба — f16. Для K доступны f32, f16, bf16, q8_0, q4_0 и другие; для V набор такой же. В режиме tensor квантование KV не поддерживается, допустимы только f32, f16, bf16.

Практическое правило распределения:

Флаг -fit включён по умолчанию и автоматически подгоняет незаданные аргументы под память устройства. С tensor он не работает, поэтому размер контекста там выставляют вручную. Для двух карт с разной памятью -fit в режиме layer часто сам подбирает разумное распределение, а -ts нужен, когда автоподбор оставляет перекос.

Внутренняя ссылка о выборе моделей под локальный запуск: Gemma или Qwen: сравнение локальных моделей.

Документированная команда запуска

Документация приводит готовые рецепты. Базовый запуск pipeline parallel по всем видимым GPU выглядит так:

llama-cli -m model.gguf
llama-server -m model.gguf

Это самая простая конфигурация: KV-cache распределяется по GPU вместе со слоями, а --fit (включён по умолчанию) подбирает размеры автоматически.

Pipeline parallel с пользовательским соотношением:

llama-cli -m model.gguf -sm layer -ts 3,1

Такой вариант полезен, когда GPU имеют разную память: первая карта получает три части, вторая — одну.

Режим одной карты с выбором конкретного устройства:

llama-cli --list-devices
llama-cli -m model.gguf -dev CUDA1

Здесь используется только устройство, которое --list-devices показывает как CUDA1.

Tensor parallelism (экспериментальный):

llama-cli -m model.gguf -sm tensor -ctk f16 -ctv f16

В этом режиме flash attention обязателен, а KV-cache остаётся неквантованным.

Порядок для двух карт:

1. llama-cli --list-devices — узнать имена и память.
2. llama-cli -m model.gguf -ngl all — проверить базовый запуск на двух GPU.
3. llama-cli -m model.gguf -sm layer -ts 3,1 — задать пропорции при разной памяти.
4. llama-cli -m model.gguf -sm tensor -ctk f16 -ctv f16 — попробовать tensor, если нужна низкая задержка.

Флаги одинаковы для llama-cli и llama-server, поэтому серверную команду собирают из тех же аргументов. Для серверного сценария пригодится материал llama.cpp API: как запустить llama-server и подключиться.

Готовый промпт для проверки конфигурации модели после запуска — задача: получить от модели структурированный отчёт о распределении слоёв и предложениях по флагам.

Ты помогаешь настроить llama.cpp на двух GPU. Я дам вывод загрузки и параметры запуска.
Разбери их по шагам:
1. Сколько слоёв ушло на каждую видеокарту и сколько осталось на CPU.
2. Как распределился KV-cache между устройствами.
3. Есть ли признаки перекоса загрузки между картами.
4. Какие флаги стоит изменить: -sm, -ts, -ngl, -ctk, -ctv, -fa.
5. Что проверить в логах при следующем запуске.
Модель: [название и размер модели]
Карты: [модель и объём памяти каждой]
Параметры запуска: [ваша команда]
Вывод загрузки: [вставьте фрагмент лога]
Отвечай кратко, списком, без общих советов.

Что менять под себя: [название и размер модели], [модель и объём памяти каждой], [ваша команда], [вставьте фрагмент лога].

Вариации той же задачи:

• Промпт для сравнения режимов: попросить модель сопоставить layer и tensor для вашей пары карт и указать, какой режим выбрать под prefill или под генерацию.
• Промпт для подбора -ts: дать объёмы памяти карт и размер модели, получить пропорции и обоснование.
• Промпт для разбора OOM: дать текст ошибки и параметры запуска, получить список изменений по приоритету.
• Промпт для проверки совместимости: дать архитектуру модели и список карт, получить ответ, поддерживает ли tensor эту архитектуру.
• Промпт для серверного запуска: собрать команду llama-server с нужными флагами под вашу конфигурацию.

Проверка распределения через логи и мониторинг

После запуска распределение проверяют по логам загрузки и внешнему мониторингу. Документация llama.cpp описывает флаги, влияющие на распределение, а фактические доли видны в выводе при инициализации модели.

Что смотреть в логах:

• Список устройств и их память — совпадает с выводом --list-devices.
• Число слоёв, отправленных на каждую GPU, и число слоёв, оставшихся на CPU.
• Размер KV-cache и его привязку к устройствам.
• Предупреждения о нехватке памяти или о переходе на системную RAM.

Порядок проверки:

1. Запустите модель с -ngl all и сохраните вывод загрузки.
2. Сопоставьте число слоёв на каждой карте с ожидаемым распределением.
3. Проверьте, что KV-cache распределился вместе со слоями в режиме layer.
4. Сравните занятую память карт с их объёмом.
5. При перекосе добавьте -ts и повторите запуск.

Внешний мониторинг: nvidia-smi для NVIDIA, rocm-smi для AMD, системные утилиты для других backend. Наблюдайте занятую память каждой карты во время prefill и генерации. Сравнивайте занятую память с ожидаемыми долями весов и KV-cache. В layer разные слои выполняются последовательно, поэтому мгновенная утилизация двух GPU может различаться при корректной конфигурации.

В первичном руководстве ggml-org для tensor указаны неквантованные типы KV-cache: f32, f16 и bf16. Описание KVarN и квантованных tensor-кэшей из отдельного форка к этому контракту не относится. Перед запуском сверяйте параметры с документацией выбранной сборки.

Внутренняя ссылка о сравнении моделей под локальный инференс: GLM или Qwen: сравнение моделей и что выбрать.

Разбор OOM и неравномерной загрузки

OOM и перекос загрузки между картами — две частые проблемы при запуске на двух GPU. Причины и решения различаются по режиму.

Причины OOM и других ошибок запуска:

• Слишком высокий -ngl: все слои отправлены на GPU, а суммарной VRAM не хватает.
• Большой контекст: KV-cache занимает больше памяти, чем осталось после весов.
• Квантованный KV-cache в режиме tensor: документация указывает, что это даёт ошибку, поскольку поддержка не реализована.
• --flash-attn off в режиме tensor: жёсткая ошибка.

Что делать при OOM:

1. Снизить -ngl до значения, при котором модель помещается.
2. Уменьшить --ctx-size, чтобы сократить KV-cache.
3. Проверить типы KV-cache: в tensor оставить f32, f16 или bf16.
4. Убедиться, что --flash-attn включён при tensor.
5. В режиме layer задать -ts пропорционально памяти карт.

Причины неравномерной загрузки:

• Автоматическое разделение в layer распределяет модель пропорционально памяти, и при разной ёмкости карт доли различаются ожидаемо.
• Отсутствие -ts при картах разной ёмкости даёт перекос в сторону более ёмкой карты.
• В tensor сегменты делятся поровну, и на картах разной ёмкости одна заполняется раньше.
• Порядок значений -ts не совпадает с порядком устройств в --device.

Что делать при перекосе:

1. Задать -ts вручную, например 3,1 для карт с соотношением памяти три к одному.
2. Проверить порядок устройств в --device и привести -ts в соответствие.
3. В режиме tensor учесть, что деление идёт поровну, и подбирать карты близкой ёмкости.
4. Снизить -ngl, если перекос вызван нехваткой памяти на одной из карт.

Таблица типовых ошибок:

Порядок диагностики:

1. Прочитайте текст ошибки и определите, к какому флагу она относится.
2. Проверьте соответствие режима и архитектуры модели.
3. Сверьте типы KV-cache с требованиями режима.
4. Сравните занятую память карт с их объёмом.
5. Измените один параметр за раз и повторите запуск.

Внутренняя ссылка о замене облачных сервисов локальным запуском: Аналоги ГигаЧата: чем заменить.

Частые вопросы

Как запустить llama.cpp на двух видеокартах с разной памятью?

Используйте режим layer и задайте пропорции через -ts. При соотношении памяти три к одному подойдёт -ts 3,1: первая карта получит 75 %, вторая — 25 %. Пропорции нормализуются, поэтому -ts 3,1 эквивалентно -ts 75,25. Значения следуют порядку устройств в --device, поэтому проверьте этот порядок перед запуском.

Какой режим разделения выбрать для двух GPU?

По умолчанию используется layer — pipeline parallelism, самый совместимый вариант для нескольких GPU. Он подходит, когда нужно больше памяти, чем даёт одна карта, а приоритет — быстрый prefill. Режим tensor включают для минимальной задержки генерации, но он помечен как экспериментальный и требует поддержки flash attention.

Почему возникает OOM при запуске на двух картах?

Чаще всего из-за слишком высокого -ngl или большого контекста. Снизьте -ngl до значения, при котором модель помещается, и уменьшите --ctx-size. В режиме tensor проверьте, что KV-cache неквантованный: допустимы f32, f16 и bf16. Также убедитесь, что flash attention включён.

Как проверить, что модель распределилась по двум картам?

Запустите llama-cli --list-devices и сравните список с логом загрузки. Проверьте размещение слоёв и KV-cache, затем сопоставьте занятую память через nvidia-smi или rocm-smi с ожидаемыми долями. В layer мгновенная утилизация карт может различаться из-за последовательного конвейера.

Работает ли tensor parallelism на двух видеокартах NVIDIA?

Документация llama.cpp указывает, что производительность tensor должна быть хорошей на нескольких NVIDIA GPU с CUDA backend, для других конфигураций гарантий нет. Режим помечен как экспериментальный, и его не поддерживают многие архитектуры, включая MoE и гибридные модели. Перед развёртыванием проверьте качество вывода.