Как да изградим рентабилно LLM моделно маршрутизиране, без да жертваме качеството

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

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

Какво съобразено с разходите маршрутизиране оптимизира

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

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

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

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

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

Рутерът се нуждае от етикет за натоварване, преди да може да вземе полезно решение. Един модел по подразбиране не може да представи рисковия профил на всяка заявка.

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

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

Класът на задачата може да идва от изрични метаданни на заявка, API ключов обхват, маршрут на приложение или олекотен класификатор. Изричните метаданни обикновено са по-добри от извеждането на намерение от подканващия текст, тъй като неясните подкани принуждават рутера към консервативни настройки по подразбиране.

Прикрепете качествен под към всяка задача

Маршрутизирането с оглед на разходите работи само ако всяка задача има долна граница на качеството. Без такъв рутерът няма принципен начин да отхвърли по-евтин модел.

Качественият под може да включва няколко проверки:

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

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

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

Създаване на регистър на възможностите на доставчика

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

Записът на способностите трябва да включва:

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

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

Оценка на цената на маршрута преди избор

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

estimated_cost =
  input_tokens * input_token_price
  + cached_input_tokens * cached_input_token_price
  + output_tokens_expected * output_token_price
  + tool_call_overhead_expected
  + retry_allowance_expected
  - batch_discount_if_eligible

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

Оценката на разходите трябва също така да отчита допустимостта на кеша и пакета:

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

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

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

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

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

Маршрут с изрична последователност от решения

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

1. Четене на клиент, API ключ, среда и метаданни на приложението.
2. Идентифицирайте клас на задача от изрични метаданни или изход от класификатора.
3. Заредете версията на правилата за маршрутизиране за този клиент или работно пространство.
4. Прилагане на ограничения за управление като запазване на данни, регион, разрешен списък на модела и ограничения на функции.
5. Филтриране по изисквани възможности: дължина на контекста, инструменти, структуриран изход, поточно предаване, модалност и пакетна поддръжка.
6. Филтриране по минимално ниво на качеството, подкрепено от оценка за класа на задачата.
7. Оценка на разходите с помощта на входни токени, очаквани изходни токени, допустимост на кеша, допустимост на партида и риск от повторен опит.
8. Прилагане на бюджетна политика и предпочитания на наемателя.
9. Изберете допустимия маршрут с най-ниска цена.
10. Прикачване на резервен маршрут, време за изчакване, повторен опит и правила за поправка.
11. Регистрирайте решението със стабилен код на причината.

В псевдокод рутерът трябва да прилича повече на оценка на политиката, отколкото на твърдо кодирано предпочитание на доставчика:

function selectRoute(request):
  context = buildRoutingContext(request)
  task = classifyTask(context)
  policy = loadPolicy(context.tenant_id, task)

  candidates = modelRegistry.models
    .filter(model => policy.allows(model))
    .filter(model => model.supports(context.required_capabilities))
    .filter(model => evalStore.passes(task, model, policy.quality_floor))

  priced = candidates.map(model => ({
    model,
    estimated_cost: estimateCost(model, context),
    expected_latency: estimateLatency(model, context),
    risk_flags: estimateRisk(model, context)
  }))

  eligible = priced.filter(route => route.risk_flags.noneBlocking())
  return minBy(eligible, route => route.estimated_cost)

Регистрирайте всяко решение за маршрутизиране

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

Регистрирайте тези полета за всяка заявка:

• ID на заявка, ID на клиента, API ID на ключ, ID на приложение и среда.
• Резултат и увереност на класификатора на задачи.
• Версия на правилата за маршрутизиране.
• Използвана версия на набор от данни Eval и порта за качество.
• Отговарящи на условията модели и отхвърлени модели.
• Причина за изключването на всеки отхвърлен модел.
• Оценени входни, кеширани входни и изходящи токени.
• Прогнозна цена на маршрута и окончателна уредена цена, когато са налични.
• Избран доставчик, модел, версия на адаптера и ниво.
• Политика за резервен маршрут и повторен опит.
• Кеширайте телеметрията за попадение или пропуск, когато е налична.
• Пакетен срещу синхронен режим на изпълнение.
• Проверка на схемата, опити за поправка, статус на отказ и флагове за безопасност.

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

Добавете контроли за движение, преди да популяризирате по-евтини маршрути

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

Основната верига за контрол на дрейфа трябва да включва:

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

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

Дайте на екипи замени, но ги накарайте да изтекат

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

Всяка замяна трябва да включва:

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

Изтеклите замени трябва да не успеят да се затворят към нормалната политика за маршрутизиране или да изискват подновяване. Това предпазва спешните решения от превръщането им в скрити разходи или рискове за качеството.

Компромиси, за да се направи изрично

Осъзнатото маршрутизиране има реални оперативни разходи. Все пак си струва да се направи, когато разходите за LLM са значителни, но компромисите трябва да са видими.

• Зависимост от метаданни: качеството на маршрутизирането зависи от точните етикети на задачите и метаданните за работното натоварване. Липсващите етикети тласкат трафика към консервативни настройки по подразбиране.
• Поддръжка на Eval: оценките на задачите се нуждаят от актуализации, тъй като подканите, продуктите и поведението на потребителите се променят.
• Сложност на доставчика: кеширането и пакетните отстъпки могат да подобрят икономиката, но да направят логиката на маршрутизиране по-сложна.
• Риск за преносимост: специфичните за доставчика функции трябва да съществуват в адаптери и записи на възможности, а не в продуктов код.
• Несигурност на прогнозата: крайната изходна дължина, извикванията на инструментите, повторните опити и попаденията в кеша не са напълно известни преди изпълнението.
• Тежест за обяснение: агресивната оптимизация може да направи поведението на продукта трудно обяснимо, освен ако всяко решение не се регистрира с версия на правилата и кодове на причина.

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

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

Заключение

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

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

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

• ограничения на разходите на ниво шлюз