Что такое механизм предварительного списания для API-вызовов?
Как работает предварительное списание (предварительно потреблённая квота) в APIYI: перед запросом оно оценивает удержание на основе цены модели и входных данных, а затем производит окончательный расчёт по фактическому использованию — а также как читать ошибку insufficient_user_quota.
Перед тем как запрос фактически выполняется, APIYI рассчитывает предварительное удержание («цена модели × предполагаемые token» — максимальная возможная стоимость) и временно блокирует эту сумму на вашем балансе. Когда запрос завершается, система производит окончательный расчет по фактически использованным tokens и возвращает разницу — предварительное удержание это только оценка, а не итоговый счет.
Две ключевые строки
Предварительное удержание: предварительная оценка перед запросом, которая используется, чтобы понять, «можете ли вы оплатить этот вызов».
Фактическая тарификация: окончательный расчет по реальным token после завершения запроса — именно это и списывается по-настоящему.
Если оценка предварительного удержания > ваш текущий баланс, запрос отклоняется еще до запуска, и возвращается insufficient_user_quota. Это и есть основная причина ситуации «баланс у меня явно есть, но запрос все равно не проходит».
Система читает ваш input (prompt, изображения, историю переписки и т. д.) и, используя текущую цену модели и оценочную длину output, вычисляет максимально возможную стоимость и временно удерживает ее из вашего баланса.Оценка примерно такая:pre-deduction ≈ model price × (input tokens + estimated output tokens)
2
Проверка перед отправкой: достаточно ли баланса
Она сравнивает предварительное списание с вашим текущим балансом:
balance ≥ pre-deduction → разрешено, запрос отправляется
balance < pre-deduction → отклонено с insufficient_user_quota, и вызов фактически не выполняется
3
После запроса: расчет по факту, возврат разницы
После завершения система берет фактическое использование token для input/output и пересчитывает списание по факту:
фактическая стоимость обычно меньше, чем pre-deduction → излишне удержанная квота возвращается на ваш баланс
неудачные/прерванные запросы → как правило, не тарифицируются, а удержанная квота освобождается
Большое предварительное списание не означает, что вы действительно потратили столько же — это оценка в формате «резерв на худший случай». Фактически списываются actual token после завершения запроса.
Когда предварительное списание превышает ваш баланс, вы увидите примерно такое:
{ "error": { "message": "user [25359] quota [50264897] preConsumedQuota [154753475] is not enough", "localized_message": "Insufficient user quota", "type": "shell_api_error", "param": "", "code": "insufficient_user_quota" }}
По полям:
Поле
Значение
quota [50264897]
Ваш текущий доступный баланс (внутренняя единица квоты)
preConsumedQuota [154753475]
Квота, которую этот запрос хочет предварительно списать
is not enough
предварительное списание > баланс, недостаточно для удержания, запрос отклонен
code: insufficient_user_quota
Код ошибки: недостаточная квота пользователя
Важно именно соотношение между двумя числами: здесь предварительное списание 154753475 примерно в 3× больше баланса 50264897, поэтому оно блокируется.
Эти числа — это внутренние единицы квоты APIYI, и их можно напрямую сравнивать. В долларовом выражении: баланс ≈ $100, оценка предварительного списания для этого запроса ≈ $310 (внутри системы ~500,000 единиц ≈ $1). Иными словами, этот единственный запрос попытался удержать более $300, хотя на счете было только $100 — поэтому он не смог выполниться.
Почему «у меня есть баланс, но это не запускается»
В подавляющем большинстве случаев проблема в слишком большом input, а не в самом балансе.Реальный пример: gpt-5.5 имеет контекстное окно до 1,050,000 tokens. Если загрузить туда весь большой code repository, количество input token становится огромным, и предварительное списание резко возрастает — даже при балансе в $100 оценка в $300 все равно будет отклонена еще до запуска запроса.
Чем больше input, тем выше предварительное списаниеСлишком большой input не только увеличивает предварительное списание и легко вызывает insufficient_user_quota, но и:
даже если запрос пройдет, фактическая стоимость будет высокой (тарификация идет по реальным token);
если загрузить слишком много нерелевантного контента, модель может вернуть посредственный результат — деньги потрачены, а результат слабый.
Отправляйте только релевантный код/документацию — не загружайте весь репозиторий или длинный документ целиком. Это самый эффективный способ исправить проблему.
Установите max_tokens
Явно ограничьте длину вывода, чтобы снизить «оценочное количество output tokens» и, соответственно, предварительное списание. См. руководство по max_tokens.
Пополните баланс
Если вам действительно нужен большой входной объем, просто убедитесь, что баланс > предварительное списание. См. способы оплаты.
Сначала протестируйте на небольшой модели
Проверьте, что ваш входной объем разумен для дешевой модели, а затем переключитесь на более дорогую — не допускайте «сжигания больше, чем вы можете себе позволить».
Будьте осторожны с большими входными данными: модели с большим контекстным окном (например, у gpt-5.5 1.05M tokens) могут удерживать очень много, но «могут удерживать» не означает «должны удерживать». Запихивать в них весь репозиторий часто и дорого, и посредственно — сначала подумайте, какой контекст вам действительно нужен.
Действительно ли предварительное списание спишет такую сумму?
Нет. Предварительное списание — это лишь временное удержание перед запросом; окончательное списание определяется фактическим использованием token после завершения запроса, а излишне удержанная часть возвращается. preConsumedQuota, который вы видите, — это оценка «резерв на худший случай», а не реальный счет.
Будет ли с меня списание, если запрос завершится ошибкой?
Обычно нет. Ошибка insufficient_user_quota блокируется до выполнения, поэтому модель фактически не вызывается, реальных затрат не возникает, а удержанная квота освобождается.
На балансе явно достаточно средств — почему возникает ошибка квоты?
В этой ошибке сравнивается предварительное списание с вашим балансом, а не «фактическая стоимость» с балансом. Слишком большой ввод делает оценку предварительного списания намного выше вашего баланса, поэтому запрос отклоняется. Сначала сократите ввод или задайте max_tokens, чтобы снизить оценку вывода, и пополните баланс, если этого все еще недостаточно.
Всегда ли модели с большим контекстным окном дороже?
Базовая цена модели задается самой моделью — большее окно ≠ более высокая цена за единицу. Но большее окно означает, что вы можете передать больше ввода, и когда вы действительно заполняете его, количество input tokens резко растет, и как предварительное списание, так и фактическая стоимость становятся высокими. Дорого стоит не само окно, а «сколько вы в него помещаете».