Kuboresha utendaji wa LLM na Cache ya LM: Miundombinu, Mkakati, na Maombi ya Dunia ya Kweli

Abstract Abstract ya Makala hii inatoa mtazamo wa kina wa utafiti wa kiufundi wa kazi ya Cache ya LM na jinsi mashine ya caching inaboresha ufanisi, uwezekano wa kupanua, na kupunguza gharama za utekelezaji wa Model ya Lugha Kuu (LLM). Tunajifunza aina tofauti za usanifu wa caching na taratibu, jinsi zinaweza kuunganishwa pamoja na miundombinu mpya ya AI na kutathmini kwa utendaji. Mifano kutoka kwa uwanja unafafanuzi jinsi baadhi ya wateja wetu wakubwa wanatumia Caches ya LM katika vitendo na kile wanajifunza wakati huo. Introduction Maelezo ya Fikiria msaidizi wa AI ambaye anapaswa kutoa majibu sawa kila siku kwa mamia ya wakati! Hiyo si matokeo, inapaswa kuzalisha majibu yote kutoka kwenye msingi, mara kwa mara? Wakati LLMs (fikiri GPT-4, PaLM, nk) ni kubadilisha kila kitu kutoka kwa msaada wa wateja hadi kuzalisha msimbo wao. Katika uzalishaji, kila swali kwa mfano mkubwa inaweza kuwa na gharama ya sekunde na kompyuta kubwa ya GPU. Kama ukubwa wa mfano na matarajio ya mtumiaji yanaongezeka, haja ya ufuatiliaji wa haraka inakuwa muhimu zaidi kuliko hapo awali. deployment at scale is stymied by latency requirements, computational cost and memory footprint Kwa kuzingatia yote haya, cache ya LM inaonekana kama jibu la busara sana kwa matatizo haya kwa kuhifadhi na kutumia tena matokeo yaliyokusudiwa tayari. Caching ni kimsingi ambayo inawezesha mfumo wetu kukumbuka kila kitu ambacho imekuwa akiona kabla. Wazo la jumla la dhana sio mpya katika sayansi ya kompyuta, lakini imekuwa na uvumbuzi wa uwezekano katika LLM yenyewe kwa upungufu mkubwa sana na kupunguzwa kwa muda wa majibu. Kama vile destillation ya mfano (kuunda mifano ndogo, ya haraka), uzalishaji wa upatikanaji (kuongezeka juu ya misingi ya maarifa ya nje), na database ya vektor kwa ajili ya utafutaji wa semantic, LM Cache huongeza mbinu zingine za kuboresha. Pamoja na kiwango cha mwisho cha mekanisms Foundations of LM Cache Msingi wa LM Cache dhana ya ni tu reuse kompyuta kwa ajili ya si overwork. Katika kesi ya LLM inference, caching inaweza kuwepo katika ngazi tofauti ya granularity: 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 us_cache = ya kweli Mwisho wa KV Mwisho wa KV Mfano wa Decode_Next Vitu vyote vilivyotajwa hapo juu vinatumia kanuni ya moja kwa moja ambayo Kwa sababu ya utaratibu wa kujitegemea, hesabu ya kila token mpya katika LLMs ya msingi ya transformer mara nyingi inategemea tokens ya awali. Kama katika ngazi ya haraka au ndani ya mfano, kuhifadhi matokeo ya hesabu hizi za awali inaruhusu shughuli za baadaye kushuka moja kwa moja kwa matokeo ya mwisho. Kuboresha muhimu katika kasi na matumizi ya rasilimali hutokana na hili. system shouldn't re-compute what you have already done LM Cache Architectures and Strategies LM Cache Miundombinu na Mkakati Kwa kuwa si kazi zote ni sawa katika mifumo ya LLM, idadi kubwa ya miundombinu na mikakati imekuwa iliyoundwa na wahandisi ili kuongeza hit cache na kupunguza overhead. Statistical vs. Dynamic Caches: Statistical Caches zinakuja na wanandoa wa input / output zilizopangwa kabla, ambayo inafanya kuwa nzuri kwa mizigo ya kazi inayoweza kutabiri. Hizi ni ufumbuzi wa caching kwa maswali ya kawaida au ufumbuzi wa haraka, kama FAQs au majibu ya kesi ya majaribio. Caches ya Dynamic, kwa upande mwingine, hujaza kama mfumo unaendesha, kubadilisha mifano ya trafiki, kubadilisha usambazaji wa query, na kiwango cha matumizi. Wao kwa kweli "kujifunza" kutoka kwa trafiki ya mtumiaji ili kuboresha viwango vya hit. Katika maisha halisi, mifumo ya kupunguza caching ya nguvu kwa kutumia sera za kuondolewa kulingana na mahitaji ya sasa, ambayo hupoteza bidhaa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utaratibu wa Utarat Kuhifadhi kwa kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha kiwango cha chini cha ki Cache Granularity na Key: Kuchagua kiwango cha cache ni hatua ya busara. Kiwango cha ufanisi cha kifungo kwenye mstari wa prompt kamili ni rahisi kutumia, lakini huanguka kwa urahisi—mabadiliko yoyote hupoteza kifungo. Ili kupata matukio zaidi, mifumo hutumia kifungo cha semantic cha msingi cha kuingizwa ambacho hutafakari maagizo kama sawa hata kama maandishi ni tofauti, au kifungo cha prefix / chunk ambacho kinafanana na vipengele vya kuunganisha. Baada ya usindikaji wa kifungo cha imara, "caching ya prefix" huchukua snapshot ya hali ya KV ya mfano. Kwa njia hii, kifungo kipya ambacho huanza na kifungo hiki kinaweza haraka kuhamia hali hiyo. Mradi wa vLLM Sera za ukubwa wa Cache na Kuondolewa: Kwa sababu kumbukumbu ya cache ni mdogo, LLM hutumia sera kama LRU au LFU ili kuamua ambayo machapisho kuhifadhi na ambayo kuondolewa. Hii hutoa nafasi kwa data mpya. Mbali na kuondolewa vitu kulingana na umri au mzunguko, cache ya LLM pia inahitaji kukabiliana na kuondolewa kwa umuhimu na mfano au upyaji wa data kwa kuondoa vitu vya zamani. Katika 2024, utafiti ulionyesha kwamba kuondolewa kwa kujifunza inafanya kazi: cache ambazo zilifundishwa kupata na kuondolewa kwa kifungo na thamani ndogo ya baadaye (Xiong et al., 2024). Hizi mifumo ya kuondolewa ya "intelligent", ambayo inafanywa kwa kazi za LLM, labda itakuwa kanuni Kwa kifupi, kujenga cache ya LM ni usawa mzuri: Tunataka kuongeza kiwango cha hit wakati kupunguza upungufu kama vile matumizi ya kumbukumbu na volatility. Ikiwa hii inamaanisha unahitaji kufanya kazi na mifumo hiyo ya tafsiri ya mashine ngumu zaidi, basi uwe mgeni wangu! Mkakati huu (static vs. dynamic, usambazaji wa usambazaji, kuvutia katika cache iliyopigwa kwenye terminology kwa kuunda wakati wa mteja na lugha za mfano wa zamani) ni vidokezo ambavyo vinaweza kukusaidia kufanya zaidi na caching bila kuanguka juu ya mashambulizi yanayohusiana na cache. Maombi tofauti yanaweza kuchanganya mbinu hizi na kutumia Kwa mfano, mfumo wa uzalishaji unaweza kutumia kwenye ngazi ya maombi cache ya semantic (kwa mfano wakati maswali ya Mchoro wa usanifu wa LM Cache katika LLM Inference Pipeline Hapa chini ni usanifu wa msingi unaonyesha ushirikiano wa LM Cache ndani ya mtiririko wa kawaida wa LLM: Diagram ya mchakato wa kazi ya kulinganisha Cached vs. Maombi ya Inference yasiyo ya Cached Ili kuelewa zaidi faida, fikiria kulinganisha mtiririko wa kazi kati ya maombi ya ufuatiliaji yaliyopangwa na yasiyo ya ufuatiliaji: Ushirikiano na miundombinu ya kisasa ya AI Caching LM haina kukaa peke yake - itatoka kwenye mazingira ya maombi makubwa zaidi katika AI. Hapa tunazingatia jinsi caching inavyofaa katika miundombinu mbalimbali na miundombinu: 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 us_cache = ya kweli Kwa muhtasari, vichaka vya kisayansi vya AI vya kisasa vinatumia zaidi na zaidi "kumbukumbu. Miundombinu ya ngazi ya juu huanza kuingiza hii, kutoka kwenye maktaba zinazohusika na mechanics kwa ajili yako hadi kwenye usanifu wa mfumo unaoshiriki caches katika maombi na miundombinu. Caching ni kitu ambacho huduma nyingi za LLM zinatumia, kwa sababu hii ni nini wachezaji wakubwa katika AI (OpenAI, Google na Microsoft kwa mfano) wamezungumzia au wamefanya katika mapendekezo yao ya LLM. Baadhi ya maelezo yanajulikana kama ChatGPT ya OpenAI (hakuna makaratasi ya umma lakini tukio hili hasa inajulikana) inawezekana kutumika katika mazingira ya mazungumzo ya kiwango kikubwa; timu ya Claude ya Anthropic (kuja baadaye...) ilit Performance Metrics and Evaluation Ufanisi wa Metrics na Tathmini Ok, katika nadharia caching inaweza kuonekana ya kushangaza lakini jinsi gani tunaweza kupima? Kuna wachache wa viwango vya kawaida vya utendaji ambayo husaidia kutathmini ufanisi wa caching ya LM Lower Latency: Less Latency: Faida kuu ni latency kidogo, ambayo ni muda unachukua ili kupata jibu. Caching husababisha mabadiliko ya mzunguko wa utendaji: cache iliyotengenezwa mara kwa mara hutoa upatikanaji mkubwa na latency kidogo. Tunafanya hivyo kwa kuzingatia wakati unachukua kufanya maombi na bila cache. Chatbot ambayo kwa kawaida inachukua sekunde 2 kujibu swali itarudi katika sekunde 0.2 ikiwa inashuka cache, ambayo ni 90% haraka zaidi. kasi halisi inategemea kiwango cha hit. Kwa mfano, kama 80% ya hits ni mara 1000 haraka, latency jumla itakuwa bora zaidi. Timu mara nyingi kuzungumza juu ya p50 na p95 latencies na na bila caching. Kwa caching mazingira Anthropic, aliona hadi 85% chini ya latency Kuboresha kwa njia: Kwa kuhifadhi, upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji wa upatikanaji Kwa sababu caching pia itaokoa juu ya hesabu ya upungufu, kwa kweli hupunguza FLOPs ambayo ni pesa (kwa mfano wakati unalipa kwa saa ya GPU au simu ya API). Mtaji wa kawaida kwa hili ni matumizi ya GPU na hata wakati wa kompyuta jumla kuhifadhiwa. Kwa mfano, Anthropic alidai kwamba katika mazungumzo ya muda mrefu, caching ya haraka inaweza kupunguza matumizi ya token (kwa hiyo gharama) kwa 90% (Anthropic, 2024), anthropic.com. Hii pia ilionyeshwa katika mpango wa bei - kutumia tokens zilizopunguzwa gharama ya ukubwa wa utaratibu chini kuliko kuzalisha kutoka scratch. bdtechtalks.com. Ikiwa unatathmini kwenye mkusanyiko wa mtihani, na bila ya cache, unaweza karibu asilimia ya tokens au shughuli ziliz Hit Rate na Miss Penalty: Hizi ni takwimu zinazohusiana na cache. Hit Rate: Kiwango cha asilimia ya maombi (au tokens) ambayo yalifikiwa na cache Kiwango cha juu cha hit inamaanisha faida bora ya utendaji kwa ujumla. Hizi ni muhimu kwa ripoti, kama vile " mfumo wetu ulikuwa na kiwango cha 60% cache hit juu ya maombi katika prod (X kwa kweli X dhidi ya Y bila cache). Kesi ya miss ni kiasi gani cha chini cha cache miss vs hit. Kwa maneno mengine, wakati fulani kuongeza cache hutoa juu ya juu (kwa mfano, kompyuta kuingizwa kwa ajili ya utafutaji wa semantic, au upungufu wa mtandao wa ziada ili kuangalia cache iliyotolewa) - kama miss bado hufanya mfano kamili ya kuendesha pamoja na juu hii, hiyo ni Kumbukumbu na Overhead Cache-offs: Caching inahifadhi matokeo ya mfano au hali ya kati, ambayo inatumia RAM zaidi ya GPU. Kwa mazingira ya muda mrefu, cache ya KV inazidi kukua katika mstari wa moja kwa moja. Kwa mfano, cache ya mfano wa 405 B kwa tokens 16k inaweza kutumia kuhusu 15 GB (karibu nusu ya ukubwa wa mfano). GitHub. Matumizi ya takwimu kama "memory overhead kwa token ya ziada" au "uhusiano wa ukubwa wa cache" ili kujua mabadiliko. Kutumia mbinu kama vile tahadhari nyingi, unaweza kupunguza cache kutoka mamia ya gigabytes hadi mamia ya megabytes. Hii ni kupunguza 97% kwa mfululizo wa 16k na kupoteza usahihi kidogo. huggingface.co. Ili Ufanisi / Ubora Uathiri: Matokeo ya mfano haipaswi kubadilika (isipokuwa kutumika na matokeo ya uwezekano mdogo) kwa sababu ya kuhifadhi. Hata hivyo, katika baadhi ya mifano ya kuhifadhi (yaani wale ambao ni karibu au semantic), majibu inaweza kuishia si kamili sawa na swali jipya. Hivyo, tunaweza kuona kama kuhifadhi hufanya kupoteza ubora au sio. Hasa, ikiwa tunahifadhi maswali yanayohusiana na semantic kwa swali jipya na majibu ya swali jipya yanapaswa bado kuwa sahihi, hivyo inaweza kuchunguza kama usahihi au ufanisi. Katika jamii ya kitaaluma, kiwango cha ubora kinachojulikana mara nyingi kama "kiwango cha hit"—yaani asilimia gani ya majibu yaliyohif Kulinganisha na Baselines: Watafiti mara nyingi kulinganisha mfano wa kuboresha kuboresha kuboresha kwa mfano wa msingi bila kuboresha kuboresha kupima faida. Wanaweza pia kujadili kulinganisha na mbinu tofauti za kuboresha. Kwa mfano, kuboresha usahihi-match vs. kuingizwa-based kuboresha vs. hakuna kuboresha katika seti ya data ya maswali, na latency na usahihi kwa hiyo. vLLM vs vanilla HF server Throughput & Memory. Masomo haya kulinganisha kuhesabu maelezo ya kuthibitisha hisia kwamba kuboresha kama sheria ya thumb ni wazo nzuri. Matokeo ya mfano inaweza kuwa: kuboresha kuboresha kupitia 2x na latency kwa 40%, kwa gharama ya GB ya ziada (gabyte) kwa kuboresha, vs Ikiwa tunatathmini Caching ya LM, ni muhimu kuzingatia ushindani ambapo unaweza kuokoa kwenye kompyuta lakini kwa gharama ya kumbukumbu zaidi; muda mdogo wa mwisho, lakini unahitaji kushughulikia majibu ya mara kwa mara. Kwa hiyo, ni muhimu kuangalia takwimu kama vile moja hapo juu kwa pamoja. Kwa mfano, hatari ya 5% ya majibu kuwa kidogo ya muda mrefu inaweza kuwa na thamani ya kupata matokeo yako 10x haraka - au inaweza kuwa haina (kushauri wa matibabu vs. chit-chat ya kawaida ina mipango tofauti!). Wote makala za kitaaluma na ripoti za sekta zinaanza kuingiza caching katika viwango vyao, ambayo ina maana kwa kuzingatia utekelezaji mkubwa wa caches. Katika utafiti wa baadaye wa 2024, ilionekana kwamba karibu maagizo yote ya juu kwa kazi za LLM ya muda mrefu yanategemea aina fulani ya caching au uboreshaji wa tahadhari ili kukabiliana na urefu wa mazingira kwa ufanisi (Chen et al., 2024). Idadi ni ushindi mkubwa mara kwa mara. Kwa kusema kwa urahisi: caching hupunguza upungufu, huongeza upungufu na kupunguza gharama kwa swali kwa wote kutumikia maswali mapya kwa haraka na kuepuka kazi ya duplicate. Bila uboreshaji huu, yoyote ya tathmini ya huduma ya LLM itakuwa mbali na kamili. Msisemi Shaykh Rabiy ́ ni Imaam Real-World Case Studies Utafiti wa kesi ya dunia halisi Sisi sote tunajua kwamba caching si tu kwa ajili ya hoja ya kitaaluma, na vipengele hivi hutoa thamani halisi katika mazoezi. Hapa ni mifano kadhaa ya hali tofauti, tu kuonyesha jinsi caching kusaidia : Mazungumzo ya AI (Chatbots / Msaidizi): Badala ya re-coding historia kamili kila hatua, multi-turn chat LLMs cache mazungumzo ya awali. Kwa mfano, wao cache swali la kwanza ya mtumiaji na majibu ya msaidizi ili tu input mpya inashughulikiwa juu ya maswali ya baadaye. huggingface.co. Hii inaruhusu mifumo kama ChatGPT kujibu haraka bila kuwa na kufanya maadili yote tena. Pamoja na caching iliyounganishwa, Anthropic's Claude 3 inaruhusu watengenezaji kuingiza mazingira ya muda mrefu, ambayo inapunguza muda wa kutosha kwa 79% na gharama ya 90% juu ya maombi ya 100k-token. (Anthropic, 2024) anthropic.com. Xiaoice kutoka Microsoft pia husaidia majibu ya Utekelezaji wa Kodi na Usaidizi: GitHub Copilot na TabNine hutumia caching ili kuharakisha utekelezaji wa kanuni. Mfano unapaswa kusindika mazingira yote tena kila mara unapotumia kifungo, ambayo ingekuwa na kufanya ni polepole sana. Badala yake, wanahifadhi uwakilishi wa mfano wa kifungo katika kifungo ili tu wahusika waliohusishwa watatumiwa. Hii inajulikana kama caching ya kifungo. Wengi wa maombi ya coding hujaribu (kama Fibonacci), hivyo caching ya kifungo cha kifungo hutoa maswali sawa mara moja. Pia inashughulikia maswali sawa ya watengenezaji katika majadiliano ili waweze kutumika mara moja. Katika jukwaa, LLM inaweza kuhifadhi wanandoa wa Q&A maar Wasaidizi wa "Copilot" wa Biashara: Makampuni mengi yanatumia wasaidizi wa AI kwa ajili ya ndani - aina kama vile co-pilots za AI ambazo husaidia kukusanya nyaraka, kufanya mapendekezo ya barua pepe, kujibu maswali ya biashara kutoka data ya ndani, nk Hizi kwa kawaida huendesha juu ya msingi wa ujuzi uliopangwa (docs ya kampuni, wikis, ripoti) Caching ni muhimu sana hapa pia, katika ngazi nyingi: unaweza kuhifadhi kuingizwa kwa docs ya ndani ili kurudi kwa haraka; unaweza kuhifadhi majibu ya kawaida ya maswali ya ndani ("je, jinsi ya kuwasilisha ripoti ya gharama?"). Wanaweza hata kuhifadhiwa ili hatukufanya kuunda matokeo fulani, au matokeo ya sehemu kama maelezo ya nyaraka - ikiwa watu wawili wanauliza Vifaa vya Multi-Turn / Wafanyabiashara: Caching inaweza kupiga mzunguko mfupi katika mifumo ngumu ya wafanyabiashara wa AI (kama vile mfanyabiashara anayepanga kazi kupitia simu nyingi za LLM, na hutumia zana). Sasa angalia mfanyabiashara anayejibu maswali kwa kutafuta huduma ya wavuti na kupata matokeo ya kutumia kama input kwa LLM. Katika kesi hiyo, ikiwa swali hilo linaulizwa tena, mfanyabiashara anaweza kuchukua jibu la awali kutoka kwenye cache yake moja kwa moja ( badala ya kuiga hatua za mfanyabiashara) au kusema inawezekana kutumia tena matokeo yoyote ya utafutaji (usafirishaji wa zana za caching pamoja na matokeo ya LLM). Hii inahusiana na dhana ya caching ya mfanyabiashara au matokeo ya mfanyabiashara. Huduma za Mtandao wa Kiwango kikubwa: Hii ni hasa kweli katika kesi ya injini za utafutaji ambazo zinaweza kufaidika sana kutokana na kuhifadhi majibu ya LLM. Kwa mfano, Bing Chat hutumikia mamilioni ya watumiaji na kuna maombi mengi ya mara kwa mara. Ikiwa backend ya LLM ya Bing (ambayo ni GPT-4) hutoa majibu ya maswali maarufu ("Ni nini mji mkuu wa X", " Jinsi ya kufanya pancakes"), inaweza kurudi mara moja badala ya kuzalisha kutoka nyuma kila wakati. Kwa kweli, utafutaji wa non-LLM wa Bing umewahi kutumia kuhifadhi maswali kwa miongo; na majibu ya LLM yanatokana sasa tunaona mfano sawa. Watafiti tu walionyesha mfumo ambao mara moja walipata matokeo kwa ajili ya uchunguzi, hutoa yao kwamba utafuta Mwezi Agosti 2024, , ambayo ilikuwa mara ya kwanza kwa LLMs za kibiashara kuwa na caching kwa watumiaji. seva za Anthropic zinaweza kuhifadhi mazingira makubwa, yasiyofaa, kama kitabu (100,000 tokens). Kuandika kwa cache inachukua 25% zaidi kwa token ya kuingia, lakini kusoma maudhui ya cache inachukua tu 10% ya kiwango cha msingi. Wateja walisema majibu yalikuwa mara nne ya haraka (latency ilikuwa kutoka sekunde 11.5 hadi sekunde 2.4) na kwamba na gharama ya maombi ya token 10,000 ilipungua kwa takriban 86%. Washirika wa mazungumzo, msaidizi wa coding, na maswali ya makala kubwa ni matumizi ya kawaida, na mazingira ya imara ni bora kwa hit cache. Anthropic ilifanya caching kesi ya biashara yenye nguvu kwa kuunganisha uboreshaji wa utendaji na motisha ya kifedha. Haishangazi kwamba washindani kama OpenAI na Google hutoa vipengele sawa ili kupata faida sawa za gharama na latency. Anthropic's Claude 3 added Prompt Caching ya Anthropic cost of 100,000-token prompts went down by 90% ya Anthropic Kwa kesi nyingine: OpenAI haina kufafanua yoyote ya hii kwa umma, lakini mtu anaweza kujiuliza kama watengenezaji walipanga vizuri na / au walitoa maandishi machache katika kila ombi, sehemu hiyo inaweza kuhifadhiwa upande wa seva ili mfano hauhitaji kuingiza mifano hiyo kutoka nyuma kila wakati. Ni sawa na mbinu ya Anthropic. kwa mfano, ikiwa unatuma mwongozo wa mfumo wa token 2000 + Maelekezo juu ya kila wito wa API (ambayo wengi hufanya), OpenAI itahifadhi mchanganyiko wa mfano wa kwamba ndani na tu kuunganisha na utambulisho wako ulioboreshwa. Itakuwa wazi kabisa kwa watumiaji lakini (inaweza kuokoa) katika kiasi kikubwa cha kompyuta na itasaidia OpenAI kukabiliana na mzigo zaidi kwenye vifaa vyao. OpenAI's system messages and few-shot examples caching Kwa jumla, karibu makampuni yote makubwa ya AI yanatumia caching ya LM katika ulimwengu halisi. Ingawa OpenAI, Anthropic, Microsoft, Google na Hugging Face wote katika wakati fulani wamezungumzia au kuandika mikakati ya caching na kujifunza tofauti kama matokeo, wengi wao wanashiriki matokeo sawa: caching hutoa ongezeko kubwa la utendaji, lakini inakuwa muhimu kusimamia freshness ya cache bila kuharibu kumbukumbu na uwezekano wa kupanua. hadithi ya "tumechukua cache na kuona kupungua kwa 30% katika matumizi yetu ya GPU wakati wa kudumisha QPS" sio isiyojulikana. caching is the ticket to turbocharging LLM applications. Challenges and Limitations changamoto na vikwazo Bila shaka, caching sio risasi ya fedha. Hii ni, bila shaka, kidogo ndogo - ikiwa ilikuwa rahisi kila mtu angekuwa caching mambo yote baada ya yote! Kuna changamoto nyingi na vikwazo katika mazoezi ambayo wahandisi wanapaswa kufanya kazi kuhusu wakati wa kuanzisha caches ya LM: Cache Invalidation (Stale Data): Wakati data ya msingi au update ya LLM inabadilisha maana ya jibu, matokeo ya cache huwa ya kudumu, kama vile matatizo ya ukiukwaji wa cache ya wavuti. Suluhisho la busara ni kuondoa cache zote wakati mfano ni upya. Hii ni rahisi lakini gharama kubwa kwa sababu inaondoa machapisho ambayo bado ni sahihi. Baadhi ya watu hutumia sheria ya "ikiwa haipatikani, kupokea mapya", lakini hii inaweza kusababisha kupoteza data muhimu. Ni bora kutoa vitu thamani ya muda wa kuishi (TTL) ili kuishia baada ya muda fulani, au kurekebisha vifungo vya cache kwa idadi ya mfano au vigezo ili usitumie machapisho kutoka kwa mifano ya zamani. Kuongezea hashes au timestamps Kwa mfano, ikiwa uhifadhi jibu kwa swali A na kisha mtumiaji kuongeza habari zaidi, kwa kutumia jibu moja tena inaweza kupoteza mabadiliko muhimu. Ili kuzuia hili kutokea, caches mara nyingi kuhifadhi ID kamili ya mazungumzo, si tu mwongozo wa hivi karibuni, au wao tu cache mzunguko wa mazungumzo mfupi. Badala ya kuhifadhi majibu yote, unaweza kuhifadhi fupi, mahojiano ya mazingira ya juu badala. Hii inapunguza hatari ya kuwa na mabadiliko muhimu. Ni bado vigumu kusimamia caches vizuri. sera za kizuizini (kuhifadhi tu maagizo ambayo hayana uwezekano wa kubadilika) au uhakikisho wa kimantiki (kama vile kuhifadhi maneno muhimu ya mazingira ili kupata mabadiliko) inaweza kusaidia kuhakikisha kwamba huna kutumikia maudhui Mabadiliko ya haraka na kipekee: LLM mara nyingi hufanya kazi na input tofauti sana, hivyo caches za ajabu hazifanyi kazi vizuri sana. Kwa mfano, programu za kizazi cha ubunifu ambazo zinakuuliza "kuandika poem kuhusu X katika mtindo wa Y na twist Z" karibu kamwe hawana hit yoyote bila caching semantic. caches za semantic hujaribu kuzidisha kwa kuunganisha embeddings, lakini zinafanya kazi tu wakati maswali ni sawa sana. rohan-paul.com. Faida za caching zinategemea uzito wa kazi. caches za KV daima ni muhimu kwa matokeo ya muda mrefu, lakini caching ya majibu kamili ya ad-hoc haina kazi vizuri kama hakuna maswali mawili ni sawa. Caching ya sehemu au modular, ambayo inamaanisha kuanguka kwenye sehemu zinazotumiwa Picha ya kumbukumbu: Caches hutumia mengi ya kumbukumbu, RAM au GPU, kwa sababu cache ya KV kwa mazingira ya muda mrefu inaweza kuwa kubwa kama mifano yenyewe. huggingface.co. Caches za majibu pia zinaweza kuwa kubwa sana, ambayo inamaanisha wanapaswa kuharibu kwenye CPU au diski. Hii inamaanisha kwamba unahitaji kuchagua kati ya uwezo na ukubwa wa mfano au ukubwa wa mfululizo. Kwa mfano, ikiwa umeweka nje 20 GB ya GPU ya 40 GB kwa cache, hakuna nafasi nyingi kwa ajili ya mifano kubwa au kukabiliana na maombi zaidi. Ili kukabiliana na tatizo hili, watafiti au compress KV tensors (Shutova et al., 2025) arxiv.org au kufanana (4-bit vs. 16-bit yields ~4× uhifadhi wa kumbukumbu Ufanisi na Uhandisi Overhead: Caching hufanya mambo haraka, lakini pia hufanya mambo kuwa magumu zaidi. Unahitaji kuanzisha njia za kuhifadhi, kuangalia, kuboresha, na kuzuia machapisho, ambayo mara nyingi inamaanisha kutumia maduka ya nje kama Redis kwa ajili ya caches za usambazaji, ambayo inaweza kushindwa. Ili kuhakikisha kwamba mambo yanakubalika, unaweza haja ya kufanya uhandisi wa makini, kama kutumia wito usio na kuzuia async au miundo isiyo na kufungwa. Debugging pia inakuwa ngumu zaidi kwa sababu matokeo yasiyotarajiwa yanaweza kuja kutoka kwa data ya cache ya zamani au iliyoharibiwa badala ya mfano mwenyewe. Hiyo ndiyo sababu ni muhimu kuwa na kumbukumbu nzuri na ufuatiliaji kwa ajili ya hit na kushindwa. Katika Usalama na faragha: Ikiwa si kusimamiwa kwa usahihi, caching ya maombi na matokeo ya hisia yanaweza kufanya data ya kibinafsi kuwa ya umma. Katika mifumo ya wamiliki wengi, daima kuzuia upatikanaji wa cache kwa maombi yaliyoidhinishwa na maagizo ya kiwango kwa mtumiaji mmoja au mzunguko. Caching pia huendesha hatari ya mashambulizi ya njia ya upande, ambayo hackers huona maswali ya watu wengine. Kupunguza hatari, au kupunguza maudhui ya cache ya hisia. Hata hivyo, encryption inaweza kufanya mafanikio ya semantic kuwa ngumu. Pia, sheria kama GDPR inaweza kutibu outputs za AI zilizohifadhiwa kama data, ambayo inamaanisha kuwa zinahitajika kufutwa ikiwa mtumiaji anataka. Kama caching ya Ufuatiliaji wa Cache katika mifumo iliyosambazwa: Cache iliyosambazwa inakuwezesha kufanya nakala za data, lakini ina matatizo na ufuatiliaji. Kwa mfano, updates au ukiukwaji katika mfano mmoja hauwezi daima kuonekana na wengine, na wakati majaribio mawili hupoteza cache moja wakati huo huo, wanaweza kuwa na kurekebisha na kushindana kuandika orodha hiyo. Ili kuzuia duplicates, unahitaji shughuli za atomiki au kufunga. Kwa mfano, amri za atomiki za Redis husaidia hii. Medium. Ili kujenga cache iliyosambazwa, unahitaji kuchagua protocols za ufuatiliaji wa nguvu au kukubali ufuatiliaji wa mwisho na kusoma na kuandika mara kwa mara. Redis. Jaribio na kupang Hata hivyo, kwa Hii ni kwa madhumuni mengi. Hivyo, haiwezi kuwa mshangao mkubwa kwamba karibu kila huduma ya LLM inayohusiana na kampuni inahusisha caching ya fomu moja au nyingine yoyote, na tofauti ni mtu yeyote anayeweka kazi hii ya kubuni ili kukabiliana na mashambulizi. Kupunguza hatari: vitu vya cache ambazo hazipatikani sana (au tu mabadiliko ya polepole) + Matumizi ya mikakati mengi ya ukiukwaji wa cache + Tazama matumizi ya kiwango cha hit / ram na Kuwa na upungufu (kama kitu kimoja kinachotokea na cache yako, mfumo utafanya kazi, itakuwa tu polepole). Tunaanza kuona zana bora na maktaba za kukabiliana na mengi ya hiyo moja kwa moja (kwa mfano, cache ya ufanisi wa kiwango cha framework au kukabiliana moja kwa moja overall performance gains of caching generally significantly exceed LLM ni nguvu sana, lakini si bure kama tulivyoona na kuongeza kiwango cha ziada cha utata kwa LLMs - cache. Wanasayansi wa LLM sasa wanajua ya kwanza! Lakini na kubuni nzuri, mkataba unaweza kusimamiwa, na faida kubwa zinaweza kufanywa. Kuna mambo mawili tu ngumu katika sayansi ya kompyuta: uharibifu wa cache na jina la vitu Future Directions and Research Opportunities Njia za baadaye na fursa za utafiti Uwanja wa cache wa LLM ni nguvu sana, na njia nyingi za kusisimua ambazo watafiti na wahandisi wanatafuta kuongeza uwezo wake: Adaptive na Intelligent Caching: Machine learning inaweza kusaidia na sera za caching na kuondolewa. Kwa mfano, wafanyakazi wa RL wanajaribu kupata mafanikio ya muda mrefu zaidi (hit rate × usahihi). Wanaweza prefetch data wanafikiri watahitaji, kama OS kusoma mbele, cache matokeo maarufu wakati wa muda mfupi, na kuondoa vipengele ambavyo havina thamani kubwa. Utekelezaji wa uwezekano hutokea wakati caches hufanya hesabu na kuhifadhi data ambayo inaweza kutokea. Meta-ujuzi wa msingi wa LLM inaweza kufikiria ambayo hesabu ya kati itakuwa ya gharama kubwa na kuhifadhiwa katika cache. Ujuzi wa kuimarisha pia unaweza kusimamia kuondolewa kwa kuondokana na vipengele ambavyo havina uwezekano wa kuwa na manufaa Compression ya Cache na Uhifadhi wa Ufanisi: Quantization na kukata ni mbinu mbili ambazo cache hutumia kupunguza. AQUA-KV inapunguza tensors ya KV hadi bit chache tu na kupoteza ubora kidogo (Shutova et al., 2025). Pruning, kama vile kupoteza stopword KVs, inapoteza machapisho ambayo hayahitajika. Katika mazingira ya muda mrefu, Anchor Attention inahifadhi tu "anchor" token KVs na inapunguza wengine (Sun et al., 2024). Caches za majaribio za "kupoteza" huchukua vektor ambazo ni sawa na kuunganisha katika moja. kumbukumbu ya bandwidth ya juu au kumbukumbu ya darasa la kumbukumbu (Optane) inaweza kupoteza cache ya KV na P Caching ya Cross-Modal na Cross-Domain: LLMs za Multimodal na hata tafsiri ya video zinahitaji caching maalum. Kwa mfano, kuhifadhi embeddings ya picha inakuwezesha kuepuka kurekebisha picha ambazo umewahi kuona, na caching ya vipande vya sauti zilizopigwa hufanya msaidizi wa sauti kufanya kazi haraka. Kwa kila aina ya data, unahitaji mkakati tofauti. Kwa mfano, hashes za ufahamu kwa picha na ishara za sauti kwa sauti. Caching ya shirikisho kati ya vifaa vinaweza kushiriki matokeo ya kawaida kwa kibinafsi, ambayo ni sawa na dhamana ya faragha ya kujifunza ya shirikisho. Kama cache ya kivinjari ya kimataifa kwa msaidizi wa AI, cache ya jamii inaruhusu watumiaji wengi au vifaa kuongeza kwenye Kuhifadhi katika Mafunzo na Fine-tuning: Kuhifadhi pia inaweza kutumika kwa Mafunzo na Fine-tuning LLMs, sio tu kwa ufuatiliaji. Ili kuepuka I/O disk, uendeshaji wa kiwango kikubwa tayari kuhifadhi seti za data za tokenized katika kumbukumbu. Kuhifadhi wakati wa mafunzo katika hali ya kati kwa njia ya ubunifu zaidi. Kwa mfano, mifano ya kazi nyingi zinaweza kutumia muonekano wa mstari katika kazi badala ya kutuma tena. Kuhifadhi vipengele au gradients ambazo hutumiwa mara nyingi katika cache pia hupunguza kompyuta zisizohitajika. Hasa husaidia kwa utafiti, lakini pia hupunguza gharama katika kujifunza endelevu au RLHF kwa kuepuka hatua ambazo zinahesabiwa mara kwa mara Utawala wa Cache na Usimamizi wa Ubora: Mabadiliko mengine muhimu ambayo yanahitaji kutokea katika siku zijazo ni kuangalia mara kwa mara majibu ya cache ili kuweka uzoefu wa mtumiaji mzuri. Ikiwa majibu ya cache ya LLM haifai kupita filters, maoni ya mtumiaji, kama re-frasing ya mara kwa mara, inaweza maana kwamba inahitaji kubadilishwa au kuondolewa. Hii itakuwa kuunda mzunguko wa majibu ambayo huendelea kuboresha cache na kuifanya kuwa msingi wa ujuzi wa kuishi. Kazi za nyuma zilizopangwa zinaweza kurekebisha na kuboresha machapisho ya juu ya cache kama mfano wa msingi ni upya au upya. Kwa njia hii, majibu maarufu yanapata vizazi bora. Njia hii ni sawa na jinsi injini za Kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha juu cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha kiwango cha ki Maelezo ya Cache_scratch Hivyo, inaonekana kwamba mustakabali wa caching ya LM ni jua na imejaa ufumbuzi mpya. Kwa ujumla, shinikizo ni dhahiri: tunapoweka mifano kubwa kwa idadi kubwa zaidi ya watumiaji, mkakati wa caching ni mahali rahisi ya kuchukua baadhi ya slake. Matoleo ya baadaye itaongeza caching (kuhusiana na kujifunza), kupunguza uzito wake (kuongezea na usimamizi bora ndani ya kumbukumbu), na kuifanya kuwa zaidi ya kuenea kwa njia tofauti na kwa mafunzo / uchunguzi.* Hivyo ni mashindano ya Silaha, sio tu kujenga mifano makubwa lakini kuwatumikia kwa akili zaidi._* Kwa njia hii, kuboresha kwa caching na ufanisi ni kwa nini LLMs kama GPT-4 na Llama-2 zinaweza kuendesha haraka sana Kutoka hapa, pengine wale wenye mkakati mkubwa zaidi wa cache wanaweza kushinda jina la kutoa huduma za haraka na hatimaye za bei nafuu za AI. Kwa sababu, baada ya yote, kwa nini kuhesabu wakati unaweza cache? Mifano ya Mifano.co Maelezo ya: Anthropic. (2024, Agosti 14). Kulingana na taarifa ya Anthropic News: Hivyo kujiandaa kutumia kuongezeka na zawadi kwa upendo. kwa ajili ya anthropic.com kwa ajili ya anthropic.com Hinton, G., Vinyals, O., na Dean, J. (2015). NIPS Deep Learning na Mafunzo ya Uwakilishi. Kutoa ujuzi katika mtandao wa neva. Lewis, P., na wenzake (2020). Ufanisi katika mifumo ya usindikaji wa habari ya neural. Kuanzisha mlinzi juu ya msalaba wa ufahamu wa NLP. Paul, R. (2025 Aprili 20). Kulwant Nagi - Maandishi ya Blogu Mkakati wa Caching katika Huduma za LLM kwa Mafunzo na Ufuatiliaji. Msisemi Shaykh Rabiy ́ ni Imaam Msisemi Shaykh Rabiy ́ ni Imaam Pol, S. (2025 Aprili 6). Blog ya Medium. Kuharakisha Inference ya Transformer na Caching ya KV. Siku ya Kumbukumbu 522.medium.com Siku ya Kumbukumbu 522.medium.com Msisemi Shaykh Rabiy ́ ni Imaam wa Jarh wat-Ta ́diyl. wa wa wa wa wa wa wa wa . Transformer ya haraka ya decoding: One Write-Head ni kila unahitaji. Maelezo ya .org Shutova, A., Malinovskii, V., Egiazarian, V., et al. (2025). ya ya ya ya ya ya ya ya ya ya ya ya . Cache Me If You Must: Adaptive Key-Value Quantization kwa mifano ya lugha kubwa. Maelezo ya .org Yazdani Aminabadi, R., Rajbhandari, S., Zhang, M., et al. (2022). Kifungu cha 207.00032 . Inference ya DeepSpeed: Kuwezesha Inference ya ufanisi ya mifano ya Transformer kwa kiwango kipya. Maelezo ya .org Kwon, W., Li, Z., Zhuang, S., et al. (2023). Utaratibu wa SOSP 2023 . Usimamizi wa ufanisi wa kumbukumbu kwa mfano wa lugha kubwa unaotumika na PagedAttention (vLLM). Blogu ya Mwisho. Blogu ya Mwisho. Timu ya Transformers ya Hugging Face (2023). Kulwant Nagi - Maandishi ya Blogu Kuimarisha LLM yako katika uzalishaji. Mifano ya Mifano.co Mifano ya Mifano.co Lorello, S., McCormick, R., & Partee, S. (2023). Kulwant Nagi - Maandishi ya Blogu Jinsi ya kujenga Cache ya Inference ya Usambazaji na NVIDIA Triton na Redis. (Maelezo ya ziada kwa ujasiri wa kitaaluma na ukamilifu inaweza kuingizwa kama inahitajika ili kufanana na maagizo yote hapo juu.)