Провайдери LLM часто віддають 32K контексту всупереч картці моделі

Розробник, який веде хостингового агента для чату й коду на моделях із відкритими вагами, попередив на dev.to 26 вересня: вікно контексту в картці моделі рідко збігається з тим, що реально віддає endpoint.

Число на картці не дорівнює тому, що ви отримуєте

Вікно в картці є властивістю ваг, а вікно, яке реально отримує клієнт, залежить від того, хто обслуговує ці ваги. Серед перевірених автором endpoint-ів більшість дає близько 32K токенів незалежно від заявленого числа, кілька сягають 256K, а цифри 1M із анонсів релізів він досі не зустрів у роботі.

Оператор має причину: максимальна довжина контексту є бюджетом KV-кешу, і мільйон токенів на кожен запит усім був би надто дорогим. Компроміс майже ніколи не документують, і збій відбувається безшумно.

Жодної помилки

413 немає, попередження теж. Запит виконується за найнижчою стелею, і початок контексту просто зникає. У чаті це майже непомітно: розмова з часом трохи дурнішає.

Для агентних запусків це головне обмеження. Довгий build упирається в стелю, спрацьовує компакція, опис мети перетворюється на розмитий переказ, і модель, уже не знаючи точно, що робила, тихо починає план заново. Зовні це виглядає як модель, яка погано працює з довгими задачами; причина в конфігурації хостингу, пише автор.

Як знайти справжню стелю

Надішліть свідомо завеликий запит і прочитайте помилку: провайдери зазвичай розкривають справжній максимум у тексті помилки, тож 500K токенів на endpoint, який обіцяє 1M, покажуть, що прийде у відповідь. Інший метод грубіший: знайдіть момент, коли найдавніший вміст перестає впливати на відповідь, і порахуйте назад.

Ні документація провайдера, ні картка моделі не виявилися надійними.

Три наслідки, які варто засвоїти

Оцінка в бенчмарку описує модель за однієї довжини контексту, а не модель як таку: однакові ваги на 32K і на 200K це не той самий агент. Порівнювати провайдерів за ціною токена, не зафіксувавши стелю, означає називати різницю ціною.

У gateway з fallback-ами стеля може змінитися посеред сесії. Запуск, який переходить із провайдера на 200K на провайдера з 32K, не видає помилки, а обрізає контекст. Це проблема коректності, а не продуктивності.

У RAG це безшумно знецінює налаштування пошуку: розмір chunk-а, top-k і reranking підбирають під бюджет із картки. Система, налаштована на 128K, але обслугована на 32K, витягує зайве, її переранжовані chunk-и обрізаються, а відповідь повертається впевненою й хибною; далі команда береться за embedding-модель, яка не була проблемою.

Побажання автора коротке: можливість дізнатися дійсний обсяг контексту для кожного запиту, хай то метадані чи заголовок відповіді. Він розкриває, що створює Grunz, агента для чату й коду на моделях із відкритими вагами.