Kostenoptimalisatie: snelle caching

Winst:

• Leg de logica voor het matchen van voorvoegsels van promptcaching uit
• Verhoogt de cachetreffer door de vaste context eerst en de variabele context erna te plaatsen
• Kan de cacheschrijf-/leeseconomie en het break-evenpunt berekenen

Een LLM-product ziet er in prototype goedkoop uit; Wanneer je op de weegschaal stapt, verrast de rekening. Bij de meeste workloads komt het grootste deel van de rekening uit dezelfde vaste context die bij elk verzoek keer op keer wordt verzonden: een lange systeemprompt, een rulebook, referentiedocumentatie. Snelle caching elimineert precies deze verspilling. In dit onderdeel leer je hoe de cache werkt, hoe je de prompt kunt regelen en hoe je het break-evenpunt van de cache-economie kunt berekenen. Als het correct wordt geïnstalleerd, kan het alleen al uw factuur halveren of zelfs verlagen.

Hoe werkt cache? De enige onveranderlijke regel

Prompt caching is een voorvoegselmatch. De provider slaat tijdelijk de tokens op die hij sinds het begin van uw prompt heeft verwerkt. Als de prompt bij het volgende verzoek met hetzelfde voorvoegsel begint, wordt dit gemeenschappelijke deel niet opnieuw berekend; Het is veel goedkoper om te lezen dan cache.

Hieruit volgt één onveranderlijke regel: als een enkele byte ergens in het voorvoegsel verandert, wordt de hele cache vanaf dat moment ongeldig. Dat wil zeggen dat de vaste inhoud aan het begin moet staan ​​en de variabele inhoud aan het einde. Als u aan het begin van de systeemprompt een regel plaatst die bij elk verzoek verandert, zoals "De datum van vandaag: 18.07.2026", kan alles daarachter niet in de cache komen.

De verwerkingsvolgorde is doorgaans: tools → systeemprompt → berichten. Het cachepunt (breekpunt) plaats je aan het einde van het vaste gedeelte.

Cache-economie

Cache heeft drie prijsniveaus:

• Cache schrijven: voor de eerste keer opslaan. ~1,25x de normale invoerprijs (voor opslag van 5 minuten).
• Cache lezen: Lezen bij volgende verzoeken. ~0,1 keer de normale inputprijs, dat wil zeggen een tiende.
• Normale invoer: het deel dat niet in de cache terechtkomt en elke keer tegen de volledige kosten wordt verwerkt.

Break-even punt: Eerste aanvraag betaalt schrijfpremie (1,25×). Vanaf het tweede verzoek komt de aflezing (0,1×) in beeld. Grofweg liggen jullie nek aan nek over twee verzoeken; Daarna is het een netto besparing. Hoe groter de vaste context en hoe meer verzoeken deze worden hergebruikt, hoe groter de winst wordt.

Scenario

Werkt cache?

Grote vaste systeemprompt, duizenden verzoeken

Ja – hoogste verdiensten

Veel vragen over dezelfde referentiedocumenten

Ja

Voor elke aanvraag een compleet andere korte tekst

Nee – schrijfbonus is verspild

Eenmalig verzoek

Nee – helemaal niet lezen

Datum/ID verandert bij elk verzoek na de systeemprompt

Nee: het voorvoegsel is verbroken, de hit is nul

Stap voor stap: hoe stel ik een hitprompt in?

1. Aparte constante en variabele. Welke inhoud verandert nooit (systeemprompt, rulebook, documentatie)? Wat verandert er bij elk verzoek (gebruikersvraag, datum, ID)?
2. Zet de constante aan het begin. Tijdens de verwerking moet het onderdeel dat het eerst komt (gereedschap, systeem) stabiel zijn.
3. Zet de variabele aan het einde. Huidige vraag van de gebruiker, laatste.
4. Plaats het bord aan het einde van de rand. Plaats het cachepunt in het laatste blok van het vaste gedeelte.
5. Controleer de treffer. Controleer of cache_read_input_tokens groter is dan nul in het gebruiksveld in het antwoord. Indien nul, zit er een verborgen disruptor in het voorvoegsel.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "rol": "user", "content": "{{user_current_question}}" } ]}

