LLM шлюзінде сурет лимиттері не үшін қажет?

Ауыр мультимодалды сұрауды провайдердің қатесі деп санауға болмайды. Егер шлюз сурет немесе PDF қабылдаса, ол рұқсат етілген кірісті воркер жадын тауысып, base64 бар JSON-ды үлкейтіп, модель контекстінен асып кететін немесе басқа жүйенің түсініксіз қатесіне әкелетін файлдан ажыратуға жауапты.

Лимиттер саясаты клиентті үлкен скан жібергені үшін жазалау үшін қажет емес. Ол бас тартудың сыртқы шақыруға дейін орындалуы, бір тұрақты кодпен қайтарылуы және клиентке нақты нені түзету керегін түсіндіруі үшін керек. Пиксельдер, байттар, вложениелер саны және PDF беттері әртүрлі тәуекелдерді өлшейді. Олардың бәрін max_file_size_mb деген бір өріске сыйғызу мәселенің көп бөлігін бақылаусыз қалдырады.

Ерте бас тарту маршруттауға дейін болуы керек

Шлюз вложениелерді модельді таңдаудан және провайдерге желілік сұрау жіберуден бұрын тексеруі тиіс. Бұл кезеңде HTTP денесінің өлшемі, жеткізу тәсілі, бөліктер саны, мәлімделген MIME-түрі және қауіпсіз талдаудан кейінгі нақты формат, сурет өлшемдері мен құжат беттерінің саны белгілі болады.

Маршруттаудан кейін тексеру тартымды көрінеді: нақты провайдердің шектеулерін алып, файлды оған жібере салуға болады. Іс жүзінде бұл үш мәселе туғызады. Біріншіден, бір клиент сұрауы маршрутқа қарай әртүрлі қате алады. Екіншіден, жауап алдын ала белгілі болса да, шлюз сұрауға қол қоюға, base64 сериализациясына және сыртқы шақыруға уақыт жұмсайды. Үшіншіден, клиент үйлесімді API арқылы интеграцияға емес, нақты провайдердің құжаттамасын оқитын адамға арналған мәтінді көреді.

Ерте тексеру провайдер лимиттерін жоймайды. Ол шлюздің жария келісімшартын маршруттың өзгермелі шектеулерінен бөледі. Жалпы тексеруден кейін маршрутизатор таңдалған модельдің неғұрлым тар профилін қолдана алады. Модель бір ғана файл қабылдаса немесе аудан шегі төмен болса, шлюз сол қате форматымен бас тартады, бірақ таңдалған маршруттың шектеуін көрсетеді.

Реттіліктің мәні қарапайым:

1. HTTP деңгейінде сұрау денесін шектеу.
2. Сұрау құрылымын талдап, барлық медиа бөліктерін жинау.
3. Вложениелерді шектеулі буферге декодтау.
4. Мүмкін болған жерде толық рендерингсіз метадеректерді оқу.
5. Жалпы және маршруттық ережелерді тексеру.
6. Осыдан кейін ғана сұрауды провайдерге беру.

Әр қадамда шлюз алғашқы сенімді бұзушылық анықталғанда жұмысты тоқтатуы керек. Егер сұрау денесі рұқсат етілген шектен асқаны тақырыптан көрініп тұрса, PDF-тің барлық бетін ашудың қажеті жоқ. Файлдар санының лимиті он болса, жиырмасыншы суреттің пиксельдерін есептеудің де қажеті жоқ.

Байттар, пиксельдер және беттер әртүрлі сұрақтарға жауап береді

Файл өлшемі желіге, кезектерге, журналдауға және уақытша сақтауға түсетін жүктемені өлшейді. Пиксель өлшемдері қанша визуалды деректі декодтап, модельге беру керегін көрсетеді. Беттер саны құжатпен жұмыс көлемін өлшейді. Вложениедегі нысандар саны талдауға, токендерге және операциялар санына кететін үстеме шығынды шектейді.

Шлюздерде жиі кездесетін қате: JPEG-ке 10 МБ шек қойып, мәселе шешілді деп санау. Үлкен біртекті аймағы бар JPEG аз орын алуы мүмкін, бірақ декодталғаннан кейін ондаған миллион пиксель беруі ықтимал. Мөлдірлігі, палитрасы және метадеректері бар PNG басқа жүктеме профилін жасайды. PDF үшін файл өлшемі беттер санын, ендірілген растрлар көлемін және рендеринг күрделілігін нашар болжайды.

