Посмотрел “Карту пул-реквестов”. И сразу видно - в пятницу не релизим (ну почти). В четверг вjobываем до победного (а точнее до пятницы). Понедельник - отправляем все, что скопилось за пятницу.
Но самый смак - пул-реквесты 24 часа в сутки 7 дней в неделю. Максимум - перед рассветом по выходным их нет.
P.S. Я, конечно, понимаю, что там не обязательно везде один часовой пояс. И не только от разработчиков PR идут (а скорее от дежурных инженеров по ночам). Но все равно очень показательно получилось )))
В Ollama контекст по умолчанию 4096 (для инференса на CPU), т.е. даже меньше. Да, Q4_K_M - это оно. Или что-то вроде UD-Q4_K_XL от unsloth.
OpenWebUI нагружает систему может и не сильно, но у него в требованиях от 2GB RAM. На 1GB RAM он даже не запускается - пробовал на RaspPi 3 запустить, не получилось. Хотя после запуска аппетиты меньше в простое. Но если памяти и так мало - то это может быть критичным.
С Modelfile от ollama не игрался особо - быстро перешел на llama.cpp и ik_llama.cpp, где все настройки можно указать флагами.
Для инференса на CPU неплохо подходят MoE примерной размерности 30B-A3B.
Т.е. те же Qwen3.6-35B-A3B и gemma-4-26B-A4B. 32GB им хватит (как минимум если размер контекста ограничить до 10к и использовать квант Q4), но если есть и другой софт, потребляющий память - то могут быть проблемы с их одновременной работой.
Как запускать - уже другой вопрос. Лично я предпочитаю llama.cpp или ik_llama.cpp - один раз запускаешь с нужной моделью и LLM всегда под рукой, сразу занимая нужную ей RAM. И неплохой UI в браузере до кучи (OpenWebUI хорош, но тяжеловесен).
Практически все модели, что меньше показали себя заметно хуже - или скорость инференса никакая, или просто тупая. Максимум - gemma-E4B может себя чуть лучше показать, но многого я бы не ожидал.
P.S. а Qwen3-Coder-30B-A3B будет заметно шустрее работать относительно Qwen3.6 и gemma-4. Но эта модель послабее будет.
Так Qwen3-Coder (Qwen3-Coder-30B-A3B) - это не мыслящая модель, она сразу начинает отвечать. И да, она в целом склонна к коротким ответам - в этом ее существенный плюс.
Не замечал подобного. От силы на фразу “пиши комментарии в коде на английском” она весь текст ответа на английском дает. Но этим практически все модели “страдают” (по крайней мере из тех, что пробовал локально).
При сравнении gemma3 с qwen3 за gemma были переводы и литературный текст, за qwen технические вещи. Если же брать свежие ревизии gemma4 и qwen3.6 - то я еще недостаточно игрался с ними, чтобы назвать сильные и слабые стороны.
Подозреваю, что с языками gemma4 не хуже справляется. И как минимум технические вещи подтянули у нее - это я уже успел проверить.
Qwen3.6 же только вышел - еще не успел поиграться толком. Обещают прорыв, даже относительно gemma4 (она есть в сравнении от производителя). На сколько правда - другой вопрос.
Но как минимум qwen3.6 правильно отвечает на вопрос вида “Unixtimestamp <…> это какая дата и время по UTC?” - gemma4 совсем слилась на нем.
Линейка qwen как раз знаменита своей хорошей поддержкой русского. Может сильно агрессивный квант скачали? Или был какой тюнинг после квантования? У unsloth c UD-Q2 сталкивался с подобным - перешел на UD-Q4 и все исправилось.
P.S. и да, gemma хороша в переводах. Даже qemma3 была хороша.
В llama.cpp отключается параметром "chat_template_kwargs": {"enable_thinking": false} (или через аргументы передается). Только убедитесь, что --jinja есть в параметрах - не уверен, что в стандартном шаблоне работает параметр.
Вообще, на странице модели через системный промт описывают как включать или отключать мышление.
Ответ больше промта только если спрашивать в чате, постоянно начиная новый разговор. Но после первого же ответа все последующие уточнения имеют больший промт (потому как содержат весь разговор). Благо кеширование спасает )
В агентах же только системный промт может иметь десятки тысяч токенов. А сделать несколько действий - на промты 1кк токенов только так улетит. Благо, кеширование и тут спасает )
По спекулятивному декодированию я бы сказал, что оно не очень в домашних условиях используется - небольшие модели выигрыша не увидят, а для больших железо надо покруче.
Те же модели MoE примерной размерности 30-a3b выглядят оптимально для дома, пробовал подключать спекулятивное декодирование - особого выигрыша не увидел.
Потому как все упирается в объем памяти и в ее пропускную способность. У маков как раз много объединенной памяти (оперативная и видеопамять обьеденина) и она быстрая (чем старше линейка процессора - тем быстрее). GPU по пропускной способности может и быстрее, но больших объемов там нет (а где есть - стоит нереальных денег).
Есть и альтернативы - Ryzen AI MAX+ 395 или NVIDIA DGX Spark. Но это тоже не более чем компромисс - для серьезного использования не хватит ни объема, ни скорости памяти…
Все “думающие” модели можно в не-думающем режиме запустить - для llama.cpp параметр "chat_template_kwargs": {"enable_thinking": false} в запросе (или параметрами запуска настраивается), другой софт может свои параметры иметь для этого.
Качество падает (не сильно, на мой взгляд, но тут от задач зависит), а скорость значительно возрастает.
P.S. Gemma-4-26B-A4B - тоже думающая модель, но она без отметки thinking указана.
И часто происходят эти самые аберрации памяти у человека? Если человек не знает или не уверен - он так и скажет. Да, может додумать/придумать/исказить - не спорю.
LLM же не умеет признаваться в подобном - и это один из значимых недостатков LLM. Она с одинаковой уверенностью говорит и полную ерунду.
И лично у меня больше доверия человеку - особенно если он профессионал в интересующей меня теме.
LLM обучены на материалах от этих же людей - там “личных мнений” на любой цвет и вкус можно найти. Но это все-таки не галлюцинации.
Галлюцинации - это появление фактов, которых не было в обучающих материалах. Человек тоже может забывать, путаться, галлюцинировать в конце концов - не спорю. Но это, как правило, происходит очень редко и сильно от человека зависит.
Интеграционные тесты в лучшем случае проверят, что продукт ведет себя так, как задумывалось. Но оставят за бортом большой пласт проблем из серии “такое не задумывалось”. В частности дыры в безопасности, плавающие баги и прочие моменты. Да, ревью кода не даст гарантий на отсутствие этих проблем. Но хоть что-то - лучше, чем ничего.
P.S. Исследования показывают, что от 70% до 90% современных приложений содержат критические уязвимости из-за недостаточного тестирования кода, созданного ИИ.
Мне кажется, баги чаще всего прячутся в неожиданных местах независимо от того, кто автор.
Да, но с опытом примерно понимаешь, что можно глянуть “краем глаза”, а что надо “копнуть” глубже. С LLM же под внимательное изучение попадает весь код - и все равно упускаются проблемы.
Не говоря уже о том, что после LLM кода просто больше. И LLM в целом имеет привычку усложнять.
Посмотрел “Карту пул-реквестов”. И сразу видно - в пятницу не релизим (ну почти). В четверг вjobываем до победного (а точнее до пятницы). Понедельник - отправляем все, что скопилось за пятницу.
Но самый смак - пул-реквесты 24 часа в сутки 7 дней в неделю. Максимум - перед рассветом по выходным их нет.
P.S. Я, конечно, понимаю, что там не обязательно везде один часовой пояс. И не только от разработчиков PR идут (а скорее от дежурных инженеров по ночам). Но все равно очень показательно получилось )))
В Ollama контекст по умолчанию 4096 (для инференса на CPU), т.е. даже меньше. Да, Q4_K_M - это оно. Или что-то вроде UD-Q4_K_XL от unsloth.
OpenWebUI нагружает систему может и не сильно, но у него в требованиях от 2GB RAM. На 1GB RAM он даже не запускается - пробовал на RaspPi 3 запустить, не получилось. Хотя после запуска аппетиты меньше в простое. Но если памяти и так мало - то это может быть критичным.
С Modelfile от ollama не игрался особо - быстро перешел на llama.cpp и ik_llama.cpp, где все настройки можно указать флагами.
Для инференса на CPU неплохо подходят MoE примерной размерности 30B-A3B.
Т.е. те же Qwen3.6-35B-A3B и gemma-4-26B-A4B. 32GB им хватит (как минимум если размер контекста ограничить до 10к и использовать квант Q4), но если есть и другой софт, потребляющий память - то могут быть проблемы с их одновременной работой.
Как запускать - уже другой вопрос. Лично я предпочитаю llama.cpp или ik_llama.cpp - один раз запускаешь с нужной моделью и LLM всегда под рукой, сразу занимая нужную ей RAM. И неплохой UI в браузере до кучи (OpenWebUI хорош, но тяжеловесен).
Практически все модели, что меньше показали себя заметно хуже - или скорость инференса никакая, или просто тупая. Максимум - gemma-E4B может себя чуть лучше показать, но многого я бы не ожидал.
P.S. а Qwen3-Coder-30B-A3B будет заметно шустрее работать относительно Qwen3.6 и gemma-4. Но эта модель послабее будет.
Так Qwen3-Coder (Qwen3-Coder-30B-A3B) - это не мыслящая модель, она сразу начинает отвечать. И да, она в целом склонна к коротким ответам - в этом ее существенный плюс.
Не замечал подобного. От силы на фразу “пиши комментарии в коде на английском” она весь текст ответа на английском дает. Но этим практически все модели “страдают” (по крайней мере из тех, что пробовал локально).
При сравнении gemma3 с qwen3 за gemma были переводы и литературный текст, за qwen технические вещи. Если же брать свежие ревизии gemma4 и qwen3.6 - то я еще недостаточно игрался с ними, чтобы назвать сильные и слабые стороны.
Подозреваю, что с языками gemma4 не хуже справляется. И как минимум технические вещи подтянули у нее - это я уже успел проверить.
Qwen3.6 же только вышел - еще не успел поиграться толком. Обещают прорыв, даже относительно gemma4 (она есть в сравнении от производителя). На сколько правда - другой вопрос.
Но как минимум qwen3.6 правильно отвечает на вопрос вида “Unixtimestamp <…> это какая дата и время по UTC?” - gemma4 совсем слилась на нем.
Линейка qwen как раз знаменита своей хорошей поддержкой русского. Может сильно агрессивный квант скачали? Или был какой тюнинг после квантования? У unsloth c UD-Q2 сталкивался с подобным - перешел на UD-Q4 и все исправилось.
P.S. и да, gemma хороша в переводах. Даже qemma3 была хороша.
У меня отключились мышления - сразу отдает ответ. Отключал через
chat_template_kwargs.В llama.cpp отключается параметром
"chat_template_kwargs": {"enable_thinking": false}(или через аргументы передается). Только убедитесь, что--jinjaесть в параметрах - не уверен, что в стандартном шаблоне работает параметр.Вообще, на странице модели через системный промт описывают как включать или отключать мышление.
Так Qwen3.6-35B-A3B уже выложен несколько дней назад.
Ответ больше промта только если спрашивать в чате, постоянно начиная новый разговор. Но после первого же ответа все последующие уточнения имеют больший промт (потому как содержат весь разговор). Благо кеширование спасает )
В агентах же только системный промт может иметь десятки тысяч токенов. А сделать несколько действий - на промты 1кк токенов только так улетит. Благо, кеширование и тут спасает )
По спекулятивному декодированию я бы сказал, что оно не очень в домашних условиях используется - небольшие модели выигрыша не увидят, а для больших железо надо покруче.
Те же модели MoE примерной размерности 30-a3b выглядят оптимально для дома, пробовал подключать спекулятивное декодирование - особого выигрыша не увидел.
Все “свежие” модели, что пробовал используют именно enable_thinking в шаблоне (и все “думающие” модели из статьи такие). Но да, бывают варианты.
Потому как все упирается в объем памяти и в ее пропускную способность. У маков как раз много объединенной памяти (оперативная и видеопамять обьеденина) и она быстрая (чем старше линейка процессора - тем быстрее). GPU по пропускной способности может и быстрее, но больших объемов там нет (а где есть - стоит нереальных денег).
Есть и альтернативы - Ryzen AI MAX+ 395 или NVIDIA DGX Spark. Но это тоже не более чем компромисс - для серьезного использования не хватит ни объема, ни скорости памяти…
Работает действительно быстрее, особенно в обработке промта заметна разница - в 1,5-2 раза (на CPU). В генерации токенов особой разницы не заметил.
Все “думающие” модели можно в не-думающем режиме запустить - для llama.cpp параметр
"chat_template_kwargs": {"enable_thinking": false}в запросе (или параметрами запуска настраивается), другой софт может свои параметры иметь для этого.Качество падает (не сильно, на мой взгляд, но тут от задач зависит), а скорость значительно возрастает.
P.S. Gemma-4-26B-A4B - тоже думающая модель, но она без отметки thinking указана.
И часто происходят эти самые аберрации памяти у человека? Если человек не знает или не уверен - он так и скажет. Да, может додумать/придумать/исказить - не спорю.
LLM же не умеет признаваться в подобном - и это один из значимых недостатков LLM. Она с одинаковой уверенностью говорит и полную ерунду.
И лично у меня больше доверия человеку - особенно если он профессионал в интересующей меня теме.
К мифам и легендам. Правда, не понимаю, к чему вопрос. Как это соотносится к галлюцинаниям?
LLM обучены на материалах от этих же людей - там “личных мнений” на любой цвет и вкус можно найти. Но это все-таки не галлюцинации.
Галлюцинации - это появление фактов, которых не было в обучающих материалах. Человек тоже может забывать, путаться, галлюцинировать в конце концов - не спорю. Но это, как правило, происходит очень редко и сильно от человека зависит.
Интеграционные тесты в лучшем случае проверят, что продукт ведет себя так, как задумывалось. Но оставят за бортом большой пласт проблем из серии “такое не задумывалось”. В частности дыры в безопасности, плавающие баги и прочие моменты. Да, ревью кода не даст гарантий на отсутствие этих проблем. Но хоть что-то - лучше, чем ничего.
P.S. Исследования показывают, что от 70% до 90% современных приложений содержат критические уязвимости из-за недостаточного тестирования кода, созданного ИИ.
Да, но с опытом примерно понимаешь, что можно глянуть “краем глаза”, а что надо “копнуть” глубже. С LLM же под внимательное изучение попадает весь код - и все равно упускаются проблемы.
Не говоря уже о том, что после LLM кода просто больше. И LLM в целом имеет привычку усложнять.