Максимум токенов

Максимум токенов — это параметр запроса, ограничивающий число токенов, которые модель может сгенерировать в ответе. Это жёсткий потолок, а не цель: модель не стремится к числу, она просто останавливается, дойдя до него. Смысл параметра — контроль: над стоимостью, над задержкой и над худшим случаем, когда модель иначе продолжала бы генерировать далеко за пределами полезного. Параметр оправдан тем, что длина генерации предсказуема ненадёжно. Промпт, обычно дающий короткий ответ, на необычном входе способен выдать нечто огромное, и без потолка это превращается в медленный запрос и крупный счёт. В многошаговом агенте эффект складывается: вывод каждого шага становится входом следующего, поэтому неограниченный ответ раздувает стоимость всего, что идёт дальше. Характерный сбой — обрезание. Когда предел достигнут в середине фразы, ответ просто заканчивается, и вызывающая сторона получает нечто, выглядящее как полный ответ, пока его не прочитают внимательно. Больше всего страдает структурированный вывод: обрезанный объект JSON не короткий, а невалидный, и код, рассчитывающий на успешный разбор, падает так, будто ошиблась модель, а не конфигурация. Правильная обработка означает проверять причину завершения, которую возвращает провайдер, а не просто наличие ответа. Хорошее значение подбирают, зная распределение, а не выбирая круглое число. Посмотрите на фактическую длину хороших ответов для задачи, оставьте разумный запас над самым длинным законным и относитесь к случаям обрезания как к поводу разобраться, а не как к шуму. Предел, обрезающий один ответ из ста, тихо портит качество; предел, не обрезающий ничего никогда, возможно, вовсе не защищает. Максимум токенов — это потолок, а не способ попросить краткости. Сократить вывод на самом деле помогает указание в промпте ответить в определённом объёме или в заданной структуре; параметр лишь предотвращает патологию. Использование его как регулятора длины даёт ответы обрезанные, а не сжатые, — читателю хуже, а дешевле, чем хорошо сформулированный короткий ответ, не выходит. Ещё одно взаимодействие важно для моделей с интенсивным рассуждением: токены, потраченные на размышление, могут учитываться в том же бюджете, что и видимый ответ, поэтому предел, подобранный под короткую реплику, способен не оставить места самому ответу. Там, где провайдер их различает, планируйте бюджеты отдельно; где нет — ставьте потолок на суммарный вывод и проверяйте на настоящих случаях, а не на предположении.