Планировщик бюджета и лимитов для нескольких AI-проектов

Планировщик сначала вычитает из общей суммы резерв, затем распределяет доступный бюджет пропорционально весам. Вес — не процент и не прогноз токенов, а относительный приоритет: проект с весом два получает вдвое больше проекта с весом один. Для каждого лимита отдельно считается warning threshold. Формула прозрачна и не обращается к серверу, поэтому её удобно использовать на бюджетной встрече.

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

Резерв не распределяется заранее между проектами. Он оставляет пространство для сезонного пика, уже выполняющегося запроса и контролируемого решения владельца. Размер выбирают по истории нагрузки и максимальной операции, а не по универсальному проценту. Если резерв постоянно расходуется, его нельзя бесконечно увеличивать: нужно пересмотреть прогноз или устранить повторы.

В критичном контуре финансовый запас дополняют timeout, ограничением параллелизма и собственным circuit breaker. Один запрос может завершиться после достижения лимита. Поэтому нулевой резерв не означает строгую остановку на заданной сумме, а высокий резерв не заменяет мониторинг.

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

Проекты в TokenTool являются логическими группами. Отдельный лимит и ключ помогают учёту, но не обещают RBAC или автоматическую изоляцию данных. Если несколько клиентов используют одно приложение, права и маршрутизацию проверяют вне этого расчёта.

После согласования для каждой строки создают или выбирают логический проект, выпускают отдельный ключ, задают лимит и назначают владельца warning-сигнала. Значения credentials не копируют в таблицу. В техническом паспорте сохраняют только код ключа, назначение, дату выпуска и процедуру отзыва.

На первой сверке сравнивают лимит, предупреждение, успешные операции и списание. Если модель или сценарий изменились, план пересчитывают. Generic non-chat нагрузки тестируют отдельно: инструмент не заявляет одинаковое поведение ограничений для всех типов генерации.

Перед утверждением сохраняют базовый, пиковый и аварийный варианты. В базовом действуют плановые веса, в пиковом растёт полезная нагрузка одного проекта, в аварийном увеличивается доля повторов. Для каждого варианта команда проверяет, хватает ли резерва и когда срабатывает warning. Если один проект забирает весь запас, его границу и правила эскалации описывают отдельно.

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