Туториал: запускаем Hunyuan-A13B модель на vLLM и на llama.cpp

Недавно вышла новая модель – Hunyuan-A13B:

https://huggingface.co/tencent/Hunyuan-A13B-Instruct-GPTQ-Int4 ^[1] (это уже квант)

Это MOE (Mixture of Experts), размер модели – 80 миллиардов параметров, но для вычисление следующего токена используется ограниченное количество “экспертов”, которые активизируют только 13 миллиардов.

Я заметил, что когда выкатывают новые модели, то для них обычно готовят поддержку в таких движках, как vLLM, а вот для “народного” llama.cpp – поддержка приходит с задержкой в несколько недель.

vLLM

https://github.com/vllm-project/vllm ^[2]

Это более “энтерпрайзный” движок.

У него лучше сделано поддержка многих запросов одновременно.

В чём vLLM отличается от llama.cpp?

• llama.cpp поддерживает GGUF кванты, а vLLM – не очень (https://docs.vllm.ai/en/latest/features/quantization/index.html ^[3]).

• llama.cpp можно запустить так, чтобы выгрузить модель на одну или несколько GPU и частично в память ^[4]. У vLLM в этом плане намного меньше вариантов. Несколько одинаковых GPU поддерживается – а разные GPU, или GPU + RAM не запускаются. Может и есть какие “танцы с бубном” для таких вещей, но у меня не запустилось.

• vLLM лучше поддерживает одновременные запросы, более эффективно использует KV cache под каждый запрос.

Конкретно в случае с этой моделью, преимущество vLLM в том, что квант INT4 выпущен разработчиками модели, и как они пишут, натренирован этот квант был вместе с основной моделью, то есть качество выше, чем например у квантов GGUF.

Квант INT4 занимает 40GB VRAM. Плюс нужна память для контекста.

Получается, как минимум нужно 48GB VRAM. Тогда помещается контекст на 19500 токенов.

Я запускал на китайской поделке: RTX 4090D 48GB VRAM.

Запускаем vLLM в Docker compose

services:
vllm:
image: vllm/vllm-openai:latest
container_name: Hunyuan80B
deploy:
resources:
reservations:
devices:
- driver: nvidia
capabilities: [gpu]
ports:
- "37000:8000"
volumes:
- /home/user/.cache/huggingface:/root/.cache/huggingface
ipc: host
command:
- "--model"
- "tencent/Hunyuan-A13B-Instruct-GPTQ-Int4"
- "--trust-remote-code"
- "--quantization"
- "gptq_marlin"
- "--max-model-len"
- "19500"
- "--max-num-seqs"
- "4"
- "--served-model-name"
- "Hunyuan80B"

Я тестировал версию 0.9.2

Наверное оно должно запуститься если есть две карточки по 24GB. В этом случае надо будет добавить –tensor-parallel-size 2

Вам нужно будет поменять volumes на подходящий для вас.

Когда контейнер запуститься, то будут доступны только REST запросы. UI у vLLM нету.

И вам надо будет отправлять curl запросы, или использовать что-то типа OpenWebUI.

Запускаем llama.cpp в Docker compose

Разработчики llama.cpp недавно добавили поддержку этой модели, и есть уже разные кванты, но как-то народ пишет, что качество поддержки надо бы ещё улучшить.

https://github.com/ggml-org/llama.cpp ^[5]

Модель скачиваем вот здесь: https://huggingface.co/unsloth/Hunyuan-A13B-Instruct-GGUF ^[6]

Я использовал квант Q4_0. Размер – чуть больше чем INT4.

services:
llama-server:
image: ghcr.io/ggml-org/llama.cpp:full-cuda
container_name: hun80b
deploy:
resources:
reservations:
devices:
- driver: nvidia
capabilities: [gpu]
ports:
- "37000:37000"
volumes:
- /home/user/.cache:/root/.cache
entrypoint: ["./llama-server"]
command: >
--model /root/.cache/huggingface/hub/models--unsloth--Hunyuan-A13B-Instruct-GGUF/snapshots/14968524348ad0b4614ee6837fd9c5cda8265831/Hunyuan-A13B-Instruct-Q4_0.gguf
--alias Hunyuan80B
--ctx-size 19500
--flash-attn
--threads 4
--host 0.0.0.0 --port 37000
--n-gpu-layers 999

Скорость

Вот что у меня в логах vLLM:

Avg prompt throughput: 193.3 tokens/s, Avg generation throughput: 71.4 tokens/s

А вот что в логах llama.cpp:

prompt eval time = 744.02 ms / 1931 tokens ( 2595.36 tokens per second)
eval time = 29653.01 ms / 2601 tokens ( 87.71 tokens per second)

На одном запросе llama.cpp – быстрее. Проверять на многих запросах я не стал, это не мой сценарий, но вроде бы там vLLM должен проявить себя лучше, чем llama.cpp.

vLLM вроде бы ожидается будет иметь немного лучшее качество ответов, но тут я не уверен, как это протестировать.

По умолчанию, эта модель сначала “рассуждает” (reasoning), а потом – даёт ответ. Если вначале своего вопроса (query) написать “/no_think” – то модель рассуждать не будет, а будет отвечать сразу. Так получается намного быстрее. Это работает одинаково в обоих движках. Кстати, точно также “/no_think” используется и для моделей Qwen3.

Контекст

vLLM не сможет обработать контекста больше, чем помещается в GPU VRAM.

llama.cpp – если контекст не помещается в GPU VRAM, то можно разгрузиться на второй GPU, или в обычную память, хотя это будет значительно снижать скорость.

Заключение

Я – обычный пользователь, не эксперт. Тут на Хабре есть те, кто больше в теме. Поэтому критика, дополнения, рекомендации по использую других параметров и конфигурация – приветствуются.