Meningkatkan prestasi LLM dengan LM Cache: Arsitektur, Strategi, dan Aplikasi Dunia Real

Abstract abstrak Artikel ini menawarkan pandangan penyelidikan teknikal yang mendalam mengenai operasi LM Cache dan bagaimana mesin caching meningkatkan kecekapan, skalabiliti, dan pengurangan kos pengenalan Model Bahasa Besar (LLM). Kami mengkaji pelbagai jenis arsitektur caching dan mekanisme, bagaimana mereka boleh disepadukan bersama dengan infrastruktur AI baru dan dinilai untuk prestasi. Contoh dari lapangan terperinci bagaimana sesetengah pelanggan terbesar kami mengimplementasikan LM Caches dalam amalan dan apa yang telah mereka pelajari sepanjang jalan. Introduction Pengenalan Pikirkan seorang pembantu AI yang mesti sentiasa memberikan jawapan yang sama sepanjang hari selama beratus-ratus masa! Ini bukan hasil, adakah ia perlu menghasilkan semula setiap jawapan dari awal, secara harfiah setiap kali? manakala LLM (pikirkan GPT-4, PaLM, dan lain-lain) mengubah segala-galanya dari sokongan pelanggan kepada pengeluaran kod mereka. Dalam pengeluaran, setiap pertanyaan kepada model yang besar boleh dikenakan kos saat dan pengiraan GPU yang besar.Sementara saiz model dan jangkaan pengguna meningkat, keperluan untuk kesimpulan yang cepat menjadi lebih penting daripada sebelumnya. deployment at scale is stymied by latency requirements, computational cost and memory footprint Mengingat semua ini, cache LM muncul sebagai jawapan yang sangat bijak kepada masalah ini dengan caching dan penggunaan semula hasil yang telah dikira. Caching pada asasnya adalah apa yang membolehkan sistem kami mengingati semua yang telah dilihat sebelum ini. Gagasan umum konsep ini bukan baru dalam sains komputer, tetapi ia mempunyai kemajuan yang berpotensi dalam LLM itu sendiri untuk pencapaian yang lebih besar secara signifikan dan penurunan masa respons yang besar. Seperti pemusnahan model (menciptakan model yang lebih kecil dan lebih cepat), pengeluaran yang ditingkatkan (menggantung pada pangkalan pengetahuan luaran), dan pangkalan data vektor untuk carian semantik, LM Cache meningkatkan teknik pengoptimalan lain. Dengan ukuran akhir mekanisme caching yang digunakan bersama-sama dengan kaedah ini, penyebaran LLM berskala besar boleh memberi mereka bukan sahaja pencapaian yang lebih Foundations of LM Cache Perkhidmatan LM Cache Konsep daripada adalah semata-mata pengkomputeran penggunaan semula untuk tidak bekerja berlebihan. Dalam kes penyelesaian LLM, caching boleh wujud pada tahap yang berbeza 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 Penggunaan_Cache=True Terdahulu - KV Terdahulu - KV Perkhidmatan.decode_next Semua tahap caching yang disebutkan di atas menggunakan prinsip sederhana yang Kerana mekanisme perhatian diri, pengiraan setiap token baru dalam LLM berasaskan transformator sering bergantung kepada token terdahulu. Sama ada pada tahap prompt atau dalam dalam model, penyamaran hasil daripada pengiraan terdahulu ini membolehkan operasi seterusnya untuk melompat terus kepada hasil akhir. Peningkatan yang signifikan dalam kelajuan dan penggunaan sumber berpunca daripada ini. system shouldn't re-compute what you have already done LM Cache Architectures and Strategies LM Arsitektur dan Strategi Cache Oleh kerana tidak semua beban kerja adalah sama dalam sistem LLM, sejumlah besar seni bina dan strategi telah direka oleh jurutera untuk memaksimumkan hit cache dan mengurangkan overhead. Cache statis vs. Dynamic: Cache statis datang dengan pasangan input/output yang diisi terlebih dahulu, yang menjadikannya hebat untuk beban kerja yang boleh diramalkan. Ini adalah penyelesaian caching untuk soalan biasa atau output prompt tetap, seperti FAQs atau jawapan kes ujian. Cache dinamik, sebaliknya, mengisi sebagai sistem berjalan, berubah untuk menyesuaikan corak lalu lintas, mengubah distribusi pertanyaan, dan puncak penggunaan. Mereka sebenarnya "pelajari" daripada lalu lintas pengguna untuk meningkatkan kadar hit. Dalam kehidupan sebenar, sistem mengehadkan cache dinamik dengan menggunakan dasar penghapusan berdasarkan permintaan semasa, yang secara automatik menyingkirkan item lama. Caching dinamik lebih disukai untuk kebanyakan penyebaran dunia sebenar kerana ia boleh diubah. MeanCache adalah contoh yang baik daripada ini. Ia adalah cache pembelajaran berasaskan yang menyesuaikan model untuk mencari Menyimpan Caching Distributed dan Federated: Dalam penyebaran besar dengan banyak instansi LLM pada pelayan atau pods yang berbeza, cache per-mesin tidak berfungsi untuk pemprosesan semula antara pelayan. Sebagai contoh, jika Server A memproses dan memadamkan pertanyaan, Server B mesti menghitung semula jawapan walaupun ia tidak boleh mengakses Server A. Cache Distributed memperbaiki ini dengan berkongsi entri melalui kedai luaran, seperti Redis. Triton Inference Server NVIDIA menambah caching disebarkan pada tahun 2023, walaupun rangkaian hops hanya menambah kira-kira 8% lebih banyak latency daripada cache dalam proses tempatan. (Lorello et al., 2023; Paul, 2025) rohanpaul.com. Kemudian, pelayan memadamkan sekali dan menggunakan hasil sekali lagi, yang mengurangkan penyebaran kerja yang tidak perlu dan membuat sistem Caching layer-wise dan pengoptimalan memori GPU/TPU: Caching tidak terhad kepada output; ia juga boleh digunakan pada lapisan LLM tertentu. Untuk mengelakkan daripada perlu mengira lapisan tengah yang mahal sekali lagi pada hit cache, seseorang boleh, contohnya, cache output lapisan itu untuk input kerap tertentu. Selain itu, ia mungkin masuk akal untuk cache hanya pengaktifan yang paling mahal atau menggunakan memori pada cip untuk cache pada pengecas perkakasan (GPU/TPU), di mana memori adalah berharga. Analog inference teknik seperti gradient checkpointing, yang melibatkan perakaunan perdagangan untuk perakaunan semasa latihan memori, membolehkan anda untuk secara selektif mengekalkan output lapisan tertentu. manakala mengekalkan jejak memori yang boleh dikendalikan, cache layer-like yang direka dengan baik Cache Granularity dan Keys: Memilih indeks cache adalah langkah pintar. Kunci tumpuan tepat pada string prompt penuh adalah mudah untuk digunakan, tetapi mereka patah dengan mudah – sebarang perubahan melepaskan cache. Untuk mendapatkan lebih banyak hits, sistem menggunakan hash semantik berasaskan embedding yang merawat prompts sebagai sama walaupun perkataan yang berbeza, atau prefix/chunk keys yang mencocokkan segmen yang berlapis. Selepas memproses prefix yang stabil, "prefix caching" mengambil snapshot keadaan KV model. Dengan cara ini, prompt baru yang bermula dengan prefix itu boleh bergerak dengan cepat ke keadaan itu. Projek vLLM sumber terbuka melakukan ini secara automatik dengan mencari prefix bersama dalam permintaan masuk dan menggunakan kembali tensors cache. Ini mempercepat pemprosesan prompts panjang dengan jumlah yang besar (Kwon et al., 2023). Ini serupa dengan Kebijakan Saiz Cache dan Penghapusan: Kerana memori cache terhad, LLM menggunakan dasar-dasar seperti LRU atau LFU untuk memutuskan entri mana yang perlu disimpan dan mana yang perlu dikeluarkan. Ini membebaskan ruang untuk data baru. Selain daripada menghapuskan item berdasarkan umur atau frekuensi, cache LLM juga mesti menangani kerosakan relevansi dan model atau kemas kini data dengan menghapuskan item lama. Pada tahun 2024, penyelidikan menunjukkan bahawa penghapusan pembelajaran berfungsi: cache yang dilatih untuk mencari dan menyingkirkan kunci dengan nilai masa depan yang sedikit (Xiong et al., 2024). Sistem penghapusan "pintar" adaptif ini, yang dibuat untuk beban kerja LLM, kemungkinan akan menjadi norma untuk menguruskan cache dengan cekap. Singkatnya, membina cache LM adalah keseimbangan yang halus: Kami mahu memaksimumkan kadar hit sambil meminimalkan overhead seperti penggunaan memori dan volatiliti. Jika ini bermakna anda perlu bekerja dengan sistem terjemahan mesin yang lebih sukar, maka jadilah tetamu saya! Strategi ini (static vs. dinamik, arsitektur terdistribusi, menarik dalam cache hit pada terminologi dengan membina pada masa klien dengan bahasa contoh terdahulu) adalah semua trik yang boleh membantu anda melakukan lebih banyak dengan caching tanpa melampaui perangkap yang berkaitan dengan cache. Aplikasi yang berbeza boleh menggabungkan kaedah ini dan menerapkan Sebagai contoh, sistem pengeluaran boleh menggunakan pada tahap aplikasi cache prompt semantik (untuk kes apabila pertanyaan pengguna menyerupai satu sama lain) dan pada tahap model sebuah cache KV (untuk mempercepatkan peng Grafik Arsitektur Cache LM dalam Pipeline Inference LLM Berikut ialah seni bina rujukan yang menggambarkan integrasi LM Cache dalam aliran penyelesaian LLM biasa: Diagram aliran kerja yang membandingkan permintaan cache berbanding permintaan inference yang tidak cache Untuk memahami lebih lanjut faedah, pertimbangkan perbandingan aliran kerja antara permintaan kesimpulan cache dan tidak cache: Integrasi dengan infrastruktur AI moden Caching LM tidak berdiri sendiri - ia akan berasal daripada ekosistem aplikasi yang lebih luas dalam AI. Di sini kita melihat bagaimana caching sesuai dengan pelbagai infrastruktur dan kerangka kerja: 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 Penggunaan_Cache=True Untuk meringkaskan, stack AI moden semakin “cache-aware. sistem peringkat yang lebih tinggi mula menginternalisasikan ini, dari perpustakaan yang menguruskan mekanik untuk anda kepada seni bina sistem yang berkongsi cache di seluruh permintaan dan infrastruktur. Caching adalah sesuatu yang kebanyakan perkhidmatan LLM akan menggunakan, kerana itulah yang pemain besar dalam AI (OpenAI, Google dan Microsoft contohnya) telah bercakap atau dilakukan dalam tawaran LLM masing-masing. Sesetengah spesifikasi dikenali seperti OpenAI's ChatGPT (tidak didokumenkan secara awam tetapi peristiwa ini terutamanya digambarkan) mungkin menggunakan konteks perbualan skala besar caching; pasukan Claude Anthropic (yang akan datang seterusnya...) telah mengimplementasikan prestasi yang boleh dilihat oleh pengguna, prompts cache untuk menjimatkan; Azure perkhidmatan AI Cache melalui ONNX Run Performance Metrics and Evaluation Metrik Prestasi dan Penilaian Ok, dalam teori caching mungkin terdengar menakjubkan tetapi bagaimana kita boleh mengukurnya? Terdapat beberapa metrik prestasi biasa yang membantu anda menilai keberkesanan caching LM Latency yang lebih rendah: Latency yang lebih rendah: Faedah utama adalah latency yang lebih sedikit, yang merupakan masa yang diperlukan untuk mendapatkan jawapan. Caching mengubah kurva prestasi: cache primed secara konsisten menawarkan aliran yang tinggi dan latency yang rendah. Kami melakukan ini dengan melihat masa yang diperlukan untuk membuat permintaan dengan dan tanpa cache. Chatbot yang biasanya mengambil masa 2 saat untuk menjawab soalan akan kembali dalam 0.2 saat jika ia menjatuhkan cache, yang adalah 90% lebih cepat. Kecepatan sebenar bergantung kepada kadar hits. Sebagai contoh, jika 80% daripada hits adalah 1000 kali lebih cepat, latency keseluruhan akan lebih baik. Pasukan sering bercakap tentang latency p50 dan p95 dengan dan tanpa caching. Dengan caching konteks Anthropic, melihat sehingga 85% kurang latency pada perbualan yang lebih lama. (Anthropic, 2024) anthropic.com Penambahbaikan melalui: Dengan caching, throughput—permintaan per saat (RPS) atau token per saat (TPS)— boleh melalui atap. Ini kerana caching menyelamatkan pengiraan dengan tidak perlu melakukan pengiraan yang sama berulang kali. Benchmark DenseNet untuk NVIDIA Triton pergi dari 80 kepada 329 inf/sec (kira-kira 4×) dan model yang lebih ringan melihat kira-kira 20% keuntungan dengan caching respons. rohan-paul.com. Apabila datang kepada LLM berkhidmat, PagedAttention vLLM menggunakan pengurusan cache KV yang lebih pintar untuk permintaan kumpulan yang lebih baik, yang bermakna ia boleh menangani sehingga 24 kali lebih banyak permintaan daripada Hugging Face Transformers. blog vLLM. Dalam situasi dengan lebih daripada satu pengguna, pengukuran throughput sangat penting. caching membantu mengekalkan trafik daripada berlaku dan menjaga pel Caching juga akan menjimatkan pada pengiraan berlebihan, ia benar-benar menjimatkan FLOPs yang adalah wang (contohnya apabila anda membayar oleh jam GPU atau panggilan API). Metrik biasa untuk ini adalah penggunaan GPU dan juga jumlah masa pengiraan disimpan. Sebagai contoh, Anthropic mengklaim bahawa dalam perbualan yang lebih lama, prompt caching boleh mengurangkan penggunaan token (juga kos) sebanyak 90% (Anthropic, 2024), anthropic.com. Ini juga tercermin dalam skim harga - menggunakan token cache kos yang lebih kecil daripada menghasilkan mereka dari scratch.bdtechtalks.com. Jika anda menilai pada set ujian, dengan dan tanpa cache, anda boleh mendekati peratusan token atau operasi yang disimpan menggunakan cache. Mengarah kepada wang sebenar disimpan pada kos awan. Dalam arti ini, anda boleh Hit Rate dan Miss Penalty: Ini adalah metrik khusus cache. Hit Rate: Persentase permintaan (atau token) yang dipenuhi oleh cache Tingkat hit yang lebih tinggi bermakna peningkatan prestasi yang lebih baik Secara umum. Ini berguna untuk melaporkan, seperti "sistem kami mempunyai kadar hit cache 60% pada prompts dalam prod (X sebenarnya X vs Y tanpa cache). Penalti miss adalah berapa banyak lebih lambat cache miss vs hit. Dengan kata lain, beberapa masa penambahan cache memperkenalkan beberapa overhead (contohnya, mengkomputerkan embedding untuk carian semantik, atau hop rangkaian tambahan untuk memeriksa cache terdistribusi) - jika miss masih menjalankan model penuh ditambah overhead ini, yang merupakan faktor lain yang perlu diingat. Memori dan Overhead Trade-offs: Caching mengekalkan output model atau keadaan pertengahan, yang menggunakan lebih banyak RAM GPU. Untuk konteks yang panjang, cache KV tumbuh dalam garis lurus. Sebagai contoh, cache model 405 B untuk 16k token boleh menggunakan kira-kira 15 GB (kira-kira separuh saiz model). GitHub. Gunakan metrik seperti "memori overhead per token tambahan" atau "perbandingan cache-size" untuk mencari tahu kompromi. Menggunakan teknik seperti perhatian pelbagai pertanyaan, anda boleh memotong cache dari puluhan gigabyte kepada beberapa ratus megabyte. Ini adalah pengurangan 97% untuk 16k urutan dengan sedikit kehilangan ketepatan. huggingface.co. Untuk memastikan bahawa sistem ini direka dengan baik, penting untuk membandingkan jejak kaki cache antara kaedah untuk mencari keseimbangan terbaik antara Kesan ketepatan / Kualiti: output model tidak boleh berubah (kecuali untuk dihidangkan dengan hasil yang mungkin sedikit terlambat) kerana caching. Walau bagaimanapun, dalam beberapa model caching (iaitu yang kira-kira atau semantik), jawapan mungkin berakhir tidak selaras dengan sempurna daripada pertanyaan baru. Jadi, kita boleh melihat sama ada caching menghasilkan kerugian kualiti atau tidak. Secara khusus, jika kita caching pertanyaan yang relevan secara semantik kepada pertanyaan baru dan jawapan pertanyaan baru harus tetap betul jadi boleh diperiksa sebagai ketepatan atau skor relevansi. Dalam komuniti akademik, pengukuran kualiti itu sering dipanggil sebagai "hit rate"—iaitu persentase jawapan caching yang betul? Ini bukan masalah untuk caching KV (karena ia mempunyai pemulihan nilai dalaman yang sempurna, jadi output yang sama akan seperti uncached), tetapi jawapan tingkat yang lebih tinggi Perbandingan dengan Baselines: Para penyelidik biasanya membandingkan model caching yang ditingkatkan dengan model baseline tanpa caching untuk mengukur keuntungan. Mereka mungkin juga membincangkan perbandingan kaedah caching yang berbeza. Sebagai contoh, caching yang tepat berbanding caching berasaskan embedding berbanding tidak caching dalam satu set data pertanyaan, dengan latency dan ketepatan untuk itu. vLLM berbanding vanilla HF server Throughput & Memory. Kajian perbandingan ini mengira spesifikasi untuk mengesahkan intuisi bahawa caching sebagai peraturan jempol adalah idea yang baik. Hasil contoh boleh menjadi: caching meningkatkan melalui 2x dan latency oleh 40%, dengan kos GB tambahan (gabyte) untuk cache, berbanding baseline non-cache. Ia disebabkan oleh nombor-nombor ini yang melebihi pengenalan ke dalam cache — tidak lebih Jika kita menilai caching LM, ia adalah penting untuk menimbang kompromi di mana anda boleh menjimatkan pada pengkomputeran tetapi dengan kos lebih banyak memori; latensi akhir yang lebih rendah, tetapi perlu menangani jawapan yang teratur kadang-kadang. Kedua-dua makalah akademik dan laporan industri mula memasukkan caching ke dalam benchmark mereka, yang bermakna mengingat penyebaran cache yang luas. Dalam kajian seterusnya pada tahun 2024, ia telah diperhatikan bahawa hampir semua penyerahan teratas untuk tugas LLM konteks panjang bergantung kepada beberapa bentuk caching atau pengoptimalan perhatian untuk menangani panjang konteks secara berkesan (Chen et al., 2024). Bilangan-bilangan ini secara konsisten kemenangan besar. Sederhananya: caching mengurangkan latency, meningkatkan aliran dan mengurangkan kos per pertanyaan dengan kedua-dua melayani pertanyaan baru lebih cepat dan mengelakkan kerja duplikat. Tanpa pengoptimuman ini, apa-apa penilaian LLM akan jauh daripada lengkap. Melayu kepada Melayu.com Real-World Case Studies Kajian kes dunia sebenar Kita semua tahu bahawa caching bukan sahaja untuk kepentingan argumen akademik, dan ciri-ciri ini membawa nilai nyata dalam amalan. Berikut adalah beberapa contoh pada senario yang berbeza, hanya untuk menunjukkan bagaimana caching membantu : Perbincangan AI (Chatbots/Assistants): Alih-alih mengenkripsi semula sejarah penuh setiap putaran, multi-turn chat LLM memadamkan perbualan terdahulu. Sebagai contoh, mereka memadamkan soalan pengguna pertama dan jawapan penolong supaya hanya input baru diproses pada soalan-soalan kemudian. huggingface.co. Ini membolehkan sistem seperti ChatGPT bertindak balas dengan cepat tanpa perlu melakukan semua matematik lagi. Dengan memadamkan dihidupkan, Anthropic's Claude 3 membolehkan pemaju menjejaskan konteks hidup lama, yang mengurangkan latensi sebanyak 79% dan kos sebanyak 90% pada prompt token 100k. (Anthropic, 2024) anthropic.com. Xiaoice dari Microsoft juga menyimpan jawapan adegan supaya ia tidak perlu mengatakan perkara-perkara yang sopan yang sama berulang Penyelesaian dan Bantuan Kod: GitHub Copilot dan TabNine menggunakan caching untuk mempercepatkan penyelesaian kod. Model akan perlu memproses keseluruhan konteks sekali lagi setiap kali anda menekan kunci, yang akan menjadikannya sangat lambat. Sebaliknya, mereka menyimpan representasi model prefiks dalam cache supaya hanya watak-watak yang dilampirkan diproses. Ini dipanggil caching prefiks. Banyak prompt koding mengulangi diri mereka sendiri (seperti Fibonacci), jadi prompt-level caching memberi anda pertanyaan yang sama dengan segera. Ia juga menangani pertanyaan pengembang yang sama di seluruh sesi supaya mereka boleh digunakan dengan segera. Dalam forum, LLM boleh menyimpan pasangan Q&A popular (atau menyesuaikan dan menyimpan mereka) supaya ia boleh menjawab soalan biasa dengan cepat (Paul, 2025) rohan-paul.com. Penolong kod Asisten "Copilot" Enterprise: Banyak syarikat mengimplementasikan asisten AI untuk dalaman - sejenis seperti copilot AI yang membantu meringkas dokumen, membuat rancangan e-mel, menjawab soalan perniagaan dari data dalaman dan lain-lain.Ia biasanya berjalan di atas pangkalan pengetahuan yang ditentukan (dokumen syarikat, wikis, laporan) Caching juga sangat berharga di sini, pada banyak lapisan: anda boleh memadamkan embeddings dokumen dalaman untuk mengembalikan mereka lebih cepat; anda boleh memadamkan beberapa jawapan permintaan dalaman yang biasa ("bagaimana saya memaparkan laporan kos?").Mereka juga boleh disimpan dalam cache supaya kami tidak menghasilkan semula beberapa hasil, atau hasil parsial seperti meringkas dokumen - jika dua orang meminta ringkasan dokumen yang sama ia dilakukan hanya sekali.Office 365 Copilot oleh Microsoft mungkin menggunakan cache untuk memastikan permintaan pengguna berulang boleh disampaikan Multi-turn Tools/Agents: Caching boleh short-circuit loop dalam sistem agen AI yang kompleks (seperti agen yang merancang tugas melalui panggilan LLM yang berbilang, dan menggunakan alat). Sekarang pertimbangkan agen yang menjawab soalan dengan menginterogasi perkhidmatan web dan mendapatkan hasil untuk digunakan sebagai input untuk LLM. Dalam kes ini, jika soalan yang sama ditanya lagi, agen boleh mengambil jawapan terdahulu dari cachenya secara langsung (bukan mengulang semula alat) atau mengatakan mungkin menggunakan semula apa-apa hasil carian (output alat caching serta output LLM). Ini berkorelasi dengan konsep cache planner atau caching alat hasil. Hasil panggilan pertengahan disimpan dalam cache oleh projek seperti LangChain, jadi apabila aliran kerja mengulangi langkah-langkah ia tidak menggandakan kerja. Oleh kerana mereka juga membina Bardant dan Assistant untuk penggunaan Perkhidmatan Internet Skala Besar: Ini terutamanya berlaku dalam kes enjin carian yang boleh mendapat manfaat secara drastik daripada caching jawapan LLM. Sebagai contoh, Bing Chat berkhidmat berjuta-juta pengguna dan terdapat banyak permintaan berulang. Jika backend LLM Bing (yang merupakan GPT-4) cache jawapan kepada soalan-soalan yang popular ("Apa yang ibu kota X", "Bagaimana untuk membuat pancake"), ia boleh mengembalikan mereka dengan segera bukannya menghasilkan dari awal setiap kali. Pada hakikatnya, carian bukan LLM Bing telah menggunakan caching pertanyaan selama bertahun-tahun; dengan jawapan LLM muncul sekarang kita melihat corak yang sama. Para penyelidik hanya menunjukkan sistem bahawa sekali ia mendapati hasil untuk penilaian, cache mereka bahawa pertanyaan carian yang sama bermaksud pengurangan latency yang besar. rohan-paul.com. Mungkin sesuatu yang kedua-dua Pada bulan Ogos 2024, , yang merupakan kali pertama LLM komersial mempunyai caching untuk pengguna. pelayan Anthropic boleh menyimpan konteks yang besar dan tidak perlu, seperti buku (100,000 token). Menulis ke cache kos 25% lebih per token input, tetapi membaca kandungan cache hanya kos 10% daripada kadar asas. Panggilan pertama menyimpan data; panggilan seterusnya menggunakan ID prompt untuk menemukannya dan hanya menghantar kandungan baru. dan kos prompts 10,000 token turun kira-kira 86%. Agen perbualan, pembantu kod, dan dokumen besar Q&A adalah kegunaan biasa, dan konteks yang stabil adalah yang terbaik untuk hit cache. Anthropic membuat caching kes perniagaan yang kuat dengan menggabungkan peningkatan prestasi dengan insentif kewangan.Tidak menghairankan bahawa pesaing seperti OpenAI dan Google menambah ciri-ciri yang serupa untuk mendapatkan kos dan faedah latens yang sama. Anthropic's Claude 3 added Prompt Caching Antropologi cost of 100,000-token prompts went down by 90% Antropologi Kes lain : OpenAI tidak menguraikan apa-apa perkara ini secara terbuka, tetapi seseorang mungkin bertanya-tanya sama ada pengembang menyesuaikan dan / atau menyediakan teks-teks dalam setiap permintaan, bahagian itu boleh disemak di sisi pelayan supaya model tidak perlu menyemak semula contoh-contoh itu dari asalnya setiap kali.Ini adalah analog dengan pendekatan Anthropic. contohnya.Jika anda menghantar prompt sistem 2000 token yang sama + Instruksi pada setiap panggilan API (yang banyak melakukan), OpenAI akan menyemak penyemak model yang dimasukkan ke dalamnya dan hanya menyatu dengan persembahan yang diproses pertanyaan anda.Ini akan sepenuhnya transparan kepada pengguna tetapi (boleh menyimpan mereka) dalam jumlah besar pengkomputeran dan akan membantu OpenAI menangani lebih banyak beban pada perkakasan mereka. OpenAI's system messages and few-shot examples caching Secara keseluruhan, hampir semua syarikat AI utama menggunakan caching LM dalam dunia sebenar. manakala OpenAI, Anthropic, Microsoft, Google dan Hugging Face semua pada satu titik telah membincangkan atau mendokumentasikan strategi caching dengan pembelajaran yang berbeza sebagai hasilnya, kebanyakan daripadanya berkongsi kesimpulan yang sama: caching menyediakan peningkatan prestasi yang besar, tetapi menjadi penting untuk menguruskan kesegaran cache tanpa mengorbankan memori dan keluasan. Kisah-kisah "kami mendorong cache dan melihat penurunan 30% dalam penggunaan GPU kami sambil menyimpan QPS tidak disentuh" tidak pernah terdengar. caching is the ticket to turbocharging LLM applications. Challenges and Limitations Cabaran dan keterbatasan Sudah tentu, caching bukan peluru perak. Ini, tentu saja, agak trivial - jika ia mudah semua orang akan caching semua perkara selepas semua! Terdapat pelbagai cabaran dan batasan dalam amalan yang jurutera mesti bekerja di sekitar apabila menggunakan cache LM: Cache Invalidation (Stale Data): Apabila data asas atau kemas kini LLM mengubah makna jawapan, output cache menjadi tidak sah, seperti masalah kegagalan cache web. Penyelesaian naif adalah untuk memadamkan semua cache apabila model dikemas kini. Ini mudah tetapi membuang-buang kerana ia memadamkan entri yang masih sah. Sesetengah orang menggunakan peraturan "jika tidak didapati, dapatkan segar", tetapi ini boleh menyebabkan mereka kehilangan data yang berguna. Lebih baik untuk memberikan item nilai time-to-live (TTL) supaya mereka tamat tempoh selepas tempoh masa tertentu, atau untuk versi cache kunci mengikut ID model atau parameter supaya anda tidak menggunakan entri daripada model yang lebih tua. Menambah hash atau timestamp ke kunci cache membantu untuk mencari data lama. Walaupun dengan kaedah ini, kegagalan masih sukar kerana anda perlu menjejaki apa yang berubah dan sama Mengekalkan konteks dalam Dialog: Apabila konteks berubah kemudian dalam perbualan berulang-ulang, jawapan dalam cache boleh menjadi tidak berkesan. Sebagai contoh, jika anda menyimpan jawapan kepada soalan A dan kemudian pengguna menambah lebih banyak maklumat, menggunakan jawapan yang sama sekali boleh kehilangan perubahan penting. Untuk menghalang ini daripada berlaku, cache sering menyimpan ID perbualan penuh, bukan hanya petunjuk terkini, atau mereka hanya mengekalkan jangkauan dialog yang lebih pendek. alih-alih menyimpan jawapan keseluruhan, anda boleh menyimpan ringkas, ringkasan yang kaya konteks alih-alih. Ini mengurangkan risiko mereka menjadi tua. Ia masih sukar untuk menguruskan cache dengan baik. Dasar konservatif (hanya menyimpan entri yang tidak mungkin berubah) atau pengesahan dinamik (seperti mengekalkan syarat konteks kunci untuk mencari perubahan) boleh membantu memastikan anda tidak melayani kandungan lama Prompt Variabiliti dan Keunikan: LLM sering berurusan dengan input yang sangat berbeza, jadi cache naif tidak berfungsi dengan baik. Sebagai contoh, aplikasi generasi kreatif yang meminta anda untuk "menulis puisi tentang X dalam gaya Y dengan twist Z" hampir tidak pernah mendapat apa-apa hits tanpa caching semantik. Cache semantik cuba menggeneralisasi dengan mencocokkan embeddings, tetapi mereka hanya berfungsi apabila pertanyaan sangat serupa. rohan-paul.com. Faedah caching bergantung kepada redundansi beban kerja. Cache KV sentiasa berguna untuk output panjang, tetapi caching respon penuh ad-hoc tidak berfungsi dengan baik jika tiada dua pertanyaan yang sama. Caching parsial atau modular, yang bermakna memecahkan output ke dalam bahagian yang boleh digunakan semula seperti frasa biasa atau snippets kod, boleh membantu sedikit. Memory Footprint: Caches menggunakan banyak memori, sama ada RAM atau GPU, kerana cache KV untuk konteks yang panjang boleh menjadi sama besarnya dengan model itu sendiri. huggingface.co. Cache respons juga boleh menjadi terlalu besar, yang bermakna mereka perlu ditumpahkan ke CPU atau cakera. Ini bermakna anda mesti memilih antara kapasiti dan saiz model atau batch throughput. Sebagai contoh, jika anda meletakkan sekurang-kurangnya 20 GB daripada 40 GB GPU untuk cache, tidak akan ada banyak ruang untuk model yang lebih besar atau untuk menangani lebih banyak permintaan. Untuk menangani masalah ini, penyelidik sama ada memampatkan tensors KV (Shutova et al., 2025) arxiv.org atau kuantiz mereka (4-bit vs. 16-bit yields ~4× penghematan memori). Kertas AQUA-KV dari "Cache Me If Kompleksiti dan Kejuruteraan Overhead: Caching menjadikan perkara-perkara lebih cepat, tetapi ia juga membuat perkara-perkara lebih rumit. Anda perlu menetapkan cara yang selamat daripada benang, latens rendah untuk menyimpan, mencari, mengemas kini, dan membatalkan entri, yang sering bermakna menggunakan gudang luaran seperti Redis untuk cache terdistribusi, yang boleh gagal. Untuk memastikan bahawa perkara-perkara bertindak balas, anda mungkin perlu melakukan kejuruteraan berhati-hati, seperti menggunakan panggilan async yang tidak menghalang atau struktur bebas kunci. Debugging juga menjadi lebih sukar kerana output yang tidak dijangka boleh datang daripada data cache lama atau rosak daripada model itu sendiri. Itulah sebabnya penting untuk mempunyai logging yang baik dan pemantauan untuk hits cache dan kegagalan. Dalam bidang bertaruh tinggi seperti penjagaan kesihatan dan kewangan, Keselamatan dan Privasi: Jika tidak dikendalikan dengan betul, caching prompts dan outputs sensitif boleh menjadikan data peribadi awam. Dalam sistem pelbagai penyewa, sentiasa hadkan capaian cache kepada permintaan yang telah diluluskan dan entri skop kepada satu pengguna atau sesi. Cache juga menjalankan risiko serangan saluran samping, yang membuat penyiar melihat pertanyaan orang lain. Untuk mengurangkan risiko, mengehadkan atau mengenkripsi kandungan cache sensitif. Walau bagaimanapun, enkripsi boleh membuat perpaduan semantik lebih sukar. Juga, peraturan seperti GDPR boleh mengendalikan outputs AI cache sebagai data yang disimpan, yang bermakna mereka mesti dipadamkan jika pengguna meminta. Sebagai caching AI menjadi lebih biasa, isu-isu keselamatan dan kepatuhan ini menjadi lebih penting. Cache Coherence dalam Sistem Distributed: Cache Distributed membolehkan anda membuat salinan data, tetapi ia mempunyai masalah dengan konsistensi. Sebagai contoh, kemas kini atau kegagalan dalam satu kes tidak selalu dilihat oleh yang lain, dan apabila dua replika kehilangan cache yang sama pada masa yang sama, mereka mungkin perlu mengira semula dan berlumba untuk menulis entri yang sama. Untuk menghentikan duplikat, anda memerlukan operasi atom atau kunci. Sebagai contoh, perintah atom Redis menyokong ini. Medium. Untuk membina cache yang didistribusi, anda perlu memilih protokol konsistensi yang kuat atau menerima konsistensi yang mungkin dengan bacaan dan tulis yang tidak teratur. Redis. Pengujian dan penyesuaian strategi ini menjadi terutamanya sukar dalam perkhidmatan LLM, di mana entri cache boleh menjadi sangat besar atau kunci oleh embeddings yang rumit. es Walau bagaimanapun, yang Ini untuk banyak tujuan. Oleh itu, ia tidak boleh menjadi kejutan besar bahawa hampir setiap perkhidmatan LLM yang merangkumi syarikat melibatkan caching kedua-dua bentuk atau mana-mana yang lain, dan perbezaan adalah sesiapa yang meletakkan kerja reka bentuk ini untuk menangani perangkap. Mengurangkan risiko: Perkara cache yang tidak ultra-sensitif (atau hanya berubah perlahan-lahan) + Gunakan banyak strategi kegagalan cache + Pegang mata pada kadar hit / penggunaan ram dan Mempunyai fallbacks (jika sesuatu yang funky berlaku dengan cache anda, sistem akan berfungsi, ia hanya akan lambat).Kami mula melihat alat dan perpustakaan yang lebih baik untuk menangani banyak daripada itu secara automatik (contohnya, cache enkripsi peringkat kerangka atau pengesahan auto pada kemas kini model). overall performance gains of caching generally significantly exceed LLM sangat berkuasa, tetapi tidak percuma seperti yang telah kita lihat dan menambah lapisan tambahan kerumitan kepada LLM - cache. Akademik LLM kini tahu yang pertama! tetapi dengan reka bentuk yang baik, kompromi boleh dikendalikan, dan faedah yang besar boleh dicapai. Terdapat hanya dua perkara yang sukar dalam Sains Komputer: kegagalan cache dan nama perkara-perkara Future Directions and Research Opportunities Arahan masa depan dan peluang penyelidikan Bidang cache LLM sangat dinamik, dengan banyak jalan yang menarik yang penyelidik dan jurutera sedang menyiasat untuk mengembangkan lagi keupayaannya: Adaptive and Intelligent Caching: Machine learning boleh membantu dengan kebijakan caching dan pengusiran. Sebagai contoh, agen RL cuba mendapatkan ganjaran jangka panjang (hit rate × correctness). Mereka boleh prafetch data yang mereka fikir mereka akan perlukan, seperti OS membaca-ke depan, cache hasil popular semasa masa sibuk, dan menyingkirkan entri yang tidak bernilai banyak. Eksekusi spekulatif berlaku apabila cache secara aktif mengira dan menyimpan data yang mungkin berlaku. Pembelajaran meta berdasarkan LLM boleh menebak perhitungan pertengahan mana yang akan mahal dan menyimpannya dalam cache. Pembelajaran penguatkuasaan juga boleh menguruskan pengusiran dengan menyingkirkan entri yang tidak mungkin berguna di masa depan. Ini termasuk perkara-perkara seperti mengurutkan melalui bug perisian, seperti meringkaskan aliran kod dan memberikan diagnostik terperinci atas permintaan. K Kompresi Cache dan Penyimpanan Efisien: Quantization dan pemotongan adalah dua kaedah yang digunakan untuk melemahkan cache. AQUA-KV memampatkan tensor KV kepada hanya beberapa bit dengan sedikit kerugian kualiti (Shutova et al., 2025). Pruning, seperti drop stopword KVs, menyingkirkan entri yang tidak diperlukan. Dalam konteks yang panjang, Anchor Attention hanya menyimpan token KV "anchor" dan memampatkan sisanya (Sun et al., 2024). Cache "kehilangan" eksperimen mengambil vektor yang serupa dan menggabungkan mereka ke dalam satu. Memori lebar band tinggi atau memori kelas penyimpanan (Optane) boleh membuang cache KV dengan pertukaran latensi P99 di sisi perkakasan. Ini boleh membawa kepada kebangkitan pelayan cache yang terpecah Caching Cross-Modal dan Cross-Domain: LLM Multimodal dan bahkan terjemahan video memerlukan caching khas. Sebagai contoh, penyimpanan embeddings imej membolehkan anda melampaui pemprosesan semula imej yang telah anda lihat, dan caching snippets audio yang dipaparkan membuat pembantu suara bekerja lebih cepat. Untuk setiap jenis data, anda memerlukan strategi yang berbeza. Sebagai contoh, hash perceptual untuk imej dan sidik jari audio untuk audio. Caching terfederasi di seluruh peranti tepi boleh berkongsi hasil biasa secara peribadi, yang selaras dengan jaminan privasi pembelajaran terfederasi. Seperti cache pelayar global untuk pembantu AI, cache komuniti membolehkan banyak pengguna atau peranti menambah ke dalam kolam bersama (menggunakan enkripsi homomorphic atau enclaves selamat). Ini membolehkan anda menjawab soalan Caching dalam Latihan dan Penyesuaian Fine: Caching juga boleh digunakan untuk Latihan dan Penyesuaian LLM, bukan sahaja untuk kesimpulan. Untuk mengelakkan I/O cakera, berjalan skala besar sudah menyimpan set data tokenized dalam memori. Cache masa latihan menyimpan keadaan pertengahan dengan cara yang lebih inovatif. Sebagai contoh, model pelbagai tugas boleh menggunakan perwakilan siri di seluruh tugas bukannya menghantarnya lagi. Menyimpan bias atau gradient yang sering digunakan dalam cache juga mengurangkan pengkomputeran yang tidak perlu. Ia terutamanya membantu dengan penyelidikan, tetapi juga mengurangkan kos dalam pembelajaran berterusan atau RLHF dengan melepasi langkah-langkah yang diulang. Google's Retro (2022) menggunakan cache kepingan teks sebagai lapisan pemulihan yang berbeza. Ini menghentikan backprop penuh melalui mereka dan menjimatkan Pengurusan Cache dan Kawalan Kualiti: Perubahan penting lain yang perlu berlaku di masa hadapan adalah mengkaji secara teratur jawapan cache untuk menjaga pengalaman pengguna yang baik. Jika jawapan cache LLM hampir tidak melewati penapis, maklum balas pengguna, seperti pengubahsuaian berulang, boleh bermakna bahawa ia perlu diubah atau dihapuskan. Ini akan mewujudkan loop maklum balas yang terus meningkatkan cache dan mengubahnya menjadi pangkalan pengetahuan hidup. Kerja latar belakang yang dijadualkan boleh mengira semula dan mengemas kini entri cache teratas kerana model yang mendasari dilatih semula atau disesuaikan dengan baik. Dengan cara ini, jawapan popular mendapat generasi yang lebih baik. Kaedah ini serupa dengan bagaimana enjin caching menyegarkan halaman cache apabila kandungan sumber berubah. Sistem boleh menyeimbangkan peningkatan prestasi caching dengan ketepatan jawapan jangka panjang dan Lapisan API Standarisasi dan Cache: Tidak menghairankan jika kita melihat lapisan-lapisan yang disetorkan dalam lapisan pembelajaran mesin yang berorientasikan khusus untuk caching. Pada masa ini, setiap rangka kerja atau aplikasi mesti mencipta logik cache mereka sendiri. Mungkin kita boleh, tetapi seseorang boleh membayangkan beberapa "API caching" jenis yang ditawarkan oleh pembekal model atau rangka kerja yang berkhidmat dan membenarkan pengembang untuk menyambungkan logik tersuai mereka (hampir seperti plugin cache dengan pelayan web). Sebagai contoh, OpenAI atau pembekal lain boleh menyediakan parameter API untuk mengaktifkan dan mematikan kecekapan caching, mungkin mendefinisikan tahap agresi dalam pembinaan cache hits, atau sama ada hasilnya hendaklah konsisten dengan kesamaan semantik. Penyimpanan / Scratch Oleh itu, kelihatan bahawa masa depan caching LM agak cerah dan dipenuhi dengan penyelesaian baru. Secara keseluruhan, dorongan adalah jelas: apabila kita melancarkan model yang lebih besar untuk bilangan pengguna yang lebih besar, strategi caching adalah tempat yang mudah untuk mengambil sedikit slack. Iterasi seterusnya akan meningkatkan caching (digerakkan oleh pembelajaran), mengurangkan beratnya (kompresi dan pengurusan yang lebih baik dalam memori), dan menjadikannya lebih meluas di seluruh modalitas yang berbeza dan untuk latihan/inference.* Jadi ia adalah perlumbaan Arms, bukan sahaja untuk membina model yang lebih besar tetapi untuk melayani mereka lebih pintar._* Melalui ini, caching dan peningkatan kecekapan adalah mengapa LLM seperti GPT-4 dan Llama-2 boleh berjalan begitu cepat dalam antarmuka chat (seperti seorang jurutera Hugging Face quipped — “alasan mengapa Dari sini, mungkin mereka yang mempunyai strategi cache yang paling agresif boleh memenangi tajuk menawarkan perkhidmatan AI yang paling cepat dan akhirnya paling murah. Melayu kepada Melayu.co Rujukan : Antropik (2024 pada 14 Ogos) Diambil daripada Anthropic News: Perbincangan singkat dengan Claude kepada anthropic.com kepada anthropic.com Hinton, G., Vinyals, O., dan Dean, J. (2015). NIPS Deep Learning dan Workshop Pembelajaran Perwakilan. Distilasi Pengetahuan dalam Rangkaian Neural P. Lewis dan rakan-rakan (2020) Perkembangan Sistem Pemprosesan Maklumat Neural. Retrieval-Augmented Generation untuk NLP Intensif Pengetahuan. Paul, R. (2025 pada 20 April) Perbincangan di blog Rohan. Strategi Caching dalam Perkhidmatan LLM untuk kedua-dua latihan dan kesimpulan. Melayu kepada Melayu.com Melayu kepada Melayu.com Pol, S. (2025 6 April) Kumpulan Blog Medium Mempercepatkan Transformer Inference dengan KV Caching. Pihak berkuasa : sudhirpol522.medium.com Pihak berkuasa : sudhirpol522.medium.com Rujukan N. (2019) arXiv:1911.02150 daripada . Transformer Decoding Pantas: One Write-Head ialah semua yang anda perlukan. Arsip.org Shutova, A., Malinovskii, V., Egiazarian, V., et al. (2025). arXiv:2501.19392 daripada . Cache Me If You Must: Kuantizasi nilai kunci adaptif untuk model bahasa yang besar. Arsip.org Yazdani Aminabadi, R., Rajbhandari, S., Zhang, M., et al. (2022). Tajuk : 2000032 . DeepSpeed Inference: Membolehkan Inference yang berkesan daripada model Transformer pada skala yang belum pernah terjadi sebelumnya. Arsip.org Kwon, W., Li, Z., Zhuang, S., et al. (2023). Prosedur SOSP 2023 . Pengurusan memori yang berkesan untuk model bahasa besar yang berkhidmat dengan PagedAttention (vLLM). Blog.Penghormatan Blog.Penghormatan Hugging Face Transformers Kumpulan (2023). Tag: muka muka muka blog Mengoptimumkan LLM anda dalam pengeluaran. Melayu kepada Melayu.co Melayu kepada Melayu.co Lorello, S., McCormick, R., dan Partee, S. (2023). Blog teknikal Nvidia Cara Membina Cache Inference Distributed dengan NVIDIA Triton dan Redis. (Rujuk tambahan untuk ketekunan akademik dan kesempurnaan boleh dimasukkan mengikut keperluan untuk mencocokkan semua kutipan di atas.)