Основная ценность ixbt - форум, в котором иногда можно нарыть что-то интересное и полезное. Но, к сожалению, это ооочень старая информация. А активны ээээ странные завсегдатаи. Я уже лет 10 почти ничего там не пишу.
Но везде своя обстановка. Здесь тоже по-разному бывает. Скажем так люди здесь очень чувствительные.
3090 б/у сейчас реальная цена от 80000, 5060 ти 16 гб новая от 50000. Из-за ии очень подрос спрос и цены. Недавно искал, все б/у по Питеру дешевле 80000 потенциально проблемное.
Тут еще один момент есть. Недавно в обсуждении одной статьи встретил обоснованный коммент. Там говорилось о том, что gemma очень чувствительна к квантованию контекста. Мне нужен достаточно крупный контекст для opencode, приходится использовать q8_0. И гемма через некоторое время 'рассыпается' забывая то, что ещё есть в контексте или просто зацикливается в рассуждениях.
Про llama.cpp верное замечание. По опыту таже ollama может давать двухкратное проседание по сравнению с правильно отстроенным llama.cpp.
Не расскажете, как заставить параллельно две карты работать? По факту в той же llama.cpp на вашем и моем железе доступен только tensor-split в режиме layer, то есть последовательная обработка. И кстати поэтому нет большого смысла ограничивать потребление - один фиг в среднем никогда не будет максимального потребления - видеокарты работают по очереди.
По точности стоит взглянуть на специальные квантования моделей. Для той же qwen3.6-35b есть квантования от fraQtl/apex/duoneural. Если совсем по простому - когда квант по слоям не равномерный, а такой, чтобы найти баланс между размером и точностью.
Но стоит ещё посмотреть специальные квантования с повышенной точностью. Для qwen3.6-35b это DuoNeural, fraQtl, APEX. Я в основном сейчас пользуюсь fraQtl с mtp.
Интересно. А какие сборки gemma используете? Я в самом начале после появления в opencode пробовал и очень часто налетал на зацикливание. В итоге пока сижу на qwen3.6
А как вообще по производительности и стабильности этот форк?
Я сейчас как основной использую ik_llama.cpp. Он быстрее (сейчас не так значительно, как 1-2 месяца назад, но все равно ощутимо), а самое главное не так расточителен к памяти. Я не знаю, что сейчас намудрили с llama.cpp, но qwen3.6-27b (точно сборку не помню, квант q4_k_m) при включении mtp просто не лезет в память с максимальном контексте квантованном в q8_0, а на ik_llama еще 2 гб остается от 32 гб.
Спасибо вам. Очень полезная картинка. Личный опыт использования 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).
Грустно, если стало так плохо. Я как раз активно по аудио у них на форуме тусил раньше. Были вполне отзывчивые люди
Основная ценность ixbt - форум, в котором иногда можно нарыть что-то интересное и полезное. Но, к сожалению, это ооочень старая информация. А активны ээээ странные завсегдатаи. Я уже лет 10 почти ничего там не пишу.
Но везде своя обстановка. Здесь тоже по-разному бывает. Скажем так люди здесь очень чувствительные.
3090 б/у сейчас реальная цена от 80000, 5060 ти 16 гб новая от 50000. Из-за ии очень подрос спрос и цены. Недавно искал, все б/у по Питеру дешевле 80000 потенциально проблемное.
Тут еще один момент есть. Недавно в обсуждении одной статьи встретил обоснованный коммент. Там говорилось о том, что gemma очень чувствительна к квантованию контекста. Мне нужен достаточно крупный контекст для opencode, приходится использовать q8_0. И гемма через некоторое время 'рассыпается' забывая то, что ещё есть в контексте или просто зацикливается в рассуждениях.
Квантование-сжатие контекста не помогает?
Про llama.cpp верное замечание. По опыту таже ollama может давать двухкратное проседание по сравнению с правильно отстроенным llama.cpp.
Не расскажете, как заставить параллельно две карты работать? По факту в той же llama.cpp на вашем и моем железе доступен только tensor-split в режиме layer, то есть последовательная обработка. И кстати поэтому нет большого смысла ограничивать потребление - один фиг в среднем никогда не будет максимального потребления - видеокарты работают по очереди.
По точности стоит взглянуть на специальные квантования моделей. Для той же qwen3.6-35b есть квантования от fraQtl/apex/duoneural. Если совсем по простому - когда квант по слоям не равномерный, а такой, чтобы найти баланс между размером и точностью.
Вам уже перечислили интересные варианты.
Но стоит ещё посмотреть специальные квантования с повышенной точностью. Для qwen3.6-35b это DuoNeural, fraQtl, APEX. Я в основном сейчас пользуюсь fraQtl с mtp.
Интересно. А какие сборки gemma используете? Я в самом начале после появления в opencode пробовал и очень часто налетал на зацикливание. В итоге пока сижу на qwen3.6
А как вообще по производительности и стабильности этот форк?
Я сейчас как основной использую ik_llama.cpp. Он быстрее (сейчас не так значительно, как 1-2 месяца назад, но все равно ощутимо), а самое главное не так расточителен к памяти. Я не знаю, что сейчас намудрили с llama.cpp, но qwen3.6-27b (точно сборку не помню, квант q4_k_m) при включении mtp просто не лезет в память с максимальном контексте квантованном в q8_0, а на ik_llama еще 2 гб остается от 32 гб.
Не накидаете, что почитать о вашем подходе? Если не сложно, конечно
Спасибо вам. Очень полезная картинка. Личный опыт использования 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).