Tip: Raad cachehits niet, maar meet ze. Als gebruik.cache_read_input_tokens nog steeds nul is bij opeenvolgende verzoeken, wordt er een stille breker (datetime.now() op de systeemprompt, ongeordende JSON, lijst met tools die bij elk verzoek veranderen) uitgevoerd. Vergelijk de onbewerkte prompt van de twee verzoeken byte voor byte en zoek het verschil.

Stille disruptors

Typische patronen die onbewust de cache beschadigen:

# BREAKER: informatie insluiten in de systeemprompt die verandert bij elk verzoek "De datum van vandaag: {{nu}}. Je bent een assistent..." ← het voorvoegsel verandert bij elk verzoek, de hit is nul # TRUE: verplaats de variabele naar het berichtensysteem: "Je bent een assistent..." ← constante komt in de cacheberichten: [{rol: gebruiker, inhoud: "Vandaag is het {{nu}}. Vraag: ..."}] ← variabele aan het einde

Andere problemen: JSON wordt bij elk verzoek anders gesorteerd (sleutels in een vaste volgorde bewaren), lijst met tools die per gebruiker varieert (tools worden eerst verwerkt; er gaat niets in de cache als ze veranderen), het model wijzigen tijdens een gesprek (caches zijn modelspecifiek).

Zwakke prompt/sterke prompt (cachevriendelijke structuur)

# ZWAK (cache busting build) systeem: "Datum: 18.07.2026 14:32. Gebruiker: Ahmet (id 8842). Je bent een ondersteuningsbot. Regels: ...(2000 tokens)..."

# STERK (cachevriendelijke structuur)systeem: "Je bent een ondersteuningsbot. Regels: ...(2000 tokens, verandert nooit)..." [cacheteken]berichten: [ {rol: gebruiker, inhoud: "Datum: 18.07.2026 14:32. Gebruikers-ID: 8842. Vraag: hoe start ik mijn terugbetaling?" }]

In de zwakke versie wordt het regelblok van 2000 tokens bij elk verzoek tegen de volledige kosten verwerkt. In de sterke versie wordt hetzelfde blok één keer geschreven en bij alle volgende verzoeken gelezen voor een tiende van de prijs.

Drie mini-hoesjes

Geval 1 — Het rulebook in cache opslaan. Een boekhoudkundige automatisering voegde het regelboek van 12.000 tokens toe aan elke factuur; 5.000 aanvragen per dag. Invoer zonder cache kost ~$180 per dag. Ze hielden het rulebook constant en sloegen het op in de cache: voor de eerste verzoeken werd een schrijfpremie betaald, daarna werd er 0,1× gelezen. De inputkosten daalden met ~90% naar ~$18 per dag.

Geval 2 — Kosten van verborgen datumgrens. Eén team zette een cache op, maar kreeg geen treffers; cache_read_input_tokens was altijd nul. Reden: Er stond datetime.now() in de eerste regel van de systeemprompt, het voorvoegsel veranderde bij elk verzoek. Toen we de datum naar het gebruikersbericht verplaatsten, steeg het hitpercentage plotseling van 0% naar 94%.

Geval 3 — Misplaatste cache. Een zoekapplicatie stuurde bij elk verzoek totaal verschillende korte zoekopdrachten; Ze voegden gretig een cachebord toe. Omdat er geen gemeenschappelijk voorvoegsel bestond, betaalde elke aanvraag slechts een schrijfpremie, geen leesbewerkingen, wat de kosten verhoogde. Ze hebben het bord verwijderd. Les: cache betaalt alleen als er een groot en constant voorvoegsel is dat opnieuw wordt gebruikt.

Veel voorkomende fouten

