Why Local LLM Agents Fail at Complex Tasks (And When They Still Work)

Local LLM‑агенты: почему маркетинг разбивается о жесткий диск

Вчера вечером задача на OAuth с JWT‑обновлением так и не сдвинулась с мёртвой точки. После третьего подтверждённого diff и четвёртого обещания «сейчас добавлю refresh token» разработчик понял, что контекст улетает между вызовами агентов. Логи OpenCode печатали исправно сгенерированные ответы, но ни одна сессия не довела дело до конца. То, что в блогах рисуют как плавный переход от требования к фиксу, на практике превращается в цепочку перезапусков и ручных вставок кода.

OpenCode и Ollama продают образ идеально замкнутого стека: приватность, контроль расходов, отсутствие зависимости от облачных API. OpenCode разбивает задачу на роли — Build (полный доступ к инструментам), Plan (только чтение), General (разведка кода), Explore (только чтение) — и позволяет переключаться между ними или вызывать под‑агентов через @‑упоминание. Ollama держит модель на той же машине, открывает локальный API на 11434 и отдаёт OpenCode совместимые с OpenAI endpoints.

Для простых сценариев — рефакторинг, добавление тестов, генерация документации — стек действительно работает в первые часы. Но как только задача выходит за рамки шаблона, начинают проявляться швы, которые в демонстрационных роликах остаются за кадром.

Цифры из мартовских бенчмарков выглядят убедительно: Step 3.5‑Flash‑INT4 на SWE‑bench достиг 74 %. Но на SWE‑Bench Pro разрыв с облачными моделями уже 5–8 процентных пунктов, а на ARC‑AGI‑2 он заметно шире. Бенчмарки тестируют короткие, воспроизводимые задачи с фиксированным контекстом. Реальная работа — это поток изменений, переключений между задачами, забытых токенов и несохранённых состояний.

Именно здесь локальные агенты начинают «забывать» недавние правки, переспрашивать контекст или останавливаться на середине пути. То, что в блоге выглядит как плавный переход от требования к фиксу, в логах превращается в повторяющиеся сессии с одним и тем же недоделанным результатом.

Приватность и контроль расходов оборачиваются железом и настройкой. При 4‑битном квантовании на каждый миллиард параметров уходит примерно 1,5 ГБ RAM. На ноутбуке с 16 ГБ можно комфортно крутить модели до 14B; 32B уже требуют свопинга или GPU‑оффлоудинга.

MoE‑архитектуры вроде Qwen3‑Coder‑30B‑A3B‑4bit активируют лишь около 3B параметров на токен, сохраняя качество ближе к 30B, но скорость остаётся на уровне модели в 3B. На практике это значит, что на среднем рабочем ноутбуке без дискретной видеокарты вы ограничены либо небольшими задачами, либо большими моделями с заметным лагом. То, что в презентации звучит как «запускаем на ноутбуке», на деле превращается в постоянный мониторинг загрузки RAM и GPU.

За кадром остаются технические швы. Ollama поддерживает /v1/chat/completions и /v1/embeddings, умеет стримить ответы по SSE, но не имеет нативной поддержки стриминга вызовов функций или принудительного tool_choice. OpenCode компенсирует это обходными путями, но в длинных сессиях они начинают ломаться: агенты то и дело переспрашивают контекст, не фиксируют изменения в памяти, а инструменты вызываются не в том порядке.

Лог вчерашнего вечера — не исключение. Build‑агент принял правку, предложил diff, Explore‑агент подтвердил, что тесты прошли, но ни один из шагов не сохранил JWT‑логику в финальной версии. Контекст испарился между вызовами, и каждый раз задача начиналась заново.

Это не значит, что локальные агенты бесполезны. Они хорошо справляются с небольшими задачами на правильном железе: подправить конфиги, добавить тесты, сгенерировать документацию, провести поверхностный рефакторинг. Для команд, которые ценят приватность и предсказуемость затрат, стек OpenCode + Ollama + MoE‑модель может дать до 80 % результата облачных решений при меньших маржинальных расходах — при условии, что железо уже амортизировано и есть кто‑то, кто будет следить за обновлениями моделей и настройками квантования.

Но если проект сжигает больше 50–100k токенов в месяц, требует долгого контекста, мультимодальных вводов или многочасовой оркестрации, облачные модели с топовыми возможностями по tool‑вызовам и long‑context остаются единственным практичным выбором. Локальный стек не заменяет их — он перераспределяет риски: вместо абонентской платы вы платите за железо, за sysadmin‑время и за постоянную подстройку модели. Если в команде нет человека, который готов балансировать между железом, моделями и логами хотя бы полдня в неделю, иллюзия «всё работает локально» быстро превращается в иллюзию.