Недавно вышла новая модель — Hunyuan-A13B:
https://huggingface.co/tencent/Hunyuan-A13B-Instruct-GPTQ-Int4 (это ссылка на их квант).
По тестам — модель на уровне лучших:
Это MOE (Mixture of Experts), размер модели — 80 миллиардов параметров, но для вычисление следующего токена используется ограниченное количество «экспертов», которые активизируют только 13 миллиардов.
Я заметил, что когда выкатывают новые модели, то для них обычно готовят поддержку в таких движках, как vLLM, а вот для «народного» llama.cpp — поддержка приходит с задержкой в несколько недель.
vLLM
https://github.com/vllm-project/vllm
Это более «энтерпрайзный» движок.
У него лучше сделана поддержка многих запросов одновременно.
В чём vLLM отличается от llama.cpp?
llama.cpp поддерживает GGUF кванты, а vLLM — не очень (https://docs.vllm.ai/en/latest/features/quantization/index.html). vLLM поддерживает кванты INT4, с которыми llama.cpp вообще не работает.
llama.cpp можно запустить так, чтобы выгрузить модель на одну или несколько GPU и частично в память. У 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.
Запускается движок довольно долго — около трёх минут.
Если нет GPU на 48GB, то наверное оно должно запуститься и на двух карточках по 24GB. В этом случае надо будет добавить --tensor-parallel-size 2
Вам нужно будет поменять volumes на подходящий для вас.
Когда контейнер запустится, то будут доступны только REST запросы. UI (пользовательского интерфейса) у vLLM нету.
И вам надо будет отправлять curl запросы, или использовать что-то типа OpenWebUI.
Запускаем llama.cpp в Docker compose
Разработчики llama.cpp недавно добавили поддержку этой модели, и есть уже разные кванты, но как-то народ пишет, что качество поддержки надо бы ещё улучшить.
https://github.com/ggml-org/llama.cpp
Модель скачиваем вот здесь: https://huggingface.co/unsloth/Hunyuan-A13B-Instruct-GGUF
Update (10 июля): Разработчики модели выпустили собственные GGUF кванты: https://huggingface.co/tencent/Hunyuan-A13B-Instruct-GGUF
Я использовал квант Q4_0. Размер — чуть больше чем INT4.
Загрузить можно прямо с вебсайта, или например вот так:# 45GBhuggingface-cli download unsloth/Hunyuan-A13B-Instruct-GGUF --include "Hunyuan-A13B-Instruct-Q4_0.gguf"
Или
# 49GBhuggingface-cli download tencent/Hunyuan-A13B-Instruct-GGUF --include "Hunyuan-A13B-Instruct-Q4_K_M.gguf
Compose manifest: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 --jinja --temp 0.7 --top-k 20 --top-p 0.8 --repeat-penalty 1.05 --flash-attn --threads 4 --host 0.0.0.0 --port 37000 --n-gpu-layers 999
У llama.cpp есть неплохой UI, который можно открыть в браузере и использовать для запросов.
Скорость
Вот что у меня в логах vLLM:
Avg prompt throughput: 193.3 tokens/s, Avg generation throughput: 71.4 tokens/s
А вот что в логах llama.cpp:
Для кванта unsloth Q4_0 на 45GB:
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)
Для кванта tencent Q4_K_M на 49GB:
prompt eval time = 1174.69 ms / 1930 tokens ( 1642.98 tokens per second) eval time = 34680.68 ms / 2161 tokens ( 62.31 tokens per second)
На одном запросе llama.cpp — быстрее. Проверять на многих запросах я не стал, это не мой сценарий, но вроде бы там vLLM должен проявить себя лучше, чем llama.cpp.
vLLM вроде бы ожидается будет иметь немного лучшее качество ответов, но тут я не уверен, как это протестировать.
По умолчанию, эта модель сначала «рассуждает» (reasoning), а потом — даёт ответ. Если вначале своего вопроса (query) написать «/no_think» — то модель рассуждать не будет, а будет отвечать сразу. Так получается быстрее. Это работает одинаково в обоих движках. Кстати, точно также «/no_think» используется и для моделей Qwen3.
Контекст
Сама модель поддерживает максимальный размер контекста — 262144 токенов.
vLLM не сможет обработать контекста больше, чем помещается в GPU VRAM.
llama.cpp — если контекст не помещается в GPU VRAM, то можно разгрузиться на второй GPU, или в обычную память, хотя это будет значительно снижать скорость. У себя на RTX 4090D 48GB + RTX 3090 24GB я смог запустить Q4_0 квант с контекстом 163840 токенов.
Заключение
Я — обычный пользователь, не эксперт. Тут на Хабре есть те, кто больше в теме. Поэтому критика, дополнения, рекомендации по использую других параметров и конфигурация — приветствуются.