Спасибо вам. Очень полезная картинка. Личный опыт использования qwen3.6-35b при экспериментах с квантованием кэша показал, что через некоторое время в opencode он начинает искажать/забывать/зацикливаться при q4_0, чего у меня не происходит на q8_0. Видя цифры на картинке становится понятно почему. И тем более понятно, почему с gemma у меня вообще все плохо было. Можно попробовать ассиметричное квантование KV-кэшей: K-кэш оставить f16, а V пожать. По идее ключи значительно более чувствительны к ошибке. Все не соберусь эксперимент провести.
Стоит обратить внимание на форк ik_llama.cpp для moe моделей. Там специальная заточка под moe (fused moe). Если включить smart expert routing -ser 7,1 и grouped expert routing, то получается неплохой прирост производительности. Кстати и на плотной модели ik_llama у меня быстрее
А насчет mtp на moe более менее заметный эффект получается если драфт-токенов 3-5 и p_min ставить 0.4-0.5, а не 0.75 как обычно рекомендовали для плотной модели.
В llama для этого есть ключ --fit, который они и пользуют. Но на деле при ассиметричной конфигурации имеет смысл минимум отправить на самую хилую видеокарту, чтобы меньше тормозила всех.
Только в реальности начинается упор в количество реальных линий pcie в процессоре. Типично это 20-24 для десктоп процессора. Часть сразу уходит в чипсет и nvme ssd. соответственно х16+х8 в реальности работают как х8+х8, а иногда как х8+х4. Уход на серверные решения дает сразу больше линий pcie: даже у моего старинного 2690v4 их уже 40 штук, то есть вполне рабочая схема x16+x16 или x16+x8+x8 (бюджет если что у меня получился 12000 рублей процессор+мать, хоть и б/у, но приличная asus x99a-ii). А у более серьезных-современных серверных процессоров и 64 линии бывает легко. Помимо этого на более современных серверных решениях потенциально появляется возможность сделать tensor-split не layer, а graph (в layer у нас обработка размазанной по вк модели идет последовательно, а в graph параллельно)
Ну там тест gpt-oss. И в то же время низкие цифры на маленьких моделях. Я все-таки про qwen3.6. Впрочем там тоже нет цифр ttft. Я читал ту статью и общее впечатление - часто странное поведение в плане производительности. Я все равно не понимаю вашей надежды на игровую материнку. Вы pcie распаяли?
Еще дополню. Игровая материнка вас совсем не спасет:
Вы ограничены шиной майнинговых видеокарт. Это всего лишь древний pcie 1. И линий в лучшем случае 4 от видеокарты. Потенциально можно количество линий увеличить, распаяв их, но pcie v1 останется.
На игровых материнках ограничено количество линий pcie. Их просто в игровом процессоре 20 штук всего обычно.
Как вариант можно смотреть серверные решения или решения для рабочих станций. Но это реально дорого или компромисс, как у меня - lga2011v3+xeon (я взял asus x99a-a + xeon 2690v4, линий pcieот процессора много, но pcie все равно не сильно современный). Хотя такой компромисс под майнинговые вк с апгрейженной шиной вполне вариант. В любом случае вряд ли прирост будет с 20 до 40 т/с, если 30 т/с - это уже очень круто будет.
Ну не сильно верьте тому, что вам гугловский ии показал (если уж совсем честно - тут полная ерунда написана). ik_llama вполне стабильный форк. У меня пока небольшие проблемы были только с моделями apex, но там как раз очень не стандартное квантование. И с 610 драйвером nvidia на моей системе глюков хватило, но и классическая llama с ним не подружилась (думаю и надстройки над llama, такие как ollama и lmstudio тоже имели бы проблемы). Все стандратные модели как раз неплохо пашут.
90 с это что-то запредельное. Судя по всему начинает играть роль скорость cpu и, очень вероятно, крайне низкая скорость pci-e (я конкретно про вашу вк не помню, но на майнинговых обычно pcie 1 и всего лишь x1, в лучшем случае x4. Кстати на части майнинговых карт получается сделать x16 элементарными доработками.
Кстати, тем более надо смотреть в сторону ik_llama.cpp. Там как раз максимальная оптимизация именно по обмену cpu/gpu.
На самом деле того стоит. Навайбкодить каким-нибудь дипсиком скрипт, который будет llama.cpp настраивать недолго.
Плюс есть уже готовые web-интерфейсы для удобного управления llama.cpp. Я не пользуюсь, у меня сейчас самодельный интерактивный скрипт на питоне позволяющий быстро настроить и запустить модель через llama/ik_llama. Как отлажу (остались некоторые баги), наверное статью выпущу
Посмотрите ik_llama.cpp. Специально оптимизированный под moe и гибридные архитектуры cpu/gpu форк llama.cpp. Реально заметный прирост.
Ещё одно достоинство форка - меньше тратит память. У меня получалось оставить 17 слоев экспертов на cpu и kv-кэш 262144 запихать в 16гб (кэш естественно со сжатием q8_0).
Сделайте замер ttft (time to first token) и скорости обработки промпта. Как только вся модель уйдет на gpu выигрышь будет значительным.
У меня даже на оптимизированном под cpu/gpu форке ik_llama.cpp разница в ttft сейчас в 2 раза, а скорость обработки промпта в 3 раза. До оптимизаций была до 5-10 раз (надо отметить, что за последние два месяца явно серьезно в архитектуре cpu/gpu поработали что в ikllama, что в llama).
Имеете в виду даунклок 4080/4090? 4060 даунклокать же нет смысла.
В остальном - все верно. Вместо 4060 все-таки имеет смысл брать сразу 5060. Она не только быстрее будет, но и перспективнее - тот же nvfp4 туда завезли уже
Через cpu-moe вполне заведется qwen3.6-35b. Даже около 50 т/с наверное получите. Но время первого токена будет большим - то есть всякие opencode будут болью, а чатики приемлимо. Добавка еще видеокарты, чтобы модель влезала добавит т/с слегка (у меня с 60 до 80 выросло, после добавки к 5060 ти 16гб серверной tesla 10 16 гб), но время первого токена упадет на порядок и больше.
Но на 16гб уже gpt-oss-20b влезает. Какие у васзадачи к ии?
Дополняю. Несколько дней использования для рефакторинга легаси проекта на c#. Периодически в opencode работа прерывается с сообщением terminated. В выходные обновил драйвер нвидия с 580 на 610. По мере роста контекста количество terminated стало рости в геометрической прогрессии. По dmesg видно, что много segfaultов от ik_llama. Откатился на fraqtl - работает как часы
Это в варианте cpu-moe? Я проходил такое. Правда 5060 ти 16 гб. Очень большой ttft (время первого токена) при неплохой скорости генерации. На opencode при работе с многофайловым средним проектом можно было успеть кофе попить. Докинул tesla t10 pg150 16gb (2080ti, ужатый по tdp, шине памяти, но с 16 гб). Намного комфортнее стало. Раз в 10 быстрее. Бюджет 25 тыр: 22 видеокарта, 3 тыр охлаждение от 2080ти.
Есть ещё один момент, о котором все забывают. Да, есть скорости блочного чтения, но основной смысл любого ssd в реальной жизни не в этом, а в iops - количестве операций в секунду. К примеру у hdd о цифрах больше 300 iops я не слышал, а на зачуханном сверхдешевом ssd это десятки тысяч. Надо было на тесте еще картинку с iops привести в сравнении с sata накопителем.
Это как в машине - хорошо везет крутящий момент, а не цифра максимальной момощности.
Дополняю: как раз на третьем тесте косвенно видно, что по iops этот ssd таки быстрее раза в 1.5 точно чем sata. То есть запуск программ и их работа может быть вполне даже быстрее. Особенно если много мелких файлов
Все правильно, но уж очень дорого. Я пока для себя открыл оптимизированные по точности квантования от fraQtl и DuoNeural. Понимаю, что полумера и жесткий компромисс
"V100 загружена меньше всех по проценту — хотя держит ~15 ГБ весов. MoE активирует небольшую долю параметров на каждый шаг, в этом и фокус. " Фокус не в этом. Фокус в том, что она значительно быстрее остальных. В вашем случае надо взять вариант квантования по-меньше, не Q5, а например IQ4_XS или хотя бы Q4_K_M и пытаться играть в tensor-split, максимально загнав модель на самый сильный GPU. То есть сейчас вы используете ключ --fit, а надо его убрать и поиграть ключом --tensor-split. Синтаксис его простой: --tensor-split <число пропорциональное части на GPU 0>,<число пропорциональное части на GPU 1> и т.д.. Deepseek в помощь, он про это знает и поможет. К примеру у меня два GPU 5060 ti 16 gb + tesla t10 16 gb. Tesla имеет приблизительно ту же скорость памяти, но значительно более медленный чип - по сути старинный 2080 ti ужатый до 150 Вт. Методом подбора у меня оказалось оптимальной конфигурация --tensor-split 18,14 - приличная часть модели ушла на 5060 - на ней 14.9 gb, а на tesla 12.7 gb. Мне это дает немного, но все-таки ощутимые около 5-10 т/с. --tensor-split 20,12 уже у меня почти не дает эффекта - торможу явно на скорости памяти далее, а не на скорости чипа. А ключ fit размазывал у меня модель равномерно. У вас из-за большой разницы между GPU эффект будет куда более значительный - загоняйте все что влезет в V100.
Теперь по апгрейду. Две V100 с Nvlink позволят включить режим tensor-split не layer, а например graph. Что это значит (упрощаю, но смысл такой): - в режиме layer у нас модель работает по очереди: часть обработалась на одном GPU, дальше передаем второму и т.д., поэтому и загрузка GPU не 100% и имеем накладные расходы на передачу между GPU (это приходится делать CPU через pcie, вы кстати платформу не описали, от скорости pcie можем ощутимо терять, CMP90HX в этой части может быть просто якорем); логично исходя из этого одиночная V100 на 32 gb будет заметно быстрее чем V100 16gb + V100 16gb без nvlink - в режиме graph видеокарты могут трудиться практически параллельно и самостоятельно обмениваясь данными без участия CPU, но работает это только через Nvlink или на достаточно свежих серверных платформах через pcie (у меня на lga2011v3 такое не доступно, но у меня даже для режима layer оптимальнее конфигурация - линий pcie от CPU много, хватает на две видеокарты). То есть теоретически (я в руках не держал такое пока, чисто по статьям) 2 штуки V100 16 gb c Nvlink могут быть быстрее, чем одна V100 32 gb вплоть до 2 раз, на практике конечно не так заметно Так что если не экономите - 2 штуки V100 c Nvlink (но могут быть нюансы с настройкой, изучите вопрос плотно), если экономите, то все в продажу и покупаете одну V100 32 gb - это сейчас 55000-65000 рублей за ВК и на 20000-30000 потенциально продадите свое. Я сейчас зрею купить именно V100 32 gb.
Спасибо вам. Очень полезная картинка. Личный опыт использования qwen3.6-35b при экспериментах с квантованием кэша показал, что через некоторое время в opencode он начинает искажать/забывать/зацикливаться при q4_0, чего у меня не происходит на q8_0. Видя цифры на картинке становится понятно почему. И тем более понятно, почему с gemma у меня вообще все плохо было.
Можно попробовать ассиметричное квантование KV-кэшей: K-кэш оставить f16, а V пожать. По идее ключи значительно более чувствительны к ошибке. Все не соберусь эксперимент провести.
Стоит обратить внимание на форк ik_llama.cpp для moe моделей. Там специальная заточка под moe (fused moe). Если включить smart expert routing -ser 7,1 и grouped expert routing, то получается неплохой прирост производительности. Кстати и на плотной модели ik_llama у меня быстрее
А насчет mtp на moe более менее заметный эффект получается если драфт-токенов 3-5 и p_min ставить 0.4-0.5, а не 0.75 как обычно рекомендовали для плотной модели.
В llama для этого есть ключ --fit, который они и пользуют. Но на деле при ассиметричной конфигурации имеет смысл минимум отправить на самую хилую видеокарту, чтобы меньше тормозила всех.
Только в реальности начинается упор в количество реальных линий pcie в процессоре. Типично это 20-24 для десктоп процессора. Часть сразу уходит в чипсет и nvme ssd. соответственно х16+х8 в реальности работают как х8+х8, а иногда как х8+х4. Уход на серверные решения дает сразу больше линий pcie: даже у моего старинного 2690v4 их уже 40 штук, то есть вполне рабочая схема x16+x16 или x16+x8+x8 (бюджет если что у меня получился 12000 рублей процессор+мать, хоть и б/у, но приличная asus x99a-ii). А у более серьезных-современных серверных процессоров и 64 линии бывает легко. Помимо этого на более современных серверных решениях потенциально появляется возможность сделать tensor-split не layer, а graph (в layer у нас обработка размазанной по вк модели идет последовательно, а в graph параллельно)
Ну там тест gpt-oss. И в то же время низкие цифры на маленьких моделях. Я все-таки про qwen3.6. Впрочем там тоже нет цифр ttft. Я читал ту статью и общее впечатление - часто странное поведение в плане производительности. Я все равно не понимаю вашей надежды на игровую материнку. Вы pcie распаяли?
Еще дополню. Игровая материнка вас совсем не спасет:
Вы ограничены шиной майнинговых видеокарт. Это всего лишь древний pcie 1. И линий в лучшем случае 4 от видеокарты. Потенциально можно количество линий увеличить, распаяв их, но pcie v1 останется.
На игровых материнках ограничено количество линий pcie. Их просто в игровом процессоре 20 штук всего обычно.
Как вариант можно смотреть серверные решения или решения для рабочих станций. Но это реально дорого или компромисс, как у меня - lga2011v3+xeon (я взял asus x99a-a + xeon 2690v4, линий pcieот процессора много, но pcie все равно не сильно современный). Хотя такой компромисс под майнинговые вк с апгрейженной шиной вполне вариант. В любом случае вряд ли прирост будет с 20 до 40 т/с, если 30 т/с - это уже очень круто будет.
Ну не сильно верьте тому, что вам гугловский ии показал (если уж совсем честно - тут полная ерунда написана). ik_llama вполне стабильный форк. У меня пока небольшие проблемы были только с моделями apex, но там как раз очень не стандартное квантование. И с 610 драйвером nvidia на моей системе глюков хватило, но и классическая llama с ним не подружилась (думаю и надстройки над llama, такие как ollama и lmstudio тоже имели бы проблемы). Все стандратные модели как раз неплохо пашут.
90 с это что-то запредельное. Судя по всему начинает играть роль скорость cpu и, очень вероятно, крайне низкая скорость pci-e (я конкретно про вашу вк не помню, но на майнинговых обычно pcie 1 и всего лишь x1, в лучшем случае x4. Кстати на части майнинговых карт получается сделать x16 элементарными доработками.
Кстати, тем более надо смотреть в сторону ik_llama.cpp. Там как раз максимальная оптимизация именно по обмену cpu/gpu.
На самом деле того стоит. Навайбкодить каким-нибудь дипсиком скрипт, который будет llama.cpp настраивать недолго.
Плюс есть уже готовые web-интерфейсы для удобного управления llama.cpp. Я не пользуюсь, у меня сейчас самодельный интерактивный скрипт на питоне позволяющий быстро настроить и запустить модель через llama/ik_llama. Как отлажу (остались некоторые баги), наверное статью выпущу
Посмотрите ik_llama.cpp. Специально оптимизированный под moe и гибридные архитектуры cpu/gpu форк llama.cpp. Реально заметный прирост.
Ещё одно достоинство форка - меньше тратит память. У меня получалось оставить 17 слоев экспертов на cpu и kv-кэш 262144 запихать в 16гб (кэш естественно со сжатием q8_0).
Сделайте замер ttft (time to first token) и скорости обработки промпта. Как только вся модель уйдет на gpu выигрышь будет значительным.
У меня даже на оптимизированном под cpu/gpu форке ik_llama.cpp разница в ttft сейчас в 2 раза, а скорость обработки промпта в 3 раза. До оптимизаций была до 5-10 раз (надо отметить, что за последние два месяца явно серьезно в архитектуре cpu/gpu поработали что в ikllama, что в llama).
Имеете в виду даунклок 4080/4090? 4060 даунклокать же нет смысла.
В остальном - все верно. Вместо 4060 все-таки имеет смысл брать сразу 5060. Она не только быстрее будет, но и перспективнее - тот же nvfp4 туда завезли уже
Через cpu-moe вполне заведется qwen3.6-35b. Даже около 50 т/с наверное получите. Но время первого токена будет большим - то есть всякие opencode будут болью, а чатики приемлимо. Добавка еще видеокарты, чтобы модель влезала добавит т/с слегка (у меня с 60 до 80 выросло, после добавки к 5060 ти 16гб серверной tesla 10 16 гб), но время первого токена упадет на порядок и больше.
Но на 16гб уже gpt-oss-20b влезает. Какие у васзадачи к ии?
Дополняю. Несколько дней использования для рефакторинга легаси проекта на c#. Периодически в opencode работа прерывается с сообщением terminated. В выходные обновил драйвер нвидия с 580 на 610. По мере роста контекста количество terminated стало рости в геометрической прогрессии. По dmesg видно, что много segfaultов от ik_llama. Откатился на fraqtl - работает как часы
Это в варианте cpu-moe? Я проходил такое. Правда 5060 ти 16 гб. Очень большой ttft (время первого токена) при неплохой скорости генерации. На opencode при работе с многофайловым средним проектом можно было успеть кофе попить. Докинул tesla t10 pg150 16gb (2080ti, ужатый по tdp, шине памяти, но с 16 гб). Намного комфортнее стало. Раз в 10 быстрее. Бюджет 25 тыр: 22 видеокарта, 3 тыр охлаждение от 2080ти.
Есть ещё один момент, о котором все забывают. Да, есть скорости блочного чтения, но основной смысл любого ssd в реальной жизни не в этом, а в iops - количестве операций в секунду. К примеру у hdd о цифрах больше 300 iops я не слышал, а на зачуханном сверхдешевом ssd это десятки тысяч. Надо было на тесте еще картинку с iops привести в сравнении с sata накопителем.
Это как в машине - хорошо везет крутящий момент, а не цифра максимальной момощности.
Дополняю: как раз на третьем тесте косвенно видно, что по iops этот ssd таки быстрее раза в 1.5 точно чем sata. То есть запуск программ и их работа может быть вполне даже быстрее. Особенно если много мелких файлов
Скачал, попробовал, очень интересный вариант. Судя по информации это еще лучше, чем fraQtl или DuoNeural
Спасибо. Я как-то этот вариант пропустил. Качаю, попробую
Все правильно, но уж очень дорого. Я пока для себя открыл оптимизированные по точности квантования от fraQtl и DuoNeural. Понимаю, что полумера и жесткий компромисс
"V100 загружена меньше всех по проценту — хотя держит ~15 ГБ весов. MoE активирует небольшую долю параметров на каждый шаг, в этом и фокус. "
Фокус не в этом. Фокус в том, что она значительно быстрее остальных. В вашем случае надо взять вариант квантования по-меньше, не Q5, а например IQ4_XS или хотя бы Q4_K_M и пытаться играть в tensor-split, максимально загнав модель на самый сильный GPU. То есть сейчас вы используете ключ --fit, а надо его убрать и поиграть ключом --tensor-split. Синтаксис его простой:
--tensor-split <число пропорциональное части на GPU 0>,<число пропорциональное части на GPU 1> и т.д.. Deepseek в помощь, он про это знает и поможет.
К примеру у меня два GPU 5060 ti 16 gb + tesla t10 16 gb. Tesla имеет приблизительно ту же скорость памяти, но значительно более медленный чип - по сути старинный 2080 ti ужатый до 150 Вт. Методом подбора у меня оказалось оптимальной конфигурация --tensor-split 18,14 - приличная часть модели ушла на 5060 - на ней 14.9 gb, а на tesla 12.7 gb. Мне это дает немного, но все-таки ощутимые около 5-10 т/с. --tensor-split 20,12 уже у меня почти не дает эффекта - торможу явно на скорости памяти далее, а не на скорости чипа. А ключ fit размазывал у меня модель равномерно. У вас из-за большой разницы между GPU эффект будет куда более значительный - загоняйте все что влезет в V100.
Теперь по апгрейду. Две V100 с Nvlink позволят включить режим tensor-split не layer, а например graph. Что это значит (упрощаю, но смысл такой):
- в режиме layer у нас модель работает по очереди: часть обработалась на одном GPU, дальше передаем второму и т.д., поэтому и загрузка GPU не 100% и имеем накладные расходы на передачу между GPU (это приходится делать CPU через pcie, вы кстати платформу не описали, от скорости pcie можем ощутимо терять, CMP90HX в этой части может быть просто якорем); логично исходя из этого одиночная V100 на 32 gb будет заметно быстрее чем V100 16gb + V100 16gb без nvlink
- в режиме graph видеокарты могут трудиться практически параллельно и самостоятельно обмениваясь данными без участия CPU, но работает это только через Nvlink или на достаточно свежих серверных платформах через pcie (у меня на lga2011v3 такое не доступно, но у меня даже для режима layer оптимальнее конфигурация - линий pcie от CPU много, хватает на две видеокарты). То есть теоретически (я в руках не держал такое пока, чисто по статьям) 2 штуки V100 16 gb c Nvlink могут быть быстрее, чем одна V100 32 gb вплоть до 2 раз, на практике конечно не так заметно
Так что если не экономите - 2 штуки V100 c Nvlink (но могут быть нюансы с настройкой, изучите вопрос плотно), если экономите, то все в продажу и покупаете одну V100 32 gb - это сейчас 55000-65000 рублей за ВК и на 20000-30000 потенциально продадите свое. Я сейчас зрею купить именно V100 32 gb.