Když váš lokalizační engine překládá text, část promptu, který posílá do LLM, je u každého požadavku stejná a část se mezi požadavky mění. Cache promptů umožňuje engine znovu použít stabilní část, místo aby se její zpracování pokaždé účtovalo znovu. Tyto znovu použité tokeny se ve vaší spotřebě zobrazují jako cache tokeny a stojí jen zlomek ceny běžných vstupních tokenů.
Jak se skládá překladový prompt#
Každý požadavek, který engine posílá modelu, se skládá z několika vrstev. Některé jsou stabilní napříč všemi požadavky pro stejný engine a jazyk, jedna je dynamická a mění se s každým požadavkem.
| Vrstva | Stabilní nebo dynamická | V cache |
|---|---|---|
| Systémový prompt – identita engine, lokalizační pravidla, gramatika | Stabilní pro každý engine | Ano |
| Vaše instrukce a hlas značky pro každý jazyk | Stabilní, dokud engine neupravíte | Ano |
| Termíny ze slovníčku načtené pro tento konkrétní požadavek | Dynamická – liší se podle požadavku | Ne |
| Text k překladu | Dynamická | Ne |
Stabilní vrstvy tvoří souvislý prefix na začátku promptu. Engine označí konec tohoto prefixu jako cache breakpoint: vše před ním lze uložit do cache a znovu použít, zatímco vše za ním – slovníček pro konkrétní požadavek, příklady a váš vstupní text – se při každém požadavku posílá znovu.
Proč se slovníček neukládá do cache
Slovníček se načítá pro každý požadavek podle konkrétního textu, který překládáte, takže se mezi jednotlivými požadavky mění. Když zůstane za cache breakpointem, zbytek promptu lze znovu použít bez ohledu na to, které termíny ze slovníčku si daný požadavek natáhne.
Proč je vstup z cache levnější#
První požadavek pro daný engine a jazyk stabilní prefix zapíše do cache poskytovatele. Každý další požadavek, který tento prefix znovu použije, ho z cache načte, místo aby ho zpracovával od nuly. Poskytovatelé účtují čtení z cache jen jako zlomek běžné sazby za vstupní tokeny, takže hlavní část vašeho promptu – ta, která se nikdy nemění – se při každém požadavku přestane znovu účtovat v plné ceně.
Cache má krátkou životnost a spravuje ji poskytovatel modelu, ne váš engine. Největší přínos proto má ve chvíli, kdy během krátkého okna překládáte hodně textu ve stejném engine a jazyce: požadavky přicházejí, zatímco je prefix stále warm, a načítají se rovnou z cache.
Cachování je automatické
Nemusíte nic nastavovat. To, jestli požadavek využije cache, závisí na modelu, který ho zpracovává – modely Anthropic a Google používají explicitní cache breakpointy, modely OpenAI si dlouhé prefixy cachují samy a někteří poskytovatelé necachují vůbec. Engine pro každý model použije správné chování.
Co tím získáte#
- Nižší náklady – stabilní prefix zaplatíte jednou za plnou cenu a pak při každém opakovaném požadavku už jen za sníženou sazbu za čtení z cache.
- Nižší latence – cache tokeny není potřeba znovu zpracovávat, takže warm požadavky se vracejí rychleji.
- Bez nastavování – cachování je zapnuté ve výchozím nastavení; v konfiguraci engine není co aktivovat.
Přínosy se násobí při stabilním provozu na stejném engine a jazyce – přesně tak vypadá produkční lokalizační pipeline, kde stejná konfigurace obsluhuje jeden požadavek za druhým.
Jak číst cache tokeny ve své spotřebě#
Každá odpověď z překladu obsahuje rozpad spotřeby, který odděluje cache tokeny od nových vstupů:
{
"usage": {
"inputTokens": 1200,
"outputTokens": 800,
"cacheReadTokens": 950,
"cacheWriteTokens": 0
}
}| Pole | Význam |
|---|---|
inputTokens | Tokeny promptu nově zpracované v tomto požadavku |
outputTokens | Tokeny vygenerované modelem |
cacheReadTokens | Tokeny promptu obsloužené z cache poskytovatele. 0, když se nic nenačetlo z cache. |
cacheWriteTokens | Tokeny promptu zapsané do cache při tomto požadavku – cache miss / první volání. |
První požadavek pro daný engine a jazyk obvykle ukazuje kladnou hodnotu cacheWriteTokens (prefix se zapisuje) a cacheReadTokens ve výši 0. Následné požadavky, zatímco je cache stále warm, to obrátí: cacheReadTokens roste a cacheWriteTokens klesá na 0. Souhrnnou spotřebu tokenů napříč svými enginy sledujte v Reportech.
