Comments 61
В целом да, там забавный момент, что в последних релизах, Ollama настолько обнаглели, что перестали писать , что их движок написан на llama.cpp :)
Но могу ошибаться, им уже дали по бошке и они это должны вернуть.
Я почему на Ollama написал - она банально проще в запуске. Понятно, что можно было и получше домашнюю работу проделать и уже добить топик, сделав бенчмарки на llama.cpp , но вот не дошли руки.
Скорость llama.cpp vs Ollama примерно в 1.5 и бывает в 2 раза больше. Не скорость, а t/s имею в виду.
а вот vllm вообще не получилось запустить, описал внутри об этом. Там прям ну нереально
Здесь обычный десктопный i7-10700K на Z490/Z590
На консьюмерских материнских платах обычно не бывает двух полноценных x16 слотов. Или один х16 или x8/x8. Что для multigpu без nv-link нехорошо.
~3K / 5K / 10K / 14K токенов на входе
У вас очень специфичные задачи с микроскопическими объёмами в запросах к LLM.
Проще и очень дёшево было бы юзать облачные провайдеры.
В облаках сегодня апи работает, а завтра они прайсинг меняют или аккаунт банят без обьяснений. Своя железка дает хоть какую-то предсказуемость бюджетов)
Для продвинутого использования ллм провайдеры не подходят, ибо ты не можешь щупать саму модель (файнтюнить под свои задачи к примеру), а так да, для агентных сценариев нужно хотя бы 100к контекстное окно, хотя вроде турбоквант от гугла пытается как раз эту проблему решить, надо бы поизучать этот вопрос
Хороший материал, особенно ценно, что есть не только смета, но и сырые прогоны.
Я бы, наверное, отдельно вынес в бенчах влияние межкарточного обмена. Для 2×V100 без NVLink результат сильно зависит не только от суммарных 64 ГБ VRAM, но и от того, как конкретный стек раскладывает модель: tensor parallel, pipeline parallel, offload, частота синхронизаций между GPU и размер контекста.
На consumer-платформе x8/x8 по PCIe это может быть почти незаметно для одних сценариев и очень больно для других. Было бы интересно увидеть рядом с tokens/s ещё:
вывод
nvidia-smi topo -m;PCIe generation / lanes для каждой карты;
P2P bandwidth/latency test;
сравнение одной и той же модели, если она помещается: 1×V100 vs 2×V100 TP=2;
отдельный прогон на длинном контексте, где обмен между картами может проявиться сильнее.
Тогда статья закрывала бы не только вопрос “можно ли собрать 64 ГБ VRAM за 200к”, но и более практичный вопрос: где именно 2×V100 без NVLink остаётся выгодным решением, а где уже лучше смотреть в сторону SXM2/NVLink или другой архитектуры.
2× Tesla V100 32GB дают 64 ГБ VRAM суммарно — столько же, сколько три RTX 5080 16GB, и дешевле.
Четыре
Ошибочка в математике не 3, а 4. Тут дело даже не в цене, а дальнейшей реализации на вторичке.
Дело в шинах pcie, у epyc 9000 их всего 192, это 12 полных шин. С nvlink x4 (оно работает, у меня пока собрано 32*2) можно собрать сервер на 1.5 ТБ видеопамяти (и ~20квт электрической мощности). В теории могут появиться платы на 8 v100. Ещё на sxm2 можно поиграть в pcie3-pcie5 (то есть получить полную шину до самой карточки)
Для обзора возможностей и про железо написано отлично! Но почему такие устаревшие модели?
Qwen2.5 когда актуальные 3.5 и 3.6.
Gemma3 и о боги даже Gemma2! Когда есть Gemma4-4b которая уделывает даже Gemma3-27b и при этом летает на одном CPU без GPU.
И почему 32GB много, когда даже маленькая Gemma4-31b требует одну H100 на 80GB (без квантования)? Ну минимум то хотя бы 40-48GB надо. Что уж говорить о моделях 70b и 120b. А это ещё даже не DeepSeek свежий с её 1,4T.
Ну хорошо, вы подбирали под свои задачи - маленькие модели, старенькие модели. Но неужели вас не интересует размер контекста? А он как раз любит дополнительную память.
Спасибо за комментарий, хорошее наблюдение.
Конечно логичнее было бы сначала что-то посвежее прогнать. Я сделал там в Бенчах qwen3. Сейчас вышла уже 3.6. Но у меня немного не хватило сил еще 10-15 моделей засунуть в обзор…
Я там ссылку оставил на гит с таблицей. Как руки дойдут, дополню еще моделями!
Увидел также до этого про контекст вопрос. Можно было бы добавить и побольше запросы, согласен. Я учту на будущее, и добавлю в существующую табличку на гите потом плюс тесты с контекстом 32к+, где позволит, конечно.
Но ведь там далеко не все старые модели же, в обзоре.
Но опять же, учту и спасибо за полезный комментарий
Найдите в себе силы уйти от ollama, а использовать последние версии llama.cpp, у ollama плохой бакграунд и история, говорят у них медленнее работает и они что то там идеологически нарушают, нехорошо обижать разработчиков llama.cpp на которых весь мир держится.
Настоятельно рекомендую qwen3.6-35b-a3b, она у вас должна пойти впритык с оригинальными весами но с llama.cpp она может влезть в одну карту с квантизацией (вопрос только сколько контекста без ошибок сможет обслуживать параллельно), по моему мнению это лучшая на текущий момент модель, которую можно запускать на доступном железе до 200-300т.р и способная стабильно работать в агентском режиме (qwen coder, opencode, letta,..) пока контекстное окно не превышает 65к..96к токенов (работать может и до своего капа в 200к токенов но качество в этом режиме сильно падает)
Скрытый текст
например эта модель у меня сумела решить задачу извлечения данных из ozon.ru через браузерный cdp, а это не просто, нащупав проблему сокрытия информации за shadow root и проблемы с симуляцией действий мыши, она увидела что под капотом vue и копаясь напрямую в ее переменных, отреверсила и извлекла полноценно из списка результата поиска карточки с картинками (их там по 6 на каждую, одну легко но все шесть нет).
Еще, с ее помощью я успешно анализировал исходники llama.cpp. например она решала задачу прогноза затрат токенов на основе mmproj выбранной модели и размера изображения (т.е. что бы к примеру понять когда нужно перестать докидывать изображения в контекст и пора задавать вопрос, так как после 8к токенов качество ответа сильно падает).
Она дает советы по опциям сборки, и буквально способна в цикле оптимизировать работу сервера (я успешно заставлял ее перед запуском тестов выгружать модель, которая обслуживает ее саму, загружать тестируемую сборку, а после загружать обратно, это буквально процесс, когда модель свои мозги на полочку складывает а затем возвращает обратно, любая ошибка - остановка работы)
Еще рекомендую последнюю модель от гугла google/gemma-4-26b-a4b, почему то в llama.cpp она у меня не работает (не хватает 2x16gb) но работает в lmstudio, агентские задачи у нее плохо получаются, но перевод текстов с инструкциями мне понравился, очень похоже, что под капотом google translate и онлайн перевода веб сайтов, именно она.
В целом да, там забавный момент, что в последних релизах, Ollama настолько обнаглели, что перестали писать , что их движок написан на llama.cpp :)
Но могу ошибаться, им уже дали по бошке и они это должны вернуть.
Я почему на Ollama написал - она банально проще в запуске. Понятно, что можно было и получше домашнюю работу проделать и уже добить топик, сделав бенчмарки на llama.cpp , но вот не дошли руки.
Скорость llama.cpp vs Ollama примерно в 1.5 и бывает в 2 раза больше. Не скорость, а t/s имею в виду.
а вот vllm вообще не получилось запустить, описал внутри об этом. Там прям ну нереально
у меня gpt-oss-20b залезает без проблем на мой игровой ноут с 4 гб видео, и 16 гб оперативы, впрочем там очевидно квантованная версия, вроде 4-бит но точно не помню. На коротком горизонте отлично щелкает довольно сложные задачи, хотя на длинных агентных сессиях с высокой вероятностью начнет плыть. В целом сжимание весов большие модели переносят лучше чем маленькие, но маленькие чаще всего сильно сжимать нет нужды в принципе
И все же 2-3 3090 за те же деньги будут более предпочтительными и тезисы про то "что их гоняли лайнеры, а они не предназначены" не состоятельны. И у 3090 есть существенные плюсы: 1. Они существенно производительней V100 2. Они имеют рассчитанную систему охлаждения и тише 3. Если нужна водянка, то есть качественные водоблоки, а не поделие от дядюшки Ляо. 4. Нет геморроя с запуском vllm и llamacpp
На самом деле сложно без прямых тестов. Я вот раньше тоже так думал, но погоняв 5060ti + 3080 (слепил из того что было так сказать) - обнаружил что - карты не греются, и под нагрузкой, вместе потребляют мало, даже вертушки не разгоняют. Я так понимаю для инференса все равно не вся площадь чипа используется, так что про охлаждение аргумент точно сомнительный. Да и про существенно большую производительность - тоже. В идеальных условиях да, себя по текстам - 15-30%, но учитывая что в сборке и остальное железо не идеальное, узким местом может стать не гпу и эффект может быть и не очень существенный.
Точно сборка с более чем 2мя гпу на стандартных материнках - плохая идея, даже с 2мя танцы с бубном у меня были знатные (хотя у меня ещё разная архитектура сыграла, не делайте так). В майнинга то все карты подключались по x1, а для инференсе - это будет узким местом, и для 3х 3090 чтобы набрать те-же 64гб весь выигрыш от скорости чипов может съесть деление шины pci-e, а весь выигрыш цены - необходимость материнки, в которую 3 карты встанут нормально (даже чисто физически в большинстве случаев они не влезут без райзеров).
Короче 1 карта это в разы проще чем 2 а 2 - существенно проще чем 3, чисто по цифрам выводы нужно делать очень осторожно.
Если у вас нормально все настроено, то утилизация GPU будет стремиться к 100%, а вместе с этим будет расти и нагрев. Проверено лично. В инференсе, если не делать деление по тензорам, ширина шины не имеет значения, она активно используется только при загрузке модели и ее warmup, далее обмен инфой мизерный. А по поводу V100 в китайских корпусах с дудкой где проверено что они перегреваются и троттлят
Согласен с вами, я ведь вроде упомянул в статье, что банально у v100 есть очень серьезное ограничения из-за ее старой архитектуры.
Но цель статье все таки обзор написать на сам видеопроцессор в целом, ведь когда-то и он в свое время стоил в как «крыло от Боинга». Интересно было поработать с ней
Три 3090 физически не встанут в десктопную мать без райзеров и жуткого колхоза. А сборка серверной платформы под них утащит бюджет далеко за пределы 200к
3 3090 и в серверный корпус 4U не влезут без колхоза и рейзеров. И в серверную мать даже если там выведены порты PCI-E 16х в нужном количестве тоже с вероятностью 99% их без рейзеров вы сами не будете ставить - из-за толщины данных видеокарт и из-за особенностей их охлаждения. Поэтому сборка хоумлабы под LLM это всегда, как вы выразились "жуткий колхоз". Но впрочем, и что в этом такого?
У меня самое дешманское открытое шасси с Али, мать Machinist X99 и три видеокарты, одна из которых стоит над другими на напечатанном креплении, и подключается к PCIe удлиннителем 20см. Отлично работает. Я бы мог подключить ещё одну, но смысла в этом не очень много.
Картина ожидаемая: топ забирают модели до 2B, где decode упирается уже не в карту, а в пропускную способность HBM2 (900 ГБ/с) и накладные расходы рантайма. С 4B начинается перелом — контекст ощутимо съедает скорость.
Только из ваших же цифр следует, что у более крупных лучше КПД генерации относительно размера модели:
qwen3:0.6b-q4_K_M - 190
qwen3:1.7b-q4_K_M - 166
Разница в размере почти в 3 раза, разница в скорости - 1.14 раза
gemma3:1b - 197
gemma3:4b - 119
Разница в размере в 4 раза, в скорости - в 1.6 раза.
Т.е. более крупные модели “выгоднее” запускать - лучше утилизация пропускной способности памяти.
(1024×1024, V100), SDXL-base-1.0, 26 сек - ну качество так себе :)
Это без LoRA и ControlNet, просто текстовый промпт на уже загруженной модели?
Главный вопрос - это сколько steps (шагов) генерации?
Просто почти пол минуты на такое разрешение это как-то очень медленно выглядит для такого бюджета.
Тестирование какое-то бессмысленное.
Из маленьких рабочих LLM сейчас только Qwen3.6-27b и для нее хватит одной RTX3090, в кванте Q4_K_M и контекст [128000 q8_0] - prefil=980tok/s tg=30tok/sec вполне достаточно. Чуть хуже по мозгам Gemma4-31b, и еще слабее Qwen3.5-35b и Gemma4-26 но они работать будут намного быстрее, даже в большем кванте. Все цифры получены с llama.cpp
Для двух RTX3090, Qwen3.6-27b в кванте Q8 и контексте [256000 q8_0] --- prefill=1500tok/sec tg=33tok/sec, для Q4_K_M prefil==1500tok/sec tg=24tok/sec.
C MTP работает нестабильно, вплоть вылета с жесткой перезагрузки компа.
Все модели типа Qwen3.5-122b, Qwen3.5-397 по мозгам хуже Qwen3.6-27b, при чем Qwen3.5-397 немного хуже, Qwen3.5-122b еще немного хуже. Ну это кроме того что они еще и медленнее будет работать у вас, хотя сырых знаний в этих моделях, больше, но в кодинге это им несильно помогает.
То есть на слабом железе у вас выбор крайне ограничен:
Qwen3.6-27b, Gemma4-31b, Qwen3.6-35b ну и еще может Gemma4-26b
Для всего остального желательно RAM > 220Gb, быстрой DDR5 типа DDR6000 тогда, на двух RTX3090 + i7 265k + DDR5-6000 220Gb = 2x64gb+2x48Gb: (для RTX3090 снижен PW до 270 и память разогнана немного) - с медленной RAM у вас будет маленький prefill, есть VRAM недостаточно, да и еще желательно быстрый NVME на PCIе 5.x
Qwen3.5-122b Q5_K_XL tg=17t/s
Qwen3.5-397b Q4_k_M=9t/s
MiniMax-M2.7 Q4_k_XL=10t/s; Q4_K_M=13t/s [ctx=128000 q8_0] prefill=300t/s
MiMo-V2.5 Q4_K_M=8t/s; IQ4_XS=10t/s [ctx=128000 q8_0] prefill=254t/s
GLM-4.7 Q3_K_XL=5t/s IQ4_XS=5t/s [ctx=64000 q8_0] prefill=160t/s
GLM-5.1 IQ3_XXS=4t/s [ctx=64000 q8_0] prefill=19t/s
По моделям, про Qwen3.5 я уже написал, MiniMax-M2.7 примерно на уровне Qwen3.6-27b по моим тестам, но возможно сырых знаний у нее больше, но она НЕ умнее.
MiMo-v2.5 поумнее немного, но она и больше, про GLM вы и сами знаете.
Кстати где видел инфу что Qwen3.6-Plus это модель типа Dense-70b, поэтому видимо ее и не выложили, чтобы не обрушить рынок продажи токенов. Видимо знания туда тромбовали всем Китаем.
А что если я хочу быстро на GLM-5.1-IQ3_XX3
Да запросто нужно 2шт RTX6000 96Gb и у вас будет prefill=95t/s tg=16t/s -- это я тестировал на арендованном сервере, но думаю что низкая скорость prefill, как то связана с виртуализацией, потому что на всех арендованных серверах, скорость всегда меньше, иногда намного чем на моем локальном компе.
А вот если LLM влезает в VRAM почти полностью, то к примеру
MiMo-v2.5 Q4_K_XL на 2хRTX6000 96Gb дает prefil=3400t/s tg=74t/s, а на одной RTX6000 96Gb то есть тут влезла наполовину, уже prefill=77t/s tg=29t/s но я не уверен что это нормально, что-то на серверах которые сдают в аренду очень плохо настроено, не должно такого сильного падения быть я думаю. Буду тестировать потом на своем, когда расширю у себя VRAM до 100Gb.
Да кстати сейчас и получше карты есть недорогие, те же AMD MI50 на 16gb и 32Gb
У автора специфика немного другая, им нужно много мелких транскриптов обрабатывать, но без быстрой памяти эти бюджетные сборки реально быстро превращаются в тыкву
скорее всего провайдеры не расчитывали настройку сервера для инференса - там нужно память во все слоты / диск быстрый очень + биос ковырнуть, короче говоря специальные сборки под инференс делать - будет очень быстро
2 недели уже работаю с qwen3-27b-MTP в llama.cpp (мастер ветка), нагенерил уже более 20 млн токенов и никаких проблем не наблюдаю, никаких вылетов, никакого аномального поведения по сравнению с "ванильным" квеном. Единственное, что нужно учитывать, что с MTP потребление памяти будет чуть выше - поэтому на первых порах, когда подбирал оптимальные настройки, то мониторил потребление ресурсов (nvtop) и пришлось понизить немного размер контекста, чтобы точно укладываться в видеопамять.
Вы JSON, XML (для tool call) пробовали генерировать? Я пытался в opencode ее заставить по подробному prompt'у что-то кодить, так qwen3.6-27b (FP8, официальные .safetensors от самого разработчика, крутятся в vLLM) постоянно возвращает некорректный XML, из-за чего opencode останавливается с ошибкой раз в несколько минут (а расширение Cline в Visual Studio Code показывает предупреждение "используйте Claude / Chat GPT, ибо ваша модель не справляется со сложными запросами").
С unlsoth/MiniMax-M2.7-GGUF/MiniMax-M2.7-UD-IQ4_XS (крутится в llama.cpp) таких проблем нет — всегда сама до конца доходит (ну, пока я не подобрал ограничение на контекст, чтоб по памяти не падала).
И еще заметил: если заставить модель обрабатывать сотни файлов по какому-то алгоритму в том же самом opencode, Qwen 3.6 27B после пятого файла начинает жаловаться, что задача трудоемкая и пытается "срезать углы", сочиняя (несуществующие) команды для regexp, массовой замены и еще какую-то фигню вместо того, чтоб просто действовать по инструкции.
заставить модель обрабатывать сотни файлов по какому-то алгоритму
потому что по умолчанию opencode и другие агенты пытаются файлы в контекстное окно запихнуть, и уже после 65к токенов начинается сильная просадка по качеству.
делайте /compact в узловых местах беседы (дошли до какой то точки - сжали контекст), разделяйте задачу по разным агентам, вместо решения всей задачи в одном окне пусть их будет несколько.
вам нужно строит задачу исходя из этого ограничения, с самого начала объясните модели что файлы объемные и напрямую работать с ними не нужно, пусть проведет исследование, проанализирует форматы (у меня qwen3.6-35b-a3b неплохо работал с xml).
И главное, это слабые модели, даже то что qwen3.6 показывает потрясающую стабильность, они все еще слабы в архитектуре... в конечном счете алгоритм должны создать вы, не важно как и на каком языке.
Под две 3090 уже лучше vLLM разворачивать. Да, неудобно переходить, но приросты огромные.
Qwen3.6-27B-AWQ-BF16-INT4 220к токенов контекста с MTP на 4 токена. Я не запускал чистый бенчмарк, но по логам при реально использовании видно, что promt processing иногда 5000+ токенов в секунду. Token generation в среднем около 60 тк/с, минимум около 40 тк/с, максимум 90 тк/с при написании текста, который легко предсказать, например код и правки в нём
AMD MI50 дороже, проблемы с поддержкой, и куда как сложнее найти.
У меня на V100 32Gb SXM2 скорость генерации на голой llama.cpp server была примерно вдвое выше, чем на ollama с той же моделью.
Не брали в расчеты 2хА5000 (ampere) + nvlink (что дает суммарно дает 48 vRAM) и является золотой серединой + поддержка нативно всего софта
Убить целую неделю на попытки завести vLLM, чтобы в конце плюнуть и уйти на Ollama с GGUF - типичные будни сурового ML-инженера на сэкономленном бюджете)
Что на счет рабочего применения, чем загружены ежедневно, есть доход и окупаемость? Есть финансовое преимущество перед покупкой токенов дорогих качественных моделей ?
Спасибо за статью!)) Раньше были некоторые сомнения, но теперь окончательно убедился, что выбрал 2х RTX3090 вместо 2х V100 абсолютно правильно.
Я работаю с моделью unsloth\Qwen3.6-27b-MTP-UD-Q8_K_XL.gguf (35 ГБ), настройки llama.cpp следующие, кому интересно:
-m "/mnt/AI/LLM/models/llama/unsloth/Qwen3.6-27b-MTP/Qwen3.6-27B-Q8_0.gguf" \
--mmproj "/mnt/AI/LLM/models/llama/unsloth/Qwen3.6-27b-MTP/mmproj-BF16.gguf" \
--spec-type draft-mtp --spec-draft-n-max 6 \
--spec-draft-p-min 0.75 \
--alias Qwen3.6-27B-mtp \
--host 0.0.0.0 \
--port 8080 \
-c 131072 \
--n-gpu-layers 999 \
--split-mode layer \
--tensor-split 0.53,0.47 \
--batch-size 2048 \
--ubatch-size 1024 \
--threads 16 \
--temp 0.6 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.00 \
--presence-penalty 0.0 \
--repeat-penalty 1.0 \
--flash-attn on \
--cache-type-k bf16 \
--cache-type-v bf16 \
-np 1 \
--parallel 1 \
--jinja \
--chat-template-kwargs '{"preserve_thinking":true}' \
--no-mmapПри таких настройках в работе потребляется суммарно около 45,5 ГБ VRAM. Скорость чтения промпта - 1100-1200 токен/сек, скорость генерации 45-50 токен/сек. Все работает 24/7, никаких вылетов, все абсолютно стабильно. Новая версия llama.cpp автоматически компилируется каждые 3 дня. Проблем с MPT не наблюдаю. MPT - отличная технология, которая на "ровном месте" увеличивает производительность почти в 2 раза (да есть небольшое падение скорости чтения промпта за счет появления лишнего слоя, но это несущественно, т.к. на RTX3090 скорость чтения и без того достаточно большое). Это очень существенный плюс относительно старых серверных решений.
В связи с тем, что я также загружаю мультимедиа модель (чтобы Qwen мог распознавать изображения), которая загружается в память первой видеокарты, то я перераспределяю на вторую видеокарту на 1 слой больше (команда –tensor-split). С такими настройками модель работает с максимально возможным качеством (у модели Q8_K_XL самый минимальный KLD), но 48 ГБ VRAM не позволяют использовать весь возможный контент (256k). Чтобы использовать полный контент можно либо взять модель Q8_0 (29 ГБ), либо изменить настройки квантования кэшей с bf16 на q8_0.
Модель Qwen3.6-27b-MTP-UD-Q8_K_XL просто на голову выше древних моделей типа Llama-3.3-70B, Qwen3-Coder, GPT-OSS-120B. В кодинге и агентских задачах лучше чем Gemma4-31B, Qwen3.5-122b, Qwen3.5-397, Nemotron3-33B. Честно говоря постоянно недоумеваю, когда вижу в технически вроде бы грамотных статьях, как авторы продолжают использовать эти неактуальные модели, зачем???
На основе личных наблюдений относительно Qwen3.6-27B: разница в квантовании между Q4 и Q8_K_XL существенна, разница в квантовании кэшей очень существенна, особенно на больших (>100k) контекстах. Поэтому, хоть Qwen3.6-27B и можно запустить на одной RTX3090 (24 ГБ), но качество работы будет гораздо ниже чем на двух. 48 ГБ - это оптимальный объем видеопамяти.
Покупка третьей и четвертой видеокарты RTX3090 (то есть увеличение VRAM свыше 48 ГБ) в данный момент не имеет особого смысла. Сейчас просто нет моделей которым нужно 64-128 ГБ VRAM и которые при этом лучше чем Qwen3.6.-27B. Что толку, что появится возможность разместить в видеопамяти GPT-OSS-120B или Qwen3.5-122B-A10B если они ничем не лучше Qwen3.6.-27B? А модели которые лучше, типа Kimi-K2.6 или DeepSeek-V4-Flash, уже требуют принципиально иного количества видеопамяти.
Я там под другим комментом расписал про vLLM. Рекомендую тоже глянуть. К сожалению, там пока кванты без KLD замеров и не совсем понятно какие из них дают минимальные потери. А в остальном прирост скорости огромный
Под две 3090 уже лучше vLLM разворачивать. Да, неудобно переходить, но приросты огромные.
Qwen3.6-27B-AWQ-BF16-INT4 220к токенов контекста с MTP на 4 токена. Я не запускал чистый бенчмарк, но по логам при реально использовании видно, что promt processing иногда 5000+ токенов в секунду. Token generation в среднем около 60 тк/с, минимум около 40 тк/с, максимум 90 тк/с при написании текста, который легко предсказать, например код и правки в нём
Что скажете про ASUS Ascent GX10? Вроде по цене он близок к компу с двумя 2х3090 при этом электричество меньше потреблять будет?
Я GX10 не пользовался, но про него регулярно читаю на реддите (как и про Nvidia DGX Spark). Если сравнивать с конфигом 2х RTX3090, то эти мини ПК существенно уступают в скорости, особенно в скорости чтения промпта (который зависит от скорости памяти). Они могли быть востребованы там где требуется много памяти, например, 128 ГБ, но как я написал в сообщении выше, проблема в том, что сейчас в этой нише (от 48 до 200 ГБ) нет моделей, которые были бы лучше чем Qwen3.6-27B.
Скажите, а что на одной 3090 можно гонять поэффективнее? На вторую карту только засматриваюсь. Задачи пока без мультимодалки, класса «экспериментирую дома»
Qwen3.6-27B через llama.cpp с турбоквантом. Можно и с мультимодалкой, только мультимодальный прожектор на CPU перенести
Наверное, то же Qwen3.6 27b, но с квантованием Q4_K_M, квантованием кэша q8_0. Также можно уменьшить бенчи, например, "–batch-size 1024", " --ubatch-size 512", на качество ответов это не влияет, только несколько снизит скорость. Выбрать максимальный размер контекста на всю оставшуюся после загрузки основных весов видеопамять. Использовать llama.cpp. Смотреть, сколько потребляется видеопамяти после загрузки модели и корректировать настройки, чтобы свободной оставалось ~512 МБ.
О дивный мир локально го запуска ллм. В соседней статье пишут что на 96gb ничего не запустить о чем не стыдно в приличном обществе говорить. Но я задумываюсь взять именно две 3090, вполне достаточно чтобы пощупать что умеют локальные модели. Подскажите, у вас можно попрость/купить консультацию по железу для такой системы?
Сейчас каждый месяц выходит какая-нибудь интересная модель, поэтому в ближайшее время с высокой вероятностью стоит ожидать, что появится что-нибудь для запуска на 64-128 ГБ VRAM
Уже прикольнее, но почему десктопная платформа то блин?! Взять б/у зион или эпук будет не дороже, зато будет больше линий PCI-e и больше каналов памяти, что может помочь при оффлоаде на CPU.
По поводу выбора 2 V100 на 32, а не будет ли выгоднее взять 4 V100 16Gb и бекплейн на 4 ГПУ? По текущим ценам с али это будет где-то на 10-15к дешевле, видеопамяти столько же, но ядер в 2 раза больше.
не умаляя достоинств и сил, потраченных на статью, не могу еще раз не отметить, что стоимость потраченных человеко-часов инженера / энтузиаста, да кого угодно на борьбу с этими ветряными мельницами багами на устаревшем стэке просто умножает на ноль все эти преимущества и выгоды V100. И интересно разве что только в области ретро-компьютинга. Один день работ человека на багах / поиске рабочих комбинаций для компании стоит в лучшем случае 30 тыс. рублей. А сколько вы на это потратили времени? Даже один день этих работ окупает сходу любую водянку для двух 3090, которая решит проблемы с перегревом при работе 24/7. А может быть даже и 4090, которая держит FP8 и еще меньше проблем - просто берешь оригинальную FP8 модель с предсказуемыми параметрами, требуемыми ресурсами, пара строк в докер композе -> актуальный vllm и работаешь, а не вот это вот всё.
Спасибо за комментарий!
Я заметил огромный спрос на эти Видеокарты из-за их а) размера б) цену на нашем рус. рынке. И возможно даже и хорошо, что вышли те результаты, которые есть в статье.
Меня скорее удивляло, что о всех проблемах и преимуществах V100 никто комплексно никогда не говорил и не писал. Я предварительно посмотрел ролики на Ютуб, где такие же любители как я начали сборку с V100+NVlink, но никто не уделяет должного вниманию комплексно этой видеокарте. Я под этим подразумеваю то, а на каком фреймворке она строилась, а можно ли вообще запускать на ней разные модели , помимо Ollama, и так далее.
Тут очень активная сессия обсуждения в комментариях и я этому очень рад.
Все любительские сборки первым делом спотыкаются на билды с 3090 / 4070 / 4080. Но здорово иметь и альтернативную информацию о других видеокартах при принятии решений.
Мне в свое время , да буквально год назад, этого очень сильно не хватало. Даже немного бесило, что все сводилось к "да б/у 3090 за 50-60к купи и не делай себе мозги". Блин, ну ведь есть такой спектр видюх щас, и с каждым днем запускать интересные решения становится все проще и проще.
Но если резюмировать, то конечно от v100 очень много геморроя. :)
Но не все так однозначно (простите)
Столько мороки, чтобы запускать всякие музейные экспонаты типа Qwen2.5 (когда есть 3.6) и Gemma 3 (когда есть 4)? Спасибо, не надо. С одной 3090 проку больше будет.
2× Tesla V100 32GB дают 64 ГБ VRAM суммарно — столько же, сколько три RTX 5080 16GB, и дешевле.
я так понимаю, математика - не ваша сильная сторона?
Лаборатория ИИ за 200 000 ₽: как мы собрали локальный ИИ-сервер на 2× Tesla V100