Prompt cache-ը խնայում է մինչև 80%, եթե գործիքները չեն կոտրում prefix-ը

Երկարատև ԱԲ գործակալի API ծախսը նվազեցնելու համար հարցման սկզբում պահեք նույն գործիքների սահմանումներն ու կայուն հրահանգները, իսկ օգտատիրոջ տվյալներն ու գործիքների նոր արդյունքները տեղափոխեք դրանցից հետո։ Ավելի քան 500 գործակալային սեսիայի հետազոտությունում prompt caching-ը API ծախսը նվազեցրել է 41–80%-ով, իսկ առաջին տոկենի սպասումը՝ 13–31%-ով՝ փորձարկված մատակարարների և կարգավորումների շրջանակում։ Մինչև 80%-ը այդ չափումների վերին սահմանն է, ոչ թե յուրաքանչյուր գործակալի սպասվող արդյունքը։

OpenAI-ի քեշավորման ուղեցույցի համաձայն՝ վերաօգտագործվում է հարցման սկզբի ճշգրիտ համընկնող հատվածը, իսկ GPT-5.6 և ավելի նոր մոդելների համար դրա նվազագույն երկարությունը 1,024 տեսանելի մուտքային տոկեն է։ Գործիքների սահմանումները նույնպես այդ սկզբնական համատեքստի մաս են. անվան, նկարագրության, սխեմայի կամ հերթականության վաղ փոփոխությունը կրճատում է քեշից կարդացվող հատվածը։ Ուստի երկար prompt ունենալը բավարար չէ. հաջորդ կանչը պետք է կրկնի դրա համապատասխան սկիզբը։

Դասավորեք նախածանցը ըստ փոփոխության հաճախության

Կայուն շերտում տեղավորեք այն, ինչ նույնն է մնում բազմաթիվ կանչերի ընթացքում՝ գործակալի վարքագծի հրահանգները, պատասխանի ձևաչափի կանոններն ու ընդհանուր տեղեկատու նյութը։ Դրանցից հետո դրեք տվյալ հարցումների խմբի համար հաստատուն համատեքստը, իսկ վերջում՝ սեսիայի ընթացքում փոխվող տեղեկությունը։ Շերտերի սահմանը որոշում է բովանդակության կրկնվելու հավանականությունը, ոչ թե դրա կարևորությունը պատասխանի համար։

Հաճախորդների հարցերին պատասխանող գործակալի համար հետևյալը պայմանական դասավորություն է, ոչ API-ի պարտադիր սխեմա.

1. Գործիքների սահմանումներ՝ նույն անուններով, նկարագրություններով, պարամետրերի սխեմաներով և հերթականությամբ։
2. Ընդհանուր հրահանգներ՝ պատասխանի լեզու, թույլատրելի գործողությունների սահմաններ և արդյունքի կառուցվածք։
3. Կրկնվող տեղեկատու նյութ՝ միայն այն կանոնները, որոնք կիրառվում են տվյալ հարցումների խմբում։
4. Փոփոխական վերջաբան՝ օգտատիրոջ խնդիրը, ընթացիկ գրառումները և գործիքների նոր պատասխանները։

Եթե ընթացիկ ժամը կամ օգտատիրոջ անունը հայտնվի ընդհանուր հրահանգի մեջտեղում, հետագա նույնական տեքստն այլևս չի շարունակվի որպես հին քեշի ճշգրիտ նախածանց։ Նույնը վերաբերում է ամեն կանչի համար նորից կազմվող տեղեկատու հատվածին, եթե փոխվում են դրա բովանդակությունը կամ հերթականությունը։ Կարևոր փոփոխական տվյալը կարելի է պահել վերջում. մոդելը այն կստանա ամբողջությամբ, մինչդեռ սկզբի կրկնվող մասը կմնա վերաօգտագործելի։

Գործիքների փոփոխությունը կառավարեք առանձին

Գործիքների ցանկը կայուն պահելը չի նշանակում բոլոր գործիքներին ամեն քայլում գործելու թույլտվություն տալ։ OpenAI Responses API-ում կարելի է փոխանցել նույն սահմանումները և tool_choice կամ allowed_tools կարգավորումներով որոշել, թե տվյալ կանչում որոնք են հասանելի։ Այդ մոտեցումը պահպանում է կրկնվող գործիքացանկը, երբ փոխվում է միայն տվյալ քայլի գործողությունը։

Մեծ գործիքացանկի դեպքում բոլոր սահմանումները նախապես փոխանցելը նույնպես արժեք ունի՝ դրանք մեծացնում են յուրաքանչյուր մուտքը։ Հետաձգված բեռնումը կարող է փոքրացնել սկզբնական հարցումը. նոր գործիքները սեսիայի հետագա համատեքստին ավելացնելու եղանակը պետք է պահպանել հետևողական։ Ընտրությունը կատարեք ամբողջ սեսիայի ծախսով, քանի որ փոքր առաջին կանչը կարող է փոխել հետագա կանչերի քեշավորվող հատվածը։

Գործիքի սխեման իսկապես փոխվելու դեպքում գործակալը պետք է ստանա նոր տարբերակը, նույնիսկ եթե հաջորդ կանչի քեշային հիթը նվազի։ Օգտակար կարգապահությունը նույն տարբերակի ներսում պատահական վերադասավորումից և նկարագրությունների անհարկի վերաշարադրումից խուսափելն է։ Եթե գործիքների տարբերակները տարբերվում են ըստ սեսիայի, դրանց ծախսն ու հիթերը նույնպես չափեք առանձին խմբերով։

Քեշավորման սահմանը համադրեք սեսիայի ընթացքին