Сурет үшін кемінде мына төрт мәнді сақтаңыз:

• encoded_bytes, base64 декодталғаннан немесе файл жүктелгеннен кейінгі байт саны;
• width және height, нақты форматтан алынған мәндер;
• pixel_count, ені мен биіктігінің көбейтіндісі;
• mime_type, кеңейтімнен емес, мазмұннан анықталған түр.

PDF үшін page_count қосылады. Егер шлюз беттерді өзі рендеринг жасаса, әр беттің және барлық беттердің жиынтық ауданына да шек қойыңыз. Екі жүз шағын беттен тұратын құжат пен A0 форматындағы екі жүз плакат бірдей емес, тіпті екеуінде де page_count = 200 болса да.

Пиксель лимитін қабырға ұзындығы лимитімен араластырмаңыз. Тек еніне немесе биіктігіне қойылған шек тым созылыңқы суреттерді өткізіп жібереді. Тек ауданға қойылған шек кітапхананы, тұтынушыны немесе алдын ала қарауды бұзуы мүмкін, бір қабырғасы шектен тыс ұзын суретті өткізіп жібереді. Екі ереже де қажет: максималды ен, максималды биіктік және максималды көбейтінді.

Base64 сұрау денесін үлкейтеді, бірақ файл тексеруін алмастырмайды

Клиент data: URI немесе base64 өрісін жібергенде, шлюз дайын файлды емес, жолды алады. Оның ұзындығы бастапқы байттардан шамамен үштен бірге үлкен болады, оған JSON экранирленуі мен URI қызметтік бөлігі қосылады. HTTP денесі лимиті серверді шамадан тыс сұраудан қорғайды, бірақ декодтаудан кейін не шығатынын көрсетпейді.

Сондықтан тексеруде екі шек болуы керек. Біріншісі Content-Length мәнін және клиент chunked transfer қолданса, нақты оқылған байт көлемін шектейді. Екіншісі декодер шығара алатын байт санын шектейді. Жолды алдымен шартсыз түрде жадқа декодтап, содан кейін нәтиже өлшеміне қарауға болмайды. Бұл сәтте қорғаныс әлдеқашан іске аспады.

Тексеру псевдокоды мынадай:

if request_body_bytes > limits.max_request_bytes:
    reject("REQUEST_TOO_LARGE")

for part in media_parts:
    if part.base64_chars > limits.max_base64_chars:
        reject("MEDIA_ENCODED_SIZE_EXCEEDED", part.index)

    decoded = decode_base64_with_output_cap(
        part.data,
        limits.max_file_bytes
    )

    if decoded.output_limit_reached:
        reject("MEDIA_FILE_SIZE_EXCEEDED", part.index)

Base64 ұзындығының лимиті max_file_bytes мәнін алмастырмайды. Ол жұмысты ертерек тоқтатуға және клиент өте үлкен жол жасаған жағдайда диагнозды нақтылауға көмектеседі. Ал нәтиже лимиті ұзындықты қате бағалаудан, бос орындардан, жол үзілімдерінен, URI префикстерінен және іске асыру қателерінен қорғайды.

URL арқылы берілетін вложениелердің мәселесі басқа. Клиент байттарды тікелей жібермегені үшін ғана шлюз URL-ды қауіпсіз деп санамауы керек. Егер шлюз нысанды өзі жүктесе, лимиттерді ағынды оқу кезінде жауапқа қолданыңыз, күтпеген қайта бағыттауларға тыйым салыңыз және сыртқы сұраулардың қайда жіберілуіне бақылау қойыңыз. Әйтпесе inline base64 лимитін қашықтағы файл арқылы айналып өтуге болады.

Метадеректерге соқыр сенуге болмайды

Клиент кез келген байтты image/png деп атай алады, .jpg кеңейтімін тіркей алады немесе JSON ішінде шындыққа ұқсайтын width пен height мәндерін көрсете алады. Бұл өрістердің ешқайсысы шешім қабылдауға жарамайды. Шлюз түрді сигнатура арқылы өзі анықтап, формат тақырыптарын қауіпсіз оқуы керек.

JPEG өлшемдері әдетте кадр маркерлерінде, PNG өлшемдері IHDR тақырыбында, ал WebP өлшемдері өз контейнер құрылымдарында болады. Бірақ бірнеше шартты оператор жазу жеткіліксіз. Форматтарда кодтау нұсқалары мен метадеректер бар, ал сурет өңдегіштері қауіпсіздік жаңартуларын үнемі алады. Ресурс шектеулерімен тақырыптарды оқи алатын кітапхананы қолданыңыз және оны HTTP стек сияқты мұқият жаңартыңыз.

