Comments 8
Идея для следующего теста: взять более компактную модель взять, да сравнить больше квантализаций )
Например, ту же qwen3:235b-a22b можно запустить в fp16 на таком сервере, а потом понижать постепенно.
Нужно как то верифицировать качество генерации. Не запускать же "змейку" несколько тысяч раз. Нужен простенький но обьективный тест, хеллоуворлд они все напишут без проблем, а змейка слишком сложная для автооценки. Что-то эдакое, что можно численно измерить хотя бы (ну или передать результат заведомо более мощной LLM чтобы сама выставляла оценку)
Читал что большое количество потоков CPU, примерно больше 10 не дают особого прироста скорости генерации, было бы очень интересно ещё увидеть тест на 8-16-32 количества потоков, потому что может быть не обязательно брать много ядер, а лучше мало, но быстрых?
Просто у меня есть epyc на 16 ядер и мне интересно, если я просто докуплю ОЗУ, то смогу ли получить что-то похожее, или надо смотреть что-то с большим количеством ядер
Я подумаю над таким тестом. Но могу сказать что данное замечание актуально к тем процессорам которые имеют разные по производительности ядра. Когда при увеличении количества ядер подключаются энергоэффективные. Могу сказать что тестировал на EPYC7282 и скорость была примерное 1,8t/s
Тут важна скорость памяти, число каналов памяти. Ядра - у меня 2х канальную DDR4 "забивает" 4 ядра (на вывод, для наибыстрейшей обработки запросов нужно 8 ядер). Проц - i7-10700, так что не сказать, что ядра особо шустрые.
Я настроил в итоге использование 4х ядер - меньше греется и шумит.
Так что есть все шансы ускориться - если не все каналы используете, 16 ядер должно "хватить" на 8 каналов памяти.
Оно не влияет если вычислительная сложность модели никая и упирается в память. Гонял какие-то "крутые" локальные модели и больше ядер давало буст. А вот самая тупорылая LLAMA, у меня, буквально считается на 4 из 20 ядер и никакой буст от ядер не получаю.
"--cache-type-k", "${CACHE_TYPE_K:-q4_0}",
Получившиеся данные стали для меня откровением. Оказалось что несмотря увеличение скорости генерации токена, общее время ответа растёт, модели дают ответы содержащие больше токенов. При этом ещё и снижается качество ответов.
Любые замеры качества при квантовании кэша q4_0 не имеют смысла, так как любое квантование кэша даёт непредсказуемый результат качества, а на столько экстремальное тем более.
q4_0 это опция только для тех, кому любой ценой надо сэкономить память. Только q8_0 можно считать условно не влияющим на качество, но надо держать в голове, что что-то может пойти не так, особенно в программирование, где каждый символ имеет значение.
UD-Q5_K_XL 481GB
UD-Q4_K_XL 384GB
UD-Q3_K_XL 296GB
UD-IQ2_M 229GB
Динамическое квантование UD, то есть улучшенное качество по сравнению с обычными квантами, имеют только UD-...-XL кванты, остальные кванты имеют обычное квантование, поэтому UD-IQ2_M так отличается.
UD-Q2_K_XL с натяжкой всё еще влезает в 256гб памяти, с учётом разгрузки на GPU.
И только с UD-IQ2_M из представленных в тесте возможен переход в сборке на более бюджетные модули памяти по 32GB вместо модулей по 64GB.
Если интересует малый размер и повышенное качество - стоит попробовать ik_llama.cpp. Бонусом будет в 1.5-2 раза возросшая скорость.
Создатель форка ik_llama.cpp и есть создатель того самого квантования в llama.cpp, большинство квантов сделаны им, включая K кванты и лучшие i-кванты. Можно посмотреть его выступление на Fosdem: https://fosdem.org/2025/schedule/event/fosdem-2025-5991-history-and-advances-of-quantization-in-llama-cpp/
В ik_llama представлена серия новых SOTA квантов, которые работают быстрее, весят меньше, и дают качество лучше.
Например, среди них DeepSeek-R1-0528-IQ2_K_R4, размер 220гб, с запасом укладывается в 256гб, при этом падение качества ppl всего 9%, с 3.21 до 3.5. PPL не лучший показатель, но он является быстрым замером примерного уровеня.
И ik_llama позволяет получить лучшую скорость, что даже на домашнем ПК минимальный квант можно запустить и пользоваться этим: Запускаем настоящую DeepSeek R1 671B на игровом ПК и смотрим вменяемая ли она на огромном контексте (160к)
Ускорение DeepSeek-R1 с подвохом: Когда токены в секунду врут о реальной скорости