Комментарии 23
А почему новый NVLink медленнее старого ?(
На более старых архитектурах он работает лучше или в чем дело ?
Просто читал где Вы его тестировали на P100, и там результат был намного лучше, хотя Паскаль старее на несколько поколений…
На самом деле тут все совсем сложно. Дело в том что NVLink работает по числу линий. И это число линий NVLink может крайне различаться в зависимости от продукта. Видеокарты Tesla P100 были флагманами от Nvidia, поэтому там все работает на полную катушку.
А вот A5000 это бывшая Quadro и тут NVlink есть, однако в таком демо режиме)
Если делать более корректное сравнение, то за референс у Ампера надо брать A100(бывшая линейка Tesla). Вот у этой карты для линка потребуется сразу 3 мостика и их суммарная пропускная способность составит 600 гигабайт в секунду, что составляет ~40% от пропускной способности ее HBM2E памяти)
Модель нейронки выбрана не очень, на мой взгляд развернутый ии-майнкрафт куда интереснее раскрыл бы потенциал нвлинка)
Непонятен выбор ollama - написанной на go обёртки вокург llama.cpp, которая вносит к тому же дополнительное(хоть и небольшое) потребление видеопамяти
Если хотите потестить производительность - возьмите llama.cpp, соберите конкретно под ваше железо, воспользуйтесь встроенным llama-bench или llama-cli. Поиграйтесь с параметрами -ngl (number of layers to store in VRA) для каждого CUDA устройтва.
>>Мониторинг отображал картину которая больше походила на то, что по какой-то причине в один момент времени была в большей степени загружена либо одна, либо другая видеокарта, хотя иногда нагрузка и была поровну.
Абсолютно нормальное поведение для LLM сети на нескольких отдельных нодах(что cuda, что cpu, что через сеть Ethernet). Собственно, вопрос - почему у вас Квадры отображаются как 2 отдельных устройства, а не одно единое на 48ГБ VRAM? (в этом же и смысл NV-link, а не в скорости)
Я так понимаю ollama выбрана исходя из ее популярности. Разделяю ваш подход и вероятно нам бы не помешало повысить уровень технической подготовки под тесты.
Кстати, хочу отметить, что ServerFlow открыт к сотрудничеству и мы ищем авторов способных выполнить такие манипуляции.
>>Для наглядности теста нами была выбрана последняя языковая модель LLaMA 3.2 на 90 миллиардов параметров.
Эта модель для анализа картинок+текста. Для генерации текста/кода она соответсвует LLama 3.1 70B - разница в 20 млрд параметров как раз и относится к картинкам и вполне возможно, что всё-равно у вас загружается и бесполезно висит в видеопамяти(нужно смотреть по логам).
Мета зря для одной и той же модели использует индексы 3.1 и 3.2 - и это многих вводит в заблуждение
>>В наших тестах мы используем версию модели с 4-битной квантизацией. Такой выбор не случаен:
Добавлю из личного опыта - для генерации кода подходит квантизация минимум Q6_K, а лучше Q8_0. Всё, что ниже - может начать давать сильно отличающийся от оригинальной модели результат. Причём это зависит от вашего запроса - на чём-то простом результат будет корректный , а на чём-то сложном уже будет что-то совсем не то .
Для мультимодальных моделей по типу LLaMA 3.2 разве используется llama.cpp? Но, там же до сих пор нету поддержки мультимодальных сеток умеющих в распознание изображений, 3.2 по крайней мере точно. Так что скорее всего Ollama какой-то свой скрипт для инференса писали, а не просто обёртку.
Плюс, они в целом судя по их документации ряд оптимизаций своих накидывают и там где llama.cpp точно используется.
Я, возможно, не очень корректно выразился (а ребята из Meta зря дали 2м разным моделям название LLama 3.2, устроив путаницу).
ollama - это действительно обёртка вокруг llama.cpp - но я не утверждал, что только вокруг неё. Она может и другие GGML/С либы для реализации мультимодальности, но для генерации кода (как в примере выше) используется исключительно llama.cpp - я именно об этой части писал и про избыточность тоже.
>> Плюс, они в целом судя по их документации ряд оптимизаций своих накидывают и там где llama.cpp точно используется.
летом у ollama в Issue был вопрос - почему не используется AVX2 оптимизация(только AVX), если llama.cpp/ggml её поддерживают. Ответ же - и так много всего нужно собирать, а оптимизация под AVX2 даёт в пределах 5-10% скорости. Так что не только накидывают, но и удаляют имеющиеся.
PS: вот эту вашу мысль я совсем не понял:
>> Так что скорее всего Ollama какой-то свой скрипт для инференса писали, а не просто обёртку.
скрипт - это намного более примитивная вещь, чем компилируемая обёртка на C подобном языке go, на котром ollama и написана
Поразительные результаты. Не знаю как у вас, но у меня NVLink ассоциируется с максимально профессиональным решением, преемником величественного SLI, и я был почти уверен, что в конце статьи нас ждет хотя бы 10-15% прирост. Но, видимо, Ollama так не считает. В идеале хотелось бы увидеть работу NVLink и на других движках для инференса. Популярно - не значит лучше. Однако, спасибо за ОС по вопросу совместимости NVLink и Ollama. Теперь буду знать, что из коробки ничего не работает.
Написал пару комментариев чуть выше - если кратко - то NVLink+Quadro и не тестировался вовсе. Корректные цифры для такой системы из 2х А5000 для генерации кода (на модели Llama-3.1-70B_Q4_K_M, которая лежит в основе мультимодальной Llama-3.2-90В) должны быть сильно больше 10 токенов в секунду (а не 3.68 токенов в секунду, как тут).
По моим оценкам, корректно настроенная система выдаст в районе 15-17 токенов.
Было бы интересно посмотреть инференс llama на двух GPU подключенные на pcie x1, чтобы понять насколько влияет ширина канала с GPU вообще. Например, через райзеры можно подключить порядка 16 GPU к одной мат. плате и существенно сэкономить на запуске больших моделей, если разница не сильно велика.
Мало влияет. Веса сетки преварительно загружаются на ноды (вот тут будет заметна скорость PCIE x1) - а дальше между ними гоняется лишь KV-cache (который зависит от настроек) + команды исполнения - так что если не фанатсвовать - его размер будет небольшой - и траффик будет на уровне десятков мегабайт в секунду(зависит от железа и сетки). Но сильно влияет латентность - вот тут райзер может тоже повлиять.
У llama.cpp (для которой упомянутая тут olama является лишь обёрткой) есть даже режим RPC(Remote Procedure Call), позволяющий гонять её по сети уровня 1Gb/s Ethernet, разнося GPU по нескольким ПК.
Прошу прощения, но с каких пор видеокарты в CLI режиме стали суммировать свою ОЗУ? Вроде бы это и было основной причиной почему никто особо и не лез в обвязки из видеокарт. Или если карта не игровая то таки научили складывать?
Почему вы ожидаете, что llama.cpp будет поддерживать адекватную работу с nvlink? сам разработчик это не тестировал и спрашивал как там дела... nvlink универсально просто предоставляет виртуальный пул оперативной памяти всех подключенных gpu, когда как для оптимального его использования, необходимо спроектировать приложение таким образом, что бы задания были равномерно распределены были и что бы минимизировать передачу данных, так еще и указать, что данные нужно передавать именно через nvlink а не pci-e
Скрытый текст
inference для llm тут очень просто распределяется - по слоям, между gpu передавать приходится только промежуточный вектор, размерность которого квадратный корень от размера слоя, например в случае 70b модели это примерно 80 слоев, там порядка мбайта гуляющих между слоями данных, правда есть еще KV-cache, как его тут считать я хз
Наверное лучше тестировать на чем то типа vllm, и самое главное, не в задачах inference, а для finetuning. Либо выбрать режим batching, когда сеть обрабатывает одновременно несколько запросов (это сильно потребляет оперативную память gpu, но значительно, чуть ли не на порядок, ускоряет итоговый результат, и соответственно нагружает железо по максимуму).
видеокарты имеют крайне большой потенциал
A5000 довольно старые и довольно медленные. Габариты, лицензии и продержка виртуализации были бы преимуществом при построении большого кластера, но делать его на A5000 вряд ли кому-то интересно. А при десятке карточек всё же 4090 (или будущая 5090) заметно интереснее.
1) Интерфейс нужен чтобы делать большие батчи при обучении/файнтьюнинге.
2) Прирост на инференсе может быть значительным если модель не влазит в одну GPU. А в других случаях особой разницы быть не должно.
3) Вам надо использовать PyTorch или huggingface для адекватной работы с несколькими GPU.
Короче очень странная статья...
Мне вообще не понятно, за счет чего nvlink должен был ускорить инференс модели, если больших перетоков данных между GPU и не происходит? Я отслеживал загрузку pci-е при инференсе через ollama, там жалкие гигабиты и никакой nvlink не требуется. Более того, если движки, которые позволяют осуществлять распределенный инференс, разбивая llm на слои размещенные на разных хостах и это работает удовлетворительно не только через гигабитную сеть, но и даже через сеть Интернет со всеми сопутствующими задержками.
320 тыс руб за nvlink это не опечатка? Я купил на ebay nvlink для RTX3090 за 15000 руб.
Для тестирования можно написать небольшой скрипт по копированию переменной с использованием nvlink и через cpu. У меня получилась скорость с nvlink 48 ГБ/с, а через CPU 1,4 ГБ/с. Разница в 34 раза, но почувствовать ее можно если требуется гонять данные туда сюда.
Спасибо за интересный тест. Почему такая низкая скорость инференса, если вся модель влезла в vram? Какого компонента не хватает системе для инференса хотя бы на уровне 10т\с?
Вы пытетесь загрузить 90b модель 55Гб в 48Гб видеопамяти. Конечно у вас обработка на процессоре частично будет. Используйте команду ollama ps, чтобы убедиться, что модель полностью влезла в видеопамять.
Мы потратили 320 тысяч рублей ради Nvlink для нейросетей. Но был ли в этом смысл?