Pull to refresh
4K+
3

User

5,6
Rating
Send message

Экстрим обусловлен тем, что я хотел запускать Hermes, которому требуется контекстное окно минимум 65 000 токенов, и конкретно на модели Qwen3.6 27B.В моём случае мне достаточно одного потока.

В моём примере две карты с llama.cpp показывали загрузку 48–50% и выдавали примерно 32 токена в секунду. В свою очередь, vLLM загрузил обе карты на 100%, достигнув скорости 60 токенов в секунду.

Это при условии, что первая PCIe-шина работала в режиме 16x напрямую в процессор, а вторая была подключена через чипсет в режиме 4x. Пробовал конфигурацию 8/8 — разницы не заметил.

На ваших четырёх картах можно получить скорость генерации токенов выше, чем на RTX 5090, используя флаг --tensor-parallel-size  в vLLM. Добейтесь 100% загрузки карт, и вы увидите прирост.

На днях сделаю видео с тестами, где выложу конкретные цифры.

Ecли есть интерес давайте протестируем на ваших 4 картах.

Ну, это не правда. Всё, что вы видите в тексте, было надиктовано мной. Что именно вам не понятно в ответе?

В статье суммированы мои тесты за почти 4 дня. В каждом из ваших параметров я разобрался. Лично тестировал отличия vLLM и llama.cpp. Вот тут можете посмотреть один из моих тестов, записанных для знакомого: https://www.youtube.com/watch?v=45DjGF9OA0Q. Там использовалась одна карта, ещё без напечатанного кожуха для охлаждения. Еще раз коротко. llama.cpp вы использовали mtp vLLM вы его явно выключили. В моих тестах я не мог добится загрузки 2х карт на GPU 100% в одно и тоже время. Только vLLM смог с форком 1CAT поскольку без него, вы и vLLM на tesla v 100 вы не запустите Qwen3.6 из за проблем с совместимостью версий.

watch -n1 nvidia-smi вот вам команда для просмотра в риальном времени статуса GPU, протестируйте, вы увидите проблему что llama.cpp не грузит карты v100 GPU полность, а vLLM и --tensor-parallel-size 2 флаг смог.

Сумировала, правила грамматику данная unsloth/GLM-4.7-Flash-GGUF локальная модель.

Для многих облачное решение, безусловно, лучший выбор. Но от облака вы не получите приватность и возможность крутить "любые" модели, в том числе без цензуры.

Ключевое различие в твоих командах — спекулятивный декодинг. У llama.cpp включён MTP (--spec-type draft-mtp --spec-draft-n-max 4), а у vLLM ты MTP явно отключил (VLLM_1CAT_DISABLE_QWEN35_MTP_DEFAULTS=1 + cudagraph_capture_sizes:[5] без num_speculative_tokens). MTP даёт высокий accept rate, поэтому 60 ток/с против 45 — это в первую очередь сравнение «с MTP» против «без MTP», а не «llama.cpp против vLLM».

В чём смысл vLLM: tensor parallelism (--tensor-parallel-size 2) заставляет обе карты считать каждый токен одновременно, тогда как llama.cpp по умолчанию делит модель по слоям (layer-split) — пока считает одна карта, вторая ждёт. Но это преимущество видно не на single-stream, а на параллельной нагрузке: при --max-num-seqs 1 ты сам отключил continuous batching, главную фишку vLLM. Для одного запроса за раз выигрыша у vLLM нет — твой вывод про llama.cpp верный. vLLM начнёт обгонять, когда агент пойдёт слать параллельные запросы.

Верно, несколько разных карт llama.cpp/Ollama запустит без проблем — оно умеет раскладывать слои по любым устройствам через --tensor-split, и замечание про самую большую карту первой (или явный --main-gpu) тоже в точку: на main-устройство llama.cpp вешает KV-cache, промежуточные буферы и compute graph, поэтому при неправильном порядке оно недосчитывает и падает в OOM.

НО, как я и указывал, проблему это не решает: полной скорости от этих карт вы не получаете. По умолчанию llama.cpp использует layer split (--split-mode layer) — слои просто раскиданы по картам, и forward pass идёт последовательно: пока GPU0 считает свои слои, GPU1–3 простаивают, потом наоборот. Карты работают поочерёдно, одна считает — остальные ждут. На 4 картах это грубо ~25% загрузки на карту, суммарный throughput ≈ одной карте (плюс небольшой проигрыш на PCIe-пересылках активаций между слоями). Вы получаете суммарный объём памяти под большую модель, но не суммарную скорость.

Есть --split-mode row (tensor parallelism по строкам матриц) — он даёт реальную параллельную работу карт, но в llama.cpp реализован слабо: требует быстрый интерконнект (NVLink), плохо масштабируется на разнородных картах и часто оказывается даже медленнее layer split на PCIe. Для вашего винегрета из разных поколений он практически бесполезен.

Настоящий tensor parallel, где все карты молотят одновременно, — это vLLM с --tensor-parallel-size. Но он требует одинаковых карт и упирается в compute capability.

P.S. Про CUDA level полностью согласен: если у вас compute capability ≥ 8.0 (Ampere и новее — 3090 это SM86, A100 SM80), то форки не нужны, берёте основной upstream vLLM, он всё поддерживает из коробки (FP8, compressed-tensors AWQ, flash-attention 2 и т.д.). Форки вроде 1CatAI нужны именно для V100 (SM70), которые официально выпали из поддержки vLLM. Так что 3090 в этом миксе через vLLM завести проще, чем V100 — но смешивать SM70 и SM86 в одном tensor-parallel всё равно не выйдет, vLLM требует однородности.

V100 примерно в 17 раз дешевле 5090. Токенов/с с одной карты вы получите примерно 40% от 5090. На YouTube есть отличное сравнение этих карт, можете найти. Вы сравниваете RTX 5090 за +3000 $ и V100 за 120 $ плюс адаптер за 50 $.

Information

Rating
1,123-rd
Registered
Activity

Specialization

DevOps-инженер
Git
SQL
PostgreSQL
Docker
Linux
Python
Английский язык
REST
CI/CD
Django