Երբ գործակալը պահպանում է նախորդ հաղորդագրություններն ու դրանցից հետո ավելացնում նոր հարցեր կամ գործիքների արդյունքներ, աճող պատմությունը կարող է դառնալ հաջորդ կանչի համընկնող նախածանցը։ Վերաշարադրումը, սեղմումը կամ հին հաղորդագրությունների հեռացումը փոխում են այդ սկիզբը։ Այդ պատճառով շարունակական թվացող սեսիան ինքնին քեշային հիթ չի երաշխավորում։

Ինքնաշխատ սահմանը հարմար է, երբ պատմության հաջորդ մասը ևս շուտով կրկնվելու է։ Եթե գործիքի արդյունքը կամ օգտատիրոջ տվյալը վերաբերում է միայն տվյալ կանչին, քեշում այդ փոփոխական վերջաբանը գրելը կարող է ավելացնել ծախսը՝ առանց հետագա ընթերցման։ Բացահայտ սահմաններ աջակցող մոդելի դեպքում սահմանը դրեք կայուն հատվածի ավարտին և փոփոխական մասը թողեք դրանից հետո։ Երկու տարբերակների արժեքը համեմատեք նույն տիպի սեսիաների համար, քանի որ ավելի շատ քեշային ընթերցումը միշտ չէ, որ նշանակում է ավելի փոքր ընդհանուր հաշիվ կամ ավելի արագ առաջին տոկեն։

Չափեք իրական հիթը և գտեք բացթողումը

Յուրաքանչյուր կանչի համար պահեք մոդելի անունը, մուտքային տոկենների ընդհանուր քանակը, քեշից կարդացված և քեշում գրված տոկենները, առաջին տոկենի սպասումը և հաշվարկված արժեքը։ Նույն տիպի կանչերի խմբում քեշի հիթի բաժինը հաշվեք՝ քեշից կարդացված տոկենների գումարը բաժանելով մուտքային տոկենների գումարին։ Միայն միացված քեշի կարգավիճակը կամ առանձին հաջող կանչը չեն ցույց տալիս, թե որքան աշխատանք է վերաօգտագործվել ամբողջ հոսքում։

Սպասված հիթը բացակայելու դեպքում OpenAI-ի քեշի ախտորոշումը թույլ է տալիս Responses API-ի ընթացիկ հարցումը համեմատել ավելի վաղ պատասխանի հետ և բացահայտել մոդելի, գործիքների, կարգավորումների կամ մուտքի փոփոխությունը։ Համեմատության համար ընտրեք նույն կազմակերպության թարմ պատասխան, որի նախածանցը պետք է կրկնվեր։ Ախտորոշումը բացատրում է կոնկրետ բացթողումը, իսկ իրական վերաօգտագործումը հաշվեք պատասխանի cached_tokens դաշտով. ախտորոշիչ գնահատականն ու հաշվարկային ցուցանիշը կարող են տարբերվել։

Հաշվեք՝ երբ է քեշում գրելը փոխհատուցվում

Ծախսը գնահատելու համար նույն ժամանակահատվածի կանչերը խմբավորեք ըստ մոդելի և կրկնվող նախածանցի։ Նշեք սովորական մուտքային տոկենի գինը՝ P, քեշից կարդալու գինը՝ Pr, և քեշում գրելու գինը՝ Pw։ Գները վերցրեք կիրառվող մոդելի սակագնից. գրելու արժեքը հաշվարկի առանձին դրույք է, ոչ թե սովորական մշակման գնի վրա ավելացվող նույն տոկենների երկրորդ վճար։

• Ընդհանուր մուտքային տոկեններ՝ T։ Առանց քեշավորման համադրելի մուտքային արժեքը T × P է։
• Քեշից կարդացված տոկեններ՝ R։ Դրանց արժեքը R × Pr է։
• Քեշում գրված տոկեններ՝ W։ Դրանց արժեքը W × Pw է։
• Սովորական մշակված տոկեններ՝ U = T − R − W։ Քեշավորմամբ մուտքային արժեքը U × P + R × Pr + W × Pw է։
• Խնայողության բաժինը՝ [T × P − (U × P + R × Pr + W × Pw)] ÷ (T × P)։

Հաշվարկային այս տողերը լրացրեք իրական տոկեններով, գներով և կանչերի հաճախությամբ։ Եթե նախածանցը հազվադեպ է կրկնվում մինչև քեշի պահպանման ժամկետի ավարտը, գրելու գինը կարող է գերազանցել ընթերցումների օգուտը։ Իսկ եթե նույն սկիզբը հաճախ է հանդիպում, յուրաքանչյուր հաջորդ ընթերցում նվազեցնում է այդ հատվածի միջին արժեքը։

Բանաձևը վերաբերում է միայն մուտքային տոկեններին. ելքային տոկենների և գործիքների կանչերի ծախսը համեմատեք առանձին, եթե կարգավորումների փոփոխությունը ազդում է նաև դրանց վրա։ Առաջին տոկենի սպասումը նույնպես դիտարկեք առանձին՝ նույն ծանրաբեռնվածության կանչերի բաշխմամբ։ Այդպես ծախսի նվազումը և պատասխանի արագացումը կմնան երկու չափված արդյունք, այլ ոչ մեկ ենթադրյալ օգուտ։

Կարդացեք նաև:

• ԱԲ գործակալը գործիքներ է ստանում․ ինչպես սահմանափակել վնասի շառավիղը
• Firebird-ի երկրորդ փուլը թանկացել է մինչև $8 մլրդ․ խոստումը՝ 100 հազար GPU