Как да проектираме резервни LLM без прекъсване на латентност, разходи или договори за изход

Резервният вариант не е просто списък с резервни модели. За инженерни екипи, използващи няколко доставчици на LLM, резервният вариант е политика за маршрутизиране, която решава кога дадена заявка може да се премести от един доставчик или модел към друг, какво трябва да остане непроменено и как системата доказва, че алтернативният път е направил приложението по-надеждно.

Проблемът с четеца обикновено е прост: намалете неуспешните заявки и по-ниско забавяне на опашката, без тихо да променяте качеството на изхода, валидността на схемата, поведението на безопасност или разходите. Решението е по-конкретно от „опитайте друг доставчик“. Надеждната резервна стратегия за LLM се нуждае от класифициране на грешките, крайни срокове за заявка, правила за съвместимост на модела, ограничения на разходите, прекъсвачи и наблюдаемост на ниво доставчик и маршрут.

Започнете с политика за резервен вариант, а не с повторен код

Повторните опити и резервният вариант решават различни проблеми. Повторният опит изисква от същия доставчик да изпълни същата заявка след временна грешка. Резервният вариант изисква друг модел, доставчик, регион или маршрут да завърши работата вместо това. Смесването на тези опасения създава системи, за които е трудно да се разсъждава по време на инциденти.

Факт: Насоките за надеждност от доставчиците на облачна инфраструктура обикновено препоръчват ограничено експоненциално забавяне, трептене, максимални ограничения за повторни опити, проверки за идемпотентност и избягване на повторни опити на множество нива, тъй като бурите при повторни опити могат да влошат претоварването. Основните доставчици на LLM също така документират преходни грешки, ограничения на скоростта, отговори на претоварване, изчакване и SDK поведение при повторен опит.

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

Минималната политика трябва да отговори на тези въпроси, преди да бъде написан какъвто и да е код:

• Кои грешки могат да се опитат повторно на същия доставчик?
• Кои грешки позволяват връщане към друг доставчик или модел?
• Кои повреди никога не трябва да задействат резервен вариант?
• Какъв изходен договор трябва да остане идентичен?
• Какво е максималното разрешено увеличение на разходите?
• Колко от крайния срок за заявка може да бъде изразходван, преди резервният вариант да бъде забранен?
• Коя телеметрия доказва дали резервният вариант е помогнал или скрихте дефект?

Класифицирайте грешките, преди да ги заобиколите

Резервният вариант е опасен, когато всеки non-200 отговор се третира по един и същи начин. Времето за изчакване на доставчика не е същото като неправилно формирана заявка. Ограничението на скоростта не е същото като отказ за безопасност.Неуспешното валидиране на изхода не е същото като повреда на мрежата.

Практическата таксономия трябва да включва поне тези класове:

• Повторна грешка при транспортиране: нулиране на връзката, проблем с DNS, временна повреда на мрежата или таймаут на шлюза.
• Претоварване на доставчика: документирано претоварване или преход от страна на сървъра грешка.
• Ограничение на скоростта: ограничение за заявка, токен, ускорение или квота, особено когато е предоставена стойност за повторен опит.
• Време за изчакване на доставчика: доставчикът прие заявката, но не завърши в рамките на прозореца на услугата.
• Невалидно заявка: неправилно образуван полезен товар, неподдържан параметър, невалидна схема или несъвместима с модела опция.
• Грешка при удостоверяване или конфигуриране: лош ключ, деактивиран акаунт, липсващо право или изчерпана квота на ниво акаунт.
• Отказ за безопасност или блокиране: доставчикът умишлено отказва или блокира съдържание въз основа на политиката за безопасност.
• Грешка при валидиране на изхода: моделът отговори, но отговорът не отговаря на договора за приложение.

Препоръка: повторете само преходни грешки в рамките на бюджета за латентност на обаждащия се. Разрешете резервен вариант само за класове грешки, които екипите на продукта и платформата са изрично одобрили. Не се връщайте към грешки при удостоверяване, неправилно формирани заявки, грешки в детерминистична схема или откази за безопасност, освен ако продуктът не дефинира конкретно алтернативно безопасно поведение.

Това разграничение има значение, тъй като в противен случай резервирането може да скрие грешки. Ако дадена схема е невалидна за основния доставчик и случайно бъде игнорирана от резервен доставчик, системата може да изглежда по-здравословна, докато връща по-малко ограничен изход. Това не е надеждност; това е дрейф на договора.

