Չափված պատասխանը հենց սկզբից. երբ llama.cpp-ի prompt cache-ն անում է իր գործը, երկրորդ հարցը նույն փաստաթղթի վրա վերադառնում է գրեթե անմիջապես, մինչդեռ առաջինը վճարում է ամբողջ prefill-ը։ Եթե cache-ն անջատած է կամ ձեր կոնվեյերը կոտրում է այն, այդ գինը վճարում է ամեն հարց։ Թվերը և միակ պայմանը, որ cache-ին պետք է, ստորև են։
Ով երբևէ երկար ֆայլ է տեղադրել լոկալ օգնականի մեջ, ճանաչում է այս ռիթմը։ Առաջին պատասխանը հավերժություն է տևում։ Դրանից հետո ամեն պատասխան վերադառնում է գրեթե ավելի շուտ, քան կհասցնեք ավարտել մուտքագրումը։ Ֆորումային թելերը սա բացատրում են cache-ի մասին ընդհանուր խոսքերով և թողնում այդտեղ։ Մենք չափեցինք իրական ճեղքը մեկ տուփի վրա՝ ամրագրված runtime-ով, երեք կրկնված անցումով և հրապարակված հում գրառումներով։
Ինչ է չափվել
Մեկ Beelink GTR9 Pro՝ Ryzen AI Max+ 395-ով և 128 ԳԲ unified հիշողությամբ, llama.cpp server՝ Vulkan backend-ի վրա, build-ն ամրագրված image-ի digest-ով։ Մոդելը Qwen3.6-35B-A3B Q4_K_M է՝ ամրագրված արտեֆակտի հեշով։ Workload-ը սառեցված փաստաթղթային սեսիա է. բեռնվում է անգլերեն փաստաթուղթ, տրվում է հարց, ապա երկրորդ հարց՝ նույն փաստաթղթի վրա։ Փաստաթղթի երկու չափ՝ 8k և 32k թոքեն։ Reasoning-ն անջատած է։ Ուսումնասիրվող միակ փոխանջատիչը սերվերի prompt cache-ն է։
Որքա՞ն է իրականում խնայում prompt cache-ը
Առաջին հարցը 32k փաստաթղթի վրա արժե 33940մվrepeated։ Դա prefill-ի հաշիվն է. մոդելը կարդում է ամբողջ փաստաթուղթը, նախքան որևէ բան ասելը, և աշխարհում ոչ մի cache չի օգնի փաստաթղթին, որը մոդելը տեսնում է առաջին անգամ։
Երկրորդ հարցը նույն փաստաթղթի վրա, երբ prompt cache-ն անում է իր գործը, արժե 860մվrepeated։ Փաստաթուղթն արդեն մարսված է. սերվերը մշակում է միայն այն, ինչ փոխվել է։
Հիմա ստուգիչ բջիջը։ Նույն երկրորդ հարցը՝ cache-ն անջատած. 33728մվrepeated։ Ամբողջ prefill-ը՝ վճարված երկրորդ անգամ, փաստաթղթի համար, որը սերվերը հենց նոր էր կարդացել։ Զարմանալիորեն շատ լոկալ տեղակայումներ հենց այս կոնֆիգուրացիայով են լուռ աշխատում։
Ավելի փոքր՝ 8k փաստաթղթի վրա cache-ված երկրորդ հարցը վերադառնում է 660մվrepeated-ում, այնպես որ cache-ված ուղին փաստաթղթի չափը հազիվ է նկատում։ Առանց cache-ի ուղին աճում է չափի հետ։
Ե՞րբ է llama.cpp-ի prompt cache-ն ընդհանրապես գործում
Cache-ը համընկնում է prefix-ով՝ բայթ առ բայթ, կենդանի սերվերային սեսիայի ներսում։ Ամեն ինչ, ինչ դիպչում է ձեր նոր հարցից առաջ եղած բայթերին, խնայողությունը դեն է նետում. system prompt, որի մեջ ներկառուցված է ընթացիկ ժամանակը; RAG-կոնվեյեր, որը հերթերի միջև վերադասավորում է դուրս բերված հատվածները; proxy, որը վերաշարադրում է պատմությունը; սերվերի վերագործարկում։ Փաստաթուղթը պետք է ժամանի նույնական, նույն դիրքում, ամեն հերթին։
Ահա թե ինչու «հաջորդ հարցերս դեռ դանդաղ են» բողոքները սովորաբար սարքաշարի խնդիր չեն։ Տուփը կարգին է։ Միջանկյալ ինչ-որ բան վերաշարադրում է prefix-ը, և ամեն հարց վճարում է առաջին հարցի գինը։
Ինչ է սա փոխում գործնականում
Այս դասի սարքաշարի վրա անձնական փաստաթղթային օգնականի համար աշխատում է այս workflow-ն. վճարեք լցումը մեկ անգամ, հետո մնացեք սեսիայի մեջ և հարցրեք այն ամենը, ինչ ունեք։ Ցավոտ workflow-ն փաստաթղթից փաստաթուղթ թռչկոտելն է կամ ցանկացած կոնվեյեր, որը կոնտեքստը վերակառուցում է ամեն հարցումի համար։ Նախքան դանդաղ հաջորդող հարցերն ավելի արագ սարքաշարով բուժելը՝ ստուգեք, թե ձեր ստեկն ինչ է անում prefix-ի հետ։ Ուղղումը կարող է անվճար լինել։
Ինչ սա ՉԻ ասում
- Այստեղ ոչինչ պատասխանների որակի մասին չէ։ Սեսիայի workload-ի gate-երը ստուգում են ֆորմատը, լեզուն և կրկնությունները; ընկալման խորությունը չի գնահատվում։
- Մեկ մոդել, մեկ քվանտ, մեկ backend, մեկ տուփ։ Տեղափոխվողը ճեղքի ձևն է; ճշգրիտ թվերը՝ ոչ։
- Սա llama.cpp server-ի վարքն է։ Այլ runtime-ները cache-ն այլ կերպ են կազմակերպում, և մենք դրանք այստեղ չենք չափել։
Կողք կողքի մատրիցը՝ համեմատության էջում, ստուգված կոնֆիգուրացիայի վճիռը՝ doc-session քարտում։ Վերևի ամեն թիվ ունի մշտական էջ՝ շրջանակով, սահմանափակումներով և հում գործարկումներով. claim-երի ռեեստրը։