У меня MacBook Pro 16 2019 года: шестиядерный Intel Core i7, 16 ГБ оперативной памяти и Radeon Pro 5300M с 4 ГБ VRAM. На нём уже стояли Ollama, gemma3:4b и gemma2:2b.
Идея казалась очевидной: зачем тратить облачный Codex на разбор короткого traceback, сводку лога или commit message? Пусть Codex отдаёт такую работу локальной модели, получает готовый результат и занимается только сложными задачами.
Я сделал MCP‑сервер, подключил его к Codex, прогнал одинаковые задачи и посмотрел точный расход токенов. Интеграция заработала. Экономия — нет.
На одной простой задаче маршрут через локальную модель использовал примерно в два раза больше облачного input, чем прямой ответ Codex.
Ниже — не инструкция «как запустить нейронку за пять минут», а разбор эксперимента: что я собрал, где ошибся в первоначальной гипотезе и для каких задач маленькая локальная модель всё‑таки пригодилась.
Что именно я хотел получить
Не второй чат рядом с Codex, а локального исполнителя внутри рабочего процесса:
Я ставлю задачу Codex.
Codex понимает, что задача простая.
Передаёт её Gemma через локальный инструмент.
Проверяет ответ.
Не расходует дорогой облачный inference на саму рутину.
Для делегирования я выбрал MCP. Codex поддерживает локальные STDIO MCP‑серверы: процесс запускается на компьютере, читает JSON‑RPC из stdin и возвращает результат через stdout. Конфигурация хранится в ~/.codex/config.toml.
Сервер получился маленьким и без внешних Python‑зависимостей. У него один инструмент — local_llm.
{ "prompt": "Что означает эта ошибка?", "context": "SMTPAuthenticationError: 535 authentication failed", "mode": "classify", "max_tokens": 160, "temperature": 0 }
В ответ приходят не только слова модели, но и измерения:
{ "answer": "Incorrect username or password for the email server", "model": "gemma3:4b", "wall_time_ms": 6098, "prompt_tokens": 71, "output_tokens": 44, "tokens_per_second": 9.52 }
Промпты и исходный код я в журнал не пишу. Сохраняются только SHA-256 промпта, длина контекста, модель, время и число токенов. Иначе «локальный и приватный помощник» незаметно превратился бы в ещё одно хранилище исходников.
Первый запуск не состоялся
Codex увидел сервер и попытался вызвать инструмент, но codex exec ответил:
MCP tool call requires approval, but approval policy is never
Поведение правильное. Неинтерактивный процесс не может показать диалог подтверждения, поэтому новый инструмент нельзя молча выполнить.
Для конкретного read‑only инструмента я явно разрешил вызовы:
[mcp_servers.ollama-worker] command = "codex-ollama-worker" default_tools_approval_mode = "approve" [mcp_servers.ollama-worker.tools.local_llm] approval_mode = "approve" output_token_limit = 1200
После этого цепочка заработала: Codex выбрал local_llm, Gemma ответила, а Codex прочитал структурированный результат и вернул итог.
На что способны 2B и 4B
Я составил восемь небольших задач. Они основаны на ошибках, с которыми столкнулся в обычном проекте:
несовпадение hostname в TLS‑сертификате;
SMTP
535;извлечение портов из Docker Compose;
path traversal при загрузке файла;
старая запись, навсегда блокирующая новую;
защита рассылки от повторной отправки;
добавление
UNIQUEв таблицу с существующими дублями;commit message.
Одинаковые промпты запускались с temperature=0.
Модель |
Время восьми задач |
Медиана |
Средняя скорость |
Сгенерировано |
|---|---|---|---|---|
|
147,1 с |
9,4 с |
9,40 ток/с |
1202 токена |
|
109,1 с |
13,8 с |
14,19 ток/с |
1328 токенов |
Обе модели работали на CPU. Несмотря на наличие дискретной Radeon с 4 ГБ VRAM, Ollama показывала 100% CPU.
На простых преобразованиях всё было нормально. Обе модели извлекли внешний и внутренний порт, назвали Redis зависимостью, поняли SMTP 535 и написали приемлемый commit message.
Но уже на коротком security review началось интересное.
Я дал gemma3:4b этот фрагмент:
target = Path('/srv/uploads') / upload.filename with target.open('wb') as output: output.write(await upload.read())
Модель упомянула directory traversal, но главным исправлением предложила заменить бинарный режим wb на текстовый w.
То есть опасное имя файла осталось опасным, а загрузка бинарных файлов дополнительно сломалась.
gemma2:2b выступила чуть лучше: она правильно указала на пользовательский upload.filename, но затем посоветовала использовать Path.joinpath() или os.path.join(). Эти функции соединяют пути, но не обезвреживают ../../etc/passwd.
На логике записей обе модели также промахнулись:
existing = await db.execute( select(Enrollment).where(Enrollment.user_id == user.id) ) if existing.scalars().first(): raise HTTPException(400, 'Уже записан')
Настоящая проблема: запрос учитывает вообще любую старую запись. После первого занятия пользователь может навсегда потерять возможность записываться дальше.
4B‑модель вместо этого предложила перевести русское сообщение об ошибке на английский. 2B заметила, что проверяется любая запись, но объяснила это настолько путано, что готовое исправление из ответа получить нельзя.
Вывод по качеству получился простой: маленькие модели подходят для механической обработки текста, но не для окончательного ревью безопасности и предметной логики.
Где исчезла экономия
После работающего вызова я повторил одну и ту же простую задачу тремя способами: напрямую через Ollama, напрямую через Codex и через связку Codex → MCP → Ollama → Codex.
Задача везде была одна: объяснить SMTP 535 authentication failed и назвать первую проверку.
Маршрут |
Время |
Облачный input |
Облачный output |
Локальные токены |
|---|---|---|---|---|
Ollama напрямую |
6,1 с |
0 |
0 |
71 + 44 |
Codex напрямую |
8,8 с |
14 309 |
49 |
0 |
Codex → MCP → Ollama → Codex |
21,4 с |
29 301 |
384 |
71 + 44 |
Почему через MCP получилось дороже?
Потому что локальная модель не заменяет облачный проход. Сначала Codex должен прочитать запрос и решить, какой инструмент вызвать. После выполнения инструмента Codex снова получает контекст вместе с результатом и формирует финальный ответ.
Для короткой задачи получаются два облачных прохода вместо одного. Локальная модель выполняет полезную работу посередине, но сама её работа почти ничего не вычитает из контекста Codex.
Важно: числа взяты из событий turn.completed, а не из процентов в интерфейсе. Проценты слишком грубые, к тому же параллельно шла разработка самого сервера.
А можно запустить весь Codex локально?
В CLI есть OSS‑режим:
codex exec --oss --local-provider ollama -m gemma3:4b
Я попробовал и его. Сначала запуск упал, потому что Codex запросил thinking, а gemma3:4b его не поддерживает. Я отключил reasoning, но получил следующую ошибку:
registry.ollama.ai/library/gemma3:4b does not support tools
Даже когда в пользовательском запросе написано «не вызывай инструменты», Codex работает как агент и передаёт модели доступные tool‑схемы. Установленная Gemma 3 4B не поддерживает такой режим.
То есть на этой машине получился работающий локальный MCP‑исполнитель, но не полностью локальный Codex‑агент.
Что в итоге имеет смысл
Моя исходная схема была поставлена задом наперёд.
Если облачный Codex уже начал ход, вызов маленькой локальной модели не обязан экономить лимит. Для мелкой задачи он может потратить больше из‑за второго облачного прохода.
Экономия появляется только тогда, когда простая задача полностью заканчивается локально — до обращения к Codex.
Рабочее разделение для моего железа выглядит так:
Локально:
извлечь факты из лога;
сжать длинный вывод команды;
преобразовать JSON или таблицу;
написать черновик commit message;
классифицировать знакомую ошибку.
В Codex:
менять код;
искать причину инцидента в нескольких слоях;
работать с миграциями;
проверять безопасность;
принимать архитектурные решения;
перепроверять сомнительный локальный ответ.
MCP‑сервер я всё равно оставил. Как локальный инструмент он работает, возвращает измеримые результаты и может быть полезен для приватной предварительной обработки. Просто называть его «экономией лимита» после этого эксперимента было бы неправдой.
Следующий шаг — сделать local‑first оболочку: сначала задача попадает в Ollama, а в Codex уходит только по явной эскалации. Именно такую схему уже можно честно проверять на экономию недельного лимита.
Комментарии (34)
Filipp42
19.09.2026 09:09Скажите, а почему вы не взяли Gemma 4? Она ведь гораздо умнее.
crymans Автор
19.09.2026 09:09Потому что промахнулся с выбором модели: взял уже установленные Gemma 2/3 и больше сосредоточился на самой схеме делегирования. Gemma 4 QAT действительно стоило включить. Поэтому сделаю отдельную статью про более новые модели и прогоню их на одинаковых практических задачах. Следом хочу отдельно сравнить модели класса 8–9B — похоже, именно там начинается разумный минимум для локальной работы с кодом и агентских сценариев. Спасибо за наводку.
thethee
19.09.2026 09:09Поэтому сделаю отдельную статью
Если там опять будет нефильтрованный слоп, то не надо, пожалуйста. Остановитесь пока не поздно. Статью с нейросетями нельзя писать так, как вы писали эту, и как отвечаете на комментарии, иначе на статье опять будет много минусов. Даже если там будет что-то полезное, статья будет восприниматься как спам из-за типичнейшего стиля, узнаваемого всеми.
alex-khv
19.09.2026 09:09Mcp ест много контекста. Лучше установить хернес и через командную строку передавать задачу
Areso
19.09.2026 09:09Зависит от MCP, но в общем случае скорее соглашусь, чем нет.
Конкретно в этом случае - не уверен, надо смотреть на тулзы и описания, чтобы понять, сколько контекста отъедает такой сервер.
nidalee
19.09.2026 09:09Да не нужен никакой сервер вообще, просто отправляйте задачу целиком как промпт и получайте результат в ответ. Вот пример скилла для claude, чтобы вызывать codex, никакого mcp не нужно в принципе:
Скрытый текст
#!/usr/bin/env bash # Runs Codex CLI as an external reviewer over the uncommitted changes of a git repo. # Prints the review to stdout. The full Codex log goes to a file whose path is printed at the end. # # Usage: codex-verify.sh [-d DIR] [-e low|medium|high|max] [-m MODEL] [task description...] # -d DIR any directory inside the repo (default: current directory) # -e reasoning effort override (default: ~/.codex/config.toml, currently max) # -m model override (default: ~/.codex/config.toml) # The remaining arguments are passed to Codex as the description of the task the changes implement. # # Exit codes: 0 review produced, 1 Codex failed, 2 usage/environment error, 3 nothing to review. set -uo pipefail usage() { sed -n '2,10p' "$0" | sed 's/^# \{0,1\}//'; exit 2; } DIR="$PWD" EFFORT="" MODEL="" while getopts ":d:e:m:h" opt; do case $opt in d) DIR=$OPTARG ;; e) EFFORT=$OPTARG ;; m) MODEL=$OPTARG ;; *) usage ;; esac done shift $((OPTIND - 1)) CONTEXT="$*" case "$EFFORT" in ""|low|medium|high|max) ;; *) echo "Invalid -e value: $EFFORT" >&2; exit 2 ;; esac command -v codex >/dev/null || { echo "codex not found in PATH" >&2; exit 2; } ROOT=$(cd "$DIR" 2>/dev/null && git rev-parse --show-toplevel 2>/dev/null) || { echo "Not a git repository: $DIR" >&2; exit 2; } cd "$ROOT" || exit 2 if [ -z "$(git status --porcelain)" ]; then echo "No uncommitted changes in $ROOT; nothing to review." >&2 exit 3 fi # Paths handed to codex.exe must be Windows paths; paths used by this script stay POSIX. if command -v cygpath >/dev/null 2>&1; then OUTDIR="$(cygpath -u "${TEMP:-/tmp}")/codex-verify" towin() { cygpath -w "$1"; } else OUTDIR="${TMPDIR:-/tmp}/codex-verify" towin() { printf '%s' "$1"; } fi mkdir -p "$OUTDIR" || exit 2 BASE="$OUTDIR/$(basename "$ROOT")-$(date +%Y%m%d-%H%M%S)" REPORT="$BASE.md" LOG="$BASE.log" PROMPT="Look for bugs and bad decisions in currently uncommitted code. Scope: staged, unstaged, and untracked files. Start from \`git status\` and \`git diff HEAD\`; read untracked files in full. Read surrounding code when a change's correctness depends on it. This is a read-only review. Do not create, modify, or delete any file inside the repository. Do not run git commands that change state (add, stash, checkout, reset, commit, clean). You may run existing tests, read-only commands, or throwaway scripts placed outside the repository to confirm a suspicion." if [ -n "$CONTEXT" ]; then PROMPT="$PROMPT The changes were made for this task: $CONTEXT Judge 'bad decisions' against that intent: wrong approach, unnecessary complexity, silent failure modes, missing error handling, and anything that would surprise the person who asked for it." fi PROMPT="$PROMPT Output: markdown, one bullet per finding, ordered by severity. Each bullet: severity tag (P0 blocker, P1 bug, P2 should fix, P3 nit), file:line, what is wrong, why it matters, the concrete fix. Mark a finding as unconfirmed when you could not reproduce it. If there is nothing to report, say so in one line. No praise, no summary of what the change does, no restating the diff." # Codex CLI cannot reach OpenAI through the proxy configured in the user environment. # Unset it for this process only; the caller's environment is untouched. unset HTTP_PROXY HTTPS_PROXY ALL_PROXY http_proxy https_proxy all_proxy # danger-full-access is required: the Windows sandbox user cannot open UNC paths, so # read-only and workspace-write fail with "access denied" on network shares such as D:\. args=(exec --color never -s danger-full-access -o "$(towin "$REPORT")") [ -n "$EFFORT" ] && args+=(-c "model_reasoning_effort=\"$EFFORT\"") [ -n "$MODEL" ] && args+=(-m "$MODEL") START=$(date +%s) codex "${args[@]}" "$PROMPT" </dev/null >"$LOG" 2>&1 STATUS=$? ELAPSED=$(( $(date +%s) - START )) if [ $STATUS -ne 0 ] || [ ! -s "$REPORT" ]; then echo "Codex exited with status $STATUS after ${ELAPSED}s and produced no report. Last 40 log lines:" >&2 tail -n 40 "$LOG" >&2 echo "Full log: $LOG" >&2 exit 1 fi cat "$REPORT" echo echo "---" echo "repo: $ROOT" echo "elapsed: ${ELAPSED}s" echo "report: $REPORT" echo "log: $LOG"
trinxery
19.09.2026 09:09Подключил локальную Gemma к Codex, чтобы экономить лимит. На простой задаче расход вырос вдвое
Заглядываем внутрь:
gemma3:4b и gemma2:2b
Сначала Codex должен прочитать запрос и решить, какой инструмент вызвать. После выполнения инструмента Codex снова получает контекст вместе с результатом и формирует финальный ответ.
Для короткой задачи получаются два облачных прохода вместо одного. Локальная модель выполняет полезную работу посередине, но сама её работа почти ничего не вычитает из контекста Codex.
Вот так новость, если делать фигню, то получится фигня. -1. Сама статья тоже написана нейронкой, причём этим же GPT, но на Хабре, видимо, котируются разоблачения только самых очевидных случаев написания нейронкой, а тут, кроме обилия
monospace, англицизмов, SHA-256, диаграмм→со→стрелочками, сгенерированных картинок и характерного для чатаГПТ стиля речи других признаков нету.P.S.: В предыдущих статьях автора наблюдается (а почему нельзя ставить ссылки в скрытый текст? редактор-позорище) такой элемент стиля конкретно чатаГПТ, как переносы даже коротких команд
crymans Автор
19.09.2026 09:09«Вот так новость» звучит эффектно, но вы буквально пересказали вывод статьи и выдали его за разоблачение. Эксперимент как раз и показал, что дешёвая локальная модель, поставленная между двумя проходами Codex, не экономит лимит, а увеличивает расход. Отрицательный результат — тоже результат, если показана причина.
С выбором моделей претензия справедливая: 2B/4B недостаточно для серьёзной агентской работы. Поэтому следующим этапом будут Gemma 4 QAT и модели класса 8–9B на одинаковых задачах, с сырыми ответами, временем, памятью и расходом токенов.
GPT при подготовке текста использовался, скрывать это не собираюсь. Но код, запуск, замеры и неудачный результат от этого выдуманными не становятся.
monospace, SHA-256 и стрелки в диаграммах — довольно странная доказательная база. Если в методике или цифрах есть конкретная ошибка, её как раз интересно обсудить.Переносы команд поправлю. А
-1— ваше право, здесь без вопросов.trinxery
19.09.2026 09:09Привет, ЧатГПТ,
вы буквально пересказали вывод статьи и выдали его за разоблачение
Здесь и без эксперимента было понятно, чем всё окончится. Вот. На местном языке это называется "низкий технический уровень материала". Где-то проходит граница между "отрицательный результат — тоже результат" и "вот так новость, если делать фигню, то получится фигня", и, имхо, эта статья относится чисто ко второму варианту.
С выбором моделей претензия справедливая: 2B/4B недостаточно для серьёзной агентской работы. Поэтому следующим этапом будут Gemma 4 QAT и модели класса 8–9B на одинаковых задачах, с сырыми ответами, временем, памятью и расходом токенов.
Давайте сразу пятьдесят статей, чего мелочиться. Вот одна статья с аналитикой сразу ряда моделей для подобного использования была бы интересной.
GPT при подготовке текста использовался, скрывать это не собираюсь.
@moderator бы сильно удивился, если бы ему не было пофигу.
Edit: какое осторожное выражение, "при подготовке текста использовался". Между "писал я, а ИИ искал опечатки" (допустимо), "я написал кучу, а ИИ её пересказал" (недопустимо без дисклеймера) и "я приказал, ИИ написал" пропасть.
monospace, SHA-256 и стрелки в диаграммах — довольно странная доказательная базаПоверьте профессионалу ^_^. И вообще, я же по этим признакам успешно эту статью вычислил, как написанную именно что ChatGPT.
Если в методике или цифрах есть конкретная ошибка, её как раз интересно обсудить.
В статье вообще не приведёно объявление MCP-сервера, т.е. описание его ручек, которое и будет использовать Codex. Не указано, является ли сам сервер агентом, т.е. может ли он вызывать инструменты. Вне зависимости от исхода получается чушь: если может, то в статье не указана информация о вызовах инструментов, а если не может, то получается, то Codex'у надо сформулировать вопрос, подобрать контекст, вызвать сервер, отправив эту задачу, подождать, и получить ответ тупенькой модельки. В таком случае идея "ещё более" была заранее обречена на провал. Сами промпты, размышления и ответы модели тоже не приведены.
crymans Автор
19.09.2026 09:09На счет
MCPсервера принято, но с натяжкой - там одна несчастная ручка, также, замечу, что статья про расход токенов. В материале, прошу заметить, отмечены мощности - это 16 гб и старенький i7. Замечание на счет раздувание статей принято, прошу понять и простить, это мой первый мощный существенный фидбек за 5 статей, буду писать лучше. На счет использованияГПТобидно, не знаю как вас переубедить.
На счет предыдущих статей, как минимум зайдите в профиль, там прикреплен мой веб сайт, при желании, посмотритеDNSLookUp, там естьCNAMEзаписи к реально существовавшему проекту, все материалы написаны на основе реальных ситуаций, для этого я, как минимум собираю логи, как максимум форматирую ихГПТшкой
Сказать задним числом «результат очевиден» несложно. Тогда покажите, как из одной только архитектуры заранее получить двукратный расход, а не, например, прибавку в 10–20%. Я проверил это на работающей интеграции и привёл числа.Edit: @moderator бы сильно удивился, если бы ему не было пофигу.
Очевидно, ведь в моем проекте везде используются модельки. Открою секрет, разрабатываем модели на700 тысяч параметров, которые, как показывает статистика, работают намного быстрее любого асинхронного кода наFastapi.
Что касается конкретно подготовки статей, у меня400ГБлогов в месяц. Самые животрепещущие инциденты сразу вношу вMarkdown, после чего пишу ручками статью. Еще один анонс,ИИможноRagать как угодно, и отвечать моделька вам будет как угодно.
Edit: Прошу, уважаемый пользователь, напиши еще раз, что это все сгенерированоИИ.trinxery
19.09.2026 09:09В материале, прошу заметить, отмечены мощности - это 16 гб и старенький i7.
А это вы к чему? Если статья про расход токенов, то скорость инференса не играет роли.
на счет раздувание статей
Уточню, что замечание не про раздувание, а наоборот, про то, что статье не хватает ряда материалов (входы, выходы, код). Ну и то, что используются устаревшие модели, автоматически делает статью устаревшей прямо в момент выхода.
На счет использования
ГПТобидно, не знаю как вас переубедить.Такая вот корреляция, что если та или иная статья написана ИИ, то есть шанс, что методология хромает. Так как с ИИ кто угодно может писать по любой теме, а проверять написанное всё ещё требует квалификации и приложения усилий, то если не сдерживать поток ИИ-статей, то весь сайт будет заполонён контентом, сообщающим о вещах, для проверки которых ни автору, ни большинству читателей не хватит либо квалификации, либо желания разбираться.
В конце концов, читатели ожидают что статью по некой теме написал автор, который в ней разбирается (это я не про вас, а про отношение к ИИ-статьям в принципе), и написал её сам. Поэтому, например, переводы отмечаются соответствующей табличкой, у цитат и картинок указывается автор, и на влиятельные источники проставляются ссылки.
как максимум форматирую их
ГПТшкойДостоверно известно, конечно, только вам, но я уверен, что в статье влияние ИИ большее, чем просто форматирование. Характерный стиль речи, включая подбор слов и организацию предложений, выдаёт это.
Сказать задним числом «результат очевиден» несложно. Тогда покажите, как из одной только архитектуры заранее получить двукратный расход, а не, например, прибавку в 10–20%.
Из "одной только архитектуры" можно понять, что эффективность общей работы не повысится, а понизится. Этого вывода уже достаточно. Выяснять, понизится производительность на 1%, на 10% или в 10 раз уже не очень полезно.
Есть codex, который и сам умеет вызывать субагентов, чтобы они за него чесали репу. Для замены этого было решено поднять локальную (и медленную) БЯМ с устаревшими моделями, единственным способом применения которой является отправка вопроса от "сильной" модели. Так как локальная модель не является агентом, и не может сама проводить раскопки информации, сильная модель должна сначала составить вопрос, потом подумать, стоит ли ей вызывать локальную модель, потом собрать контекст для локальной модели, сделать вызов, получить результат, подумать над ним. Получается, что сильная модель делает кучу приседаний, которые тратят больше сил, чем получается экономия от вызова локальной модели. Поэтому эффективность падает.
Edit: ответ на edit:
> @moderator бы сильно удивился<...>
Это я к тому, использование ИИ при подготовке статей правилами Хабра запрещено. Вот прямо в такой неадекватной формулировке и написано. Так как правила Хабра ещё и не соблюдаются (судя по всему, ни одно не соблюдается), а @moderatorна вызовы не отвечает, ситуация получается абсурдной.
Открою секрет, разрабатываем модели на
700 тысяч параметров, которые, как показывает статистика, работают намного быстрее любого асинхронного кода наFastapi.Что под этой фразой имеется вообще ввиду? Один токен быстрее одного запроса через fastapi? 700 кБ (например) с запасом влезают в L3-кэш, у кого-то и в L2, так что не очень понятно, чем вы тут хвастаетесь.
Что касается конкретно подготовки статей, у меня
400ГБлогов в месяц.Я выпиваю до 12 порций кофе в день.
Самые животрепещущие инциденты сразу вношу в
Markdown, после чего пишу ручками статью."Ручками" имеет широкое значение. Уже видно ИИшный подбор слов в статьях.
Еще один анонс,
ИИможноRagать как угодно, и отвечать моделька вам будет как угодно.Это вы к чему?
Edit: Прошу, уважаемый пользователь, напиши еще раз, что это все сгенерировано
ИИ.Этот ваш комментарий, скорее всего, не сгенерирован ИИ.
Roman-Usaty
19.09.2026 09:09Меня одного улыбает с аббревиатуры БЯМ?) Просто на слух как будто кто плюхнул того самого нейрослопа на тарелку)
Я выпиваю до 12 порций кофе в день.
А выпиваете как? Все 12 до обеда или в течении дня? Просто на мой взгляд очень много кофе
trinxery
19.09.2026 09:09А выпиваете как? Все 12 до обеда или в течении дня? Просто на мой взгляд очень много кофе
В течении дня. Одна порция из кофемашины довольно небольшая, так что я, который кофе пьёт как воду, делаю сразу две в одну кружку.
ge-os
19.09.2026 09:09Выбор так себе. Попробуйте MiniCPM5-2b или Ling 3.0 tiny. Это лучшие модели в своих тирах и не займут и трети VRAM в Q4_K_M. Даже gemma4 e2b и e4b уже не актуальны, тем более что на деле веса 5 и 8 b соответственно из-за мультимодальности, возможности 3 и 2 версий gemma уже никуда не годятся. В общем опыт был обречён на провал с самого начала. Для полноты эксперимента рекомендую сначала изучить топ artificial intelligence index на владке leaderboards/models в разделе tiny. Там все модели под вашу задачу. Как найдёте фаворита, то приходите на hf в поисках файнтьюнов
TkachenkoD
19.09.2026 09:09С большим успехом можно сделать субагента на 5.6 luna - стоит копейки, работает быстро, и явно умнее любой локальной модели, которая у Вас заведётся. Или DeepSeek v4.1 flash, если есть.
10vivo01
19.09.2026 09:09В ПИ есть плагин pi-shift-router где маленькая модель решает кто будет заниматься задачей(или какую задашь). Я поставил, но пока толком не тестировал, но он работает. Возможно это то что ты ищешь. Ну вот часть команд которые там есть для понимания в возможностей. Fast- это модель которая решает кто будет обрабатывать запрос.
/router on Включить роутинг (по умолчанию)
/router off Отключить роутинг (всё на текущей модели, без переключений)
/router Показать краткий статус
/router status Подробный статус (тир, модель, last decision, статистика)
/router eco Экономичный режим (θ=0.5, больше Fast)
/router default Стандартный режим (θ=⅓, сбалансированный)
/router sport Агрессивный Smart (θ=0.25, реже переключает на Fast)
/router config Интерактивный визард настройки тиров
/router orchestrate on/off/auto Вкл/выкл/авто оркестрации ( делегирование субагентам)
Foggy4
19.09.2026 09:09Очень странный выбор в 2026 году пытаться тестировать прошлогодние и позапрошлогодние модели, да еще и в квантах для мобильных телефонов.
Revertis
19.09.2026 09:09После первого занятия пользователь может навсегда потерять возможность записываться дальше.
А вот это вообще о чём? Статью тоже Gemma2 написала?
Jiablero
19.09.2026 09:09Автор, вы пытаетесь использовать маленькую устаревшую модель как большую и ожидаете от нее того же качества решений. В вашем случае ей нужен FSM: сформируй исправленный код > запусти в песочнице > прочитай вывод, отправь на вторую итерацию, если ошибка. Причем даже решения о том ошибка или нет лучше оставлять алгоритму вокруг модели, а не самой модели. Т.е. разделять залачу на атомарные элементы, желательно делая из нее выбор вариантов а не свободное творчество, проверять и валидировать каждый шаг, переходить к следующему через проверку состояния алгоритмом (если применимо).
Могу сказать что успешно эксплуатирую gemma 4 e4b для таких задач как:
классификация и оценка применимости предложенных алгоритмических решений в пайплайне массовой обработки данных
обработка документов и вывод струтурированной информации из них (ocr, собственный vision модели как фоллбэк)
агент-помощник аналитика (статистика по табличным данным, графики, агрегация данных (тут уже в зависимости от сложности, e4b может не хватать).
И в этих маленькая модель экономит и деньги и время.
Я это к тому что у этих моделей своя область применимости, и это точно не кодинг в широком смысле слова.
В рамках экономии токенов на кодинге попробуйте qwen3.6 35b a3b, qwen3.8 27b, qwen 3.8 flash-next. Я пробовал их давать claude в виде инструкции делегировать задачи локальной модели через запуска opencode, но и тут рещэзультат дискуссионный, потому что claude потом все равно проверял и правил ошибки, и по времени это точно было существенно медленнее чем просто claude (зависит от железа в наличии конечно).
aquasik
19.09.2026 09:09Забавно что никто не хочет прочитать хотя бы базовые вещи о том как устроены "ИИ". Все почему-то уверены что если больше "b" и больше денег уплачено за подписку, значит ллм будет "думать" и что-то там кому-то делегировать.
Насмотрелись маркетинговых роликов Альтмана "140к агентов дружно контролируют друг друга"?
Axara24
19.09.2026 09:09Qwen3.8-27b регулярно тестирую на своем macbook pro m5 max 128gb, но она все равно никак не дотягивает до связки opus-sonnet в кодинге, на болеее простых задачах норм, но для более сложного кодинга она не справляется, то запутается с отступами (у нее какой-то главный глюк с отступами в больших python или jsx файлах, и она может на этом зависнуть надолго), или в целом может сделать все хорошо на небольших задачах, но все равно что-нибудь да нарушит в коде, потом соннет быстро доделывает за ней. Я бы очень хотела увидеть в qwen3.8-27b что-то хотя бы как соннет, но пока нет, доверить ей продакт код не могу, а если и даю какие-то задачи, то обязательно с проверкой опусом. Сама лично с соннет и опусом работаю уже 2 года, начинала еще когда соннет 3.5 был, ну и опус с декабря 2025 вышел в доступной тарификации, поэтому разницу с qwen очень сильно ощущается, так же поработала месяц по подписке в qoder со всеми флагманскими китайскими моделями, в том числе и qwen3.7 max на то время был облачный, все равно не дотягивают до связки opus оркестратор-соннет исполнитель.
ToxaBes
Для любой работы с кодом и в агентских сценариях разумная нижняя граница это 8-9B.
crymans Автор
Согласен. Для самостоятельной работы с кодом 2–4B действительно слишком мало — модель быстро теряет контекст и начинает уверенно выдумывать. Моя идея была не заменить Codex локальной Gemma, а отдавать ей только узкие задачи: классификацию, краткое резюме, поиск очевидных ошибок и подготовку черновиков. Но границу стоило обозначить явно: для нормальной кодовой и тем более агентской работы начинать нужно хотя бы с 8–9B.
remainedmind
Этот коммент gemma написала или codex?)
thethee
Codex, причем даже не Astra, скорее всего gpt 5.6 sol. Для кодекса от такой вот лабуды у меня стоят unslop и ещё парочка скиллов которые стилистику для разных документов правят. Получается хоть как то приемлемо, не так много править, и отвечать стал лучше. А тут прям без фильтров слоп слопом. И построение всего текста, и отдельно взятые предложения. Аж глаз дёргается. Астра хоть и жрет лимиты как не в себя, но хотя бы общается получше
impxiii
ripgrep только работает, но он на процессоре. Не тратьте время, никакая локальная llm не поможет.
AKimovd
Или ИИ, или люди уже у моделей научились))
neiromand
openai к сожалению, в последнее время сломался.
Разумный минимум для работы с кодом это sonnet. А дефолтный opus.
А выбираешь сам, головой перед тем как промп писать - это же 2секундное дело. Но тогда статьи бы не вышло, да-с....
ToxaBes
В рамочку и в галерею самых сильных ИТ-заблуждений этого года. Из пушки по воробьям.
Я согласен, с тем что 8-9B модели гораздо хуже фронтирных, но базовые вещи они делают нормально. Это нормальное решение при малом количестве VRAM.
А вот ~30B модели при правильной подготовке показывают себя на уровне фронтир моделей прошлого поколения и иногда даже превосходят их в типовых задачах, но работают дольше.
Я вообще от фронтир моделей отказался и перешел с харнесс-кодинга, на имаго-кодинг, со временем статью напишу об этом. Фронтир модели периодически тестирую по мере выхода чтобы понимать что куда.
asdadn
Это какие модели? Gemma4-12b и Ornith-9b вроде и что-то совсем шаблонное могут, но иногда так косячат, что эти же задачи проще руками переделать. А я в целом не использую LLMки для чего-то сильно сложного. Вот Gemma4-26b уже довольно хороша, и не косячит на делегируемых мной задачах. Приятнее всего, конечно, Qwen3.8-27b для агентского режима и Gemma4-31b для чата.
О таком звере первый раз слышу, нагуглить что-то не могу. Можете, пожалуйста, подсказать, где об этом можно почитать?
ToxaBes
Все на базе Qwen архитектуры:
Qwen3.5-9B это база для кодинга в таком размере.
Ornith1.0-9B для агентной работы. Это пост трейнинг Qwen3.5 под многошаговую работу в роли агента ценой ухудшения непосредствеено кодинга. Именно 1.0 версия, не 1.5.
Qwopus3.5-9B-coder свежая модель, дистиллят Qwen на ответах Opus, заточена как под агенсткую работу, так и под работу с tools.
Вы правы, Qwen лидер среди моделей подобного класса, еще Ornith 35B неплох и работает быстро.
Это мое самоназвание, дальнейшее развитие работы с моделями над проектами после вайбкодинга/чата и харнесса/RAG. Поэтому расскажу сразу отдельной статьей.
asdadn
Что ж, это многое объясняет.
Да, его тоже пробовал и остался доволен, но меня вполне устраивает скорость Qwen3.8-27b, так что сильно много с ним времени не проводил. Единственный минус, который могу отметить у Qwen3.8-27b, так это то что на естественных языках пишет он как-то странно и перегруженно, читать это порой сложно. Поэтому для чатов Гемма представляется мне куда полезнее, она ещё и за пределами программирования меньше галлюцинирует.
Пишите, будет интересно почитать.