В этом материале
Bytes запроса и токены модели ограничиваются на разных слоях. Один лимит не заменяет остальные и не доказывает защиту после декомпрессии.
Сервис может отклонить запрос до запуска модели, потому что body слишком велико. Другой запрос проходит HTTP-предел, но превышает допустимый контекст после подготовки сообщений. Внешне оба случая похожи на «слишком длинный вход», однако исправления различаются. Для провайдера нужны отдельные границы размера, парсинга и модельного бюджета, иначе диагностика будет связывать любой отказ с GPU или tokenizer.
Определите единицы каждого лимита
NGINX core module описывает client_max_body_size и связанные настройки обработки тела запроса. Это ограничение bytes HTTP body на соответствующем слое. Оно не является числом токенов и не устанавливает допустимую длину подготовленного chat prompt.
В карте интерфейса назовите максимальный размер транспортного документа, ограничения parser и предел модельной последовательности. Если компонент использует другую единицу, запишите её явно. Символы, bytes, страницы документа и токены нельзя подменять друг другом постоянным коэффициентом для всех входов и языков.
Проверяйте обработку Content-Encoding
RFC 9110 описывает семантику представления содержимого, включая его кодирование. Но фактическая поддержка compressed request body зависит от выбранной реализации и конфигурации. Не предполагается, что любой proxy автоматически принимает, распаковывает и безопасно ограничивает такой вход.
Если сжатый body поддержан, выясните, где происходит декодирование и какой предел применяется к результату. Малый размер на проводе не устанавливает малый расход памяти после распаковки. Проверка должна иметь конечный безопасный объём; создавать неконтролируемую нагрузку ради демонстрации различия не требуется.
Отделите JSON от модели
RFC 8259 определяет 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 и длинный контекст. Они рассматривают модельную сторону; HTTP-fixtures помогают не смешивать её с размером документа на проводе или предположениями о неустановленной поддержке декомпрессии.