Смањите трошкове ЛЛМ АПИ-ја помоћу пакетних послова и брзог кеширања: практична књига

<п>Многи тимови преплаћују за ЛЛМ АПИ-је јер сваки захтев шаљу истом синхроном путањом. То је прикладно за ћаскање, помоћнике за кодирање, агенте за подршку, токове плаћања и све што чека корисника. Расипно је за евалуације, означавање, обогаћивање, модерирање, уграђивање засипања, ноћне извештаје и претходну обраду садржаја. <п>Практично питање није „Који модел је најјефтинији?“ То је: <стронг>који посао заправо захтева тренутни одговор, а који посао може да чека? Када одговорите на то, контрола трошкова АИ АПИ-ја постаје инжењерски ток рада: класификујте саобраћај, шаљите послове отпорне на кашњење у групну обраду где је подржано, структурирајте поновљене упите за кеширање и мерите стварне уштеде након неуспеха, поновних покушаја и оперативних. <х2>Почните са ревизијом трошкова према оптерећењу, а не моделу <п>Пре него што промените архитектуру, извезите узорак недавног коришћења АПИ-ја и групишите га према радном оптерећењу. Корисна табела ревизије треба да садржи: <ул> <ли><стронг>Крајња тачка и модел: довршетак ћаскања, одговори, уграђивање, модерирање или крајње тачке специфичне за добављача. <ли><стронг>Просечни улазни и излазни токени: одвојите дугачке упите од кратких задатака класификације. <ли><стронг>Облик упита: стабилна системска упутства, примери за вишекратну употребу, шеме, контекст преузимања и динамички кориснички подаци. <ли><стронг>Услов за кашњење: секунде, минуте, сати или следећи радни дан. <ли><стронг>Видљивост корисника: да ли особа чека резултат. <ли><стронг>Стопа поновних покушаја и неуспеха: неисправни захтеви, неуспели валидације, временска ограничења добављача, истекли послови и дуплиране пријаве. <ли><стронг>Власништво: пројекат, тим, клијент, АПИ кључ или партнерски налог. <ли><стронг>Пословни СЛА: последњи пут када је резултат још увек користан. <п>Ова ревизија обично открива да „ЛЛМ саобраћај“ није једно оптерећење. То је мешавина интерактивних карактеристика производа, интерне аутоматизације, извештавања, припреме података и евалуације квалитета. Третирање њих као једног центра трошкова крије најлакше уштеде. <х2>Користите троструки класификатор радног оптерећења <п>Једноставан класификатор спречава тимове да пребаце погрешан саобраћај у групу, а затим буду изненађени промашеним очекивањима. <х3>Трака 1: интерактивни захтеви у реалном времену <п>Одржавајте ове синхроне. Они обухватају УКС за ћаскање, копилоте, агенте за подршку, преглед људи у петљи, токове претраживања или преузимања уживо и позиве алата са тренутним нежељеним ефектима. Ако корисник чека, вредност јефтинијег одговора може да се избрише кашњењем. <п><стронг>Препорука: оптимизујте ову траку избором модела, брзим сечењем, управљањем ограничењем брзине, кеширањем где је применљиво и пажљивим поновним покушајима. Немојте га слати у 24-часовни скупни ред осим ако га производ експлицитно не прикаже као задатак у позадини. <х3>Трака 2: блиски захтеви који могу да чекају неколико минута <п>Ови послови не морају да блокирају учитавање странице, али и даље могу имати очекивање исте сесије или истог сата. Примери укључују анализу докумената након отпремања, ЦРМ обогаћивање након подношења обрасца или извештај који може да обавести корисника када је спреман. <п><стронг>Препорука: ставите посао који је близу линије иза реда са експлицитним статусним статусима. У зависности од подршке провајдера и рока, или га покрените кроз мале групе или синхроне раднике са нижим приоритетом. Ова трака има користи од ИД-ова послова, веб-хукова и напретка видљивог корисницима. <х3>Трака 3: групни захтеви ван мреже који могу да чекају до 24 сата <п>Ово је главна трака за оптимизацију трошкова. Добри кандидати укључују: <ул> <ли>процене великих размера; <ли>означавање скупа података; <ли>каталог или ЦРМ обогаћивање; <ли>ноћни резиме; <ли>редови за преглед усклађености; <ли>уграђивање засипања; <ли>модерација; <ли>генерисање периодичних извештаја; <ли>претходна обрада садржаја пре индексирања или објављивања. <п><стронг>Чињеница: главни добављачи сада нуде асинхроне пакетне АПИ-је за одговарајућа радна оптерећења. ОпенАИ-јев пакетни АПИ чита захтеве из отпремљене датотеке, уписује резултате у излазну датотеку и циља обраду у року од 24 сата. ОпенАИ наводи да се подржано коришћење пакетног АПИ-ја нуди уз попуст од 50% у поређењу са синхроним АПИ-јима. Антхропицов АПИ пакета порука је дизајниран за велике количине захтева за поруке, асинхрону обраду, већу пропусност и 50% нижу цену. Гоогле Гемини Батцх АПИ је дизајниран за асинхроне захтеве великог обима уз 50% стандардне цене, са циљним временом обраде од 24 сата.<п><стронг>Компром: „до 24 сата“ је одлично за попуњавање и процене, али неприхватљиво за интерактивне токове посла. Група је стратегија планирања, а не универзална замена за синхрони закључак. <х2>Дизајнирајте путању серије као животни циклус посла <п>Грешка у примени коју треба избегавати је третирање групе као једног АПИ позива. То је животни циклус: прихватите рад, потврдите га, устрајте у њему, поднесите га, испитајте га, помирите га и изложите резултате. <х3>Референтна архитектура <ол> <ли><стронг>Прихватите нормализовани захтев: држите облик захтева близу постојећег ОпенАИ компатибилног АПИ формата где је то могуће. Додајте метаподатке као што су пројекат, тим, купац, кључ идемпотенције, тражени рок и центар трошкова. <ли><стронг>Класификујте радно оптерећење: доделите захтев групи у реалном времену, скоро на мрежи или ван мреже. Ово би требало да буде засновано на смерницама, а не скривено унутар кода апликације. <ли><стронг>Креирајте ИД посла: одмах вратите идентификатор посла за рад близу и ван мреже. <ли><стронг>Провери компатибилност: проверите да ли изабрани добављач и модел подржавају скуп за тражену крајњу тачку, модалитет, величину датотеке, алатке, формат одговора и друге функције. <ли><стронг>Упорни редови захтева: складиштите нормализоване ЈСОНЛ редове или корисне податке специфичне за добављача. Укључите стабилан ИД реда ради усаглашавања. <ли><стронг>Пошаљите групу: отпремите датотеку са захтевом или инлине скупни садржај у зависности од ограничења добављача и величине посла. <ли><стронг>Статус анкете: пратите стања добављача као што су валидација, у току, завршено, неуспело, истекло, отказивање и отказано где је применљиво. <ли><стронг>Чувајте излазне редове: упишите успешне одговоре, грешке на нивоу реда, употребу токена, кеширане бројеве токена где су доступни и идентификаторе добављача. <ли><стронг>Обавестите потрошаче: изложите крајњу тачку преузимања, веб-хук, обавештење на контролној табли или Телеграм упозорење. <ли><стронг>Ускладите обрачун: припишите цену оригиналном пројекту, тиму, клијенту, АПИ кључу и ИД-у посла. <п>Овај образац чини апликацију једноставном. Тимови производа шаљу посао и примају статусе посла. Слој мрежног пролаза или оркестрације управља разликама између добављача, батцх датотекама, поновним покушајима и рачуноводством. <х3>Користите експлицитна стања послова <п>Дефинишите интерна стања чак и ако сваки добављач користи различита имена: <ул> <ли><цоде>на чекању: прихваћено, али није послато; <ли><цоде>Провера ваљаности: провајдер или мрежни пролаз проверава датотеку; <ли><цоде>покреће: послато и обрађује се; <ли><цоде>завршено: прикупљени су сви доступни резултати; <ли><цоде>цомплетед_витх_еррорс: неки редови нису успели да се провере или изврше; <ли><цоде>истекао: рок је прошао пре него што су сви редови завршени; <ли><цоде>отказан: заустављен од стране корисника, система или смерница; <ли><цоде>неуспешно: грешка на нивоу посла која захтева интервенцију. <п><стронг>Чињеница: ОпенАИ документује статусе пакета укључујући валидацију, неуспело, у току, завршено, истекло, отказивање и отказано. Такође напомиње да ако серија истекне, већ завршени радови се враћају и наплаћују док се преостали радови отказују. <п><стронг>Препорука: никада не претпостављајте да су групни послови све или ништа. Направите руковање статусом на нивоу реда од самог почетка. <х2>Израчунајте уштеде након кварова и трошкова <п>Једноставан модел уштеде је довољан за већину тимова: <пре><цоде>основни_трошак = синхрони_улазни_трошак + синхрони_излазни_трошак батцх_цост = дисцоунтед_батцх_инпут_цост + дисцоунтед_батцх_оутпут_цост прилагођени_батцх_цост = батцх_цост + оркестратион_цост + стораге_цост + рерун_цост процењена_уштеда = основни_трошак - прилагођени_скупни_трошак <п>Онда израчунајте ово по оптерећењу, а не глобално. Ноћни пакет за евалуацију може значајно уштедети. Приближан ток посла са много неисправних редова, хитних замена или поновљених понављања може да уштеди мање од очекиваног. <п>Пратите најмање ове показатеље: <ул> <ли>синхронизација у односу на потрошњу токена серије; <ли>улазни и излазни токени по моделу; <ли>број скупних задатака и просек редова по послу; <ли>стопа неуспеха на нивоу реда; <ли>стопа истеклих послова; <ли>цена поновног приказивања; <ли>трошак враћања на синхронизацију; <ли>цена према тиму, пројекту, кључу, клијенту и налогу партнера. <п><стронг>Препорука: аутоматски синхрони резервни приступ третирајте као изузетак, а не као подразумевани. Штити рокове, али ако се превише користи може избрисати очекиване уштеде. Додајте политику као што је „повратак само ако је пословни рок у року од два сата, а посао није започео.“ <х2>Додајте кеширање упита за поновљене дугачке префиксе<п>Серијална обрада смањује јединичну цену рада који испуњава услове. Брзо кеширање смањује ефективну цену и кашњење поновљених дугих упита када понашање провајдера то подржава. <п><стронг>Чињеница: Кеширање ОпенАИ упита аутоматски се примењује на упите дуже од 1.024 токена на подржаним моделима, кешира најдужи претходно израчунати префикс и извештава о <цоде>цацхед_токенс у детаљима коришћења АПИ-ја. ОпенАИ каже да се брзи кешови обично бришу након 5 до 10 минута неактивности и уклањају се у року од једног сата од последње употребе, као и да се кеш промпта не деле између организација. <п>Образац имплементације је једноставан: ставите стабилан садржај на прво, а несталан садржај на последње место. <х3>Боља структура одзива за кеширање <пре><цоде>Системска упутства Стабилан текст политике Стабилна излазна шема Стабилни примери Референтни контекст за вишекратну употребу --- Динамички унос специфичан за запис Динамички метаподаци корисника или реда <п>На пример, посао обогаћивања каталога може поново да користи исту таксономију, излазну шему, правила бренда и примере за 50.000 производа. Сваки ред мења само наслов производа, опис и атрибуте. Прво постављање префикса за вишекратну употребу пружа добављачу већу шансу да поново користи кеширано израчунавање тамо где је то подржано. <п><стронг>Компром: Кеширање није трајно складиште и не треба га третирати као загарантовано. Прозори кеш меморије, изолација, минимална дужина упита и извештавање се разликују од добављача. Мерите кеширане токене уместо да претпостављате уштеде. <х2>Потврдите подршку добављача пре слања <п>Пакетни АПИ-ји се разликују. Мрежни пролаз треба да потврди да ли испуњава услове пре него што пошаље посао. <п><стронг>Чињенице: ОпенАИ Батцх АПИ не подржава стримовање и има одвојена ограничења брзине скупа. Ограничења групе антропских докумената укључујући ограничење величине групе од 100.000 захтева или 256 МБ, рок трајања од 24 сата, доступност резултата од 29 дана, ограничења стопе и могућност да групе могу мало премашити конфигурисана ограничења потрошње радног простора. Гоогле подржава инлине групне захтеве за мање послове мање од 20 МБ и ЈСОНЛ улазне датотеке за веће групне захтеве. <п>Користите контролну листу компатибилности: <ул> <ли>Да ли је тражени модел доступан преко пакетног АПИ-ја тог добављача? <ли>Да ли је крајња тачка подржана? <ли>Да ли захтев захтева стримовање? Ако јесте, одбијте скуп. <ли>Да ли користи алате или нежељене ефекте који се морају десити одмах? <ли>Да ли батцх датотека премашује ограничења добављача? <ли>Да ли је очекивани резултат и даље користан у оквиру провајдеровог рока за завршетак? <ли>Да ли су резултати доступни довољно дуго да их системи на нижем току могу преузети? <ли>Да ли радно оптерећење може толерисати делимичан завршетак? <п><стронг>Препорука: не успете раније са валидацијом са јасним разлогом. Одбијени групни кандидат је јефтинији од истека или неисправног посла који треба касније да се преради. <х2>Заштита за тимове, агенције и партнере <п>Батцх системи могу тихо да потроше много новца јер обрађују велике датотеке у позадини. Додајте контроле пре широког представљања: <ул> <ли><стронг>Групни буџети по тиму: одвојена ограничења потрошње на мрежи и ван мреже. <ли><стронг>Максимална величина датотеке и број редова: примените ограничења добављача и своја оперативна ограничења. <ли><стронг>Редопис за мртво писмо: сачувајте неважеће редове са грешкама у валидацији за преглед. <ли><стронг>Кључеви за идемпотенција: спречавају случајно поновно подношење дуплих наплата. <ли><стронг>ПИИ преглед: групне датотеке могу да доведу до нових обавеза задржавања података и приватности. <ли><стронг>Политика задржавања: дефинише колико дуго се чувају датотеке захтева, излазне датотеке и евиденције. <ли><стронг>Смернице за обавештења: обавестите власнике када послови не успеју, истичу или премаше буџет. <ли><стронг>Атрибуција: евидентирајте пројекат, тим, клијента, АПИ кључ, модел, добављача, ИД посла и ИД реда. <п>За агенције и препродавце, атрибуција је посебно важна. Ако један партнер обавља послове обогаћивања или евалуације за много клијената, систем треба да пријави трошкове по клијенту и по послу, а не само по фактури добављача. <х2>Како се ово мапира на АИ АПИ мрежни пролаз <п>А АИ АПИ капија је природно место за имплементацију овога јер се већ налази између апликација и добављача модела. Мрежни пролаз може да сачува површину АПИ-ја компатибилну са ОпенАИ за програмере док иза себе додаје заказивање са свешћу о трошковима. <п>Корисне могућности мрежног пролаза укључују: <ул> <ли><стронг>Јединствени обрачун: упоредите синхрону, групну, кеширану и резервну потрошњу на једном месту. <ли><стронг>Аналитика коришћења АИ: разврстајте коришћење према моделу, добављачу, крајњој тачки, тиму, пројекту и АПИ кључу. <ли><стронг>Контроле тима: поставите засебне буџете за интерактивна и офлајн радна оптерећења.<ли><стронг>Атрибуција АПИ кључа: идентификујте која услуга или клијент је креирао сваки посао. <ли><стронг>Обавештења о статусу: шаљите упозорења када се групни послови заврше, не успеју, истичу или се приближе року. <ли><стронг>Токови посла за партнерски АПИ: дозволите агенцијама или препродавцима да креирају послове и преузимају резултате у име клијената уз очување рачуноводства на нивоу клијента. <п><стронг>Предвиђање: више тимова ће управљати трошковима ЛЛМ помоћу смерница заказивања, а не само замене модела. Како пакетна подршка сазрева међу добављачима, победничка архитектура ће се усмеравати по хитности, компатибилности функција и рачуноводственим захтевима пре него што буде усмеравана по цени модела. <х2>Контролна листа имплементације <ул> <ли>Извезите 30 дана коришћења ЛЛМ АПИ-ја. <ли>Свако радно оптерећење класификујте као у реалном времену, близу мреже или ван мреже. <ли>Одаберите једно оптерећење ван мреже са јасним власништвом и роком за опрост. <ли>Потврдите пакетну подршку добављача за потребну крајњу тачку и модел. <ли>Дефинишите интерна стања послова и статусе на нивоу реда. <ли>Додајте кључеве идемпотенције, ИД-ове послова и ИД-ове по реду. <ли>Чувајте нормализоване записе захтева и одговора са контролама задржавања. <ли>Пошаљите прву групу иза ознаке функције. <ли>Измерите синхрони основни трошак у односу на прилагођену скупну цену. <ли>Реструктурирајте поновљене дугачке упите да ставите стабилне префиксе на прво место. <ли>Пратите кеширане токене, неуспеле редове, истекле послове и резервну потрошњу. <ли>Проширите тек након што уштеде и оперативно понашање буду видљиви у аналитици. <х2>Закључак који се може спровести <п>Немојте покретати контролу трошкова АИ АПИ-ја тражећи од сваког тима да користи јефтинији модел. Почните тако што ћете одвојити хитан посао од посла који може да чека. Нека интерактивни захтеви буду синхрони. Преместите евалуације, обогаћивање, означавање, затрпавање, прегледе модерирања и извештаје у групе када подршка добављача и пословни рокови одговарају. Структура је понављала дугачке упите за кеширање. Затим измерите стварне уштеде након кварова, понављања, складиштења и резервних трошкова. <п>Најбоља примена је намерно досадна: ИД-ови послова, валидација, статуси на нивоу реда, буџети, аналитика коришћења и јасно власништво. Тај оперативни слој је оно што претвара попусте добављача у поуздану уштеду.<х2>Повезано читање<ул><ли><а хреф="хттпс://модел-гате.цом/ен/блог/ллм-апи-кеи-манагемент-теамс-исолатион-ротатион-спенд-лимитс-леак-респонсе-4/">>АПИ кеи цонтрол аттрибутс><ли/">АПИ кеи цонтрол аттрибутион хреф="хттпс://модел-гате.цом/ен/блог/релиабле-ллм-апи-роутинг-тимеоутс-ретриес-модел-фаллбацкс-3/">смернице за усмеравање, поновне покушаје и резервне смернице за ЛЛМ АПИ<ли><а хреф="хттпс://модел-гате.цом/ен/блог-2/артицле">ре имплементација белешке