Локальный агент на карте с 12 ГБ проходит от 9 до 19 шагов, после чего история перестает помещаться в окно модели. Карта на 80 ГБ с моделью в девять раз крупнее держит ровно столько же. Это не опечатка и не парадокс: ниже полный расчет, из которого видно, почему деньги за большую карту покупают качество шага, но не их количество.
Вопрос «влезет ли модель в мою видеокарту» отвечает не на то, что нужно знать перед запуском агента в контуре. Модель влезет: квантизация давно решила эту задачу. Ломается другое — агент проходит четыре шага из двенадцати и упирается либо в память, либо в окно контекста, либо в собственную статистику ошибок. Все три потолка считаются заранее, на бумаге, до закупки железа.
Оговорка о честности, чтобы дальше читать спокойно. Все цифры ниже выведены из архитектурных параметров моделей по формулам, которые вы можете пересчитать под свою конфигурацию за пять минут. Это расчет, и он подписан как расчет. Замеры на нашем стенде идут отдельной публикацией со своими числами; выдавать арифметику за бенчмарк мы не будем.
Что считать шагом
Шаг агента — один полный цикл «модель решила, инструмент отработал, результат вернулся в историю». В окне контекста после каждого шага оседает три вещи:
- Рассуждение модели перед вызовом — от 150 до 400 токенов, если модель думает вслух.
- Сам вызов инструмента в виде структурированного объекта — 60–150 токенов.
- Ответ инструмента — здесь разброс на порядок. Подтверждение «готово» стоит 30 токенов. Выборка из учетной системы на двадцать позиций номенклатуры с реквизитами — от 800 до 3000.
Отсюда три рабочих профиля, которыми я буду пользоваться дальше:
| Профиль агента | Прирост истории за шаг | Типичная задача |
|---|---|---|
| Легкий | ~600 токенов | Статусы, флаги, короткие подтверждения, уведомления |
| Средний | ~1500 токенов | Карточки контрагентов, короткие выборки, письма |
| Тяжелый | ~3000 токенов | Выборки номенклатуры, прайсы поставщиков, документы |
Ключевое свойство: история только растет. Ответ инструмента с третьего шага продолжает занимать место на двенадцатом, хотя нужен он был одну секунду. Именно это свойство и упирает агента в потолок.
Потолок первый: KV-кэш и видеопамять
Во время работы карта держит две вещи: веса модели и KV-кэш — сохраненные ключи и значения внимания для каждого токена, который уже в контексте. Веса занимают фиксированный объем. KV-кэш растет линейно с длиной контекста, и считается он в одну строку:
Байт на токен = 2 × число слоев × число KV-голов × размерность головы × размер числа в байтах
Двойка — потому что хранятся и ключи, и значения. Возьмем типовые конфигурации моделей с групповым вниманием (8 KV-голов, размерность головы 128) и кэш в половинной точности, два байта на число:
| Класс модели | Слоев | KV-кэш на один токен | KV на 32 000 токенов |
|---|---|---|---|
| 8B | 32 | 128 КиБ | 4,0 ГиБ |
| 14B | 48 | 192 КиБ | 6,0 ГиБ |
| 32B | 64 | 256 КиБ | 8,0 ГиБ |
| 70B | 80 | 320 КиБ | 10,0 ГиБ |
Теперь бюджет карты. Из полного объема вычитаем веса в четырехбитной квантизации и резерв на активации, контекст CUDA и фрагментацию — это от 1,3 до 2,5 ГБ в зависимости от размера карты. Остаток целиком уходит под KV-кэш:
| Карта | Модель (4 бита) | Веса | Свободно под KV | Токенов помещается |
|---|---|---|---|---|
| 12 ГБ | 8B | 4,7 ГБ | 6,0 ГБ | 49 152 |
| 12 ГБ | 14B | 8,5 ГБ | 2,2 ГБ | 12 014 |
| 24 ГБ | 8B | 4,7 ГБ | 17,8 ГБ | 145 817 |
| 24 ГБ | 32B | 18,5 ГБ | 4,0 ГБ | 16 384 |
| 48 ГБ | 70B | 39,0 ГБ | 7,0 ГБ | 22 937 |
| 80 ГБ | 70B | 39,0 ГБ | 38,5 ГБ | 126 156 |
Первый неочевидный вывод уже здесь. Модель 14B на карте 12 ГБ оставляет под контекст 12 тысяч токенов — вчетверо меньше, чем модель 8B на той же карте. Ставя модель покрупнее в тот же корпус, вы платите за качество ответа сокращением рабочей памяти агента.
Потолок второй: окно контекста и арифметика шагов
Второй ограничитель — окно модели. Даже если KV-кэш физически помещается, модель не примет больше токенов, чем у нее окно. Возьмем распространенное значение 32 768 и посчитаем, что от него остается агенту.
Из окна сразу вычитается постоянный балласт:
- Системная инструкция — 400–800 токенов на вменяемо описанную роль, границы и правила эскалации.
- Схемы инструментов — самая недооцененная статья. Восемь инструментов с честно описанными параметрами и типами занимают 1500–3000 токенов, и они присутствуют в каждом запросе.
- Постановка задачи — 300–700 токенов.
Возьмем суммарно 3500 токенов накладных. Рабочий потолок — меньшее из двух чисел: окно модели и то, что позволяет VRAM. Дальше делим на прирост за шаг:
| Конфигурация | Упор в | Рабочих токенов | Легкий (600) | Средний (1500) | Тяжелый (3000) |
|---|---|---|---|---|---|
| 12 ГБ + 8B | окно | 29 268 | 48 шагов | 19 шагов | 9 шагов |
| 12 ГБ + 14B | VRAM | 8 514 | 14 шагов | 5 шагов | 2 шага |
| 24 ГБ + 32B | VRAM | 12 884 | 21 шаг | 8 шагов | 4 шага |
| 48 ГБ + 70B | VRAM | 19 437 | 32 шага | 12 шагов | 6 шагов |
| 80 ГБ + 70B | окно | 29 268 | 48 шагов | 19 шагов | 9 шагов |
Вот та самая строка, ради которой стоило считать
Сравните первую строку и последнюю. Карта на 12 ГБ с моделью 8B и карта на 80 ГБ с моделью 70B дают одинаковое число шагов — потому что обе упираются в окно контекста, а окно у них одно и то же. Разница в цене между этими конфигурациями измеряется порядком величины, и покупает она качество каждого отдельного шага: модель крупнее реже ошибается в выборе инструмента и лучше держит сложную инструкцию. Количество шагов она не покупает вовсе.
И обратное наблюдение из середины таблицы: конфигурации 24 ГБ + 32B и 48 ГБ + 70B держат меньше шагов, чем скромные 12 ГБ + 8B. Крупная модель съедает картой собственный контекст. Инженер, который выбирает железо по принципу «возьмем помощнее», на агентной задаче получает систему, которая ломается раньше.
Потолок третий: надежность в степени
Два предыдущих потолка жесткие и честные: до них агент работает, за ними падает с внятной ошибкой. Третий потолок мягкий, и потому опаснее — за ним агент продолжает работать и выдавать правдоподобный мусор.
Пусть на одном шаге модель выбирает верный инструмент и корректно заполняет его параметры с вероятностью p. Шаги независимы, ошибка на любом ломает результат. Вероятность пройти цепочку из n шагов — p в степени n. Экспонента работает против вас:
| Точность шага | 6 шагов | 10 шагов | 19 шагов | 40 шагов |
|---|---|---|---|---|
| 99% | 94,1% | 90,4% | 82,6% | 66,9% |
| 98% | 88,6% | 81,7% | 68,1% | 44,6% |
| 97% | 83,3% | 73,7% | 56,1% | 29,6% |
| 95% | 73,5% | 59,9% | 37,7% | 12,9% |
| 90% | 53,1% | 34,9% | 13,5% | 1,5% |
Прочитайте выделенную клетку вместе с предыдущей таблицей. Карта на 12 ГБ позволяет девятнадцать шагов по памяти. При точности шага 95% — а это приличная точность для локальной модели среднего размера на нетиповых инструментах — до конца доходит меньше сорока процентов задач. Память разрешила девятнадцать шагов; статистика забрала шестьдесят процентов результата.
Отсюда правило, которое стоит повесить над столом: длина цепочки — это не характеристика мощности агента, это его фактор риска. Каждый дополнительный шаг умножает вероятность успеха на число меньше единицы.
Побочный эффект: девятнадцатый шаг медленнее второго
Есть следствие из первого потолка, которое обычно замечают уже на проде. Чтобы сгенерировать один токен, карта обязана прочитать весь KV-кэш целиком. Кэш растет с каждым шагом, значит растет и время шага. Здесь узкое место — это пропускная способность памяти:
Время на токен ≈ размер KV-кэша ÷ пропускная способность видеопамяти
Возьмем модель 8B и пропускную способность 600 ГБ/с — это порядок для потребительской карты, паспортное значение своей подставьте сами:
| Длина контекста | Размер KV-кэша | Время на токен | Шаг в 300 токенов |
|---|---|---|---|
| 2 000 | 0,24 ГиБ | 0,44 мс | 0,13 с |
| 5 000 | 0,61 ГиБ | 1,09 мс | 0,33 с |
| 15 000 | 1,83 ГиБ | 3,28 мс | 0,98 с |
| 29 000 | 3,54 ГиБ | 6,34 мс | 1,90 с |
Разница между началом и концом цепочки — почти в шесть раз, и это только чтение кэша, без учета самих вычислений и работы инструментов. Агент, который бодро отрабатывал первые шаги на демонстрации, к пятнадцатому начинает заметно тормозить, и выглядит это как «что-то сломалось», хотя все работает штатно.
Практический вывод тот же, что и по памяти: приемы, которые сокращают рост истории, одновременно чинят и скорость. Сводки вместо сырых ответов инструментов удерживают контекст в районе нескольких тысяч токенов, и последний шаг цепочки идет почти так же быстро, как первый.
Что происходит, когда контекст все-таки кончился
Отдельно стоит разобрать, как именно ломается агент на переполнении, потому что типовые стратегии вытеснения дают на агентной задаче специфический и дорогой отказ.
Обычное поведение обвязки — выкинуть самые старые сообщения и продолжить. Для чата это разумно. Для агента это означает следующее: из истории исчезает пара «вызов инструмента — его результат». Модель видит задачу, видит инструменты, не находит следа выполненной операции и делает ровно то, что должна — вызывает инструмент заново.
Если инструмент читающий, вы потеряли шаг и немного денег. Если инструмент пишущий, вы получили второй документ в учетной системе. Это тот же класс отказа, что и ретрай после таймаута, и лечится он тем же самым: ключ идемпотентности на каждой операции с побочным эффектом, собранный из смысла операции. Тогда повторный вызов упирается в проверку «документ с таким ключом уже есть» и возвращает существующий результат.
Три правила, которые закрывают этот класс отказов:
- Журнал выполненных операций живет вне контекста. Контекст — это оперативная память модели, и она вытесняется. Факт «заказ создан» обязан храниться в базе; переписка для этого не годится.
- Вытеснение никогда не трогает системную инструкцию и результаты операций с побочными эффектами. Выкидывать можно рассуждения и читающие выборки, они восстановимы.
- Переполнение обязано означать остановку. Дошли до границы — сохранили состояние, отдали человеку отчет. Молчаливое продолжение на обрезанном контексте дороже любой остановки.
Где на самом деле проходит граница
Три потолка складываются так: память и окно задают физический предел, а надежность задает полезный. Полезный всегда ниже.
Инженерная задача локального агента формулируется не через максимум шагов. Она формулируется через минимум: какое наименьшее число шагов решает задачу, и как удержать точность каждого повыше.
Отсюда следует практический вывод, который экономит клиентам сотни тысяч рублей на закупке: сначала считаем шаги, потом выбираем железо. Порядок обратный привычному, и он единственный работающий. Если процесс укладывается в шесть шагов легкого профиля, вам хватит карты на 12 ГБ, и разговор про сервер за несколько миллионов закрыт до его начала.
Как поднять число шагов, не покупая карту
Шесть приемов, все проверяются той же арифметикой. Считаю на базовой конфигурации 12 ГБ + 8B, тяжелый профиль, исходно 9 шагов.
1. Не тащить сырой ответ инструмента в историю
Главный рычаг из всех. Ответ учетной системы кладется во внешнее хранилище, а в контекст возвращается идентификатор и короткая сводка: «получено 34 позиции, идентификатор выборки B7, суммарная потребность 1,2 млн ₽». Когда модели понадобятся детали — она запросит конкретные поля отдельным вызовом.
Прирост за шаг падает с 3000 токенов примерно до 700. Пересчет: 29 268 ÷ 700 = 41 шаг вместо 9. Рост в четыре с половиной раза за ноль рублей на железе.
2. Строгий код вместо шагов модели
Все, что вычисляется детерминированно, обязано вычисляться кодом. Расчет потребности, сверка с лимитами, применение скидочной матрицы, проверка дублей — это арифметика, у нее нет вероятности ошибки. Модель нужна там, где требуется решение в неполных данных.
Эффект двойной. Цепочка укорачивается с 19 шагов до 6, и одновременно растет средняя точность — из цепочки убраны именно те шаги, где модель ошибалась чаще всего. При p = 0,95 доля успешных задач поднимается с 37,7% до 73,5%. Это самый сильный ход в списке.
3. Плоские инструменты вместо цепочек
Три вызова «получить остатки», «получить резервы», «получить заказы в пути» складываются в один инструмент «получить доступное количество по складу». Минус два шага на каждом обращении и минус две точки, где модель могла перепутать параметры.
4. Компактные схемы инструментов
Схемы висят в каждом запросе, и раздутое описание облагает налогом весь диалог. Восемь инструментов вместо двадцати, короткие имена полей, перечисления вместо свободного текста в параметрах. Экономия 1000–1500 токенов постоянного балласта — это плюс один-два шага в тяжелом профиле и заметный рост точности: чем короче список инструментов, тем реже модель промахивается мимо нужного.
5. Сброс контекста между подзадачами
Длинный процесс режется на этапы с явной точкой сохранения. Закончив этап, агент пишет краткий итог в структурированном виде и стартует следующий этап с чистым контекстом, куда подставляется только этот итог. Двадцать шагов подряд превращаются в четыре блока по пять, и потолок перестает быть проблемой вовсе.
Оговорка: сама точка сохранения обязана быть проверяемой. Иначе вы просто переносите накопленную ошибку в следующий блок в сжатом виде.
6. Жесткий лимит шагов как элемент конструкции
Лимит ставится не для красоты. Агент, упершийся в лимит, обязан остановиться и отдать человеку то, что успел собрать, вместе с журналом. Это дешевле любого исхода, в котором он на двадцать пятом шаге принимает решение по контексту, где половина уже вытеснена.
Сводка эффекта
| Состояние | Токенов на шаг | Потолок шагов | Нужно шагов | Доля успешных задач при p=0,95 |
|---|---|---|---|---|
| Как собралось само | 3000 | 9 | 19 | задача не помещается |
| Сводки вместо сырых ответов | 700 | 41 | 19 | 37,7% |
| Плюс строгий код на расчетах | 700 | 41 | 6 | 73,5% |
Обе строки достигнуты изменением архитектуры на той же карте за 12 ГБ. Ни одного рубля в железо.
Когда локальный контур оправдан деньгами
Контур в закрытом периметре дают многие, вопрос всегда в том, во что он обходится. Считается это отдельно от шагов, простой формулой окупаемости:
Месяцев до окупаемости = цена станции ÷ (счет за облако в месяц − электричество и обслуживание в месяц)
Подставьте свои числа. На малых потоках локальная модель окупается годами, и брать ее имеет смысл ради периметра: данные физически не покидают контур, и это самостоятельная ценность, если у вас персональные данные, коммерческая тайна или требования отраслевого регулятора. На потоках от нескольких сотен задач в день арифметика разворачивается в пользу своего железа за год или быстрее. Развернутый расчет с примером — в разборе сметы агентного проекта.
Отдельно предупреждение о ложной экономии. Локальная модель обычно уступает по точности шага крупным облачным, а точность стоит в показателе степени. Выигрыш в 27 000 ₽ на счете за токены обесценивается, если доля доведенных до конца задач упала с 82% до 38% и разницу разбирают руками. Считать надо суммарно: инфраструктура плюс стоимость ручного разбора того, что агент не дотянул.
Что из этого следует для проекта
- Посчитайте шаги до закупки железа. Распишите процесс по шагам на бумаге, оцените прирост истории на каждом, поделите. Час работы экономит выбор карты вслепую.
- Проектируйте под шесть-восемь шагов. Все, что длиннее, режьте на этапы с проверяемым сохранением.
- Считайте схемы инструментов частью бюджета. Они висят в каждом запросе и незаметно съедают контекст.
- Меряйте точность шага на своих данных. Без этого числа таблица со степенями к вам неприменима, а именно она определяет результат.
- Ставьте лимит шагов и журнал. Остановка с внятным отчетом дешевле уверенного решения на исчерпанном контексте.
Что мы меряем на стенде
Все выше — арифметика. Она отвечает на вопрос «сколько шагов помещается» и не отвечает на вопрос «с какой точностью модель их проходит». Второе число берется только замером, и оно зависит от конкретных инструментов, формата данных и языка, на котором написаны схемы.
Мы собираем этот замер на своей станции: одинаковый набор инструментов, одинаковый сценарий закупки, разные модели и разрядности, фиксируем долю верных вызовов на шаг и шаг, на котором цепочка рвется первый раз. Результаты выйдут отдельным материалом с методикой и сырыми числами. До того момента ни одна цифра из этой статьи не выдается за измеренную — здесь только то, что можно вывести на бумаге и проверить самому.
Вопросы и ответы
Сколько шагов держит локальный ИИ-агент?
На карте 12 ГБ с моделью класса 8B — от 9 до 48 шагов в зависимости от того, сколько данных оседает в истории за шаг. Тяжелый профиль с выборками из учетной системы дает 9, легкий со статусами и подтверждениями — 48. Полезный предел ниже физического: при точности шага 95% цепочка из 19 шагов доходит до конца меньше чем в 38% случаев.
Какая видеокарта нужна для локального ИИ-агента?
Начинать считать надо с числа шагов; карта выбирается последней. Процесс на шесть шагов легкого профиля закрывается картой на 12 ГБ. Если по расчету нужно двадцать шагов с тяжелыми ответами инструментов, покупка большей карты проблему не решит: вы упретесь в окно контекста, которое от объема памяти не зависит. Сначала сокращайте шаги, потом выбирайте железо.
Модель побольше решит проблему?
Она поднимет точность отдельного шага, и это ценно — показатель стоит в степени. Но на той же карте крупная модель забирает память у KV-кэша и сокращает доступную длину контекста: 14B на карте 12 ГБ оставляет вчетверо меньше рабочих токенов, чем 8B. Выигрыш в точности приходится взвешивать против проигрыша в длине цепочки.
Чем локальный агент отличается от облачного по надежности?
Механика одинаковая, различаются числа. Крупные облачные модели обычно дают более высокую точность шага, и на длинных цепочках эта разница усиливается степенью. Локальный контур выигрывает там, где данные не могут покинуть периметр, и там, где поток задач достаточно велик, чтобы своя станция окупилась. Оба варианта одинаково выигрывают от сокращения числа шагов.
Сколько стоит собрать локального агента в контуре?
Разработка — от 250 000 ₽ за один сценарий и до 2 500 000 ₽ за промышленный контур с несколькими процессами; полная разбивка сметы по статьям — в отдельном разборе. Железо считается поверх этого и зависит от результата расчета шагов, описанного выше.
Что дальше
Если вам нужно понять, укладывается ли ваш процесс в локальный контур, пришлите его описание по шагам — мы посчитаем потолок, точку окупаемости железа и скажем прямо, когда облако для вашей задачи дешевле. Состав работ и ступени — на странице Разработка ИИ-агентов. Если задача сводится к поиску по внутренним документам без действий в системах, смотрите LLM и поиск по документам в контуре: там другая архитектура и другой чек.