• Constant en variabel combineren: wanneer de variabele inhoud in het voorvoegsel staat, wordt de hit gereset.
• Datum/ID insluiten in systeemprompt: de meest voorkomende stille verstoring.
• De hit niet meten: als cache_read_input_tokens niet is aangevinkt, wordt er geen verspilling opgemerkt.
• Cache toevoegen als er geen openbaar voorvoegsel is: u betaalt alleen de schrijfpremie, de kosten stijgen.
• Wijzigen van de voertuiglijst of het model: Het voorvoegsel is vanaf het begin verbroken; alles wordt herschreven.
• De minimale cachegrootte vergeten: Zeer korte caches (minder dan ~1-4k tokens, afhankelijk van het model) zullen niet stil in de cache terechtkomen.

Deeper: Cache ontwerpen op basis van werklasttype

De daadwerkelijke opbrengst van caching varieert afhankelijk van de aard van uw werklast; Leer dus eerst uw verkeer kennen. Drie typische patronen en correcte installatie:

Algemene systeemprompt, verschillende vragen. Meest voorkomende ondernemingspatroon: een grote systeemprompt (rol, regels, misschien referentiedocument) met honderden verschillende gebruikersvragen. Hier wordt het vaste deel (systeem) in eerste instantie in de cache opgeslagen; elke nieuwe vraag betaalt alleen de volledige prijs voor zijn eigen kleine deel. De winst is zeer hoog omdat het grote deel herhaaldelijk wordt gereciteerd tegen een tiende van de prijs.

Monoloog met meerdere rondes. Naarmate een gesprek voortduurt, bouwt elke nieuwe ronde voort op de voorgaande geschiedenis. Als je de cachevlag aan het einde van de laatste ronde plaatst, wordt bij elk verzoek het vorige gespreksvoorvoegsel hergebruikt; hits stapelen zich op naarmate het gesprek groeit. Dit beperkt de kosten van lange assistentsessies dramatisch.

Het gedeelde voorvoegsel is het laatste stukje dat moet worden gewijzigd. Meerdere verzoeken delen een groot aantal vaste priors (voorbeeldset, instructies), maar worden aan het einde gescheiden door één enkele vraag. Je plaatst de cache-pointer aan het einde van het gedeelde deel; Anders zou elk verzoek zijn eigen afzonderlijke cache schrijven en zou niets ervan worden gelezen.

Eén kanttekening: de cache is afhankelijk van het model en een bepaalde minimumgrootte. Zeer kleine voorvoegsels (minder dan een paar duizend tokens, afhankelijk van het model) zullen niet stil in de cache terechtkomen, zelfs als u ze markeert — cache_creation_input_tokens blijft nul. Bovendien maakt het wijzigen van het model tijdens een gesprek de gehele cache ongeldig; Als een andere taak een goedkoop model vereist, houd dan de hoofdstroom in één model en plaats de bijbaan in een aparte call.

Samengevat

Prompt caching is een voorvoegselmatch: vaste inhoud moet aan het begin staan, variabele inhoud moet aan het einde staan. Voor een grote, hergebruikte context bedragen de leeskosten een tiende van de volledige prijs, wat grofweg break-even is bij twee verzoeken. De meest voorkomende fout is het corrumperen van het voorvoegsel door variabele gegevens in de systeemprompt in te sluiten; Je verifieert de hit door deze te meten in het gebruiksveld.

Applicatie taak

Kies een werklast. (1) Verdeel de inhoud in twee kolommen: "verandert nooit" en "verandert bij elk verzoek". (2) Teken de promptstructuur opnieuw, waarbij het constante deel aan het begin en het variabele deel aan het einde wordt geplaatst. (3) Schat de tokengrootte van het vaste deel en vergelijk de maandelijkse kosten met/zonder cache. (4) Noteer uit welk veld (cache_read_input_tokens) u de hit wilt verifiëren.

controlelijst

• [ ] Ik kan uitleggen dat cache het matchen van voorvoegsels is en de enige onveranderlijke regel.
• [ ] Ik kan de nauwkeurigheid vergroten door de vaste inhoud aan het begin en de variabele aan het einde te plaatsen.
• [ ] Ik ken economie en het break-even punt met twee verzoeken.
• [ ] Ik kan stille verstoorders herkennen (datum, ongeordende JSON, veranderende voertuiglijst).
• [ ] Ik kan de hit verifiëren met gebruik.cache_read_input_tokens.