Използвайте крайни срокове, а не само изчаквания

Проблемите със закъснението на опашката често идват от повторни опити, които са технически ограничени, но на практика твърде бавни. Заявка с 15-секунден бюджет, обърнат към потребителя, не трябва да прекарва 14 секунди в неуспех на основния маршрут и след това да започне пълен резервен опит, който не може да завърши навреме.

Използвайте краен срок за заявка, който преминава през целия стек. Всяко решение за маршрутизиране трябва да проверява оставащото време, преди да направи повторен опит или да се върне обратно. Например:

request_deadline_ms = 6000
primary_attempt_timeout_ms = 3500
retry_backoff_budget_ms = 500
minimum_fallback_budget_ms = 1800

if remaining_deadline_ms < minimum_fallback_budget_ms:
    return controlled_failure

Точните числа зависят от натоварването. Маршрутът за завършване на чат може да запази достатъчно време за един алтернативен модел. Задачата за извличане във фонов режим може да позволи няколко опита. Пътят за автоматично довършване в реално време може да предпочете бърз отказ пред късен резервен отговор.

Препоръка: дефинирайте бюджетите за забавяне по клас маршрут, а не глобално. Маршрутът на потребителския интерфейс с ниска латентност, маршрутът за групова класификация и маршрутът за анализ на дълъг контекст не трябва да споделят една и съща обвивка за повторен опит и резервен вариант.

Дефиниране на класовете на модела според работното натоварване

Имената на доставчици са лоша абстракция за резервен вариант. Приложението се грижи за свойствата на работното натоварване: дължина на контекста, дълбочина на разсъжденията, поддръжка на инструменти, структурирано поведение на изхода, латентност, ограничения за обработка на данни и цена.Резервните маршрути трябва да бъдат организирани около тези свойства.

Полезните моделни класове включват:

• Бърза чернова: кратки отговори, ниска латентност, умерен толеранс на качеството.
• Структурирано извличане: строг JSON изход, проверка на схема, нисък толеранс за формат отклонение.
• Обосновка: многоетапен анализ, по-високи изисквания за качество, по-висока приемлива латентност.
• Дълъг контекст: големи документи, прозорци с големи токени, внимателни правила за съкращаване.
• Евтин пакет: асинхронни или неспешни задачи, оптимизирани за икономика на единица.
• Премиум ескалация: скъпи, но способни модели, използвани само когато политиката позволява.

За всеки клас избройте разрешените първични модели, разрешените резервни модели и забранените пътища за понижаване. Заявката с дълъг контекст не трябва да се връща към модел с кратък контекст, който тихо съкращава подканата. Задачата за структурирано извличане не трябва да се връща към модел, който не може да удовлетвори ограниченията на схемата. Премиум задача за мотивиране може да позволи връщане към друг премиум модел, но не и към бърз чернови модел, освен ако потребителското изживяване изрично не поддържа влошен отговор.

За екипи, изграждащи корпоративен LLM API, тези класове трябва да съществуват в данни за конфигурация или правила, а не разпръснати в услугите на приложения. Това поддържа поведението на маршрутизиране подлежащо на проверка и по-лесно за промяна по време на инциденти с доставчик.

Защита на договорите за структурирани изходни данни

Резервният структуриран изход е едно от най-лесните места за създаване на фини производствени грешки. Доставчиците се различават по това как поддържат режим JSON, JSON схема, извиквания на инструменти, полета за отказ, обратна връзка за безопасност, причини за завършване и подмножества на схемата. Не се гарантира, че схема, която работи с един модел, е преносима към друг.

Факт: Някои документи на доставчика описват стриктно спазване на схемата за поддържаните модели, докато друга документация отбелязва поддръжка само за подмножество от JSON Схема. Отговорите на доставчика може също да включват полета за отказ, бърза обратна връзка, оценки за безопасност, причини за завършване или липса на кандидати, когато подкана е блокирана или невалидна.

Препоръка: третирайте валидирането на изхода като част от маршрута, а не като незадължителна загриженост на обаждащия се. Шлюзът трябва да потвърди крайния отговор, преди да го върне на приложението. Ако проверката е неуспешна, маршрутът трябва да класифицира неуспеха и да реши дали е разрешен опит за резервен вариант.