Маңызды шекара бар: метадеректерді оқу байқатпай толық сурет декодтауына айналмауы керек. Егер кітапханаға тек ені мен биіктігі қажет болғанда бүкіл растрға буфер бөлсе, өте жоғары сығылған суреттен әлі де қорғалмайсыз. Өңдегішке жад пен уақыт лимитін қойыңыз, тек оның жұмысынан кейін тексерілетін шектермен шектелмеңіз.

Тексеру реті мынадай болуы мүмкін:

1. Мәлімделген MIME-түрін нақты сигнатурамен салыстырып, саясат қалыпқа келтіруге рұқсат етпесе, қайшылықты қабылдамау.
2. Кітапхана қолдайтын барлық форматты емес, тек қажетті форматтарды рұқсат ету.
3. Шектеулі процесте өлшемдер мен кадрлар немесе беттер санын шығару.
4. Енді, биіктікті, ауданды және нысандар санын тексеру.
5. Тек содан кейін декодтау, түрлендіру немесе нобай жасау.

Анимациялық GIF пен WebP үшін бөлек шешім қажет. Егер маршрут тек статикалық визуалды кіріс қабылдаса, шлюз бірінші кадрды таңдауы немесе ANIMATED_IMAGE_NOT_SUPPORTED кодымен бас тартуы керек. Анимацияны үнсіз қабылдап, әр провайдер оны бірдей түсіндіреді деп үміттенуге болмайды. Кадрлар саны, олардың ауданы және ұзақтығы бір сурет лимиті қамтымайтын бөлек жүктеме санатын құрайды.

PDF-ті бір мезетте құжат әрі визуалды беттер жиыны ретінде санау керек

PDF шлюзге бір вложение түрінде түсуі мүмкін, бірақ модель үшін ол ондаған немесе жүздеген визуалды кіріске айналады. Кейбір модельдер ендірілген мәтінді шығарады, кейбірі беттерді рендеринг жасайды, ал кейбірі екі тәсілді де қолданады. Файл мегабайт лимитінен өткені үшін ғана маршрут кез келген PDF үшін бірдей сапаға уәде бермеуі керек.

Gemini құжаттамасы бұл мәселені нақты бөледі: PDF үшін өлшем мен беттер санына шектеулер көрсетіледі, ал беттер құжатты өңдеу кезінде есептеледі. Бұл max_file_bytes жалғыз ереже бола алмайтынын жақсы көрсетеді. Провайдерлердің нақты шектері мен есептеу тәсілдері өзгеруі мүмкін, бірақ тәуекел моделі өзгермейді.

PDF тексеруі үш бөлек сұраққа жауап беруі керек:

• Құжатта қанша бет бар?
• Оның құрылымын белгіленген жад пен уақыт ішінде қауіпсіз талдауға бола ма?
• Таңдалған стратегия, мәтін шығару, беттерді рендеринг жасау немесе екеуі бірге, қанша жұмыс тудырады?

Бет лимитін өңделген жиынтық аудан лимитімен толықтырған пайдалы. Мысалы, 40 беттік құжат бет саны бойынша шектен өтпеуі мүмкін, бірақ әр бетте үлкен скан болса, синхронды сұрауға қолайсыз болады. Мұнда адал нұсқалар ғана бар: клиенттен құжатты бөлуін сұрау, жібермей тұрып скандарды кішірейту немесе жұмысты асинхронды конвейерге бағыттау.

PDF-ті автоматты кішірейтуді жалғыз жауап етпеңіз. Ол ұсақ мәтінді, мөрлерді, кестелерді және қолтаңбаларды өшіріп, модельдің сенімді, бірақ қате нәтиже беруіне әкелуі мүмкін. Егер шлюз қалыпқа келтіруді ұсынса, клиент оны анық қосып, қай шек қолданылатынын білуі керек. Деректемелерді шығару тапсырмасына бір профиль, көп беттік пакетті жіктеуге басқа профиль сәйкес келеді.

Бір жалпы шек тапсырма профильдерін алмастырмайды

