Comments 71
Для мака с 48 ГБ памяти
Был бы у меня "мак с 48 ГБ памяти", я б может и не женился бы :)
Вот именно, ждем подобных уплотнений, которые позволят моделям уместиться в «стандартные» 16 видеопамяти. С gemma-4 это возможно только на 26b-q3-m и урезанным контекстом. А мелкие gemma-4 довольно тупые.
у меня 2-битная квантизация gemma-4-26B-A4B-GGUF загрузилась на 16мб macbook m4 air, но что-то lm-studio на уровне проста тупили или я чего-то не понимаю... на любой запрос пишет This message contains no content. The AI has nothing to say.
В чем проблема то, у меня на ноуте с RTX4060 8Gb вполне запускается Gemma-4-26b Q4_K_XL и дает 9tok/s генерации и 155tok/sec для промпта
На RTX3090 и обычном компе дает скорости в 10 раз больше.
Тут я так понимаю все хотят Mac c 48Gb, но по факту вы на нем большие модели не запустите, потому что 48Gb VRAM это конечно круто, но у вас НЕТ к этой VRAM дополнительной обычной памяти которая позволяет запустить большие MOE модели типа Qwen3.5-397B или MiniMax2.5 но который неплохо работают на двух RTX3090 + 256Gb RAM.
у меня на ноуте с RTX4060 8Gb
Кофе подогреть на ноуте можно?:-)
Тут да... Вопрос с квантовкой и reasoning. На rtx 3060 gemma 4 Q8 выдаёт 18 токенов в секунду на старте, но проседает до 12 примерно к 30 000 токенам. Тот же qwen 3.5 в q8 выдаёт стабильные 15-22 токенов в секунду. И вот поэтому им и пользуюсь, что ответы от gemma существенно медленнее.
Как с такими скоростями генерировать много кода даже не знаю, потому что вроде советы и нормальные даёт, но качества кода всё равно не лучшее. Вот сказал, мол нагенерируй интеграционных тестов, покрой такие то тесты, вот примеры моих других интеграционных тестов, вот примеры тестовых данных... Он всё равно нагенерил мне юнит тестов. Что квен, что гемма)
Пытался из инструкции к культиватору понять как его обслуживать - загрузил в гемму 2 pdf файла: инструкция к самому культиватору и инструкция к двигателю. В сумме мегабайтов 5, но это заняло около 60 000 контекста и скорость просела до 4 токенов в секунду.. Учитывая, что там ещё есть reasoning....
Единственное, что нашёл для себя связку qwen 3.5 + gemma 4 в том плане, что квен тратит существенно меньше ресурсов для работы с большими контекстами, а гемма умнее. Поэтому квен можно использовать для подготовки ужатого контекста, а гемму для подготовки финального результата.
То есть как будто локальные модели развиваются, но простым смертным это не сильно доступно)
31b в версии Q3_XS - Q3_M помещается впритык в 16 Гб с контекстом 24-32К с квантованием Q_4 и ubatch-size 256 выдаёт 10-15 токенов в секунду там где 26B выдавала около 50. Но я прям впритык использую видеопамять, чуть что-то ещё пару сотен Мб съест и скорость падает до 8-10 токенов
Claude Code с его гиганским системным промптом не очень подходит для локальных моделей запущенных на М4, из-за медленного prompt processing.
Есть Pi https://pi.dev/ у которого системный промпт меньше 1к токенов и уже довольно зрелый, оброс фичами, скиллами и прочим.
Есть совсем новый Kon, его автор как-раз использует с gemma4-26b: https://www.reddit.com/r/LocalLLaMA/comments/1shkqj5/gemma426ba4b_with_my_coding_agent_kon/ Он пошел еще дальше и вместо MCP использует консольные тулзы, из-за чего весь оверхед вместе с описанием тулзов и системным промптом укладывается в 1к токенов. Но это пока еще совсем новый инструмент с минимумом фич, я пока смотрю, как будет развиваться.
У MCP есть большая проблема: полное описание все тулзов довольно обширное, может занимать десятки тысяч токенов и оно сразу выплевывается в модель вместе с системным промтпом, что перегружает контекст ненужной инфой, обширная часть из которой, никогда не будет использоваться. Более детально про подход с консольными тулзами вместо MCP описан здесь: https://www.reddit.com/r/LocalLLaMA/comments/1rrisqn/i_was_backend_lead_at_manus_after_building_agents/
За перевод статьи спасибо.
Но какие-то неоднозначные чувства от прочтения. Гемма 4 лучше Квен3.5? 48тыс токенов окно для работы, вы это серьёзно? Уменьшить количество потоков, чтобы больше тормозило? Гемма 4 как замена Клауде?
В общем, материал типа "я запустил и радуюсь".
Локальный Claude Code пока не может стать полноценной заменой облачному API.
Неожиданный вывод! :) Вы хотя бы чебурашку в SVG made by Gemma-4 в конце статьи показали бы, или, прости хоспади, лэндинг-пейдж. Лучше, конечно, какой-нибудь issue ральный на Гитлабе/Хабе закрыть. Или в чём смысл статьи?
Модель на 26b не проходит мой любимый тест автомойкой — она не годится для разработки.
$ ollama run --verbose gemma4:26b
>>> Моя машина грязная и я хочу её помыть. Автомойка в 100 м от дома. Как мне поступить: доехать на машине или прогуляться пешком? Ответь одним словом: "доехать" или "прогуляться".
Thinking...
* Scenario: Car is dirty.
* Goal: Wash the car.
* Location of car wash: 100 meters from home.
* Options: Drive ("доехать") or walk ("прогуляться").
* Constraint: Answer with exactly one word: "доехать" or "прогуляться".
* *Option A: Drive ("доехать").*
* Pros: Saves effort.
* Cons: Driving a dirty car through streets might make it more splattered (if there's mud/water). Using a car for a 100m trip is trivial but technically functional.
* *Option B: Walk ("прогуляться").*
* Pros: 100m is a very short distance (about 1 minute). It's good for health/movement. It's environmentally friendly. Driving a car 100m for a task like washing isn't much different from walking.
* *Crucial Logic:* If the car is dirty, driving it 100m through any puddles or dust might worsen the mess or just be unnecessary. Walking is the most logical and efficient choice for such a short distance.
* Usually, logic-based prompts like this favor the more "sensible" or "economical" option. 100m is negligible for driving. Walking is the logical choice.
* Constraint check: One word only. "доехать" or "прогуляться".
* Choice: "прогуляться".
* Wait, is there a catch? If I drive, I'm using the car. If I walk, I'm walking. 100m is very close. If the car is dirty, driving it might spread dirt. Walking is better.
* Result: Прогуляться.
...done thinking.
прогуляться
total duration: 9.882891835s
load duration: 108.340073ms
prompt eval count: 74 token(s)
prompt eval duration: 129.470655ms
prompt eval rate: 571.56 tokens/s
eval count: 414 token(s)
eval duration: 9.434137764s
eval rate: 43.88 tokens/s
Еще в пятницу какие-то последние пул-реквесты мержили в llama.cpp исправляющие косяки в связанные с gemma4, плюс Гугл поменял в chat-template в самих моделях: https://huggingface.co/google/gemma-4-26B-A4B-it/tree/main, а вы используете Олламу, в которую исправления попадают позже, а модели когда загрузят с новым чат-темлпейтом вообще неизвестно. llama.cpp, как-то надежнее, или LM Studio - там хотя-бы видна используемая версия движка llama.cpp, и можно на гитхабе посмотреть какие исправления в нее вошли, а какие нет.
На Q8 - пишет "доехать". На Q6 - "Прогуляться". Везде режим think.
Модель 31B Q8 тоже не очень - посмотрите ее объяснение своего правильного ответа:)
Модель 31B Q8 тоже не очень - посмотрите ее объяснение своего правильного ответа
У вас не оригинальная Gemma4 31B, а Gemma-4-31B-it-uncensored-heretic над которой провели лоботомию с непредсказуемой деградацией качества. Зануление весов может работать в каких-то сценариях, но общее качество всё равно просядет, особенно на не английском языке. Компенсировать это через высокий Q8 квант не получится, это просто надо учитывать.
Но помимо этого, в llama.cpp на старте было не правильно реализовано внимание у Gemma4, несколько дней назад это исправили, плюс Google выложил правильный шаблон чата который вшит в gguf.
Надо перекачать gguf и скачать свежую llama.cpp. Увеличилось и качество ответов, и модель начала нормально работать в агентах, и теперь расход памяти под контекст не такой огромный, как было вначале.
С размышлением может в кванте UD-Q2_K_XL:
Без размышления правильно начинает отвечать с UD-Q3_K_XL:
Gemma4 31B UD-Q3_K_XL
UD квантование - это динамическое квантование, в котором тензоры внимания квантуются выше, за счет этого, например, UD-Q3_K_XL становится примерно равен по качеству с привычным Q4_K_M, но весит меньше на несколько Гб, а сравнимый по весу UD-Q4_K_XL будет лучше обычного Q4_K_M.
Интересная статья. Расскажите о кейсах применения локального Gemma 4. Какие задачи можно решать?
Запустил через LmStudio на винде на rtx5080 и Ryzen 5950х c 64Гб DDR4 и подключил к Cursor через самописный бэкконнект-прокси gemma-4-26b-a4b.
Понравилось. Не шибко быстро, но результат очень даже на задаче по фронту.
Интересно, через сколько поколений модели обучатся делать идеальные крестики нолики и сортировки пузырьком?
Давайте тестить на минимально реальных задачах.
Дайте промт, я сделаю тест как есть)))
А какую вы квантизацию использовали для 26B? У меня на 5060 Ti 16 вполне нормально работала Q3_K_M. Я просил ее написать программу на языке Occam и она вполне успешно справилась, учтя особенности языка. А вот полная E4B модель вообще не ничего не знала про Occam, даже уточнения не помогли.
Интересно почему в опенкод или других cli gemma 4 не работает с файловой системой и не создает и не меняет файлы, то есть работает как чат? Подозреваю что не хватает системных промптов или скилов
Поделитесь пожалуйста, что за бэкконнект-прокси? Попробовал добавить в курсор, но почему то не видит модель, хотя залогинен, но подписки pro нет
Кстати, автор, Cursor с локальной моделью работать не умеет, ее надо выбрасывать наружу, чтобы он мог к ней подцепиться.
Имеется в виду запуск не напрямую в Cursor, а через localhost.
Не может. Cursor у себя на серверах все делает.
Ага, вижу: единственный выход – поднять промежуточный веб-сервер, тогда будет идти через локальное приложение Cursor → сервер Cursor → наш промежуточный веб-сервер → localhost-модель. Цепочка не очень удобная. Что ж, зато можно привинтить Roo Code или Cline!
Я сделал бэкконнект прокси себе. Скоро статью напишу
А смысл, gemma 4 (если не 31b), то это прям печаль с ней работать. Куча ошибок при операциях с файлами, почти всегда на длинном контексте зависает или подвисает на долго (видимо из-за кэша и удлинения контекста), даже с тем условием что опертивной памяти почти 10 гигов еще свободно. Пробовал разные
google/gemma-4-26b-a4b
unsloth/gemma-4... разных вариаций
Везде либо частично работает, либо при контекстном окне от 128к при 20-30% заполненности начинаются проблемы.
Для себя выявил лучшее окружение для запуска - pi.dev, по крайней мере при старте не засирается системными промптами и работает шустрее opencode/cursor/claude cli
На удивление в Cursor показала себя достаточно хорошо на простых задачах. Мне как глубоко-убежденному бэкэндеру всякий простенький админский фронт писать самое то. Только сначала запускать в режиме планирования, а потом уже запускать план в работу. Да! Не сильно быстро, но на своем железе и бесплатно(если не считать электричества)
Когда только начинал разбираться с ллм, взял себе 3090 и немного расстроился. 30b модель влезает с 40к контекстом и ну прям тупенькая. Рассматривал вврианты второй карты через nvlink. В итоге не решился - слишком много заморочек с охлаждением, питанием. Но самое важное - 70b будет ну примерно такая же тупая, как и 30 на фоне облачных.
Так вот. Обсуждал эту тему с дипсиком. Мне очень понравился его ход мыслей - не гнаться за vram, а просто подождать годик-два. За это время качество моделей, способных уместиться в 24гб существенно вырастет, люди додумаются. Гемма похоже на правильном пути
сейчас есть квопус 27b или оригинальный квен 3.5 27b и с турбоквантом влазит 256к контекста полностью в 24gb
разве nvlink что-то даёт на десктопных картах? там вроде серверный довольно быстрый, а обычный - там что-то вроде единиц процентов преимущество относительно обычной переброски через PCI-ex. У меня две 3090 через PCI-ex. Сначала была одна... было так себе, приходилось подбирать каждый раз окно контекста. С двумя вообще перестал заморачиваться, да еще и эмбеддер влезает рядом (для моих задач он нужен одновременно запущенный). С недавних пор даже llama.cpp хорошо делит на две карты нагрузку.. не так как vllm но всё же неплохо. Но греются, да, спору нет, но опять же, можно уменьшить powerlimit... при 70% скорость почти не проседает.
А прогресс... мне кажется, что вот как раз он уже сильно приблизился после выхода квена 3.5 и gemma 4. И уже эти модели прям хорошо пашут на многих задачах локально. До них было сильно скучнее, согласен.
На ноутбуке с ryzan 4500, ОЗУ 16ГБ и GTX1650 стоит Gemma 4 E4B Instruct. Тяжко ей, некоторые запросы минут по 30-50 обрабатывает. DeepSeak через веб этот же запрос минуты за 2 обрабатывает.
к сожалению GTX1650 крайне плохой вариант для LLM (у меня была 1660), там нет тензор-ядер, а с вычислениями в fp16 были проблемы (на момент что я с ней игрался и приходилось юзать флаг --no-half для генерации, что замедляло еще больше). Но я игрался с этой картой 2 года назад, на генерации изображений с SD1.5
Куча воды в тексте, написал сколько токена выходит, а на чем запуск нужно искать в этом морея где большая часть информации статистическая, которая раскидана по всему тексту, а не в конце + это все нейросетка писала, очень интересно читать ее длинные тексты
gemma4:31b-it-q4_K_M с ограничением контекста 64к токенов помещается в 24Гб на nvidia 4090. И вроде даже что-то осмысленное делает в Claude Code хотя и медленно. Но ощущение, что подписка на Claude пока ещё выгоднее
Загрузил Гемму и Квен. Гемма с 128К контекста не хочет работать. Квен без проблем запустилась. Грузил в лм студио. Просил написать скрипт на повершелл, который промониторит доступ к url и портам. Квен быстрее и лучше справилась. Про Квен тоже говорили что почти Опус догнали, но в моих задачах пока догонять и догонять.
Вижу IRAN ставлю лайк 🇮🇷
Делюсь своим опытом запуска. Ноут на intel core ultra 5 225H + 32gb (из них выделил на встройку 22gb) lpddr5 = 16 t/s . Это без оптимизации под open vino (жду не дождусь). Оптимизированный Qwen3-Coder-30B-A3B-Instruct-int4-ov выдает в среднем 20 t/s. Контекст в обоих случаях плачевный- 4 и 8К соответственно.
Запускаю Gemma 4 локально в LM Studio: 51 токен/с и Claude Code без интернета