7.7 KV Cache والاهتمام المشترك بقيم Key-Value — MQA وGQA وMLA

في هذا المقال، نشرح لماذا يُعد KV Caching مهمًا جدًا أثناء عملية الاستدلال في نماذج Transformer LLM، وكيف تعمل آليات Multi-Query Attention وGrouped-Query Attention وMulti-Head Latent Attention على تقليل تكلفة تخزين key/value. في التوليد الذاتي الانحداري (Autoregressive Generation)، يتم إنشاء التوكنات واحدًا تلو الآخر، لذلك يصبح من الضروري إعادة استخدام key وvalue الخاصة بالتوكنات السابقة بكفاءة. لذلك تُعد MQA وGQA وMLA من أهم البنى المصممة لتقليل عبء KV cache.

06/15/2026

Draft Model — كيف تسرّع بنية توليد المسودة استدلال LLM؟

Draft Model هو نموذج مساعد صغير يُستخدم لتسريع LLM Inference. في التوليد التقليدي، ينتج LLM كل Token بالتتابع، بحيث تعتمد الخطوة التالية على ما تم توليده في الخطوات السابقة، وهذا يجعل إنشاء النصوص الطويلة يستغرق وقتًا أكبر. بدل تنفيذ العملية كاملة باستخدام النموذج الكبير في كل مرة، يتولى Draft Model توليد عدة Tokens مرشحة بسرعة، ثم يراجع Target Model هذه الاقتراحات ويتحقق منها. بهذه الطريقة يمكن تقليل العمليات الحسابية المتكررة وتسريع التوليد مع الحفاظ على مستوى الجودة الذي يقدمه Target Model.

08/29/2026

Inference Bottleneck (عنق زجاجة التوليد التسلسلي) — لماذا يصعب تنفيذ استدلال LLM بالتوازي؟

ينشأ Inference Bottleneck (عنق زجاجة التوليد التسلسلي) من الطريقة التي تعمل بها Large Language Models أثناء التوليد. فالنموذج لا ينتج جميع الـ Tokens المطلوبة دفعة واحدة، بل يحدد كل Token جديدة اعتمادًا على ما تم توليده قبلها. هذه الطبيعة التسلسلية تجعل تسريع LLM Inference أكثر تعقيدًا من مجرد زيادة القدرة الحسابية للـ GPU، لأن تحسن FLOPS وحده لا ينعكس بالضرورة بصورة خطية على Latency أو Throughput. ولهذا ترتبط كفاءة الاستدلال عمليًا بعوامل أخرى مثل KV Cache وMemory Bandwidth وDecoding Strategy.

08/29/2026

IO Bottleneck (اختناق الإدخال والإخراج) — لماذا تصبح حركة البيانات عائقًا أمام LLM قبل القدرة الحسابية؟

يحدث IO Bottleneck (اختناق الإدخال والإخراج) عندما لا تعود سرعة التنفيذ مرتبطة أساسًا بقدرة GPU على الحساب، بل بسرعة وصول البيانات إلى وحدات التنفيذ وخروجها منها. فقد تكون Tensor Core قادرة على معالجة عدد هائل من العمليات، لكن هذه القدرة تظل غير مستغلة إذا تأخر جلب Weight أو Activation Tensor أو KV Cache من HBM. عندها تقضي وحدات الحساب جزءًا من وقتها في الانتظار بدل التنفيذ. ولهذا يظهر أثر IO Bottleneck بوضوح في LLM Inference، حيث تتكرر قراءة Weight وKV Cache، فيصبح الأداء مرتبطًا بدرجة كبيرة بـ تقليل حركة البيانات وإعادة استخدام ما تم تحميله قبل الحاجة إلى الوصول إلى HBM مرة أخرى.

08/29/2026

KV Cache Bottleneck — لماذا تصبح الذاكرة وسرعة استدلال LLM عنق زجاجة؟

KV Cache Bottleneck هو الاختناق الذي يظهر أثناء LLM Inference عندما تبدأ تكلفة الاحتفاظ بقيم Key وValue السابقة في KV Cache بالضغط على GPU Memory وMemory Bandwidth والتأثير في زمن توليد الـ Tokens. تعتمد نماذج Large Language Model (LLM) المبنية على Transformer Architecture على KV Cache لتجنب إعادة الحسابات نفسها في كل خطوة من Autoregressive Decoding، وهو ما يجعل التوليد أسرع في الأساس. لكن مع ازدياد Context Length وعدد Layers وAttention Heads والطلبات المتزامنة، تتحول المشكلة تدريجيًا من تكلفة الحساب إلى تكلفة تخزين بيانات الـ Cache ونقلها عبر الذاكرة.

08/29/2026

Layer-wise Cache — لماذا يحتفظ Transformer بقيم KV منفصلة في كل Layer؟

Layer-wise Cache (التخزين المؤقت على مستوى كل طبقة) هو الأسلوب الذي يحتفظ فيه Transformer بقيم Key وValue الناتجة عن التوكنات السابقة داخل Cache مستقل لكل Layer. عند توليد Token جديد، لا يكون من الضروري إعادة حساب K/V لكل ما سبق في السياق؛ إذ يمكن استدعاء القيم المحفوظة وإجراء الحساب فقط لما أُضيف حديثًا. بهذه الطريقة تنخفض كمية الحساب المتكرر وتصبح عملية LLM inference أسرع بكثير. لذلك، لا يمثل KV Cache مخزنًا واحدًا مشتركًا على مستوى النموذج، بل يتكون فعليًا من مجموعة Caches منفصلة، واحدة لكل Transformer layer.

08/29/2026

بنية Transformer في عصر 2024 — لماذا أصبحت الذاكرة عنق الزجاجة الحقيقي

تشير بنية Transformer في عصر 2024 إلى اتجاه تصميم حديث يحافظ على المبدأ التوليدي الأساسي لـ Transformer، لكنه يحسّن Attention وKV Cache وRoPE وNormalization وFFN وMoE معًا لتقليل اختناق الذاكرة وتكلفة الاستدلال.

05/22/2026