Можно ли запустить современную 27-миллиардную модель и полноценного автономного агента на паре серверных ускорителей 2017 года, установленных в обычный десктоп через переходники? Короткий ответ — да, но с оговорками, которые важно знать заранее.
В этом материале я разбираю практический кейс: развёртывание Qwen3.6-27B на двух Tesla V100-SXM2-16GB под управлением автономного агента Hermes от Nous Research. Карты подключены к потребительской платформе через адаптеры SXM2→PCIe — конфигурация, которую несложно собрать дома, но которая накладывает жёсткие ограничения на доступную видеопамять и межкарточную пропускную способность.
По итогам эксперимента эту связку можно считать нижней границей практической применимости для локального запуска Hermes: всё работает, но ровно на пределе возможностей железа. Ниже — последовательный разбор всех подводных камней, рабочие конфигурации с готовыми командами и честный вывод о том, где проходит та самая стена, которую не обойти настройками.
Железо и цель
- Сервер: Proxmox, проброс (PCIe passthrough) двух карт в одну VM.
- GPU: 2× Tesla V100-SXM2-16GB через переходники SXM2→PCIe. CPU — Intel 6700k.
- Важная деталь: NVLink между картами нет (переходники выводят только PCIe-линии), и 6700k даёт всего 16 линий PCIe 3.0 → карты работают в режиме x8/x8.
- Цель: запустить Qwen3.6-27B-AWQ и подключить агента Hermes от Nous Research, которому нужно минимум 65 000 токенов контекста.
Проверить топологию и режим линий можно так (внутри VM, после установки драйвера):
nvidia-smi topo -m # между GPU0/GPU1 ждём NV*, а получили PHB = NVLink нет nvidia-smi -q | grep -A2 "Link Width" # Current: 8x = потолок межкарточного обмена
Грабля №1: «карты грузятся на 50%»
Классическая жалоба: при работе двух карт каждая загружена примерно наполовину. Причина — llama.cpp и подобные движки по умолчанию делят модель по слоям (pipeline/layer split): пока считает GPU0, GPU1 ждёт. Среднее — 50%.
Лечится переходом на tensor parallelism, где модель режется «поперёк» и обе карты считают каждый токен одновременно. В vLLM это флаг --tensor-parallel-size 2. Именно он даёт обеим картам реальные ~100% загрузки.
Грабля №2: новый vLLM не поддерживает Volta
Qwen3.6 требует vllm>=0.19.0, а свежий vLLM уже не поддерживает архитектуру Volta (sm_70) — падает при старте. Вдобавок AWQ-ядра (Marlin) требуют sm_80+. Решение — community-форк 1Cat-vLLM, который возвращает SM70-ядра внимания, AWQ под Volta и поддержку Qwen3.5/3.6.
Почему именно 1Cat-vLLM, а не другой движок
Здесь сходятся сразу несколько требований, и закрыть их все может только этот форк:
- Стоковый vLLM новых версий выкинул поддержку sm_70 — на V100 не стартует в принципе.
- Старый vLLM, который ещё поддерживал Volta, не знает архитектуру Qwen3.5/3.6 (Gated DeltaNet + MTP) — упадёт на «unknown architecture». Получается вилка: новый движок знает модель, но не знает железо; старый знает железо, но не знает модель.
- llama.cpp / GGUF заводится на V100, но Qwen3.6 в GGUF на момент экспериментов корректно не собиралась под этот гибрид, и tensor-parallelism там слабее.
- SGLang, TGI и прочие официально требуют sm_75+ для современных моделей.
1Cat-vLLM — единственный из доступных, кто одновременно закрывает обе стороны вилки: возвращает sm_70-ядра (TurboMind SM70 WMMA для AWQ) и содержит код под Qwen3.5/3.6 с MTP и mamba/GDN-слоями. Плюс он валидирован авторами именно на multi-GPU V100 (их бенчи — на 4×V100-16GB), то есть это не теоретическая совместимость, а проверенная на нашем же классе железа.
Установка — из готовых колёс (НЕ из исходников, это для разработчиков ядер):
# скачать оба.whl из релиза mkdir ‑p ~/wheels && cd ~/wheels curl ‑s https://api.github.com/repos/1CatAI/1Cat‑vLLM/releases/latest \ | grep browser_download_url | cut ‑d '“' ‑f4 | xargs ‑n1 wget” # поставить в conda‑среде python ‑m pip install ‑prefer‑binary ‑no‑cache‑dir \ ‑extra‑index‑url https://download.pytorch.org/whl/cu128 \ /flash_attn_v100-*.whl./vllm‑*.whl
Колёса тянут torch под CUDA 12.8 — это совместимо с рантайм-драйвером 580/CUDA 13, доустанавливать toolkit не нужно.
Почему именно AWQ, а не обычный 4-битный GPTQ
Это не вопрос вкуса — формат квантизации диктует само железо. На Volta (sm_70) большинство современных 4-битных схем просто не запускается:
- GPTQ-Int4 через Marlin-ядра требует sm_80+ (Ampere и новее). На V100 эти ядра не компилируются и не исполняются — стандартный «быстрый» путь GPTQ для нас закрыт.
- FP8-вычисления — это вообще Hopper (sm_90). На Volta из FP8 доступен только формат e5m2 для KV-кэша, и то с оговорками.
- GPTQ-Int8 заводится, но 8 бит на вес означают вдвое больший размер: 27B-модель в Int8 весит ~50+ ГБ и не влезает даже близко в 32 ГБ суммарной VRAM.
Остаётся AWQ 4-bit — и именно его «оживляет» форк 1Cat-vLLM: он интегрирует TurboMind SM70 WMMA-ядра и расширяет AWQ-слои vLLM так, чтобы 4-битный AWQ исполнялся на Volta. По сути это единственный 4-битный формат, который реально работает на V100.
Бонусом AWQ-4bit ужимает 27B до ~21 ГБ — только в таком виде модель вообще помещается в 2×16 ГБ. Поэтому весь поиск моделей шёл по простому правилу: Volta → только AWQ-4bit через 1Cat-форк → ищем AWQ-сборки нужных моделей (например, от QuantTrio).
Грабли по мелочи (на которых легко застрять)
- Мало RAM у VM. vLLM по умолчанию резервирует 4 ГБ swap на карту. Если у VM всего 8 ГБ RAM — падает с «Too large swap space». Дайте VM 24+ ГБ.
- fp8e4nv not supported. Volta умеет только FP8-формат e5m2. Поэтому KV-кэш в FP8 включается так: --kv-cache-dtype fp8_e5m2 (не просто fp8).
- No valid cudagraph sizes (кратность 5). Когда включён встроенный MTP (num_speculative_tokens=4), CUDA-графы должны захватываться размерами кратными 5. Ставьте --compilation-config '{"cudagraph_mode":"full_and_piecewise","cudagraph_capture_sizes":[5]}' или отключите MTP.
- Tool calling. Hermes шлёт tool_choice: auto, поэтому сервер надо поднимать с --enable-auto-tool-choice --tool-call-parser qwen3_coder --reasoning-parser qwen3.
Архитектурный сюрприз: почему 65k вообще влезают
Qwen3.6-27B — гибрид. Из 64 слоёв только 16 имеют обычное внимание с растущим KV-кэшем, остальные 48 — Gated DeltaNet (линейное внимание), у которого кэш не растёт с длиной контекста. Поэтому память под длинный контекст у неё в разы меньше, чем у обычной dense-модели, и 65k в принципе достижимы даже на 32 ГБ суммарной VRAM.
Что работает на 2×V100-16GB
После всех граблей мы получили рабочую конфигурацию: vLLM поднимается, отвечает по сети, Hermes ходит, tool-calls проходят, контекст 65k. Цена — отключённый prefix caching (об этом ниже).
CUDA_VISIBLE_DEVICES=0,1 \ VLLM_DISABLE_PYNCCL=1 \ VLLM_1CAT_DISABLE_QWEN35_MTP_DEFAULTS=1 \ python -m vllm.entrypoints.openai.api_server \ --model ~/models/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":[1]}' \ --host 0.0.0.0 --port 8000
Проверка контекста и теста:
curl -s http://127.0.0.1:8000/v1/models | python3 -m json.tool # max_model_len curl http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' \ -d '{"model":"qwen36","messages":[{"role":"user","content":"Привет!"}],"max_tokens":100}'
Реальные показатели: декод ~45 ток/с, обе карты под нагрузкой. Минус — каждый ход агент заново обрабатывает весь промпт (медленный prefill), потому что кэш отключён.
Где стена: 65k + prefix caching одновременно не выходит
Логичный шаг — включить prefix caching, чтобы статичный системный промпт + 60 инструментов Hermes не пересчитывались каждый ход. Но на 2 картах это не работает, и вот почему.
Prefix caching на этой гибридной модели функционирует только в паре с --mamba-cache-mode align. А align-режим добавляет память под выровненный кэш Gated DeltaNet. В сумме «веса 21 ГБ + 65k KV + align-буферы + временные буферы GDN-ядра» не помещаются в 32 ГБ. Сервер стартует (проверка KV проходит), но падает на первом же запросе в ядре chunk_gated_delta_rule:
RuntimeError: Triton Error [CUDA]: out of memory
Мы проверили это при gpu-memory-utilization 0.95 и 0.88, с разным контекстом — результат один. На 2×16GB честно невозможно иметь одновременно 65k контекста и работающий prefix cache. Три доступных режима:
Режим |
65k? |
Prefix cache? |
Итог |
65k без кэша (fp8, без align/MTP) |
да |
нет |
работает, но медленный prefill |
Кэш + align, контекст <65k |
нет |
да |
Hermes не стартует (нужен минимум 64k) |
65k + align |
стартует |
да |
падает в рантайме (OOM в GDN) |
Развилка и решения
Вариант А — жить с тем, что есть. Qwen3.6-27B на 65k без кэша. Полностью рабочий агент, просто первый токен каждого хода идёт через полный prefill (на x8 PCIe это ощутимо).
Вариант Б — взять модель поменьше. Память под кэш освобождает только меньшее число параметров (MoE-модели с A3B весят как полная модель — для памяти не помогают). Отличный кандидат — Qwen3.5-9B-AWQ (~6 ГБ): влезает с огромным запасом, и 65k + prefix cache + MTP реально заработают. Цена — качество 9B вместо 27B.
CUDA_VISIBLE_DEVICES=0,1 VLLM_DISABLE_PYNCCL=1 \ python -m vllm.entrypoints.openai.api_server \ --model ~/models/Qwen3.5-9B-AWQ --served-model-name qwen35-9b \ --tensor-parallel-size 2 --dtype float16 \ --gpu-memory-utilization 0.90 --max-model-len 65536 \ --enable-prefix-caching \ --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 \ --host 0.0.0.0 --port 8000
Вариант В — 3-я карта. С pipeline-параллелизмом (--pipeline-parallel-size 3 --tensor-parallel-size 1) веса 21 ГБ размазываются по ~7 ГБ на карту, освобождая память под всё сразу: 65k + prefix cache + MTP. Это единственный путь получить «27B + быстрый агент». Нюанс: --tensor-parallel-size 3 для этой модели невалиден (4 KV-головы не делятся на 3), поэтому именно pipeline.
Выводы
1. Современные LLM на старых V100 реально запускаются — спасибо community-форку 1Cat-vLLM и гибридной архитектуре Qwen3.6.
2. Tensor parallelism (--tensor-parallel-size 2) лечит «50% загрузки».
3. На 2×16GB без NVLink есть жёсткая стена: 65k контекста и prefix caching одновременно не помещаются. Это ограничение памяти, а не настроек.
4. Практический выбор: 27B медленно (без кэша), 9B быстро (с кэшем), или 3-я карта — и тогда 27B быстро.
Если ваша задача — фоновый агент в мессенджере, медленный prefill терпим. Если нужен интерактив «как ChatGPT» — берите модель поменьше или добавляйте карту. Железо честно диктует правила.
Конфигурация на момент написания: Proxmox + Ubuntu 22.04/24.04 в VM, 2× Tesla V100-SXM2-16GB (sm_70, x8 PCIe, без NVLink), драйвер 580 / CUDA 13, 1Cat-vLLM 1.1.0, Qwen3.6-27B-AWQ, Hermes Agent.
Комментарии (19)
moooV
05.06.2026 08:48Ну, и, да, hermes использую и сам - но квен27 для ежедневных задач (не кодинг) слишком туп. В итоге просто плачу гуглу за гемини 3.5 флеш по токенам и все равно выходит довольно дёшево.
А если у сяоми купить за 5 баксов план mimo-v2.5-pro то там такое количество токенов что
жопой жратьне выжрать.Экономику своего решения посчитайте
id4455000 Автор
05.06.2026 08:48Для многих облачное решение, безусловно, лучший выбор. Но от облака вы не получите приватность и возможность крутить "любые" модели, в том числе без цензуры.
Joysi
05.06.2026 08:48Немного похожая ситуация:
Есть ПК 64G DDR5 + 5070Ti (16G VRAM), показывает на локальном Qwen3.5-35B-A3B (под ollama) ~27tok-s. Хочется попробовать уже более толстые A10B и под рукой есть "запасная" 5060Ti-16Gb. Есть также возможность добить память до 128Gb (при апгрейде через месяц).
- Кто-нибудь игрался с конфигурацией 2 разные видеокарты (но одинакового объема) - реально ли "распихивать" слои по разным картам (карты одного семейства)?
svkreml
05.06.2026 08:48llama.cpp спокойно потребляет одновременно карты разных поколений и размеров, запускал такой винигрет: несколько V100 16GB, несколько V100 32GB и одну 3090. Правило только одно (по крайне мере для llama.cpp) -- первая ваша карта обязательно должна быть самой большой по памяти, или надо переопределить mainGpu, иначе там что-то может неправильно посчитать и выпасть в OOM так как llama.cpp на main грузит что-то ещё
P.S. ну и если у вас CUDA level больше 8, то вам надо не форки искать, а брать VLLM основной
id4455000 Автор
05.06.2026 08:48Верно, несколько разных карт 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 требует однородности.
svkreml
05.06.2026 08:48Не понял выгоду использования 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 (либо я что-то не так запустил)
nvidia-smi topo -m id4455000 Автор
05.06.2026 08:48Ключевое различие в твоих командах — спекулятивный декодинг. У 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 начнёт обгонять, когда агент пойдёт слать параллельные запросы.
dartraiden
05.06.2026 08:48Есть ещё CMP 50HX после майнинга, им распаивают удвоенный объём памяти и получается 20 ГБ на одну карту (попутно цена, конечно, взлетает вчетверо - с 4 до 16 тысяч).
AKimovd
05.06.2026 08:48Автору и статью и комментарии claude пишет похоже.
id4455000 Автор
05.06.2026 08:48Сумировала, правила грамматику данная unsloth/GLM-4.7-Flash-GGUF локальная модель.
svkreml
05.06.2026 08:48Мне ответы он тоже не читая через ИИ отвечал тут, обидно даже, с ИИ я и сам пообщаться приватно могу.
id4455000 Автор
05.06.2026 08:48Ну, это не правда. Всё, что вы видите в тексте, было надиктовано мной. Что именно вам не понятно в ответе?
В статье суммированы мои тесты за почти 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флаг смог.svkreml
05.06.2026 08:48А какая разница грузит он на 100% карты или нет, если производительность одинаковая? Тут ключевой вопрос в том, что вы предлагаете экстремальные параметры, то есть контекста хватает на один параллельный запрос, поэтому мой вопрос: зачем вам это что обе карты загружены на 100% если llama.cpp достигает той же производительности используя их попеременно, что позволяет им лучше успевать остывать?
P.S. если будут интересные эксперименты, можете обращаться, есть четыре карты v100 16, 4- 32 и 3090 сверху, всё подрублены x8 к epyc 7532
id4455000 Автор
05.06.2026 08:48Экстрим обусловлен тем, что я хотел запускать 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 картах.
svkreml
05.06.2026 08:48Откуда 60? У меня 60 не получилось, вы в статье тоже пишите "Реальные показатели: декод ~45 ток/с, обе карты под нагрузкой. Минус — каждый ход агент заново обрабатывает весь промпт (медленный prefill), потому что кэш отключён."
Да и без кэша печаль, я в обычно использую opencode и это всегда обработка следующего запроса как продолжение предыдущего, без кэша всё совсем печально было бы (использую Minimax 2.7 Q4, 300/50 где-то скорость вначале и 200/40 при достижении 200к контекста) , запускаю через lm-studio обычно.
Vllm не будет хорошо работать с тензорном параллелизмом без nvlink, а у меня в данный момент карты по две объединены , поэтому не уверен что можно обогнать llama.cpp с помощью vllm. Хотя я заказал плату на 4 для v100, где розни все будут соединены попарно, такое надо будет проверить может появится больше смысла.
moooV
Но зачем эти пляски с некрожелезом если на 5090 на банальной ламецпп на квене 3.6-27b-UD-4_K_XL спокойно у меня выдает 100 токенов/с с mtp на 128к контексте (q8_0+q8_0) или даже на 256 контексте если собрать с форком turboquant и использовать turbo4+turbo3 квантизацию контекста.
На 4090 выдает 75 т/с. На 3090 примерно 50, но стоит поддержанная 3090 уже просто копейки.
id4455000 Автор
V100 примерно в 17 раз дешевле 5090. Токенов/с с одной карты вы получите примерно 40% от 5090. На YouTube есть отличное сравнение этих карт, можете найти. Вы сравниваете RTX 5090 за +3000 $ и V100 за 120 $ плюс адаптер за 50 $.
igrblkv
есть же V100 на 32ГБ - почему не две таких? или одну на 16, одну на 32?
svkreml
Математика весьма интересная выходит, глобально скорее всего действительно одна на 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, а по каким критериям выбирал автор я не знаю). Возможно как и у меня, жаба душит покупать сразу что-то дорогое на тест,, а потом покупаешь ещё такую же, а потом становится в какой-то момент сложно остановиться, потому что памяти не может быть достаточно.