Команда көбіне әмбебап ережеден бастайды: 20 МБ-қа дейін, 20 суретке дейін, 20 мегапиксельге дейін. Мұндай шекті баптау ыңғайлы, бірақ ол сұраудың мақсатын көрсетпейді. Тауарды жіктеуге арналған фото, OCR үшін төлқұжат сканы, шоттар бумасы және медициналық сурет детализацияға, кідіріске және қателерге әртүрлі талап қояды.

Жария лимиттерді базалық профиль мен нақты өңдеу профильдеріне бөліңіз. Базалық профиль шлюзді қорғайды және суреті бар кәдімгі chat completion үшін жарайды. document_ocr профилі беттерді азырақ қабылдайды, бірақ бір бетке жоғарырақ ажыратымдылық береді. bulk_review профилі көбірек нысанға тек асинхронды кезекте рұқсат етеді. image_classification профилі тапсырма ұсақ мәтінге тәуелді болмаса, суретті мәжбүрлі түрде кішірейте алады.

Бұл профильдерді маршрутизатордың жасырын логикасына айналдырмаңыз. Клиент режимді бөлек параметр, модель алиасы немесе endpoint арқылы таңдауы керек. Әйтпесе бір сұрау бүгін өтіп, ертең басқа провайдерге кетіп, жасырын resize салдарынан детальдарын жоғалтады.

Конфигурация мынадай болуы мүмкін:

media_limits:
  default:
    max_request_bytes: 24MB
    max_media_items: 12
    max_file_bytes: 8MB
    max_width: 8192
    max_height: 8192
    max_pixels_per_image: 24000000
    max_total_pixels: 48000000
    max_pdf_pages: 24
  document_ocr:
    max_request_bytes: 32MB
    max_media_items: 6
    max_file_bytes: 16MB
    max_width: 10000
    max_height: 10000
    max_pixels_per_image: 40000000
    max_total_pixels: 80000000
    max_pdf_pages: 12
    require_explicit_pdf_mode: true

Бұл сандар әмбебап норма емес. Оларды воркерлердің өткізу қабілетіне, маршрут лимиттеріне, клиент файлдарының нақты үлестіріміне және рұқсат етілетін кідіріске сүйеніп шығару керек. Бірақ конфигурация құрылымы бастапқы мәндерден маңыздырақ: ол бір шаманың өзін саясат ретінде көрсетуіне жол бермейді.

Қате ішкі құрылымды емес, жасалатын әрекетті түсіндіруі керек

Клиентке provider rejected request деген жол қажет емес. Ол лимиттен не асқанын, оның қай жерде болғанын және қай шек қолданылғанын білуі керек. Бірақ өңдеу стегін, ішкі сервис атауын, нақты провайдердің ережесін немесе жүйеге жүктемені әдейі сынауға көмектесетін мәндерді сыртқа шығармаңыз.

Жақсы API жауабы тұрақты, машина оқи алатын және интерфейске жарамды болады:

{
  "error": {
    "code": "IMAGE_DIMENSIONS_EXCEEDED",
    "message": "Изображение 3 превышает допустимую площадь.",
    "param": "messages[0].content[4].image_url",
    "details": {
      "width": 12000,
      "height": 9000,
      "pixels": 108000000,
      "max_pixels": 24000000,
      "max_width": 8192,
      "max_height": 8192
    },
    "request_id": "req_01J..."
  }
}

Тұрақты код хабарлама мәтінінен маңыздырақ. Мәтін локализация кезінде өзгереді, ал код SDK, retry және аналитикаға қажет. Дене өлшемі, декодталған файл өлшемі, вложениелер саны, сурет өлшемдері, жиынтық аудан, беттер саны, қолдау көрсетілмейтін формат және қауіпсіз талдау қатесі үшін бөлек кодтар беріңіз.

Клиентке жай ғана «кейін қайталап көріңіз» деп кеңес бермеңіз. Ені 12 000 пиксель болатын суретті қайталау арқылы түзету мүмкін емес. Оның орнына нақты әрекетті көрсетіңіз: ұзын қабырғаны кішірейту, PDF-ті бөліктерге экспорттау, файлды жүктеу механизмі арқылы беру, асинхронды режимді таңдау немесе артық вложениелерді алып тастау.

Медиаға қатысты бас тартудан кейін сұрауды басқа провайдерге автоматты түрде қайталаудың қажеті жоқ. Егер шлюз сұраудың өзінің жария шегін бұзғанын анықтаса, қайта маршруттау ештеңені түзетпейді. Ал жалпы шек өтіп, маршрут шегі өтпесе, сапа мен құнды сақтау саясаты анық болған жағдайда ғана үйлесімді маршрутты таңдауға болады.

