Hoe prefix caching LLM-prompts en gecachete tokens hergebruikt
Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
Prefix caching hergebruikt de attention-toestand van een eerder compatibel promptprefix. Een nieuw verzoek verwerkt alleen het resterende deel dat niet in de cache staat, in plaats van alle promptberekeningen te herhalen. Dit helpt bij workloads met herhaalde systeeminstructies, voorbeelden, documenten of gespreksprefixen.
De overeenkomst betreft tokens en modeltoestand. Vergelijkbare bewoordingen, herhaalde tekst verderop in een prompt of dezelfde tokens met een andere adapter leveren geen geldige cachetreffer op.
Wat moet overeenkomen
In een causale transformer hangen de gecachete keys en values van een token af van de voorafgaande tokens. Een later herhaalde passage hergebruiken nadat een eerdere passage is gewijzigd, zou toestanden hergebruiken die van een andere context afhangen.
| Mogelijk hergebruik | Controle |
|---|---|
| Identieke system prompt | Exacte token-ID’s en compatibele modeltoestand |
| Herhaald document | Identiek voorafgaand prefix en identiek document |
| Voortgezet gesprek | Ongewijzigde eerdere berichten, sjabloon en tokens |
| Dezelfde tekst met een andere adapter | Adapteridentiteit en de compatibiliteitsregels van de cache |
| Multimodale prompt | Identiteit van afbeeldingen en media, niet alleen tokens als plaatsaanduiding |
Het ontwerp van de prefixcache van vLLM berekent een hash over de tokens van een blok, het bovenliggende prefix en extra identificatoren zoals LoRA en multimodale toestand. Het hergebruikt volledige blokken; een onvolledig laatste blok levert niet automatisch een cachetreffer op. Cache-salts kunnen ook verzoeken scheiden die geen gecachete toestand mogen delen.
RadixAttention van SGLang ordent herbruikbare prefixen in een radixboom. De representatie verschilt, maar compatibele prefixtoestand blijft vereist.
Vermeden prefill-werk meten
Prefix caching voorkomt vooral herhaalde promptberekeningen. Het neemt de decodering of de attention daarvan over de beschikbare geschiedenis niet weg. Bespaarde berekeningen betekenen ook niet dat de TTFT van elk verzoek verbetert: wachttijden en verzoeken met een koude cache blijven bestaan.
Vergelijk verzoeken met een koude cache afzonderlijk met verzoeken waarvan het herhaalde prefix al in de cache staat. Registreer hergebruikte tokens, niet alleen het aandeel verzoeken met een treffer. Een treffer voor 32 tokens en een voor 8,000 tokens vermijden verschillende hoeveelheden werk. Meet het geheugen dat de cache vasthoudt, verwijderingen uit de cache en latency per prefixlengte.
Plaats vaste instructies vóór gegevens die specifiek zijn voor het verzoek wanneer die volgorde de bedoelde prompt behoudt. Neem compatibiliteit van tenants en adapters op in het cachebeleid. Vermeld de cachetoestand wanneer je serving-resultaten publiceert.
Engineeringgids: prefix caching legt het verband uit tussen het hergebruikmechanisme en KV-toewijzing.