Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 20
Можно ли запустить современную 27-миллиардную модель и полноценного автономного агента на паре серверных ускорителей 2017 года, установленных в обычный десктоп через переходники?
Но зачем эти пляски с некрожелезом если на 5090 на банальной ламецпп на квене 3.6-27b-UD-4_K_XL спокойно у меня выдает 100 токенов/с с mtp на 128к контексте (q8_0+q8_0) или даже на 256 контексте если собрать с форком turboquant и использовать turbo4+turbo3 квантизацию контекста.
На 4090 выдает 75 т/с. На 3090 примерно 50, но стоит поддержанная 3090 уже просто копейки.
V100 примерно в 17 раз дешевле 5090. Токенов/с с одной карты вы получите примерно 40% от 5090. На YouTube есть отличное сравнение этих карт, можете найти. Вы сравниваете RTX 5090 за +3000 $ и V100 за 120 $ плюс адаптер за 50 $.
есть же V100 на 32ГБ - почему не две таких? или одну на 16, одну на 32?
Математика весьма интересная выходит, глобально скорее всего действительно одна на 32 будет дешевле, чем две по 16,
Выходит примерно так: на две это корпус(3000)+два охлаждения (3000*2) + плата на две (15к) + провода 8654(1500*2) + плата в комп (2000 или 10к PLX плата если нет бифуркации), + 2карты хз сколько сейчас, пусть будет 10к, итого два по 16 стоит почти 50к со всеми прибабахами. Одна на 32 стоит наверное примерно 55-60к с пошлиной+3000охлад+2к переходник в pcie. 32 выходит дороже, но проще. Ещё надо помнить что V100 всегда в режиме P0 и жрут в простое 40-60вт.
Вывода не будет, но математика примерно такая. ( Это с точки зрения что жаба душит брать по 32, а по каким критериям выбирал автор я не знаю). Возможно как и у меня, жаба душит покупать сразу что-то дорогое на тест,, а потом покупаешь ещё такую же, а потом становится в какой-то момент сложно остановиться, потому что памяти не может быть достаточно.
Ну, и, да, hermes использую и сам - но квен27 для ежедневных задач (не кодинг) слишком туп. В итоге просто плачу гуглу за гемини 3.5 флеш по токенам и все равно выходит довольно дёшево.
А если у сяоми купить за 5 баксов план mimo-v2.5-pro то там такое количество токенов что жопой жрать не выжрать.
Экономику своего решения посчитайте
Немного похожая ситуация:
Есть ПК 64G DDR5 + 5070Ti (16G VRAM), показывает на локальном Qwen3.5-35B-A3B (под ollama) ~27tok-s. Хочется попробовать уже более толстые A10B и под рукой есть "запасная" 5060Ti-16Gb. Есть также возможность добить память до 128Gb (при апгрейде через месяц).
- Кто-нибудь игрался с конфигурацией 2 разные видеокарты (но одинакового объема) - реально ли "распихивать" слои по разным картам (карты одного семейства)?
llama.cpp спокойно потребляет одновременно карты разных поколений и размеров, запускал такой винигрет: несколько V100 16GB, несколько V100 32GB и одну 3090. Правило только одно (по крайне мере для llama.cpp) -- первая ваша карта обязательно должна быть самой большой по памяти, или надо переопределить mainGpu, иначе там что-то может неправильно посчитать и выпасть в OOM так как llama.cpp на main грузит что-то ещё
P.S. ну и если у вас CUDA level больше 8, то вам надо не форки искать, а брать 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 требует однородности.
Не понял выгоду использования vllm вместо llama.cpp для однопоточного выполнения: у меня по данной инструкции для команды:
CUDA_VISIBLE_DEVICES=0,1 VLLM_DISABLE_PYNCCL=1 VLLM_1CAT_DISABLE_QWEN35_MTP_DEFAULTS=1 python -m vllm.entrypoints.openai.api_server --model QuantTrio/Qwen3.6-27B-AWQ --served-model-name qwen36 --tensor-parallel-size 2 --dtype float16 --kv-cache-dtype fp8_e5m2 --gpu-memory-utilization 0.92 --max-model-len 65536 --max-num-seqs 1 --max-num-batched-tokens 512 --trust-remote-code --attention-backend TRITON_ATTN --disable-custom-all-reduce --skip-mm-profiling --limit-mm-per-prompt '{"image":0,"video":0}' --enable-auto-tool-choice --tool-call-parser qwen3_coder --reasoning-parser qwen3 --compilation-config '{"cudagraph_mode":"full_and_piecewise","cudagraph_capture_sizes":[5]}' --host 0.0.0.0 --port 8000
вышло примерно 40-45 токенов в секунду. а при запуске с llama.cpp выходит около 60 (в обоих случаях промпт "write snake game")
CUDA_VISIBLE_DEVICES=0,1 ~/llm/llama.cpp/bin/llama-server -m /mnt/llm/lmstudio/models/unsloth/Qwen3.6-27B-MTP-GGUF/Qwen3.6-27B-Q4_K_M.gguf --host 0.0.0.0 --port 8080 --spec-type draft-mtp --spec-draft-n-max 4 -c 260000
Поэтому не совсем понятна выгода vllm в данном случае над llama.cpp (либо я что-то не так запустил)
Ключевое различие в твоих командах — спекулятивный декодинг. У 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 начнёт обгонять, когда агент пойдёт слать параллельные запросы.
Есть ещё CMP 50HX после майнинга, им распаивают удвоенный объём памяти и получается 20 ГБ на одну карту (попутно цена, конечно, взлетает вчетверо - с 4 до 16 тысяч).
Автору и статью и комментарии claude пишет похоже.
Сумировала, правила грамматику данная unsloth/GLM-4.7-Flash-GGUF локальная модель.
Мне ответы он тоже не читая через ИИ отвечал тут, обидно даже, с ИИ я и сам пообщаться приватно могу.
Ну, это не правда. Всё, что вы видите в тексте, было надиктовано мной. Что именно вам не понятно в ответе?
В статье суммированы мои тесты за почти 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 флаг смог.
А какая разница грузит он на 100% карты или нет, если производительность одинаковая? Тут ключевой вопрос в том, что вы предлагаете экстремальные параметры, то есть контекста хватает на один параллельный запрос, поэтому мой вопрос: зачем вам это что обе карты загружены на 100% если llama.cpp достигает той же производительности используя их попеременно, что позволяет им лучше успевать остывать?
P.S. если будут интересные эксперименты, можете обращаться, есть четыре карты v100 16, 4- 32 и 3090 сверху, всё подрублены x8 к epyc 7532
Экстрим обусловлен тем, что я хотел запускать 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 картах.
Откуда 60? У меня 60 не получилось, вы в статье тоже пишите "Реальные показатели: декод ~45 ток/с, обе карты под нагрузкой. Минус — каждый ход агент заново обрабатывает весь промпт (медленный prefill), потому что кэш отключён."
Да и без кэша печаль, я в обычно использую opencode и это всегда обработка следующего запроса как продолжение предыдущего, без кэша всё совсем печально было бы (использую Minimax 2.7 Q4, 300/50 где-то скорость вначале и 200/40 при достижении 200к контекста) , запускаю через lm-studio обычно.
Vllm не будет хорошо работать с тензорном параллелизмом без nvlink, а у меня в данный момент карты по две объединены , поэтому не уверен что можно обогнать llama.cpp с помощью vllm. Хотя я заказал плату на 4 для v100, где розни все будут соединены попарно, такое надо будет проверить может появится больше смысла.
А как с охлаждением SXM2 в десктопе вышло
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Tesla v100 SXM2 X2 32GB total