Бақылау құжат мазмұнын емес, себептерді көрсетуі керек

Метрикаларсыз лимиттер болжамға айналады. Қай тексерулер сұрауларды жиі қабылдамайтынын, қандай форматтар үлкен аудан тудыратынын, клиент SDK жаңарғаннан кейін өлшемдердің қалай өзгеретінін және сәтті сұраулардың шекке қаншалық жақын екенін көруіңіз керек.

Мұндай статистика үшін кәдімгі журналдарға base64, қол қойылған параметрлері бар URL, PDF мазмұны мен OCR мәтінін жазбаңыз. Техникалық өрістер жеткілікті: кіріс түрі, нақты MIME-түрі, кодталған және декодталған байттар, ені, биіктігі, ауданы, беттер саны, бас тарту коды, таңдалған профиль, маршрут класы және сұрау идентификаторы. Сезімтал салаларда бұл деректердің өзі сақтау және қолжетімділік саясатына сай болуы керек.

Екі метрика әсіресе пайдалы. Біріншісі әр код пен клиент кілті бойынша бас тарту үлесін көрсетеді. Екіншісі сәтті сұраулардың лимитке қатысты үлестірімін, мысалы рұқсат етілген ауданның 80%-ынан асатын суреттер үлесін көрсетеді. Қалыпты трафиктің едәуір бөлігі үнемі шекке тірелсе, оны бірден көтермеңіз. Алдымен бір SDK кішірейтілген көшірмелердің орнына камераның түпнұсқаларын жіберіп тұрмағанын тексеріңіз.

Шекаралық тестілер өткізіңіз. Лимитке дәл тең және бір байтқа артық файлдар, биіктігі аз болса да максималды ені бар суреттер, қабырғалары рұқсат етілген кезде максималды ауданы бар суреттер, қайшы MIME-түрі, бүлінген тақырыптар, көп шағын суреттер және мәлімделген бет саны нақты санынан өзгеше PDF қажет. Мұндай тестілер әдеттегі JPEG бар бір сәтті сұрауға қарағанда регрессияларды жақсы ұстайды.

Маршрут ережелерін жария саясаттан бөлек сақтаңыз

Әртүрлі модельдердің рұқсат етілген форматтары, суреттер саны, файл беру тәсілі және визуалды кірістің ішкі құны әртүрлі. Google Gemini құжаттамасы, мысалы, inline деректер, файл механизмі, суреттер саны және PDF беттері үшін шектеулерді бөлек сипаттайды. Мұндай айырмашылықтарды қолданба кодындағы бір санмен сенімді көрсету мүмкін емес.

Маршрут мүмкіндіктерін деректер ретінде сақтаңыз: қолдау көрсетілетін MIME-түрлер, нысандардың максималды саны, inline орнына файл жүктеу талабы, құжат лимиттері, рұқсат етілген сапа режимдері және жазбаның тексерілген күні. Шлюздің жария саясаты консервативті жоғарғы деңгей болуы керек. Нақты модель талап етсе, маршрут саясаты оны тек тарылтады.

Бұл бөлу таңдаудың дұрыс тәртібін береді. Алдымен шлюз қолдау көрсетілетін маршруттардың ешқайсысы қабылдамайтын кірісті алып тастайды. Содан кейін формат пен профильге сәйкес модельдерді таңдайды. Соңында баға, кідіріс, деректер резиденттілігі және қолданба талаптарын ескереді. Бұл кезеңдерді араластырсаңыз, клиент қатесі модельді таңдаудың кездейсоқ жеріне тәуелді болады.

AI Router ішінде мұндай саясатты бірыңғай OpenAI-үйлесімді кірісте, сұрауды сыртқы немесе жергілікті маршруттардың біріне жібермей тұрып қолданған дұрыс. Бұл жағдайда команда base_url мәнін ауыстырып, өз SDK-сын пайдалана бергенде де клиент тұрақты келісімшарт алады.

Бұл санаттағы мәселелерді конфигурациядағы бір үлкен санмен шешуге тырыспаңыз. Қате схемасын нақтылаудан, метадеректерді қауіпсіз оқудан және байттар, пиксельдер, нысандар мен беттерге арналған бөлек есептегіштерден бастаңыз. Сонда әр жаңа лимит туралы пікірталас провайдердің кезекті жауабын болжап отыру емес, нақты жүктеме мен нәтиже сапасы туралы әңгімеге айналады.