# Лимит HTTP body и лимит токенов: две проверки inference API

Как разделять лимит HTTP body, JSON parsing и модельный context budget: этапы проверки, compressed input, fixtures и корректная классификация отказа.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-request-body-size-limits/
Language: ru

Сервис может отклонить запрос до запуска модели, потому что body слишком велико. Другой запрос проходит HTTP-предел, но превышает допустимый контекст после подготовки сообщений. Внешне оба случая похожи на «слишком длинный вход», однако исправления различаются. Для провайдера нужны отдельные границы размера, парсинга и модельного бюджета, иначе диагностика будет связывать любой отказ с GPU или tokenizer.

## Определите единицы каждого лимита

[NGINX core module](https://nginx.org/en/docs/http/ngx_http_core_module.html) описывает client_max_body_size и связанные настройки обработки тела запроса. Это ограничение bytes HTTP body на соответствующем слое. Оно не является числом токенов и не устанавливает допустимую длину подготовленного chat prompt.

В карте интерфейса назовите максимальный размер транспортного документа, ограничения parser и предел модельной последовательности. Если компонент использует другую единицу, запишите её явно. Символы, bytes, страницы документа и токены нельзя подменять друг другом постоянным коэффициентом для всех входов и языков.

## Проверяйте обработку Content-Encoding

[RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html) описывает семантику представления содержимого, включая его кодирование. Но фактическая поддержка compressed request body зависит от выбранной реализации и конфигурации. Не предполагается, что любой proxy автоматически принимает, распаковывает и безопасно ограничивает такой вход.

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

## Отделите JSON от модели

[RFC 8259](https://www.rfc-editor.org/rfc/rfc8259.html) определяет JSON grammar, но синтаксически корректный документ может не соответствовать API-схеме. После parsing идут проверки messages, roles, типов и выбранной возможности. Только затем появляется основание оценивать вход модели с учётом шаблона и служебных элементов.

Сохраните первую стадию отказа, а не только итоговое сообщение клиенту. Если body не был принят, нельзя объяснять результат недостатком VRAM. Если модельный контекст превышен после успешной валидации, увеличение proxy body limit не решит проблему и может лишь расширить поверхность ненужной обработки.

## Постройте контролируемые fixtures

Нужны короткий допустимый запрос, документ выше установленного byte-предела и запрос в пределах bytes, но за пределом объявленного token budget. Размеры выбираются для локального стенда и записываются как параметры эксперимента, а не как универсальные рекомендации для любого провайдера.

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

## Проверьте порядок после обновления

Изменение proxy, parser или chat template способно сдвинуть наблюдаемую границу. Повторяйте небольшой набор вместе с release checks и сохраняйте эффективные настройки. Если лимиты противоречат друг другу, исправляйте объяснение и политику, а не только один случайный пример входа.

Смежные материалы — [max-model-len](/ru/journal/vllm-max-model-len/) и [длинный контекст](/ru/journal/long-context-capacity/). Они рассматривают модельную сторону; HTTP-fixtures помогают не смешивать её с размером документа на проводе или предположениями о неустановленной поддержке декомпрессии.