Има два работещи модела:

Използване на преносим поднабор от схеми

Съхранявайте схемите до пресечната точка на функции, поддържани от одобрени резервни доставчици. Това подобрява преносимостта и намалява оперативната сложност. Компромисът е, че може да загубите по-богати специфични за доставчика ограничения.

Използвайте специфични за доставчика адаптери за схема

Поддържайте адаптери, които превеждат договора за приложение в поддържания формат на схема на всеки доставчик. Това запазва способността, но увеличава натоварването при тестване и поддръжка.Освен това изисква матрица за съвместимост, така че инженерите да знаят кои маршрути могат да се върнат безопасно.

Един основен запис за съвместимост може да изглежда така:

{
  "route": "invoice_extraction_v3",
  "contract": "invoice_json_schema_v3",
  "primary": "provider_a.structured_model",
  "fallbacks": ["provider_b.extraction_model"],
  "disallowed": ["provider_c.fast_model"],
  "requires": ["json_schema", "enum", "required_fields"],
  "validation": "strict_before_return"
}

Препоръка: никога не връща резервен изход само защото е добре оформен текст. Върнете го само след като отговаря на същия договор на ниво приложение, очакван от основния маршрут.

Контролирайте разходите преди да се случат инциденти

Резервният вариант често пренасочва трафика към по-скъпи модели точно в момента, когато трафикът е повишен или доставчикът е влошен. Без контрол на разходите, механизъм за надеждност може да се превърне в инцидент с разходи.

Задайте резервни правила, които включват:

• Максимален множител на резервна цена за маршрут.
• Позволени нива на модел по организация, работно пространство или среда.
• Ежедневни или почасови резервни разходи бюджети.
• Отделна политика за интерактивни и групови натоварвания.
• Правила за това дали резервният вариант може да пресича границите на доставчика, региона или семейството на моделите.

Препоръка: измервайте цената на успешен отговор, а не само цената на необработена заявка. По-скъп резервен вариант може да бъде оправдан, ако предотвратява видима от потребителя повреда на критичен маршрут. Същият резервен вариант може да е неприемлив за пакетна работа с нисък приоритет.

Политиката за разходите също трябва да е видима за организациите, използващи платформата. Екипите може да искат да разрешат премиум резервен вариант за производствени работни потоци за поддръжка на клиенти, като същевременно го блокират за разработка, тестване или вътрешно експериментиране. Това е решение за управление, а не просто решение за маршрутизиране.

Добавяне на прекъсвачи за всеки доставчик, модел, регион и клас на грешка

Наивният резервен вариант може да увреди доставчик с влошено качество. Всяка неуспешна първична заявка задейства друг първичен опит, след това друг резервен опит, докато другите услуги правят същото. Прекъсвачите намаляват повтарящия се натиск и правят поведението на маршрута по-предвидимо.

Прекъсвачът трябва да е достатъчно специфичен, за да се избегне прекомерна реакция. Не маркирайте цял доставчик като нездравословен, защото един модел в един регион връща структурирани изходни грешки. Проследявайте изправността по доставчик, модел, регион, маршрут и клас на грешка, където е възможно.

Една проста машина за състояние на прекъсвача е достатъчна за много екипи:

• Затворен: нормален трафик протича към маршрута.
• Отворен: маршрутът временно се избягва след грешка праговете са превишени.
• Полуотворено: ограничен трафик на сондата тества възстановяване, преди да се възобнови пълният трафик.

Праговете трябва да отчитат обема. Десет повреди в минута може да са значими за маршрут с малък обем, но не са от значение за маршрут, обработващ хиляди заявки в минута. Използвайте минимални размери на извадката, подвижни прозорци и филтри за класове на грешки.

Препоръка: прекъсвачите не трябва да броят само HTTP повреди. Те трябва също така да проследяват неуспехите при валидиране на изхода, честотите на изчакване, честотите на ограничение на скоростта и отделно моделите на отказ или блокиране. Тези класове предполагат различни оперативни реакции.

Регистрирайте решението за маршрутизиране, а не само окончателната грешка

Резервният вариант, който подобрява потребителското изживяване, все още може да направи инцидентите по-трудни за диагностициране.Ако регистрационните файлове показват само крайния успешен доставчик, инженерите губят доказателствата, че основният доставчик е бил неуспешен.

