אופטימיזציה של הביצועים של LLM עם LM Cache: ארכיטקטורות, אסטרטגיות ויישומים בעולם האמיתי

Abstract abstractעריכה מאמר זה מציע תובנה טכנית מעמיקה במחקר על הפעילות של LM Cache וכיצד מכונת ה-Caching משפרת את היעילות, הגדלת היכולת והפחתת העלויות של הפצת מודל שפה גדולה (LLM). אנו בוחנים סוגים שונים של ארכיטקטורות ומנגנונים של ה-Caching, כיצד ניתן לשלב אותם עם תשתית ה-AI החדשה ולהעריך את הביצועים. דוגמאות מהשדה מתארות כיצד חלק מהלקוחות הגדולים ביותר שלנו מפעילים את ה-LM Caches בפועל ומה הם למדו לאורך הדרך. Introduction הוצאת תחשבו על עוזר AI שצריך לספק את אותן התשובות כל היום במשך מאות שעות!זה לא תוצאה, האם הוא צריך לייצר מחדש את כל התשובות מההתחלה, בכל פעם? בייצור, כל שאלה למודל גדול עשויה לעלות שניות וחשבונאות GPU משמעותית.בזכות הגדלת גודל המודל והציפיות של המשתמשים, הצורך בהשלכות מהירות הופך להיות חשוב יותר מאי פעם. deployment at scale is stymied by latency requirements, computational cost and memory footprint לקחת את כל אלה בחשבון, ה- LM cache מופיע כמו תשובה חכמה מאוד לבעיות אלה על ידי חיתוך ושימוש מחדש של תוצאות כבר מחושבים. חיתוך הוא בעיקר מה המאפשר למערכת שלנו לזכור את כל מה שהיא ראתה קודם לכן. הרעיון הכללי של המושג אינו חדש במדעי המחשב, אבל יש לו פריצת דרך פוטנציאלית LLM עצמה עבור עוצמה גדולה יותר באופן משמעותי והפחתה עצומה בזמן התגובה. כמו דיסטילציה מודל (יצירת מודלים קטנים יותר, מהירים יותר), ייצור הגדלת החיפוש (נפח על בסיסי ידע חיצוניים), ואת מסדי נתונים וקטור עבור חיפוש סמנטי, LM Cache מגדיל טכניקות אופטימיזציה אחרות. עם מדידה סופית של Foundations of LM Cache תגית: LM Cache הרעיון של הוא פשוט מחשב לשימוש חוזר כדי לא לעבוד יתר על המידה.במקרה של תפיסה LLM, קיצור קערה יכול להתקיים ברמות שונות של גרניליות: 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 תגית: True הקודם KV הקודם KV תגית: Decode Next כל הרמות המוזכרות לעיל משמשות את העיקרון הפשוט של בשל המנגנון של תשומת לב עצמית, החישוב של כל טוקן חדש LLMs מבוססי טרנספורמטר תלוי לעתים קרובות טוקנים קודמים. בין אם ברמה המיידית או עמוק בתוך המודל, חיבוי התוצאות של החישובים הקודמים האלה מאפשרים לפעולות הבאות לקפוץ ישירות לתוצאה הסופית. system shouldn't re-compute what you have already done LM Cache Architectures and Strategies LM Cache ארכיטקטורות ואסטרטגיות מאחר שלא כל עומסי העבודה הם זהים במערכות LLM, מספר גדול של ארכיטקטורות ואסטרטגיות תוכננו על ידי מהנדסים כדי למקסם את ההקלטה ולהפחית את ההפרשות. קשיחים סטטיים vs. דינמיים: קשיחים סטטיים מגיעים עם זוגות input/output מלאים מראש, מה שהופך אותם נהדרים עבור עומסי עבודה צפויים. אלה הם פתרונות קשיח לשאלות נפוצות או פלטים קבועים, כגון FAQs או תשובות מקרה מבחן. קשיחים דינמיים, מצד שני, ממלאים כמערכת פועלת, משתנים כדי להתאים דפוסי תנועה, לשנות הפצות שאילתות, ופיקים לשימוש. הם למעשה "לומדים" מהתנועה של משתמשים כדי לשפר את שיעורי ההשפעה. בחיים האמיתיים, מערכות מגבילות קשיחים דינמיים על ידי שימוש במדיניות של ביטול המבוססות על ביקוש הנוכחי, אשר מתאמת באופן אוטומטי Keep Distributed and Federated Caching: בפיתוחים גדולים עם מקרים רבים של LLM על שרתים שונים או Pods, קשיחים למכונה אינם עובדים לשימוש חוזר בין שרתים. לדוגמה, אם שרת A מעבד ומחזיר בקשה, שרת B חייב לחשב מחדש את התשובות גם אם הוא לא יכול לגשת ל- Server A. קשיח מפוזר פותר את זה על ידי שיתוף רשומות דרך חנות חיצונית, כגון Redis. שרת Triton Inference של NVIDIA הוסיף קשיח מפוזר בשנת 2023, למרות שהרשת מוסיפה רק כ 8% יותר עיכוב מאשר קשיחים מקומיים בתהליך. (Lorello et al., 2023; פול, 2025) rohanpaul.com. לאחר מכן, ש חיתוך במדרגות וחיזוק זיכרון GPU / TPU: חיתוך אינו מוגבל לתוצאת; זה יכול לשמש גם שכבות LLM ספציפיות. כדי למנוע את הצורך לחשב שכבה בינונית יקר שוב על חיתוך הישג, ניתן, לדוגמה, לחיתוך את היצירות של שכבה זו עבור כניסות קבועות ספציפיות. בנוסף, זה עשוי להיות הגיוני כדי לחיתוך רק את ההפעלה היקרה ביותר או להשתמש זיכרון על צ 'יפ עבור חיתוכים על מזרקים חומרה (GPUs / TPUs), שבו זיכרון הוא בעל ערך. אנלוגיים של טכניקות כגון בדיקת gradient, אשר כרוך חישוב מסחר עבור חיתוך זיכרון במהלך אימון, מאפשר לך לשמור באופן ס Cache Granularity and Keys: Choosing a cache index is a smart move. Exact-match keys on the full prompt string are easy to use, but they break easily — any change misses the cache. To get more hits, systems use embedding-based semantic hashes that treat promps as the same even if the wording is different, or prefix/chunk keys that match overlapping segments. After processing a stable prefix, "prefix caching" takes a snapshot of the model's KV state. This way, a new prompt that starts with that prefix can quickly move to that state. The open-source vLLM project does this automatically by finding shared prefixes in incoming requests and reusing cached tensors. This speeds up processing of long promps by a huge amount (Kwon et מדיניות גודל קח וביטול: מכיוון שהזיכרון קח מוגבל, LLMs להשתמש במדיניות כגון LRU או LFU כדי להחליט אילו רשומות לשמור ואילו לבטל. זה משחרר מקום לנתונים חדשים. בנוסף לביטול פריטים בהתבסס על גיל או תדירות, קח LLM חייב גם להתמודד עם התדרדרות רלוונטיות ו מודל או עדכוני נתונים על ידי הסרת פריטים ישנים. בשנת 2024, מחקרים הראו כי החיפוש מבוסס למידה עובד: קח שהוכשרו כדי למצוא ולהיפטר מפתחות עם ערך עתידי קטן (Xiong et al., 2024). אלה, "חכמים" מערכות ביטול מתאימים, אשר עשויים עבור עומסי עבודה LLM, יהפכו ככל הנראה לנורמה לניהול בקיצור, בניית קישוריות LM היא איזון עדין: אנו רוצים למקסם את שיעור ההצלחה תוך הפחתת עלייה כגון צריכת הזיכרון וטיפוח. אם זה אומר שאתה צריך לעבוד עם מערכות תרגום מכונה יותר קשה, אז להיות האורח שלי! האסטרטגיות האלה (סטטי vs. דינמי, ארכיטקטורות מפוזרות, למשוך את קישוריות פגעו בטרמינולוגיה על ידי ייצור אותו בזמן הלקוח עם שפות דוגמא קודמות) הם כל הטריקים שיכולים לעזור לך לעשות יותר עם קישוריות מבלי לטפס על מלכודות הקשורות קישוריות. יישומים שונים יכולים לשלב שיטות אלה וליישם לדוגמה, מערכת ייצור יכולה להשתמש ברמה יישומים קישוריות סמנטית (למ תבנית ארכיטקטורה של LM Cache ב LLM Inference Pipeline להלן ארכיטקטורה של התייחסות המתארת את האינטגרציה של LM Cache בתוך זרימת ההשלכות טיפוסית של LLM: דיאגרם זרימת עבודה השוואת בקשות התייחסות מאוחסנות לעומת בקשות שאינן מאוחסנות כדי להבין עוד יותר את היתרונות, לשקול את השוואת זרימת העבודה בין בקשות ההשלכות המוקלטות והלא המוקלטות: אינטגרציה עם תשתיות AI מודרניות Caching LM אינו עומד לבדו – הוא יגיע ממערכת האקולוגיה הרחבה יותר של היישומים ב- AI. 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 תגית: True לסיכום, סטים מודרניים של ה- AI הם יותר ויותר כל כך "קאצ'ה מודעים. מערכות ברמה הגבוהה יותר מתחילות לשלב את זה, מהספרייה שמטפלת במכניקה בשבילך לארכיטקטורה המשתמשת בקאצ'ים ברחבי בקשות ותשתיות. קאצ'ינג הוא משהו שרוב שירותי LLM ישתמשו בו, שכן זה מה שחקני ה- AI הגדולים (OpenAI, Google ו- Microsoft למשל) דיברו על זה או עשו בהצעות LLM שלהם. כמה ספציפיות ידועות כמו OpenAI's ChatGPT (לא מסומנת בפומבי אבל האירוע הזה מתואר בפרט) כנראה משתמשת בקאצ'ינג בקשר שיחה בקנה מידה גדול; צוות של אנתרופיק של Claude ( Performance Metrics and Evaluation מדדי ביצועים והערכה בסדר, בתיאוריה קישוריות עשויה להיראות מדהימה אבל איך אנחנו יכולים למדוד את זה? יש כמה מדדי הביצועים הנפוצים המסייעים לך להעריך את היעילות של קישוריות LM איחור נמוך יותר: איחור נמוך יותר: היתרון העיקרי הוא איחור נמוך יותר, שהוא הזמן שהוא לוקח כדי לקבל תשובה. קישוריות משנה את הקירבה של הביצועים: קישוריות ראשונה מציעה לך תנועה גבוהה ואיטיות נמוכה יותר באופן עקבי. אנו עושים זאת על ידי הסתכלות על הזמן זה לוקח כדי לבצע בקשות עם ובלעדי קישוריות. צ'אטובט אשר לוקח בדרך כלל 2 שניות כדי לענות על שאלה יחזור ב 0.2 שניות אם הוא פוגש את קישוריות, אשר 90% מהיר יותר. מהירות האמיתית תלויה בקצב ההצלחה. לדוגמה, אם 80% מהקלטות הן 1000 פעמים מהירות יותר, האיחור הכולל יהיה הרבה יותר טוב. צוותים מדברים לעתים קרובות על איחור p50 ו-p95 עם שיפור ה- Throughput: עם קישוריות, ה- DenseNet Benchmark עבור NVIDIA Triton הלך מ- 80 ל- 329 inf/sec (כ 4×) ומודלים קלים יותר ראו עלייה של 20% עם קישוריות תגובה. rohan-paul.com. כשמדובר בשירות LLM, PagedAttention של vLLM משתמש בניהול קישוריות KV חכם יותר לבקשות קבוצתיות טובות יותר, כלומר הוא יכול לטפל עד 24 פעמים יותר בקשות מאשר Hugging Face Transformers. vLLM Blog. במצבים עם יותר ממשתמש אחד, מדידת קישוריות קישוריות היא חשובה מאוד. חיסכון במחשב / עלות: זוהי התוצאה הדולר-סנט של חיתוך. מכיוון שהחיתוך יחסוך גם במחשב מיותר, הוא למעשה חוסך FLOPs כי הם כסף (לדוגמה, כאשר אתה משלם על ידי השעה GPU או שיחת API). המטריקה הנפוצה לכך היא השימוש ב- GPU ואפילו זמן מחשב הכולל נשמר. לדוגמה, אנתרופיקה טען כי בשיחות ארוכות יותר, חיתוך מיידי יכול להפחית את צריכת ה- token (ולכן עלות) על ידי 90% (אנתרופי, 2024), anthropic.com. זה גם התבטא בתכנית המחירים - שימוש ב- tokens חיתוך עולה גודל של סדר פחות מאשר יצירתם מ scratch.bdtechtalks.com Hit Rate and Miss Penalty: אלה הם מטריקים ספציפיים ל-Cache. Hit Rate: אחוז הבקשות (או תוויות) שהושלמו על-ידי ה-Cache שיעורי ההשפעה הגבוהים יותר פירושו שיפור ביצועים טוב יותר באופן כללי. אלה שימושיים לדווח, כגון "המערכת שלנו היתה שיעור ההשפעה של ה-Cache של 60% על הודעות ב-prod (X למעשה X נגד Y ללא ה-Cache). The miss penalty is how much slower a cache miss vs hit. In other words, some of the time the addition of a cache introduces some overhead (e.g. computing an embedding for semantic search, or an extra network hop to check a distributed cache) - if the miss still does the full run model plus this זיכרון ו- Overhead Trade-offs: Caching שומר על יציאות מודל או מצבי ביניים, אשר משתמשים יותר RAM GPU. עבור הקשרים הארוכים, קאש KV גדל בשורה ישר. לדוגמה, קאש של מודל 405 B עבור 16k טוקינים יכול להשתמש בערך 15 GB (כחצי גודל המודל). GitHub. השתמש במטריקים כגון "זיכרון overhead לכל טוקן נוסף" או "קאש-גודל יחסים" כדי להבין את ההבדלים. באמצעות טכניקות כגון תשומת לב רב-בקשה, אתה יכול לחתוך קאש מעשרות ג'יגה-בייטים לכמה מאות מגה-בייטים. זוהי ירידה של 97% עבור 16k סדרות עם אובדן קטן של דיוק דיוק/איכות השפעה: היציאה של המודל לא צריכה להשתנות (למעט להיות משרתת עם תוצאה פוטנציאלית מעט מאוחרת) בגלל קישוריות. עם זאת, במודלים מסוימים של קישוריות (למשל אלה שהם קרובים או סמנטיים), התשובה עלולה להיגמר לא מתאימה לחלוטין מן השאילתה החדשה. אז, אנחנו יכולים לראות אם קישוריות מייצרת אובדן איכות או לא. בפרט, אם אנחנו קישוריות קישוריות קישוריות לשאילתה החדשה והתשובה של השאילתה החדשה צריכה להיות עדיין נכונה, כך שאפשר לבחון כדיוק או רלוונטיות ציון. בקהילה האקדמית, כי אמצעי איכות הוא לעתים קרובות מתייחס ל" שיעור ההצלחה " השוואה עם Baselines: חוקרים לעתים קרובות להשוות מודל קישוריות משופרת עם מודל בסיסי ללא קישוריות כדי למדוד את הרווח. ייתכן גם לדון בהשוואות של שיטות קישוריות שונות. לדוגמה, קישוריות מדויקות מול קישוריות מבוססות השבבה מול קישוריות ללא קישוריות במערך נתונים של שאילתות, עם זקנות ודיוק עבור זה. vLLM vs Vanilla HF Server Throughput & Memory. מחקרים השוואתיים אלה מחושבים ספציפיות כדי לאשר את האינטואיציה כי קישוריות כרגיל אצבע היא רעיון טוב. תוצאה דוגמה יכולה להיות: קישוריות משופרות דרך 2× ו זקנות על ידי 40%, במחיר של GB נוסף (גבי אם אנו מעריכים את ה- LM caching, חשוב לשקול את הסתייגויות שבהן אתה יכול לחסוך על מחשב, אבל על חשבון יותר זיכרון; עתירות קצה נמוכה יותר, אבל צריך להתמודד עם תשובות קבועות מקבילות. שני המאמרים האקדמיים והדוחות התעשייתיים מתחילים לכלול קישוריות בביקורותיהם, וזה הגיוני בהתחשב בהפצה הרחבה של קישוריות. בסקר מאוחר יותר של 2024, התברר כי כמעט כל ההגדרות המובילות למשימות LLM בקשר ארוך התבססו על צורה כלשהי של קישוריות או אופטימיזציה של תשומת לב כדי להתמודד ביעילות עם אורך הקשר (Chen et al., 2024). המספרים הם ניצחונות גדולים באופן עקבי. במילים פשוטות: קישוריות מפחיתות את העיכוב, מגדילה את התפוקה ומורידה את העלות לשאילתה על ידי שניהם משרתים בקשות חדשות מהר יותר ומונעות עבודה כפולה. ללא אופטימיזציות אלה, כל הערכה של LLM משרת יהיה רחוק מלהיות שלם. יונתן פול.com Real-World Case Studies מחקר מקרים בעולם האמיתי כולנו יודעים כי קישוריות היא לא רק למען טיעון אקדמי, ותכונות אלה מביאות ערך ניכר בפועל. שיחה AI (Chatbots / עוזרים): במקום להקפיד מחדש את ההיסטוריה המלאה בכל סיבוב, LLMs צ'אט רב-סיבובים מקסימום שיחות קודמות. לדוגמה, הם מקסימום את השאלה הראשונה של המשתמש ועוזר תשובות כך רק כניסה חדשה מעובדת על שאלות מאוחרות יותר. huggingface.co. זה מאפשר למערכות כמו ChatGPT להגיב במהירות מבלי לעשות את כל המתמטיקה שוב. עם קשיח מופעל, Claude של אנתרופי 3 מאפשר למפתחים לשים את הקשרים הארוכים, אשר מקצץ את האינטנסיביות על ידי 79% ועלות על ידי 90% על מדריך 100k-טוקן. (אנתרופי, 2024) anthropic.com. Xiaoice מ מי השלמת קוד ותמיכה: GitHub Copilot ו- TabNine משתמשים ב-Caching כדי להאיץ את השלמת הקוד. המודל יצטרך לעבד מחדש את כל הקשר בכל פעם שאתה לוחץ על מפתח, מה שהופך אותו מאוד איטי. במקום זאת, הם מאחסנים את הייצוג של המודל של הכותרת ב-Cache, כך שרק תווים מצורפים מעובדים. זה נקרא קישוריות הכותרת. הרבה הצעות קישוריות חוזרות על עצמן (כמו פיבונצ'י), אז קישוריות ברמה של הצעות נותנות לך את אותן השאלות מיד. זה גם מטפל באותן שאילתות מפתחים בין הפגישות כך שניתן להשתמש בהן מיד. בפורום, LLM יכול לאחסן זוגות Q&A עוזרי "קופילוט" ארגוניים: חברות רבות מפעילות עוזרי AI פנימיים – סוג של קופילוטים של ה-AI המסייעים לסיכום מסמכים, יוצרים תערוכות דואר אלקטרוני, עונים לשאלות עסקיות ממסמכים פנימיים וכו 'אלה בדרך כלל פועלים על בסיס ידע מוגדר מראש (דוקי החברה, ויקי, דוחות) קישוריות היא בעלת ערך רב גם כאן, במספר שכבות: אתה יכול לקח קופילוטים של מסמכים פנימיים כדי להחזיר אותם מהר יותר; אתה יכול לקח קופילוט כמה תשובות לבקשות פנימיות נפוצות ("איך אני מגיש דוח עלויות?"). הם יכולים אפילו להיות מקופלים כך שאנחנו לא מייצרים מחדש כמה תוצאות, או תוצאות חלקיות כלים / סוכנים מרובים: קישוריות יכול לקצר מעגלים במערכות סוכני AI המורכבות (כמו סוכן מתכנן משימה באמצעות שיחות LLM מרובות, וכלים משתמשים). עכשיו לשקול סוכן שמגיב על שאלות על ידי שאלת שירות אינטרנט ולקבל תוצאות לשימוש ככניסת עבור LLM. במקרה כזה, אם אותה שאלה נשאלת שוב, הסוכן יכול להשיג את התשובה הקודמת מהקישוריות שלו ישירות (במקום להזמין מחדש את הכלים) או לומר שאפשר להשתמש מחדש בכל תוצאות החיפוש (יציאות כלי קישוריות כמו גם יציאות LLM). זה קשור למושג של קישוריות מתכנן או קישוריות תוצאות כלי. תוצאות שיחות ביניים מאוחסנות על ידי פרויקטים כמו LangC שירותי אינטרנט בקנה מידה גדול: זה נכון במיוחד במקרה של מנועי החיפוש שיכולים להרוויח באופן דרמטי מחיקת תשובות LLM. לדוגמה, Bing Chat משרת מיליוני משתמשים ויש הרבה בקשות חוזרות. אם backend LLM של Bing (שהוא GPT-4) מחיקה תשובות לשאלות פופולריות ("מהו הבירה של X", "איך לעשות עוגות"), זה יכול להחזיר אותם מיד במקום לייצר מאפס בכל פעם. במציאות, החיפוש הלא-LLM של Bing למעשה השתמש בחיפוש חיתוך במשך עשרות שנים; עם תשובות LLM מופיעים עכשיו אנחנו רואים את אותה דפוס מדויק. החוקרים רק הראו מערכת שכאשר היא מצאה תוצאות עבור חיפוש, מחיקת אותם כי אותה החיפוש פירושו הפחתות באוגוסט 2024 השרתים של Anthropic יכולים לאחסן מסגרות ענקיות ולא הכרחיות, כגון ספר (100,000 טוקינים). כתיבה לקאצ'ה עולה 25% יותר לכל טוקיני כניסה, אך קריאת תוכן בקאצ'ה עולה רק 10% מהשיעור הבסיסי. השיחה הראשונה שומרת נתונים; השיחות הבאות משתמשות ב-Prompt ID כדי למצוא אותו ולשלוח רק תוכן חדש. עלות ההזמנות של 10,000 טוקינים ירדה בכ- 86%. סוכני שיחה, עוזרים בקוד ו- Q&A של מסמכים גדולים הם כל השימושים הנפוצים, והקשר יציב הוא הטוב ביותר עבור הישגים במקלדת. Anthropic עשה קישוריות עסקית חזקה על ידי שילוב שיפורים ביצועים עם תמריצים פיננסיים.זה לא מפתיע כי מתחרים כמו OpenAI ו- Google מוסיפים תכונות דומות כדי לקבל את אותן יתרונות עלות וטינטציה. Anthropic's Claude 3 added Prompt Caching אנתרופי cost of 100,000-token prompts went down by 90% אנתרופי מקרה אחר : OpenAI לא פיתחה על כל זה בפומבי, אבל ייתכן שתוהה אם המפתחים מתאימים ו / או מספקים טקסטים של כמה צילומים בכל בקשה, החלק הזה יכול להיות מאוחסן בצד השרת, כך שהמודל לא צריך לקודד מחדש את הדוגמאות האלה מהעצם בכל פעם.זה דומה לגישה של Anthropic.למשל, אם אתה שולח את אותו 2000 טוקן מערכת הזמנה + הוראות על כל שיחת API (מה שרבים עושים), OpenAI יהיה לקח את המודל המוטבע של זה בפנים ורק להתחבר עם הצגת מעובד של השאילתה שלך.זה יהיה גלוי לחלוטין למשתמשים אבל (יכול להציל אותם) בכמויות גדולות של מחשב ויעזור OpenAI להתמודד עם יותר עומס על OpenAI's system messages and few-shot examples caching באופן כללי, כמעט כל חברות ה-AI הגדולות משתמשות ב- LM caching בעולם האמיתי. בעוד OpenAI, Anthropic, Microsoft, Google ו- Hugging Face דיברו או מסמנו אסטרטגיות caching עם למידה שונה כתוצאה מכך, רובם חולקים את אותה המסקנה: caching מספק שיפור ענק ביצועים, אבל זה הופך להיות חשוב לנהל את טריוויה של cache מבלי להקריב זיכרון וגמישות. סיפורים של "אנחנו דחפו קערה וראינו ירידה של 30% בשימוש ב- GPU שלנו תוך שמירה על QPS נקי" אינם חסרי תקדים. caching is the ticket to turbocharging LLM applications. Challenges and Limitations אתגרים ומגבלות כמובן, קישואים אינם כדור כסף.זה, כמובן, קצת טריוויאלי – אם זה היה קל, כולם היו מחבקים את כל הדברים אחרי הכל! אי תוקף קח (Stale Data): כאשר הנתונים הבסיסיים או עדכון LLM משנים את המשמעות של תשובה, יציאות קח הופכים לא יציבים, בדיוק כמו בעיות אי תוקפנות קח האינטרנט. תיקון נאיבי הוא לנקות את כל קח כאשר המודל מתעדכן. זה קל אבל מבוזבז כי זה מוחק רשומות שעדיין תקף. יש אנשים המשתמשים "אם לא נמצאו, להשיג טרי" הכלל, אבל זה יכול לגרום להם לאבד נתונים שימושיים. עדיף לתת פריטים ערך זמן לחיות (TTL) כך שהם נופלים לאחר כמות מסוימת של זמן, או לגרסת מפתחות קח על ידי מודל ID או פרמטרים כך שאתה לא משתמש רשומות ממודלים ישנים יותר. הוספת ת הקשר הלא קבוע בדיאלוג: כאשר ההקשר משתנה מאוחר יותר בשיחה מרובה סיבובים, התשובות המוקלטות עשויות להישאר קבועות. לדוגמה, אם אתה שומר תשובה לשאלה א ולאחר מכן המשתמש מוסיף מידע נוסף, באמצעות אותה תשובה שוב עשוי לפספס שינויים חשובים. כדי למנוע זאת, קשיחים לעיתים קרובות לשמור את מזהה השיחה המלא, לא רק את ההודעה האחרונה ביותר, או שהם רק לשמור על טווחים דיאלוגים קצרים יותר. במקום לשמור תשובות שלמות, אתה יכול לשמור קצרים, סיכום עשיר בהקשר במקום. זה מפחית את הסיכון שהם הופכים מיושנים. עדיין קשה לנהל קשיחים היטב. שינויי דחף וייחודיות: LLMs לעתים קרובות להתמודד עם כניסות שונות מאוד, כך חיתוכים נאיביים לא עובדים טוב מאוד. לדוגמה, יישומים של הדור היצירתי שדורשים ממך "לכתוב שיר על X בסגנון Y עם twist Z" כמעט אף פעם לא מקבל כל הישגים ללא חיתוך סמנטי. חיתוכים סמנטיים מנסים להגדיל על ידי תואמות השבבים, אבל הם עובדים רק כאשר השאילתות דומות מאוד. rohan-paul.com. היתרונות של חיתוך תלויים בחוסר עומס עבודה. חיתוכים KV הם תמיד שימושיים עבור יציאות ארוכות, אבל חיתוכת תגובה מלאה אקזוטית לא עובדת טוב אם אין שתי בקשות זה טביעת זיכרון: טביעות זיכרון משתמשות הרבה זיכרון, או RAM או GPU, כי טביעות זיכרון KV עבור הקשרים הארוכים יכול להיות גדול כמו המודל עצמו. huggingface.co. טביעות זיכרון התגובה יכול גם להיות גדול מדי, כלומר הם צריכים לשפוך על ה- CPU או הדיסק. זה אומר שאתה צריך לבחור בין קיבולת וגודל המודל או עוצמת החבילה. לדוגמה, אם אתה מציב חוץ 20 GB של 40 GB GPU עבור טביעת זיכרון, לא יהיה כל כך הרבה מקום עבור מודלים גדולים יותר או לטפל בקשות נוספות. כדי להתמודד עם הבעיה הזו, החוקרים או לדחוס טנטורים KV (Shutova et al., 2025) arxiv.org או לקוונטיז אותם (4 סיבי מורכבות והנדסה: קישוריות גורמות לדברים להיות מהירים יותר, אבל הן גם גורמות לדברים להיות מורכבים יותר. אתה צריך להגדיר דרכים בטוחות, עם אורך זמן נמוך לאחסון, לחפש, לעדכן ולשחרר רשומות, אשר לעתים קרובות פירושו שימוש בחנויות חיצוניות כמו Redis עבור קישוריות מפוזרות, אשר יכול להיכשל. כדי לוודא שהדברים מגיבים, ייתכן שיהיה עליך לבצע הנדסה זהירה, כגון שימוש בשיחות אסינקיות ללא בלוק או מבנים ללא מנע. דיבוגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגגג אבטחה ופרטיות: אם לא מנוהלים כראוי, זיהוי פקודות רגישות והיציאות עשוי להפוך את הנתונים הפרטיים לציבור. במערכות מרובות שכירות, תמיד להגביל גישה זיהוי לבקשות אשר אושרו ורישומים טווח למשתמש אחד או פגישה אחת. זיהומים גם להפעיל את הסיכון של התקפות ערוץ צדדי, אשר האקרים רואים שאילתות של אנשים אחרים. כדי להפחית את הסיכון, להגביל או להצפין תוכן זיהוי זיהוי. עם זאת, ההצפנה יכולה להפוך התאמה סמנטית קשה יותר. כמו כן, כללים כגון GDPR עשויים לטפל יציאות זיהוי AI כנתונים מאוחסנים, מה שאומר שהם חייבים להימחק אם המשתמש מבקש את זה. קוהרנציה קאשה במערכות מפוזרות: קאצה מפוזרת מאפשרת לך ליצור עותקים של נתונים, אבל יש לה בעיות עם עקביות. לדוגמה, עדכוני או אי תוקף באחד המקרים אינם נראים תמיד על ידי אחרים, וכאשר שתי עותקים מפסידים את אותו קאשה באותו זמן, הם עשויים להיות צריכים לחזור ולהרוויח כדי לכתוב את אותו רשומה. כדי להפסיק כתיבה כפולה, אתה צריך פעולות אטומיות או מנעולים. לדוגמה, פקודות אטומיות של רדיס תומכות בזה. בינוני. כדי לבנות קאשה מפוזרת, אתה צריך לבחור פרוטוקולי עקביות חזקות או לקבל עקביות אפשרית עם קריאות וכתובות זמניות. Redis. עם זאת, The לכן, זה לא יכול להיות הפתעה עצומה כי כמעט כל שירות LLM המקיף את הארגון כרוך בחינם של טופס אחד או אחר, וההבדל הוא כל מי שמציב את עבודת העיצוב הזה כדי להתמודד עם המלכודות. להקטין את הסיכונים: דברים בחינם שאינם רגישים מאוד (או פשוט משתנים לאט) + השתמש הרבה אסטרטגיות ביטול חירום + לשמור על מעקב על שיעור הפגיעה / שימוש RAM יש פסוקים (אם משהו funky קורה עם החיבור החיצוני שלך, המערכת תעבוד, זה יהיה רק איטי). אנחנו מתחילים לראות כלים וספריות טובים יותר כדי להתמודד עם רוב זה באופן אוטומטי (לדוגמה, חיבור חירום הצפנה ברמה של מסגרת או חיבורים אוטומטיים לאמת מודל overall performance gains of caching generally significantly exceed LLM הוא מאוד עוצמתי, אבל לא חופשי כפי שראינו ומוסיף שכבה נוספת של מורכבות ל- LLMs - ה- cache. אקדמאים LLM יודעים עכשיו את הראשון! אבל עם עיצוב טוב, את ההסכם ניתן לנהל, ואת היתרונות העצומים ניתן להשיג. יש רק שני דברים קשים במדעי המחשב: ביטול קערה ושמות דברים. Future Directions and Research Opportunities כיוונים עתידיים והזדמנויות מחקר שדה ה- LLM הוא דינמי מאוד, עם דרכים מרגשות רבות שהחוקרים וההנדסים חוקרים כדי להרחיב עוד יותר את היכולות שלה: זיהוי מתאים ואינטליגנטי: למידה ממוחשבת יכולה לסייע במדיניות זיהוי וחיסול. לדוגמה, סוכני RL מנסים להשיג את הפרסים לטווח הארוך ביותר (חיסול קצב × דיוק). הם יכולים להזין מראש נתונים שהם חושבים שהם יצטרכו, כגון OS קריאה קדימה, זיהוי תוצאות פופולריות בתקופות עמוסות, ולהיפטר מכתבים שאינם שווים הרבה. ביצוע סקרולטיבי מתרחש כאשר זיהוי מתרחש באופן פעיל לחשב ולשמור נתונים שעשויים להתרחש. מטה-למידה מבוססת LLM יכולה לנחש אילו חישובים ביניים יהיו יקרים ולשמור אותם בתיק. למידה מתוחכמת יכולה גם ל דיכאון קאצ'ה והאחסון היעיל: דיכאון ודיכאון הם שתי שיטות שהקאצ'ה משתמשת בהן כדי לרדת במשקל. AQUA-KV מדביקה את טנסי ה-KV רק לכמה סיביות עם אובדן קל של איכות (Shutova et al., 2025). דיכאון, כגון דיכאון קוו סטרפט, מסיר את ההודעות שאינן נחוצות. בהקשרים ארוכים, Anchor Attention שומרת רק את ה-KV של ה-token "אנקור" ומדביקה את השאר (Sun et al., 2024). קאצ'ה "אובדן" ניסיוניים לוקחים וקטורים דומים ומשלבים אותם לאחד. זיכרון בקנה מידה גבוה או זיכרון של מח Caching Cross-Modal ו- Cross-Domain: LLMs Multimodal ואפילו תרגום וידאו זקוקים ל-Caching מיוחד. לדוגמה, אחסון של התמונות מאפשר לך לעקוף את עיבוד התמונות שאתה כבר ראה, ו- Caching של קלטות אודיו שפורסמו גורם לעוזרי הקול לעבוד מהר יותר. עבור כל סוג של נתונים, אתה צריך אסטרטגיה שונה. לדוגמה, hashes תפיסה עבור תמונות ו טביעות אצבע אודיו עבור אודיו. Federated caching across edge devices can share common results privately, which is in line with federated learning's privacy guarantees. Like a global browser cache for AI assistants, community caches allow many users or devices to add to a shared pool (using homomorphic encryption Caching in Training and Fine-tuning: Caching יכול לשמש גם ללימודים ולימודים מתקדמים, לא רק למסקנות. כדי למנוע I/O דיסק, ביצועים בקנה מידה גדול כבר שומרים על קבוצות נתונים מסומנים בזיכרון. Caching-time שומרים את המדינות האמצעיות בצורה חדשנית יותר. לדוגמה, מודלים מרובים יכולים להשתמש בהצגת רצף בין משימות במקום לשלוח אותו שוב. אחידות אחסון או גרדינטים המשמשים לעתים קרובות ב-cache גם מפחית את חישובים מיותרים. זה עוזר בעיקר עם מחקר, אבל זה גם מצמצם את עלויות הלמידה המתמשכת או RLHF על ידי הימנעות של צעדים חוזרים. Google's Retro (2022) השתמש ב- ניהול קאש ואיכות בקרה: שינוי חשוב נוסף שצריך לקרות בעתיד הוא בדיקה קבועה של תשובות קאש כדי לשמור על חוויית המשתמש טובה. אם תשובות הקאש של LLM בקושי עברו את המסננים, משוב המשתמש, כגון מחזור חוזר, יכול להיות אומר שזה צריך להשתנות או להסיר. זה היה ליצור מעגל משוב שממשיך לשפר את הקאש ולהפוך אותו למסד ידע חי. עבודות רקע מתוכננות יכול לחשב מחדש ולעדכן את רשומות הקאש העליונות כמו המודל הבסיסי מתאמן מחדש או מתאים. בדרך זו, תשובות פופולריות מקבלות דורות טובים יותר. שיטה זו דומה לאופן שבו מנועי החיפוש לשדרג דפי קאש כאשר תוכן המקור סטנדרטיזציה ו-Cache API Layers: זה לא יפתיע אותנו אם נוכל לראות שכבות סטנדרטיות בקבוצת הלמידה המכונה ממוקדות במיוחד עבור חיתוך. כרגע כל מסגרת או יישום חייב ליצור את הלוגיה החיתוך שלו. אולי נוכל, אבל אחד יכול לדמיין כמה "API חיתוך" של סוגים כי ספקי מודל או מספקים מסדרים מציעים ולאפשר למפתחים להתחבר לוגיקה מותאמת אישית שלהם (כמעט כמו תוספי חיתוך עם שרתים אינטרנט). לדוגמה, OpenAI או ספקים אחרים עשויים לספק פרמטרים API כדי להפעיל את האפקטיביות של חיתוך, אולי להגדיר את רמות התוקפנות בבניית חיתוך הישגים, או אם התוצאות צריכות להיות ת תגית: Scratch לכן, נראה כי העתיד של חיתוך LM הוא די שמש ומלא פתרונות חדשניים. באופן כללי, הדחף הוא ברור: כאשר אנו מפתחים מודלים גדולים יותר עבור מספר גדול יותר של משתמשים, אסטרטגיה חיתוך היא מקום קל לקחת קצת סלאק. התהליכים הבאים ישפרים את החיתוך (למידה מונעת), להפחית את משקלו (חיתוך וניהול טוב יותר בתוך הזיכרון), ולהפוך אותו פופולרי יותר בין שיטות שונות ולימודים/התגלות. * אז זהו מרוץ נשק, לא רק כדי לבנות מודלים גדולים יותר, אלא כדי לשרת אותם חכמים יותר._* באמצעות זה, השיפורים בחיתוך והיעילות הם למה LLMs כמו GPT-4 ו- Llama-2 יכול לרוץ מכאן ואילך, אולי אלה עם אסטרטגיית הקאש הכי אגרסיבית עשויים להרוויח את הכותרת של מציעה את השירותים המהירים ביותר ובסופו של דבר הזול ביותר AI. תגיות קשורות.co הפניות : אנתרופי. (2024, 14 באוגוסט) פורסם על ידי Anthropic News: פגישה מהירה עם קלאוס. תגית: Anthropic.com תגית: Anthropic.com Hinton, G., Vinyals, O., & Dean, J. (2015). NIPS Deep Learning and Representation Learning סדנת למידה עמוקה. הפצה של הידע ברשת נוירלית. לואיס, פ., et al. (2020) התקדמות במערכות עיבוד מידע נוירליות. גישה ל- Knowledge-Intensive NLP פול, R (2025, 20 באפריל) הבלוג של רונאלדו. אסטרטגיות קישוריות בשירותי LLM הן לאימון והן למסקנה. יונתן פול.com יונתן פול.com פול, S. (2025 6 באפריל) בלוג בינוני להאיץ Transformer Inference עם KV Caching. תגית: sudhirpol522.medium.com תגית: sudhirpol522.medium.com גולן, נו (2019) ארכיון תגיות: 2111 . דיסקוג טרנספורמטר מהיר: ראש כתיבה אחד הוא כל מה שאתה צריך. ארכיון .org Shutova, A., Malinovskii, V., Egiazarian, V., et al. (2025). ארכיון תגיות: 501 392 . Cache Me If You Must: Adaptive Key-Value Quantization עבור מודלים שפות גדולים. ארכיון .org Yazdani Aminabadi, R., Rajbhandari, S., Zhang, M., et al. (2022). ארכיון תגיות: 220700032 . DeepSpeed Inference: מאפשר Inference יעיל של מודלים טרנספורמרים בקנה מידה חסר תקדים. ארכיון .org Kwon, W., Li, Z., Zhuang, S., et al. (2023). תגית: SOSP 2023 . ניהול זיכרון יעיל עבור מודל שפה גדול שמשרת עם PagedAttention (vLLM). Blog.מגזין Blog.מגזין Hugging Face Transformers צוות (2023). הפנים של הבלוג אופטימיזציה של LLM שלך בייצור. תגיות קשורות.co תגיות קשורות.co Lorello, S., McCormick, R., & Partee, S. 2023 בלוג טכני של Nvidia כיצד ליצור קח Inference מפוזר עם NVIDIA Triton ו- Redis. (התייחסויות נוספות לצורך קפדנות אקדמית ומלאות ניתן להוסיף לפי הצורך כדי להתאים את כל הציטוטים לעיל.)