Optimalisering van LLM-prestasie met LM Cache: Arkitekture, Strategieë en Reële Wêreld Toepassings

Abstract abstrakte Hierdie artikel bied 'n diepgaande tegniese navorsing-georiënteerde blik op die werking van LM Cache en hoe die caching masjien verbeter die doeltreffendheid, skaalbaarheid en koste-vermindering van groot taalmodel (LLM) uitrol. Ons bestudeer verskillende soorte caching argitekture en meganismes, hoe hulle saam met die nuwe AI-infrastruktuur geïntegreer kan word en geëvalueer kan word vir prestasie. Voorbeelde uit die veld detail hoe sommige van ons grootste kliënte LM Caches in die praktyk implementeer en wat hulle onderweg geleer het. Introduction Inleiding Dink aan 'n AI-assistent wat voortdurend dieselfde antwoorde die hele dag lank vir honderde tydperke moet gee! Dit is nie 'n resultaat nie, moet dit elke antwoord van nul af weer genereer, letterlik elke keer? Terwyl LLMs (dink GPT-4, PaLM, ens) alles van kliëntondersteuning na kode-generasie verander. In produksie kan elke query na 'n groot model sekondes en aansienlike GPU-berekening koste.Aangesien modelgrootte en gebruikersverwagtinge toeneem, word die behoefte aan vinnige gevolgtrekking belangriker as ooit. deployment at scale is stymied by latency requirements, computational cost and memory footprint Met al hierdie in ag geneem, die LM-cache ontstaan as 'n baie slim antwoord op hierdie probleme deur die caching en hergebruik van reeds berekende resultate. Caching is basies wat ons stelsel in staat stel om alles wat dit voorheen gesien het te onthou. Die algemene idee van die konsep is nie nuut in rekenaarwetenskap nie, maar dit het 'n potensiële deurbraak in die LLM self gehad vir beduidend groter deurvoer en 'n groot vermindering in reaksie tyd. Soos model destilleer (kleinere, vinniger modelle skep), opname-vergroot generasie (boor op eksterne kennisbases), en vektordatabasisse vir semantiese soektog, verhoog LM Cache ander optimisasie tegnieke. Met 'n finale maatstaf van caching meganismes wat in kombinas Foundations of LM Cache Gebaseer op LM Cache Die konsep van is eenvoudig 'n hergebruik berekening vir nie oorwerk. In die geval van LLM inferensie, caching kan bestaan op verskillende vlakke van granulariteit: LM cache Cache the entire output to a given input prompt. If our model receives the same prompt again, it returns the cached output without running the model. This is effectively memorizing the model's response to entire queries, at the highest-level cache. It is particularly powerful for tasks that involve the reapplication of the same query many times (e.g. Q&A model with a single question asked repeatedly) This could be implemented, for example (sample implementation in the functions promptify and getPossibleResults) as a simple dictionary that maps prompts to possible results e.g. Prompt-level cache: Pseudocode: prompt-level cache integration prompt_cache = {} # A dictionary to store prompt->response mappings def generate_response(prompt): if prompt in prompt_cache: return prompt_cache[prompt] # return cached answer result = model.generate(prompt) # expensive LLM call prompt_cache[prompt] = result # store for next time return result We cache intermediate results for each token in a sequence instead of caching whole responses. Autoregressive LLMs generate text one token after the other. This is because without caching, the entire previous context will have to generated again from start for every new token to be created. Token level caching is the process of stores intermediate state of model tokens like the activations or hidden states in a way that, when producing next token, the model can skip recomputing what it already did for prior tokens. This is highly connected to the in transformer models, more on this below. Token specific caching: key–value cache LLMs based on transformers use self-attention, which means that each token pays attention to all of the ones that came before it. Frameworks cache the "key" and "value" projections for previous tokens and only add new ones to avoid having to compute attention over the whole sequence again. . This KV cache speeds up autoregressive decoding, which is an important GPT-style optimization. It cuts the work per step from O(n²) to O(n) without changing the outputs (Yazdani Aminabadi et al., 2022; Pol, 2025) arxiv.org. By default, libraries like Hugging Face Transformers do this with during generation, which means that only new tokens are processed. A simple pseudocode loop shows how grows with each iteration. KV cache (Key-Value cache) : neptune.ai use_cache=True past_kv Pseudocode: using KV cache in an autoregressive decoder loop past_kv = None for token in prompt_tokens: output, past_kv = model.decode_next(token, past_key_values=past_kv) # past_kv now contains keys/values for all tokens up to current one The above loop accumulates the key-value pairs to be carried forward as such as that model. Then can use the cached context and need not recompute it. The KV caching makes the quadratic slowdown now avoidable, and transforming models to work with this form of storage is crucial for the continued efficiency of transformer inference, particularly if GPT-4 like models are able to generate much longer continuations far more efficiently. past_kv model.decode_next LLM follows the same procedure with all text input as firstly it converts tokens into vector embeddings. Calculating these embeddings (especially a large contextual embedding model) can cost nearly as much as running the full LLM itself, so why do it again for some common tokens/phrases? Embedding Cache — a cache where the vector representations of common inputs are stored. (Paul, 2025) . For example, we can cache those embeddings instead of computing them from scratch if application encodes the same sentences or document chunks many times (in a retrieval-augmented setup) This will save time and guide the style of such representations. . Embedding caching is a natural fit for retrieval pipelines and semantic search, as it caches the “input features” before they hit the big model. Embedding cache: rohan-paul.com rohan-paul.com Multi-Query Attention (MQA) is a type of Transformer attention in which all heads use the same keys and values as input to their attention function (Shazeer, 2019) . Typically, with 12 or 24 heads, each head has its own keys and values. This means that the cache stores 12x or 24x vectors for each token. Instead, MQA caches just one set, and heads keep their query projections while looking up a shared key-value store. In one benchmark (Shazeer, 2019) ( ; ), this cut memory and bandwidth overhead by a huge amount, from about 15 GB to less than 400 MB on a 16k-token context. There is only one shared cache instead of 100% memory overhead per head. Multi-query attention caching: arxiv.org arxiv.org huggingface.co Noam Shazeer first suggested MQA (and its grouped-query versions) in One Write-Head is all we Need ( ). It is used in PaLM, Falcon, MPT, and BLOOM to make longer contexts work better. It also makes inference faster because it needs to fetch less data from memory, which means it can do attention computations faster ( ). In theory, MQA is a smart way to cache data for the architecture, so that the number of trainable parameters doesn't go up as the number of heads or the length of the context grows. huggingface.co huggingface.co gebruik_cache = waar Volgende / KV Volgende / KV die dekode_next Al die bovengenoemde caching vlakke maak gebruik van die eenvoudige beginsel dat As gevolg van die self-oplettendheid meganisme, die berekening van elke nuwe token in transformer-gebaseerde LLMs hang dikwels af van vorige tokens. Of dit nou op die spoedvlak of diep binne die model is, die caching van die resultate van daardie vorige berekenings laat daaropvolgende operasies toe om direk na die eindresultaat te spring. system shouldn't re-compute what you have already done LM Cache Architectures and Strategies LM Cache Arkitekture en Strategieë Aangesien nie alle werklooshede dieselfde is in LLM-stelsels nie, is 'n groot aantal argitekture en strategieë ontwerp deur ingenieurs om cache hits te maksimeer en oorhead te verminder. Statiese vs. Dinamiese caches: Statiese caches kom met vooraf gevulde invoer / uitvoerpaar, wat hulle uitstekend maak vir voorspelbare werklooshede. Dit is caching oplossings vir algemene vrae of vaste prompt outputs, soos FAQ's of toetscase-reaksies. Dinamiese caches, aan die ander kant, vul as 'n stelsel loop, verander om te pas op verkeerspatrone, verandering query verspreidings, en gebruik spikes. Hulle is eintlik "leer" van gebruikersverkeer om hit tariewe te verbeter. In die werklike lewe, stelsels beperk dinamiese caches deur die gebruik van eviction beleid gebaseer op huidige vraag, wat outomaties ontslae raak van ou items. Dinamiese caching word verkies vir die meeste werk Verspreide en Federated Caching: In groot uitrustings met baie LLM-instansies op verskillende bedieners of pods, per masjien caches werk nie vir kruis-bediener hergebruik. Byvoorbeeld, as Server A verwerk en caches 'n query, Server B moet die antwoorde herbereken, selfs al kan dit nie toegang tot Server A. Verspreide cache herstel dit deur invoer te deel deur middel van 'n eksterne winkel, soos Redis. NVIDIA se Triton Inference Server het verspreide caching bygevoeg in 2023, hoewel netwerk hop net ongeveer 8% meer latentie bygevoeg as plaaslike in-proces caches. (Lorello et al., 2023; Paul, 2025) rohanpaul.com. Dan, bedieners caches een keer en gebruik die resultate Layer-wise caching en GPU/TPU geheue optimalisering: Caching is nie beperk tot die output nie; dit kan ook gebruik word by spesifieke LLM-lae. Om te vermy dat jy weer 'n duur tussenlae moet bereken op 'n cache-hit, kan jy byvoorbeeld die outputs van daardie laag voor spesifieke gereelde inputs cacheer. Daarbenewens kan dit sin maak om slegs die duurste aktiverings te cacheer of om on-chip geheue te gebruik vir caches op hardeware versnelers (GPU's/TPU's), waar geheue waardevol is. Inference analoge van tegnieke soos gradient-checkpointing, wat handel berekening behels vir geheue-opleiding, kan jou toelaat om spesifieke laag-outputs selekti Cache granularity en sleutels: Die keuse van 'n cache-indeks is 'n slim beweging. Akkurate-match sleutels op die volledige prompt string is maklik om te gebruik, maar hulle breek maklik - enige verandering mis die cache. Om meer treffers te kry, gebruik stelsels embedding-gebaseerde semantiese hashes wat prompts soos dieselfde behandel, selfs as die formulering anders is, of voorvoegsel / chunk sleutels wat ooreenstem met ooreenkomstige segmente. Na die verwerking van 'n stabiele voorvoegsel, "prefix caching" neem 'n snapshot van die model se KV-staat. Op hierdie manier, 'n nuwe voorvoegsel wat begin met daardie voorvoegsel, kan vLLM-projek vinnig na daardie toestand beweeg. Cache Grootte en Verwijdering Beleid: Omdat die cache geheue is beperk, LLMs gebruik beleid soos LRU of LFU om te besluit watter inskrywings te hou en wat om te verwyder. Dit bevry ruimte vir nuwe data. Benewens die verwydering van items gebaseer op ouderdom of frekwensie, LLM caches moet ook hanteer relevantheid verwydering en model of data-updates deur die verwydering van ou items. In 2024, navorsing het getoon dat leer-gedryf verwydering werk: caches wat opgelei is om te vind en ontslae te raak van sleutels met min toekomstige waarde (Xiong et al., 2024). Hierdie adaptiewe, "slim" verwydering stels, wat gemaak word vir LLM werkloads, sal waarskynlik die norm vir die Kortom, die bou van 'n LM-cache is 'n delikate balans: Ons wil die hitpercentage maksimeer terwyl ons oorheersing soos geheueverbruik en volatiliteit verminder. As dit beteken dat jy die masjienvertalingstelsels harder moet werk, wees dan my gaste! Hierdie strategieë (statiese versus dinamiese, verspreide argitekture, trek in die cache wat op terminologie geraak word deur dit op kliënt tyd met vorige voorbeeldtaal te vervaardig) is al die truuks wat jou kan help om meer met caching te doen sonder om oor cache-verwante valstrike te struikel. Verskeie programme kan hierdie metodes meng en toepas Byvoorbeeld, 'n produksie stelsel kan op die toepasingsvlak 'n semantiese prompt cache gebruik (for inst Architektuur Diagram van LM Cache in 'n LLM Inference Pipeline Hier is die verwysingsargitektuur wat die integrasie van LM Cache in 'n tipiese LLM-afleweringsstroom vertoon: Werkstroomdiagram Vergelyk Cached vs. Nie-Cached Inference Vrae Om die voordele verder te verstaan, oorweeg die werkstroomvergelyking tussen cachede en nie-cache inferensie versoekings: Integrasie met moderne AI-infrastruktuur Caching LM staan nie alleen nie - dit sal afkomstig wees van die breër aansoek-ekosisteem in AI. Hier kyk ons na hoe caching in 'n verskeidenheid infrastrukture en raamwerke pas: The good news is that KV caching is integrated into the majority of contemporary AI frameworks. To avoid redundant computation, Hugging Face Transformers, for example, allows you to set (the default in generate()) to automatically return and reuse previous key/value states. KV caching is used for incremental decoding in Microsoft's DeepSpeed-Inference, which is crucial for scaling large autoregressive models. Kernels are tuned appropriately. (Yazdani Aminabadi et al., 2022) . Cache decoding is also accelerated internally by NVIDIA's TensorRT and ONNX Runtime. In order to maximize speed, model architectures now assume caching in addition to software stacks. UC Berkeley's vLLM presents PagedAttention to manage GPU KV cache, paging it similarly to virtual memory and sharing identical prompt prefixes. (Kwon et al., 2023) . FlashAttention and xFormers optimize attention only for new tokens. This block-based approach reduces memory fragmentation, than standard Transformers. . Additionally, you can anticipate even wider caching support across popular frameworks as these research advances develop. Framework Support (Hugging Face, DeepSpeed, etc.): use_cache=True huggingface.co. arxiv.org blog.vllm.ai lowers overhead to under 4%, and delivers up to 24× higher throughput blog.vllm.ai Caching can greatly improve performance in retrieval-assisted LLM pipelines, such as question answering over a vector database. You can cache retrieved passages, final answers, or embeddings for semantically similar queries rather than using similarity search to retrieve new documents and calling the LLM each time. For example, the 2025 Proximity layer by Malladi et al. reduces retrieval latency by up to 59% with negligible accuracy loss by reusing passages for near-duplicate queries. . Caching retrieval results reduces the load on vector engines and scales systems because many user queries overlap (Chaidez, 2025). Caching query outputs is advised by providers such as Redis and Pinecone. In the end, caching saves duplicate embedding or retrieval effort for frequently asked or comparable queries. Retrieval-Augmented Systems (RAG and Vector DBs): rohan-paul.com These are addressed by caching in the case of serverless LLM deployments (a.k.a. AWS Lambda) and edge scenarios (on-device or in-browser LLM inference) that need to mitigate expensive cold-starts and tight resource limits. For serverless setups—in which models do not persist between invocations—an external store (like Redis or DynamoDB) enables the completion of each function call to check previous outcomes, so that redundant work can be skipped. There is potential to cache recent inferences or embeddings (e.g., user names, common commands ) on things like smartphones or small IoT type edge devices, to reduce latency and save battery. While limited memory and privacy will be a consideration, optimized should start to appear soon for ultra-efficient edge inference. Serverless and Edge Deployments: compressed caches Production-scale LLMs exceed single-GPU or machine capacity, so distributed inference requires caching. Typically, each model shard caches the key/value states for tokens it processes. When a new token arrives, parallel shards coordinate to fetch and update their cached states, avoiding redundant recomputation and memory overhead. Libraries like DeepSpeed and FasterTransformer implement this: with pipeline parallelism, each stage caches its outputs to avoid recomputing all layers per token. Tensor parallelism shards KV , to synchronize new keys/values and maintain consistency across devices. Caching and Model Parallelism: caches across GPUs using cross-GPU protocols Distributed KV caching by limiting work to new computations. One whitepaper noted that without caching, shipping the full context for each inference during distributed execution incurs prohibitive network hops. Caching keeps context local, making large-model inference across multiple machines practical. dramatically reduces inter-node communication and idle time gebruik_cache = waar Kortom, moderne AI-stacks is meer en meer so "cache-aware. Hoger vlak stelsels begin om dit te internaliser, van biblioteke wat sorg vir die meganiese vir jou tot stelsel-architektuur wat caches oor versoek en infrastruktuur deel. Caching is iets wat die meeste LLM-dienste sal gebruik, want dit is wat die groot spelers in AI (OpenAI, Google en Microsoft byvoorbeeld) het gepraat of gedoen in hul onderskeie LLM-aanbiedings. Sommige spesifikasies is bekend soos OpenAI se ChatGPT (nie openbaar gedokumenteer nie, maar hierdie gebeurtenis in die besonder is beskryf) vermoedelik gebruik groot skaal gesprek konteks caching; Anthropic se Claude se span (komende volgende...) het 'n gebruiker-visible feat, cached promp Performance Metrics and Evaluation Prestasie meters en evaluering Goed, in teorie caching mag wonderlik klink, maar hoe kan ons dit meet? Daar is min van die algemene prestasie metrikes wat jou help om die doeltreffendheid van LM caching te evalueer Laer latensie: Minder latensie: Die hoofvoordeel is minder latensie, wat die tyd is wat dit neem om 'n antwoord te kry. Caching verander die prestasiekurve: 'n primed cache bied jou konsekwent hoë deurvoer en lae latensie. Ons doen dit deur te kyk na die tye wat dit neem om versoekings met en sonder cache te maak. 'n chatbot wat gewoonlik 2 sekondes neem om 'n vraag te beantwoord, sal in 0.2 sekondes terugkom as dit die cache tref, wat 90% vinniger is. Die werklike versnelling hang af van die hit koers. Byvoorbeeld, as 80% van die hits 1000 keer vinniger is, sal die algehele latensie baie beter wees. Teams praat dikwels oor p50 en p95 latensie met en sonder caching. Deur caching konteks Anthropic Dit is omdat caching berekening bespaar deur nie weer dieselfde berekenings te hoef te doen nie. Die DenseNet benchmark vir NVIDIA Triton het van 80 tot 329 inf/sec (ongeveer 4×) gegaan en ligter modelle het ongeveer 20% winste gesien met reaksie caching. rohan-paul.com. Wanneer dit kom by LLM bedien, gebruik vLLM se PagedAttention slimmer KV-cache bestuur om groepverzoeke beter te hanteer, wat beteken dat dit tot 24 keer meer versoekings kan hanteer as Hugging Face Transformers. vLLM Blog. In situasies met meer as een gebruiker, is die meting van deurvoer baie belangrik. Caching help om verkeersspike te voorkom en hou die bediener nie te vol te word nie. Compute/Cost Savings: Dit is die dollar-en-sent uitkoms van caching. Aangesien caching ook op redundante berekening sal spaar, spaar dit eintlik FLOPs wat geld is (byvoorbeeld wanneer jy deur die GPU-uur of API-oproep betaal). Die algemene metric vir hierdie is GPU-gebruik en selfs totale berekening tyd bespaar. Byvoorbeeld, Antropic beweer dat in langer gesprekke, prompt caching die token verbruik (dus koste) met 90% kan verminder (Anthropic, 2024), anthropic.com. Dit is ook weerspieël in die prysstelsel - met behulp van cached tokens kos 'n bestelling magnitude minder as om hulle te genereer van scratch. bdtechtalks.com. As jy Hit Rate en Miss Penalty: Dit is cache-spesifieke metrikes. Hit rate: Die persentasie van versoekings (of tokens) wat deur die cache vervul is Hoër hit rate beteken beter prestasie winste in die algemeen. Hierdie is nuttig om te rapporteer, soos “ons stelsel het 'n 60% cache hit rate op oproepe in prod (X eintlik X teen Y sonder cache). Die miss penalty is hoeveel stadig 'n cache miss vs hit. Met ander woorde, sommige van die tyd die byvoeging van 'n cache stel 'n bietjie oorhead in (bv. berekening van 'n embedding vir semantiese soektog, of 'n bykomende netwerk hop om 'n verspreide cache te kyk) - as die miss nog die volle draai model plus hierdie oorhead, dit is nog ' Memory en Overhead Trade-offs: Caching behou modeluitvoer of tussenliggende toestande, wat meer GPU RAM gebruik. Vir lang kontekste groei KV-cache in 'n regstreekse lyn. Byvoorbeeld, 'n 405 B-model-cache vir 16 k-tokens kan ongeveer 15 GB (ongeveer die helfte van die modelgrootte) gebruik. GitHub. Gebruik metrikke soos "memory overhead per bykomende token" of "cache-size ratio's" om die trade-offs uit te vind. Met behulp van tegnieke soos multi-query aandag, kan jy cache van tien gigabytes tot 'n paar honderd megabytes sny. Dit is 'n 97% vermindering vir 16 k-sequences met 'n klein verlies van akkuraatheid. hugging Precision/Quality Impact: Die model se uitvoer moet nie verander nie (behalwe as dit met 'n potensieel ligte vertraging resultaat dien) as gevolg van caching. Maar in sekere caching modelle (namens die wat ongeveer of semantiese is), kan 'n reaksie uiteindelik nie perfek afgestem word van die nuwe query nie. So, ons kan sien of caching 'n kwaliteitstoot veroorsaak of nie. Spesifiek, as ons semanties relevante query's vir die nuwe query caching en die antwoord van die nuwe query moet nog korrek wees, so kan ondersoek word as akkuraatheid of relevansie score. In die akademiese gemeenskap, dat gehalte maatreëling word dikwels genoem as die "hit rate"—dws wat persentasie van cached antwoorde korrek was? Dit is Vergelyking met Baselines: Navorsers vergelyk gewoonlik 'n verbeterde caching model met 'n baseline model sonder caching om die wins te meet. Die kan ook bespreek vergelykings van verskillende caching metodologieë. Byvoorbeeld, akkuraat-match caching vs. embedding-gebaseerde caching vs. geen caching in 'n dataset van queries, met latensie en akkuraatheid vir wat. vLLM vs vanilla HF server Throughput & Memory. Hierdie vergelykende studies bereken spesifikasies om die intuïsie te bevestig dat caching as 'n duimregel is 'n goeie idee. 'n Voorbeeld resultaat kan wees: caching verbeter deur 2× en latensie deur 40%, ten koste van 'n ekstra GB (gabyte) vir cache, versus nie-cache bas As ons LM caching evalueer, is dit belangrik om kompromisse te weeg waar jy op rekenaar kan spaar, maar ten koste van meer geheue; laer eindlatensie, maar moet af en toe stilstandige antwoorde hanteer. Daarom is dit noodsaaklik om te kyk na metrikes soos die een hierbo in kombinasie. byvoorbeeld, 'n 5% risiko van 'n antwoord wat 'n bietjie out-of-date is, kan die moeite werd wees om jou resultate 10x vinniger te kry - of dit mag nie wees (mediese advies versus casual chit-chat het verskillende stappe!). Beide akademiese dokumente en industrie-verslae begin om caching in hul benchmarks in te sluit, wat sin maak as gevolg van die wye uitrusting van caches. In 'n latere opname van 2024, is daar waargeneem dat byna alle top-aanleggings aan lang-kontekst LLM-taak afhanklik was van 'n vorm van caching of aandag optimalisering om effektief met kontekslengte te hanteer (Chen et al., 2024). Die getalle is konsekwent groot oorwinnings. Simpel gestel: caching verminder latentie, verhoog deurvoer en verminder koste per query deur beide nuwe query's vinniger te bedien en dubbele werk te vermy. Sonder hierdie optimalisering, enige beoordeling van die LLM dien sou ver van voltooi wees. Rooibos.com Real-World Case Studies Reële wêreld case studies Ons weet almal dat caching nie net vir die sake van 'n akademiese argument is nie, en hierdie funksies bring tastbare waarde in die praktyk. Conversational AI (Chatbots/Assistants): In plaas daarvan om die volledige geskiedenis elke keer weer te kodeer, cache multi-turn chat LLMs vorige gesprekke. Byvoorbeeld, hulle cache die eerste gebruikersvraag en assistent antwoord sodat slegs nuwe invoer op latere vrae verwerk word. huggingface.co. Dit laat stelsels soos ChatGPT reageer vinnig sonder om al die wiskunde weer te doen. Met caching geaktiveer, laat Anthropic se Claude 3 ontwikkelaars lang-lewe kontekste, wat latensie met 79% verminder en koste met 90% op 'n 100k-token oproep. (Anthropic, 2024) anthropic.com. Xiaoice van Microsoft red ook scene antwoorde sodat dit nie dieselfde beleefde dinge oor en oor hoef te sê nie. Kode voltooiing en ondersteuning: GitHub Copilot en TabNine gebruik caching om kode voltooiing te versnel. Die model sal die hele konteks weer moet verwerk elke keer as jy 'n sleutel druk, wat dit baie stadig sal maak. In plaas daarvan stoor hulle die model se verteenwoordiging van die voorvoegsel in 'n cache sodat slegs bygevoegde karakters verwerk word. Dit word voorvoegsel caching genoem. Baie kodeer oproepe herhaal hulself (soos Fibonacci), so prompt-vlak caching gee jou dieselfde vrae onmiddellik. Dit hanteer ook dieselfde ontwikkelaar vrae oor sessies sodat hulle onmiddellik gebruik kan word. In 'n forum, kan 'n LLM gewilde Q&A paartjies stoor (of fine-tune en stoor hulle) Enterprise "Copilot" Assistent: Baie maatskappye implementeer AI-assisteure vir interne - soortgelyk aan AI-copilote wat help om dokumente op te stel, e-pos ontwerpe te maak, bespreek besigheidsvrae uit interne data, ens. Dit loop gewoonlik oor 'n vooraf gedefinieerde kennisbasis (maatskappy dokumente, wikis, verslae) Caching is ook baie waardevol hier, op baie lae: jy kan interne dokumente inboude cache om hulle vinniger terug te gee; jy kan 'n paar algemene interne query antwoorde cache ("hoe kan ek 'n uitgaansverslag lê?"). Hulle kan selfs cache word sodat ons nie 'n paar resultate weer genereer nie, of gedeeltelike resultate soos opsomming van dokumente - as twee mense 'n opsomming Multi-turn Tools/Agents: Caching kan kortsluiting loop in die komplekse AI-agentstelsels (soos 'n agent wat 'n taak beplan deur middel van verskeie LLM oproepe, en gereedskap gebruik). Dink nou aan 'n agent wat vrae beantwoord deur 'n webdiens te query en resultate te verkry om te gebruik as invoer vir 'n LLM. In so 'n geval, as dieselfde vraag weer gevra word, kan die agent die vorige antwoord direk uit sy cache kry (in plaas van die herroeping van die gereedskap) of sê moontlik hergebruik enige soek resultate (cache gereedskap outputs sowel as LLM outputs). Dit is gekorreleer met die konsep van planner caches of resultate tool caching. Intermediêre oproep resultate word deur projekte soos LangChain Grootskaalse Internet Dienste: Dit is veral waar in die geval van soekenjins wat drasties kan baat kry by die caching van LLM antwoorde. Byvoorbeeld, Bing Chat dien miljoene gebruikers en daar is baie herhaalde versoekings. As die LLM backend van Bing (wat is GPT-4) caches antwoorde op gewilde vrae ("Wat is die hoofstad van X", "Hoe om pancakes te maak"), kan dit hulle onmiddellik terugdraai in plaas van om elke keer van die nul te genereer. In werklikheid, Bing se nie-LLM soek het eintlik gebruik van query caching vir dekades; met LLM antwoorde wat ontstaan, sien ons nou presies dieselfde patroon. Navorsers het net 'n stelsel getoon wat een keer gevind het resultate vir 'n soek, caches hulle dat In Augustus 2024, Antropic se bedieners kan groot, onnodige kontekste stoor, soos 'n boek (100,000 tokens). Skryf na die cache kos 25% meer per invoer token, maar die lees van cached inhoud kos slegs 10% van die basiese tarief. Die eerste oproep red data; die volgende oproepe gebruik die prompt ID om dit te vind en stuur slegs nuwe inhoud. Kliënte het gesê dat antwoorde tot vier keer vinniger was (latensie het van 11,5 sekondes na 2,4 sekondes gegaan) en dat die en die koste van 10,000-token prompts het met ongeveer 86% gedaal. Gespreksagente, kodering helpers, en groot-dokument Q&A is al algemeen gebruik, en 'n stabiele konteks is die beste vir cache hits. Anthropic het caching 'n sterk besigheid geval deur verbetering van prestasie te kombineer met finansiële aansporings. Anthropic's Claude 3 added Prompt Caching Antropiese cost of 100,000-token prompts went down by 90% Antropiese Nog ’n geval: OpenAI het nie openbaar enige van hierdie voorbeelde uitgewerk nie, maar iemand kan wonder of die ontwikkelaars fijn aangepas en / of 'n paar foto's teks in elke versoek verskaf het nie, dat deel van die bediener se kant kan cache word sodat die model nie elke keer die voorbeelde van nul af hoef te her-kodeer nie. dit is analoog aan die benadering van Anthropic. byvoorbeeld. as jy dieselfde 2000 token stelsel prompt + instruksies op elke API-oproep stuur (wat baie doen), sal OpenAI die model embedding van wat daarin ingebring word, cacheer en net met jou query verwerkte verteenwoordiging verbind. OpenAI's system messages and few-shot examples caching Alhoewel OpenAI, Anthropic, Microsoft, Google en Hugging Face almal op 'n oomblik bespreek of gedokumenteer caching strategieë met verskillende leerresultate as gevolg, deel die meeste van hierdie dieselfde gevolgtrekking: caching bied 'n reuse prestasie boost, maar dit word belangrik om cache varsheid te bestuur sonder om geheue en skaalbaarheid te offer. Stories van "ons het 'n cache gedruk en sien 30% vermindering in ons GPU gebruik terwyl die QPS intact hou" is nie ongehoorsaam nie. caching is the ticket to turbocharging LLM applications. Challenges and Limitations Uitdagings en beperkings Natuurlik, caching is nie 'n silwerballet nie. Dit is natuurlik 'n bietjie trivial - as dit maklik was, sou almal al die dinge uiteindelik cacheer! Daar is talle uitdagings en beperkings in die praktyk wat ingenieurs moet doen wanneer hulle die LM-caches implementeer: Cache Invalidation (Stale Data): Wanneer die onderliggende data of 'n LLM-update die betekenis van 'n reaksie verander, word cached outputs stabiel, net soos webcache-invalidasie probleme. 'n naïeve oplossing is om al die cache's te verwyder wanneer die model opgedateer word. Dit is maklik maar verskriklik, want dit verwyder inskrywings wat nog geldig is. Sommige mense gebruik die "as nie gevind word nie, kry nuut" reël, maar dit kan veroorsaak dat hulle nuttige data verloor. Dit is beter om items 'n tyd-tot-lewe (TTL) waarde te gee sodat hulle na 'n sekere hoeveelheid tyd verval, of om versie cache sleutels deur model-ID of parameters te verwyder sodat jy Stale konteks in Dialoog: Wanneer die konteks later in 'n multi-turn chat verander, kan cached antwoorde staar. Byvoorbeeld, as jy 'n antwoord op vraag A spaar en dan die gebruiker meer inligting byvoeg, kan dieselfde antwoord weer gebruik om belangrike veranderinge te mis. Om dit te stop, caches dikwels die volledige gesprek ID, nie net die nuutste oproep, of hulle caches slegs korter dialoogbereik. In plaas van die spaar van hele antwoorde, kan jy kort, konteks ryk samestellings te red. Dit verminder die risiko dat hulle verouderd word. Dit is nog steeds moeilik om caches goed te bestuur. Konservatiewe beleid (slegs die bewaring van inskrywings wat onwaarskynlik verander) of dinamiese validering (soos hashing sleutel Prompt Variabiliteit en Uniekheid: LLM's gaan dikwels met baie verskillende inputs, so naïeve caches werk nie baie goed nie. Byvoorbeeld, kreatiewe generasie-programme wat jou vra om 'n gediens oor X in die styl van Y met twist Z te skryf, kry byna nooit enige treffers sonder semantiese caching nie. Semantiese caches probeer om te veralgemeend deur te pas inbeddings, maar hulle werk slegs wanneer queries baie soortgelyk is. rohan-paul.com. Die voordele van caching hang af van werkloosheid. KV caches is altyd nuttig vir lang outputs, maar ad-hoc volle reaksie caching werk nie goed as geen twee queries dieselfde is nie. Deel- of modulêre caching, wat beteken dat outputs in herbruikbare dele soos Memory Footprint: Caches gebruik baie geheue, óf RAM of GPU, want KV caches vir lang konteks kan so groot wees as die model self. huggingface.co. Response caches kan ook te groot word, wat beteken dat hulle moet versprei na die CPU of skyf. Dit beteken dat jy moet kies tussen kapasiteit en model grootte of batch deurvoer. Byvoorbeeld, as jy 20 GB van 'n 40 GB GPU vir die cache afstel, sal daar nie soveel ruimte vir groter modelle of om meer versoek te hanteer nie. Om hierdie probleem te hanteer, navorsers kompres KV tensors (Shutova et al., 2025) arxiv.org of kwanties hulle (4-bits teen 16-bits output ~4× geheue besparing). Die AQUA-KV papier van "Cache Me If You Must Kompleksiteit en ingenieurswese oorhead: Caching maak dinge vinniger, maar dit maak dinge ook ingewikkelder. Jy moet draadveilig, lae-latensie maniere instel om inskrywings te stoor, op te kyk, op te dateer en ongeldig te maak, wat dikwels beteken dat u eksterne winkels soos Redis vir verspreide caches gebruik, wat kan misluk. Om seker te maak dat dinge reageer, moet u versigtig ingenieurswese doen, soos met behulp van nie-blokkerende asynchroniese oproepe of slotvrye strukture. Debugging word ook moeiliker omdat onverwagte uitkomste van ou of gebroke cachegegegevange kan kom in plaas van die model self. Dit is hoekom dit belangrik is om goeie logging en waarneming vir cachehits en mislukkings te Sekuriteit en Privaatheid: As dit nie behoorlik bestuur word nie, kan caching sensitiewe oproepe en outputs privaat data openbaar maak. In multi-tender-stelsels, beperk altyd cache-toegang tot versoekings wat goedgekeur is en omvang inskrywings aan een gebruiker of sesie. Caches loop ook die risiko van side-kanaal aanvalle, wat hackers ander mense se vrae sien. Om die risiko te verminder, of versleutel sensitiewe cache-inhoud. Maar, encryption kan semantiese ooreenkoms moeiliker maak. Ook, reëls soos GDPR kan cache AI outputs behandel as opgeslagte data, wat beteken dat hulle verwyder moet word as die gebruiker dit vra. As AI caching meer algemeen word, word hierdie sekuriteit Cache-koherensie in verspreide stelsels: Verspreide cache laat jou toe om kopieë van data te maak, maar dit het probleme met konsekwentheid. Byvoorbeeld, opdaterings of ongeldighede in een instansie word nie altyd gesien deur ander nie, en wanneer twee replika's dieselfde cache op dieselfde tyd mis, moet hulle dalk herbereken en wedloop om dieselfde inskrywing te skryf. Om te stop duplikate, benodig jy atoomoperasies of slotte. Byvoorbeeld, Redis se atoombevelings ondersteun dit. Medium. Om 'n verspreide cache te bou, moet jy óf sterk koherensie protokolle kies of uiteindelike konsekwentheid aanvaar met af en toe stale lees en skryf. Redis. Toetsing en aanpassing van hierdie strategieë word veral moeilik in LLM bedien, waar Tog, die dit vir baie doeleindes. Dus, dit kan nie 'n groot verrassing wees dat byna elke onderneming-spanning LLM diens behels caching van beide een vorm of enige ander, en die verskil is iemand wat hierdie ontwerp werk in om te gaan met die val. Verminder die risiko's: Cache dinge wat nie ultra-sensitief is nie (of net stadig verander) + Gebruik 'n baie van cache invalideringsstrategieë + Hou 'n oog op die hit rate / frame gebruik en het terugval (as iets funky met jou cache gebeur, sal die stelsel werk, dit sal net stadig wees). Ons begin om beter gereedskap en biblioteke te sien om baie van dit outomaties te hanteer (byvoorbeeld, raamwerk vlak encryption cache of outomatiese valideer hooks op model updates). overall performance gains of caching generally significantly exceed Die LLM is uiters kragtig, maar nie gratis soos ons gesien het nie en voeg 'n bykomende laag kompleksiteit by aan die LLMs - die cache. LLM akademici weet nou die eerste!Maar met 'n goeie ontwerp, kan die kompromie bestuur word, en enorme voordele kan gerealiseer word. Daar is slegs twee moeilike dinge in rekenaarwetenskap: cache invalidering en die naam van dinge Future Directions and Research Opportunities Toekomstige rigtings en navorsingsgeleenthede Die LLM-cache-veld is hoogs dinamies, met talle opwindende paaie wat navorsers en ingenieurs ondersoek om sy vermoëns verder uit te brei: Adaptiewe en Intelligente Caching: Masjienleer kan help met caching- en verwyderingsbeleid. Byvoorbeeld, RL-agente probeer om die langtermynbelonings (hit rate × korrekte). Hulle kan data voorverwyder wat hulle dink hulle sal nodig hê, soos OS-lees-voor-lees, cache gewilde resultate tydens drukke, en ontslae raak van inskrywings wat nie baie waardevol is nie. Spekulatiewe uitvoering gebeur wanneer caches aktief bereken en data wat waarskynlik sal gebeur. LLM-gebaseerde meta-leer kan raai wat tussenliggende berekenings duur sal wees en hulle in 'n cache stoor. Versterkende leer kan ook verwyder deur inskrywings te verwyder wat nie waarskynlik in die toekoms nuttig sal wees nie. Dit sluit Cache Compression en Efficient Storage: Quantization en skraap is twee metodes wat cache slim gebruik. AQUA-KV komprimeer KV tensors tot slegs 'n paar bits met min verlies van gehalte (Shutova et al., 2025). Pruning, soos drop stopword KV's, verwyder invoer wat nie nodig is nie. In lang kontekste hou Anchor Attention slegs "ank" token KV's en komprimeer die res (Sun et al., 2024). Eksperimentele "verlies" caches neem vektore wat soortgelyke is en kombineer hulle in een. Hoë-bandbreedte geheue of opslagklas geheue (Optane) kan KV caches met P99 latency trade-offs op die hardeware versprei. Dit kan lei tot die opkom Cross-Modal en Cross-Domain Caching: Multimodale LLM's en selfs video-vertaling benodig spesiale caching. Byvoorbeeld, die bewaring van beeld embeddings laat jou toe om die herverwerking van beelde wat jy al gesien het, te slaag, en caching gepasde audio-snippets maak spraakassistente vinniger. Vir elke tipe data benodig jy 'n ander strategie. Byvoorbeeld, perseptuele hashes vir beelde en klank vingerafdrukke vir klank. Federated caching oor randtoestelle kan gemeenskaplike resultate privaat deel, wat in ooreenstemming is met federated learning se privaatheidsgaranties. Soos 'n globale lesercache vir AI-assistente, laat gemeenskaplike caches baie gebruikers of toestelle toe om 'n gedeelde pool te Caching in Opleiding en Fine-tuning: Caching kan ook gebruik word vir opleiding en Fine-tuning LLMs, nie net vir inferensie nie. Om skyf I/O te vermy, hou groot-skale hardloop reeds tokeniseerde datasets in geheue. Opleiding-tyd caches stoor tussenstande op 'n meer innoverende manier. Byvoorbeeld, multi-task modelle kan die verteenwoordiging van 'n volgorde oor take gebruik in plaas daarvan om dit weer te stuur. Die stoor vooroordele of gradiente wat dikwels in 'n caches gebruik word, verminder ook onnodige berekening. Dit help hoofsaaklik met navorsing, maar dit verminder ook koste in voortdurende leer of RLHF deur stappe wat herhaal word, te skip. Google se Retro (202) het 'n Cache Governance en Kwaliteitsbeheersing: Nog 'n belangrike verandering wat in die toekoms moet plaasvind, is gereeld te kyk na cachede antwoorde om die gebruikerservaring goed te hou. As 'n LLM se cachede antwoorde skaars deur die filters gegaan het, kan gebruikersfeedback, soos herhaalde heruitdrukking, beteken dat dit moet verander of verwyder word. Dit sal 'n terugvoerloop skep wat die cache voortdurend verbeter en dit in 'n lewende kennisbasis verander. Geplandeerde agtergrondwerk kan die boonste cache-aantekeninge herbereken en actualiseer as die onderliggende model heroplei of fijn aangepas word. Op hierdie manier kry gewilde antwoorde beter geslagte. Hierdie metode is soortgelyk aan hoe soekmasjins cachede bladsye ver Standaardisering en Cache API-lae: Dit sal ons nie verras as ons gestandaardiseerde lae in die masjienleringstapel kan sien wat spesifiek vir caching georiënteer word nie. Op die oomblik moet elke raamwerk of aansoek sy eie cache-logika skep. Miskien kan ons, maar iemand kan 'n paar "Caching API's" van soorte voorstel wat modelverskaffers of bedienende raamwerke bied en ontwikkelaars toelaat om hul aangepaste logika in te sluit (byna soos cache-plugins met webbedieners). Byvoorbeeld, OpenAI of ander verskaffers kan API-parameters verskaf om cache-effektiwiteit aan- en uit te skakel, miskien definieer die vlakke van aggressie in die bou van cache hits, of Cache - skraap So, dit blyk dat die toekoms van LM caching is redelik sonlig en vol nuwe oplossings. In die algemeen, die impetus is duidelik: as ons groter modelle vir groter aantal gebruikers uitbrei, is 'n caching strategie 'n maklike plek om 'n bietjie slak te kry. Die volgende iterasies sal verbeter caching (leer-gedrewe), verminder die gewig (kompresie en beter bestuur binne die geheue), en maak dit meer oorweldigend oor verskillende modaliteiteite en vir opleiding/inferensie.* So dit is 'n Arms-race, nie net om groter modelle te bou nie, maar om hulle slimmer te bedien._* Deur hierdie, die caching en doeltreffendheid verbeterings is hoekom LLMs soos GPT-4 en Llama-2 so vinnig kan Vanaf hier, miskien diegene met die mees aggressiewe cachestrategie kan potensieel die titel van die aanbieding van die vinnigste en uiteindelik goedkoopste AI-dienste wen. Kies vir.co Verwysings : Antropiese. (2024, 14 Augustus) Geskryf deur Anthropic News: Snel saam met Claude. Antropiese.com Antropiese.com Hinton, G., Vinyals, O., en Dean, J. (2015). NIPS diep leer en verteenwoordiging leer Workshop. Distilleer kennis in 'n neurale netwerk. Lewis, P., et al. en ander (2020). Vooruitgang in neurale inligting verwerkingsstelsels. Verhoogde generasie vir kennisintensiewe NLP. Paul, R. (2025 op 20 April) Die blog van Rohan's Bytes Caching Strategies in LLM Dienste vir beide opleiding en gevolgtrekking. Rooibos.com Rooibos.com Pol, S. (2025 op 6 April) Die medium blog. Versnel Transformer Inferensie met KV Caching. Ek is op die 522.medium.com. Ek is op die 522.medium.com. Oor die lewe, N. (2019) arXiv:1911.02150 van die jaar . Vinnig transformer dekodeer: Een skryfhoof is alles wat jy nodig het. Geskryf.org Shutova, A., Malinovskii, V., Egiazarian, V., et al. (2025). ArXiv:2501.19392 van die jaar . Cache Me If You Must: Adaptive Key-Value Quantization vir groot taalmodelle. Geskryf.org Yazdani Aminabadi, R., Rajbhandari, S., Zhang, M., et al. (2022). Tydens 202300032 . DeepSpeed Inference: Maak doeltreffende inferensie van Transformer modelle op 'n ongekende skaal moontlik. Geskryf.org Kwon, W., Li, Z., Zhuang, S., et al. (2023). Procedure van die SOSP 2023 . Effektiewe geheue bestuur vir groot taalmodel met PagedAttention (vLLM). die blog.vllm.ai die blog.vllm.ai Hugging Face Transformers se span (2023). Blog oor die gesig. Optimaliseer jou LLM in produksie. Kies vir.co Kies vir.co Lorello, S., McCormick, R., en Partee, S. (2023). Nvidia se tegniese blog Hoe om 'n Verspreide Inference Cache te bou met NVIDIA Triton en Redis. (Aanvullende verwysings vir akademiese strengheid en volledigheid kan ingevoeg word indien nodig om al die citasies hierbo te ooreenstem.)