Всяка заявка трябва да записва:

• Оригинален доставчик, модел и маршрут.
• Резервен доставчик, модел и маршрут, когато се използва.
• Клас на грешка, който е задействал повторен опит или резервен.
• Идентификационни номера на заявки на доставчици, когато са налични.
• Брой повторни опити и продължителност на забавяне.
• Краен срок, изразходван преди всеки опит.
• Резултат от валидиране на изхода.
• Прогнозна цена за всеки опит и крайна цена.
• Дали е дошъл окончателният отговор от основен или резервен.
• Метаданни за организация, работно пространство, среда и приложение, където правилата позволяват.

Тази телеметрия поддържа както инженерно, така и търговско управление. Той също така свързва резервното поведение с AI API контрол на разходите, когато различни екипи, продукти или клиенти имат различни политики за надеждност и бюджет.

Измерете дали резервният вариант действително е помогнал

Суровият процент на успех не е достатъчен. Резервната стратегия може да увеличи крайните 200 отговора, като в същото време влоши латентността на p99, удвои разходите или връща по-малко валиден структуриран изход.

Измерете поне тези показатели по маршрут:

• Първичен процент на успех.
• Краен процент на успех след повторен опит и резервен резултат.
• p50, p95 и p99 латентност преди и след резервно връщане.
• Степен на резервно извикване.
• Цена за успешен отговор.
• Процент на отговор, валиден за договора.
• Процент на отказ за безопасност или блокиране от доставчика.
• Сигнали за регресия на качеството от специфични за приложението оценка.

Прогноза: тъй като все повече компании използват LLM инфраструктура с множество доставчици, резервните политики ще станат повече като инженеринг на трафика и по-малко като ad hoc обработка на изключения.Екипите ще очакват контроли на правилата по работно пространство, среда и клас на натоварване, с одитни регистрационни файлове, обясняващи защо е избран модел.

Контролен списък за внедряване

Използвайте този контролен списък, преди да активирате резервен вариант на производствен маршрут:

• Дефинирайте бюджета за латентност на маршрута и крайния срок за заявка.
• Класифицирайте грешките на доставчика като повторни, отговарящи на условията за резервен вариант и терминални класове.
• Документирайте кои повреди не трябва да задействат резервен вариант.
• Избройте одобрените първични и резервни модели по клас на натоварване.
• Проверете дължината на контекста, поддръжката на инструмента, поддръжката на схемата и поведението на безопасност за всеки резервен вариант.
• Потвърдете всеки краен отговор спрямо приложението договор.
• Задаване на максимален брой повторни опити, забавяне, трептене и обработка на Retry-After.
• Конфигуриране на прекъсвачи по доставчик, модел, регион и клас на грешка.
• Задаване на множители на разходите и резервни ограничения на разходите.
• Идентификационни номера на заявки за регистриране, класове грешки, опити, резултати от валидиране, латентност и цена.
• Прегледайте латентността на p95 и p99 след внедряването, а не само средната латентност.
• Прекъсване на доставчика на тестове, ограничение на скоростта, невалидна схема, отказ за безопасност и сценарии за неуспешно валидиране на изхода.

Приложимо заключение

Добрата резервна стратегия за LLM е управлявана политика за маршрутизиране. Той разделя повторния опит от резервния вариант, класифицира прецизно неуспехите, запазва изходните договори, спазва крайните срокове за забавяне и прави разходите видими, преди да възникнат инциденти.

Ключовият принцип на проектиране е инвариантността. Решете какво трябва да остане вярно, когато трафикът се премества от основния модел към резервен: валидност на схемата, поведение при безопасност, обработка на контекста, поддръжка на инструменти, ограничения на разходите и възможност за наблюдение. След това разрешете резервен вариант само когато тези инварианти могат да бъдат запазени.

Започнете с един маршрут с висока стойност, а не с глобален резервен превключвател. Дефинирайте неговата таксономия на грешките, съвместими резервни модели, правила за валидиране, прекъсвачи и показатели. Изпълнете тренировки за неуспех срещу този маршрут. Ако крайната успеваемост се подобри без неприемливо забавяне на p99, загуба на валиден за договора отговор или увеличение на разходите, разширете правилата до следващия клас на натоварване.

Свързано четене

• разпределяне на разходи за LLM по екип и приложение