Тихий убийца: как неправильная настройка контекстного окна погубила мой AI-помощник

Тихий убийца: как неправильная настройка контекстного окна погубила мой AI-помощник

Сен 02, 2026 ai-development local-llm coding-agents devops configuration-management ollama qwen

Когда умная система ломается по глупым причинам

Есть особый вид раздражения — смотришь на интеллектуальную систему, которая валится из-за ерунды. Недавно столкнулся с этим, когда развлекался с локальными AI-агентами для написания кода. Тема сейчас набирает обороты: open-weight модели стали мощнее, а приватность при разработке волнует всё больше людей.

Задача была простой: может ли агент, работающий полностью на локальном железе, написать работающую игру? Не демку уровня «hello world», а что-то с настоящим управлением состоянием, логикой рендеринга, обработкой ввода и играбельным интерфейсом.

Ответ — да, смог. Но дорога к этому результату вскрыла целый пласт проблем, которые экосистема AI-инструментов пока не решает элегантно.

Настройка, которая должна была работать

Стек состоял из трёх компонентов, представляющих передний край локальной AI-разработки: CLI-агент для написания кода без привязки к конкретному провайдеру, Ollama с OpenAI-совместимым API на localhost, и Qwen3.8 27B на локальной машине.

Для справки — это не слабая конфигурация. Модель 27B при 17 ГБ умещается в 32 ГБ унифицированной памяти и поддерживает tool calling с приличными возможностями рассуждения.

Первые результаты радовали. За пятнадцать минут агент выдал полную HTML-структуру и почти двести строк NES-стилизованного CSS с фасками под аркадный автомат и правильной цветовой палитрой. Ещё круче — агент поймал свою собственную ошибку на лету: записал файл, перечитал, заметил несовпадение между задумкой и результатом на диске, и исправил без подсказок. Это уже настоящее агентное поведение.

А потом агент попытался записать файл с игровой логикой — и всё встало.

Спираль отчаяния

Дальше пошло знакомое зрелище для тех, кто боролся с AI-инструментами. Тринадцать попыток подряд записать файл движка игры, каждая обрывалась на середине генерации. Стрим просто умирал — без ошибки, без объяснения, без полезного вывода.

Самое неприятное — не сам сбой, а наблюдение за процессом рассуждения агента. Каждая попытка начиналась с чистого листа, модель заново выводила одни и те же архитектурные решения, каждый раз получая разные варианты реализации. Три ретрая — три разных ответа на один и тот же вопрос. Агент час думал и не выпускал ничего.

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

Но вывод оказался неверным.

Что на самом деле говорили логи

Серверные логи рассказали совсем другую историю. Ни единой ошибки нехватки памяти. Свободной RAM было 21-27 гигабайт при 17-гигабайтовом следе модели. Память ни при чём.

Настоящая проблема крылась в несоответствии конфигурации, которое не давало видимой ошибки. Агент был настроен на контекстное окно в 32 768 токенов. Но сервер Ollama перезапустили с лимитом 8 192 токена, и эта разница осталась незамеченной. Агент спокойно планировал записать файл на 800 строк за один проход — потому что он думал, что у него есть 32k пространства. Когда генерация упиралась в стену 8k посреди tool call, соединение рвалось без единого сообщения, которое агент мог бы обработать.

Была ещё вторая засада в логах при запуске: Ollama стартовал с включённым контекстным сдвигом, который позволяет окну скользить при заполнении — старые токены уходят, новые входят. Но архитектура модели эту функцию не поддерживала, поэтому она тихо отключилась. Мягкий лимит превратился в жёсткую стену.

DevOps-дисциплина для AI-разработки

Этот опыт высветил кое-что важное, что энтузиазм вокруг open-weight моделей часто затушёвывает. Когда запускаешь модели на своём железе, ты не просто пишешь код — ты эксплуатируешь инфраструктуру. А инфраструктура требует той же диагностической дисциплины, управления конфигурацией и внимания к операционным параметрам, что и продакшен-системы.

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

Практический вывод для разработчиков, которые изучают локальных AI-агентов: валидируй своё окружение так же тщательно, как продакшен-деплой. Проверяй, что конфигурация агента совпадает с параметрами рантайма. Читай серверные логи, а не только вывод агента. Понимай, какие фичи твоя модель реально поддерживает, а не какие пытается включить tooling.

Модели становятся лучше. Инструменты взрослеют. Но разрыв между «работает на демках» и «работает надёжно в ежедневном использовании» всё ещё требует человеческого суждения — и это суждение выглядит как обычная DevOps-дисциплина, применённая к новому классу инфраструктуры.

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

Read in other languages:

BG EL UZ CS TR SV FI RO PT NB PL NL HU IT FR DA ES DE ZH-HANS EN