Печалби:
- Обяснете логиката за съвпадение на префикса при кеширането на подкани
- Увеличава попадението в кеша, като първо поставя фиксиран контекст и след това променлив контекст
- Може да изчислява икономиката на писане/четене на кеша и точката на рентабилност
LLM продукт изглежда евтин като прототип; Когато се качите на кантара, сметката изненадва. При повечето работни натоварвания по-голямата част от сметката идва от един и същ фиксиран контекст, който се изпраща отново и отново с всяка заявка: дълга системна подкана, книга с правила, справочна документация. Бързото кеширане елиминира точно тази загуба. В този модул ще научите как работи кешът, как да подредите подканата за попадение и как да изчислите точката на рентабилност на икономиката на кеша. Когато е инсталиран правилно, той сам може да намали сметката ви наполовина или дори по-малко.
Как работи кешът? Единственото неизменно правило
Подканящото кеширане е съвпадение на префикс. Доставчикът временно съхранява токените, които е обработил от началото на вашата подкана. Ако подканата започва със същия префикс при следващата заявка, тази обща част не се преизчислява; Много по-евтино е за четене от кеша.
Едно неизменно правило следва от това: Ако един байт се промени където и да е в префикса, целият кеш става невалиден от тази точка нататък. Тоест, фиксираното съдържание трябва да е в началото, а променливото съдържание трябва да е в края. Ако поставите ред в началото на системния промпт, който се променя при всяка заявка, като например "Днешна дата: 18.07.2026", всичко зад него няма да може да влезе в кеша.
Редът на обработка обикновено е: инструменти → системна подкана → съобщения. Поставяте точката на кеша (точката на прекъсване) в края на фиксираната секция.
Икономия на кеша
Кешът има три ценови нива:
- Кеш запис: Съхранение за първи път. ~1,25x нормална входна цена (за 5 минути съхранение).
- Четене на кеша: Четене на последващи заявки. ~0,1 пъти нормалната входна цена — тоест една десета.
- Нормално въвеждане: Частта, която не влиза в кеша и се обработва на пълна цена всеки път.
Точка на рентабилност: Първата заявка плаща премия за запис (1,25 ×). От второто искане влиза в действие показанието (0,1 ×). Грубо казано, ще бъдете един до друг по две заявки; След това са нетни спестявания. Колкото по-голям е фиксираният контекст и колкото повече заявки се използват повторно, толкова по-голяма става печалбата.
Сценарий
Работи ли кеша?
Голяма фиксирана системна подкана, хиляди заявки
Да - най-високи доходи
Много въпроси относно едни и същи справочни документи
да
Напълно различен кратък текст за всяка заявка
Не — бонусът за писане се губи
Еднократна заявка
Не — никакво четене
Промяна на дата/идентификатор с всяка заявка в системния ред
Не — префиксът е повреден, хитът е нула
Стъпка по стъпка: Как да настроите подкана за попадение?
- Отделете константа и променлива. Какво съдържание никога не се променя (системна подкана, правилник, документация)? Кое се променя с всяка заявка (потребителски въпрос, дата, ID)?
- Поставете константата в началото. По време на обработка частта, която е първа (инструменти, система), трябва да е стабилна.
- Поставете променливата в края. Текущият въпрос на потребителя, последен.
- Поставете знака в края на границата. Поставете кеш точката в последния блок на фиксираната част.
- Потвърдете попадение. Проверете дали cache_read_input_tokens е по-голямо от нула в полето за използване в отговора. Ако е нула, в префикса има скрит разрушител.
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}
Съвет: Не предполагайте попаденията в кеша, измервайте ги. Ако usage.cache_read_input_tokens все още е нула при последователни заявки, се изпълнява тих прекъсвач (datetime.now() при системна подкана, неподреден JSON, списък с инструменти, променящ се с всяка заявка). Сравнете необработената подкана на двете заявки байт по байт и намерете разликата.
Безшумни разрушители
Типични модели, които несъзнателно повреждат кеша:
# BREAKER: вграждане на информация в системната подкана, която се променя с всяка заявка "Днешна дата: {{now}}. Вие сте асистент..." ← префиксът се променя с всяка заявка, ударът е нула# TRUE: преместете променливата в системата за съобщения: "Вие сте асистент..." ← константата влиза в кеш съобщенията: [{role: user, content: "Днес е {{now}}. Въпрос: ..."}] ← променлива в края
Други прекъсвачи: JSON се сортира по различен начин при всяка заявка (запазване на ключовете във фиксиран ред), списък с инструменти, вариращ според потребителя (инструментите се обработват първи; нищо не влиза в кеша, ако се променят), промяна на модела по време на разговор (кешовете са специфични за модела).
Слаба подкана/Силна подкана (удобна за кеша структура)
# СЛАБА (изграждане на кеша) система: "Дата: 18.07.2026 14:32. Потребител: Ahmet (id 8842). Вие сте бот за поддръжка. Правила: ...(2000 токена)..."
# СИЛНА (удобна за кеша структура) система: "Вие сте бот за поддръжка. Правила: ...(2000 токена, никога не се променя)..." [кеш знак] съобщения: [ { роля: потребител, съдържание: "Дата: 18.07.2026 14:32. Потребителски идентификатор: 8842. Въпрос: как да инициирам възстановяването си?" }]
В слабата версия блокът от правила от 2000 токена се обработва на пълна цена при всяка заявка. В силната версия същият блок се записва веднъж и се чете на всички следващи заявки за една десета от цената.
Три мини калъфа
Случай 1 — Кеширане на книгата с правила. Счетоводна автоматизация добавяше книгата с правила за 12 000 токена към всяка фактура; 5000 заявки на ден. Въвеждането без кеш струва ~$180 на ден. Те поддържаха правилника постоянен и го кешираха: първите заявки плащаха премия за запис, следващите четения 0,1×. Цената на входа спадна с ~90% до ~$18 на ден.
Случай 2 — Цената на скрития ред за дата. Един отбор създаде кеш, но не получи попадения; cache_read_input_tokens винаги е бил нула. Причина: Имаше datetime.now() в първия ред на системния ред, префиксът се променяше с всяка заявка. Когато преместихме датата в потребителското съобщение, процентът на попадения внезапно се увеличи от 0% на 94%.
Случай 3 — Неправилно поставен кеш. Приложение за търсене изпращаше напълно различни кратки заявки с всяка заявка; Те с нетърпение добавиха знак за кеш. Без общ префикс, всяка заявка плаща само премия за запис, без четене - увеличавайки цената. Махнаха табелата. Урок: кешът плаща само ако има голям и постоянен префикс, който се използва повторно.
Често срещани грешки
- Смесване на константа и променлива: Когато съдържанието на променливата е в префикса, попадението се нулира.
- Дата/ИД на вграждане в системна подкана: Най-често срещаният безшумен разрушител.
- Не се измерва попадението: Ако cache_read_input_tokens не е отметнато, загубата няма да бъде забелязана.
- Добавяне на кеш, когато няма публичен префикс: Плащате само премията за запис, цената се увеличава.
- Промяна на списъка или модела на превозното средство: Префиксът е счупен от самото начало; всичко е пренаписано.
- Забравяне на минималния размер на кеша: Много късите кеши (под ~1–4k токена в зависимост от модела) няма да влязат в кеша тихо.
По-дълбоко: Проектиране на кеша по тип натоварване
Действителната печалба от кеширането варира в зависимост от естеството на вашето работно натоварване; така че първо се запознайте с трафика си. Три типични модела и правилна инсталация:
Обща системна подкана, различни въпроси. Най-често срещаният модел на предприятието: голяма системна подкана (роля, правила, може би референтен документ) със стотици различни потребителски въпроси. Тук първоначално се кешира фиксираната част (системата); всеки нов въпрос плаща пълната цена само за собствената си малка част. Печалбата е много висока, защото голямата порция се рецитира многократно на една десета от цената.
Многократен монолог. Докато разговорът продължава, всеки нов кръг надгражда цялата предишна история. Ако поставите флага на кеша в края на последния кръг, всяка заявка използва повторно префикса на предишния разговор; хитовете се натрупват с нарастването на разговора. Това драматично намалява цената на дългите асистентски сесии.
Споделеният префикс е последният бит за промяна. Множеството заявки споделят голям набор от фиксирани преди (набор примери, инструкции), но са разделени от един въпрос в края. Поставяте указателя на кеша в края на споделената част; В противен случай всяка заявка ще записва свой собствен отделен кеш и нищо от него няма да бъде прочетено.
Едно предупреждение: кешът зависи от модела и определен минимален размер. Много малки префикси (под няколко хиляди токена, в зависимост от модела) няма да влязат тихо в кеша, дори ако ги маркирате — cache_creation_input_tokens остава нула. Също така, промяната на модела по време на разговор обезсилва целия кеш; Ако различна задача изисква евтин модел, запазете основния поток в един модел и поставете страничната задача в отделно обаждане.
В обобщение
Подканящото кеширане е съвпадение на префикс: фиксираното съдържание трябва да е в началото, променливото съдържание трябва да е в края. За голям, повторно използван контекст цената на четене е една десета от пълната цена, което грубо се изравнява при две заявки. Най-честата грешка е да повредите префикса чрез вграждане на променливи данни в системния ред; Вие проверявате попадението, като го измервате в полето за използване.
Задача за приложение
Изберете работно натоварване. (1) Разделете съдържанието на две колони: „никога не се променя“ и „променя се при всяка заявка“. (2) Преначертайте структурата на подканата, като поставите постоянната част в началото и променливата част в края. (3) Оценете символичния размер на фиксираната част и сравнете месечните разходи с/без кеш. (4) Отбележете от кое поле (cache_read_input_tokens) ще проверите попадението.
контролен списък
- [ ] Мога да обясня, че кешът е съвпадение на префикс и единственото неизменно правило.
- [ ] Мога да повиша точността, като поставя фиксираното съдържание в началото и променливото в края.
- [ ] Знам икономиката на писане/четене и точката на рентабилност при две заявки.
- [ ] Мога да разпозная безшумни разрушители (дата, неподреден JSON, променящ се списък с превозни средства).
- [ ] Мога да проверя попадението с usage.cache_read_input_tokens.