Добивки:
- Објаснете ја логиката за совпаѓање на префиксот за брзо кеширање
- Го зголемува ударот на кешот со ставање фиксен контекст на прво место, а потоа променлив контекст
- Може да пресмета економичност за пишување/читање на кешот и точка на прекин
Производот LLM изгледа евтин во прототип; Кога ќе се искачите на скалата, сметката изненадува. Во повеќето оптоварувања, поголемиот дел од сметката доаѓа од истиот фиксен контекст што се испраќа одново и одново со секое барање: долг системски совет, правилник, референтна документација. Навременото кеширање го елиминира токму овој отпад. Во оваа единица, ќе научите како работи кешот, како да го организирате потсетникот за погодување и како да ја пресметате точката на прекин на економичноста на кешот. Кога е правилно инсталиран, тој сам може да ја намали вашата сметка на половина или уште помал.
Како работи кешот? Едно непроменливо правило
Брзото кеширање е совпаѓање на префиксот. Давателот привремено ги складира токените што ги обработил од почетокот на вашето барање. Ако промптот започнува со истиот префикс на следното барање, овој заеднички дел не се пресметува повторно; Читањето е многу поевтино од кешот.
Од ова следи едно непроменливо правило: Ако еден бајт се смени каде било во префиксот, целиот кеш станува неважечки од таа точка па натаму. Односно, фиксната содржина треба да биде на почетокот, а променливата содржина треба да биде на крајот. Ако ставите линија на почетокот на системското известување што се менува со секое барање, како што е „Денешен датум: 18.07.2026“, сè што стои зад него нема да може да влезе во кешот.
Редоследот на обработка обично е: алатки → системско известување → пораки. Ја ставате точката на кешот (точка на прекин) на крајот од фиксниот дел.
Кеш економија
Кешот има три нивоа на цени:
- Запишување во кеш: Се чува за прв пат. ~1,25x нормална влезна цена (за 5 минути складирање).
- Читање на кешот: Читање на следните барања. ~ 0,1 пати од нормалната влезна цена - односно една десетина.
- Нормален влез: Делот што не влегува во кешот и се обработува со целосна цена секој пат.
Точка на прекршување: Првото барање се плаќа премија за пишување (1,25×). Од второто барање, отчитувањето (0,1×) влегува во игра. Грубо, ќе бидете врат и врат на две барања; После тоа, тоа е нето заштеда. Колку е поголем фиксниот контекст и колку повеќе барања повторно се користат, толку е поголема добивката.
Сценарио
Дали кешот работи?
Големо известување за фиксен систем, илјадници барања
Да - највисока заработка
Многу прашања за истите референтни документи
Да
Сосема различен краток текст за секое барање
Не - бонусот за пишување се троши
Еднократно барање
Не - воопшто нема читање
Датумот/ID се менува со секое барање на системското известување
Не - префиксот е скршен, ударот е нула
Чекор по чекор: Како да поставите знак за хит?
- Одделете константа и променлива. Која содржина никогаш не се менува (системско известување, правилник, документација)? Што се менува со секое барање (корисничко прашање, датум, ID)?
- Ставете ја константата на почетокот. За време на обработката, делот што е на прво место (алатки, систем) мора да биде стабилен.
- Ставете ја променливата на крајот. Тековно прашање на корисникот, последно.
- Ставете го знакот на крајот од границата. Ставете ја кеш-точката во последниот блок од фиксниот дел.
- Потврдете го ударот. Проверете дали cache_read_input_tokens е поголем од нула во полето за користење во одговорот. Ако е нула, има скриен прекинувач во префиксот.
{ „систем“: [ { „тип“: „текст“, „текст“: „{{large_constant_system_promptu_and_rules}}“, „cache_control“: { „тип“: „ефемерен“ } } ], „пораки“: [{„улога“: „корисник“, „содржина}_курс“:{содржина}_курс:
Совет: Не погодувајте ги погодоците од кешот, измерете ги. Ако usage.cache_read_input_tokens сè уште е нула на последователни барања, работи тивок прекинувач (datetime.now() на системско известување, неуреден JSON, список на алатки што се менуваат со секое барање). Споредете го суровиот промпт на двете барања бајт по бајт и пронајдете ја разликата.
Тивки нарушувачи
Типични обрасци кои несвесно го корумпираат кешот:
# BREAKER: вградување на информации во системот што се менуваат со секое барање „Денешен датум: {{сега}}. Вие сте асистент...“ ← префиксот се менува со секое барање, притиснете е нула# ТОЧНО: преместете ја променливата во системот за пораки: „Вие сте асистент...“ ← константата ја внесува кеш-пораката:{roow user:{roow user: Прашање: ..."}] ← променлива на крајот
Други прекинувачи: JSON различно подреден на секое барање (задржете ги клучевите во фиксен редослед), список на алатки кои се разликуваат по корисник (алатките прво се обработуваат; ништо не влегува во кешот ако се сменат), менување на моделот во средината на разговорот (кешовите се специфични за моделот).
Слаб промпт / Силен промпт (структура погодна за кешот)
# СЛАБ (изградба на кеш busting) систем: "Датум: 18.07.2026 14:32. Корисник: Ahmet (id 8842). Вие сте бот за поддршка. Правила: ...(2000 токени)..."
# STRONG (структура погодна за кешот) систем: "Вие сте бот за поддршка. Правила: ...(2000 токени, никогаш не се менуваат)..." [знак за кешот]пораки: [ { улога: корисник, содржина: "Датум: 18.07.2026 14:32. Ид на корисник: 8842. Прашање: како да ги вратам парите?" }]
Во слабата верзија, блокот на правила од 2000 токени се обработува со целосна цена на секое барање. Во силната верзија, истиот блок се пишува еднаш и се чита на сите наредни барања за десетина од цената.
Три мини футроли
Случај 1 — Кеширање на правилникот. Сметководствената автоматизација го додаваше правилникот од 12.000 токени на секоја фактура; 5.000 барања дневно. Влезот без кеш чини ~ 180 долари дневно. Тие го одржуваа правилникот константен и го чуваа во кеш: првите барања плаќаа премија за запишување, последователните читања 0,1×. Влезната цена се намали за ~ 90% на ~ 18 долари дневно.
Случај 2 - Цена на линијата за скриен датум. Еден тим постави кеш, но не добиваше никаков удар; cache_read_input_tokens секогаш беше нула. Причина: Имаше datetime.now() во првата линија од системскиот промпт, префиксот се менуваше со секое барање. Кога го преместивме датумот на корисничката порака, стапката на удари одеднаш се зголеми од 0% на 94%.
Случај 3 - Погрешен кеш. Апликација за пребарување испраќаше сосема различни кратки прашања со секое барање; Тие со нетрпение додадоа знак за кеш. Без заеднички префикс, секое барање плаќаше само премија за пишување, без читање - зголемување на цената. Го тргнаа знакот. Лекција: кешот се плаќа само ако има голем и постојан префикс што повторно се користи.
Вообичаени грешки
- Мешање константа и променлива: кога содржината на променливата е во префиксот, ударот се ресетира.
- Вградување датум/ID во системското известување: Најчестиот тивок прекинувач.
- Не се мери ударот: ако cache_read_input_tokens не се провери, отпадот нема да се забележи.
- Додавање кеш кога нема јавен префикс: ја плаќате само премијата за пишување, цената се зголемува.
- Промена на списокот или моделот на возила: префиксот е скршен од почеток; се е препишано.
- Заборавајќи ја минималната големина на кешот: многу кратки кешови (под ~1–4k токени во зависност од моделот) нема да влезат тивко во кешот.
Подлабоко: Дизајнирање кеш според типот на оптоварување
Вистинската исплата на кеширањето варира во зависност од природата на вашиот обем на работа; затоа прво запознајте го вашиот сообраќај. Три типични обрасци и правилна инсталација:
Заеднички системски промпт, различни прашања. Најчестиот модел на претпријатие: голем системски потсетник (улога, правила, можеби референтен документ) со стотици различни кориснички прашања. Овде фиксниот дел (системот) првично се кешира; секое ново прашање плаќа полна цена само за својот мал дел. Добивката е многу висока затоа што големиот дел се рецитира постојано по десетина од цената.
Повеќекружен монолог. Како што се одолговлекува разговорот, секоја нова рунда се надоврзува на целата претходна историја. Ако го ставите знамето на кешот на крајот од последниот круг, секое барање повторно го користи претходниот префикс за разговор; хитовите се акумулираат како што разговорот расте. Ова драматично ја намалува цената на долгите сесии на асистент.
Споделениот префикс е последниот бит што се менува. Повеќекратните барања споделуваат голем сет на фиксни приоритети (множество примероци, инструкции), но се одделени со едно прашање на крајот. Го ставате покажувачот на кешот на крајот од споделениот дел; Во спротивно, секое барање би напишало свој посебен кеш и ништо од него нема да се чита.
Едно предупредување: кешот зависи од моделот и одредена минимална големина. Многу мали префикси (под неколку илјади токени, во зависност од моделот) нема тивко да влезат во кешот дури и ако ги означите - cache_creation_input_tokens остануваат нула. Исто така, менувањето на моделот во средината на разговорот го поништува целиот кеш; Ако за различна задача е потребен евтин модел, задржете го главниот тек во еден модел и ставете ја страничната работа во посебен повик.
Сумирано
Промптното кеширање е совпаѓање на префиксот: фиксната содржина треба да биде на почетокот, а променливата содржина треба да биде на крајот. За голем, повторно употребуван контекст, цената за читање е десетина од целосната цена, приближно на две барања. Најчеста грешка е да се корумпира префиксот со вградување на податоци за променливи во системската промпт; Погодокот го потврдувате мерејќи го во полето за употреба.
Задача за апликација
Изберете обем на работа. (1) Поделете ја содржината во две колони: „никогаш не се менува“ и „се менува со секое барање“. (2) Прецртајте ја промпт структурата, ставајќи го константниот дел на почетокот и променливиот дел на крајот. (3) Проценете ја големината на токенот на фиксниот дел и споредете ги месечните трошоци со/без кешот. (4) Забележете од кое поле (cache_read_input_tokens) ќе го потврдите ударот.
листа за проверка
- [ ] Можам да објаснам дека кешот е совпаѓање на префиксот и единственото непроменливо правило.
- [ ] Можам да ја зголемам точноста со ставање на фиксната содржина на почетокот и променливата на крајот.
- [ ] Знам економија за пишување/читање и рамномерна точка со две барања.
- [ ] Можам да препознаам тивки прекинувачи (датум, неуреден JSON, менување на списокот на возила).
- [ ] Можам да го потврдам ударот со usage.cache_read_input_tokens.