عندما تُدخل نصًا في ChatGPT أو Claude أو DeepSeek، يبدأ النموذج في الرد حرفًا حرفًا خلال بضع مئات من الملي ثانية—يبدو الأمر بسيطًا، لكنه في الواقع واحد من أدق أعمال الهندسة في الحوسبة الحديثة. يجمع هذا المقال التحليل التفصيلي الكامل لخط سير الاستدلال لدى مهندس الذكاء الاصطناعي Akshay Pachaar، بدءًا من tokenization وembedding وattention، وصولًا إلى مرحلتين prefill/decode، وKV cache، والتكميم quantization، ولماذا خفّضت DeepSeek V4 حجم الكاش إلى 10% من حجمه الأصلي.
النموذج الذهني الأساسي: LLM لا يفعل سوى «تخمين الرمز التالي»، ثم يكرر
في جوهرها، تقوم نماذج اللغة الكبيرة بعمل واحد فقط: التنبؤ بالرمز token التالي. فهي تستقبل تسلسل الرموز المميز token الذي أدخلته، وتحسب توزيع احتمالات الرمز التالي، ثم تُنتج رمزًا عبر أخذ عينة sampling، وتلحقه بنهاية الإدخال، وبعدها تتنبأ بالرمز التالي—دون توقف—إلى أن يخرج النموذج رمز التوقف أو يبلغ حدًا أقصى.
المسألة الحاسمة في كامل عملية الاستدلال ليست «كيف يتنبأ»، بل «لماذا يصبح الرمز الثاني أسرع بكثير من الأول؟». يقود هذا الجواب إلى مفهوميْن هما الأهم في خدمات LLM الحديثة: مرحلتا prefill وdecode، وKV cache.
Step 1：Tokenization تحوّل النص إلى أرقام
لا تقرأ الشبكات العصبية النصوص، بل تقرأ المتجهات. لذلك تمر مطالبتك أولًا عبر tokenization لتُقسَّم إلى وحدات «token» متقطعة، ويرتبط كل token برقم صحيح (integer) يمثل ID. تعتمد معظم نماذج LLM الحديثة BPE (Byte Pair Encoding، ترميز أزواج البايت): تنطلق من المحارف الأصلية، ثم تقوم بدمج أزواج المحارف الأكثر تكرارًا معًا تدريجيًا، إلى أن تحصل في النهاية على مفردات تضم نحو 50 ألف token شائع.
تأثير هذه الخطوة أكبر مما يتصوره كثيرون. فاللغات التي يكون وزنها منخفضًا في بيانات تدريب tokenizer ستُقسَّم إلى عدد أكبر من token، ما يرفع كلفة الاستدلال ويُبطئه. في كثير من tokenizers الموجهة إلى الإنجليزية، تُجزّأ الأحرف الصينية—بما فيها الصينية التقليدية—عادة إلى 2 إلى 3 token لكل حرف، وهذه أحد الأسباب الجذرية لارتفاع كلفة الاستدلال على مستخدمي اللغة الصينية.
Step 2：Embedding تحوّل ID إلى متجهات، ثم تُحقن معلومات الموضع
يذهب كل token ID إلى البحث في جدول ضخم «embedding». إذا كانت مفردات النموذج هي 50K (50 ألف)، وأبعاد البعد الخفي hidden dimension هي 4096، فإن شكل الجدول هو [50000, 4096]. يحصل كل token على «سطر» من المتجهات، أي تمثيلها البالغ 4096 بعدًا.
هذه المتجهات ليست عشوائية. أثناء التدريب، يدفع النموذج token التي تحمل دلالات متقاربة إلى مناطق متجاورة في فضاء متشابه: king وqueen قرب بعض في اتجاه ما، وpython (لغة) وjavascript في اتجاه آخر، وpython وsnake (ثعبان) في اتجاه ثالث.
تُحقن أيضًا معلومات الموضع في هذه المرحلة، لأن آلية attention نفسها لا تعرف أي token يأتي قبل أي token. تعتمد النماذج السائدة حاليًا RoPE (Rotary Position Embedding، ترميز المواضع الدوراني): تقوم بتدوير المتجهات بحسب موقع الـ token، وتُدرج معلومات الترتيب ضمن المتجهات نفسها.
Step 3：Self-Attention هي جوهر Transformer
ثم تدخل المتجهات المتسلسلة إلى 32 طبقة (أو أكثر) من transformer. وفي كل طبقة تقوم عمليتان: استخدام self-attention لخلط المعلومات بين token، ثم استخدام feed-forward لخلط المعلومات داخل كل token.
آلية self-attention تعمل هكذا: يمر كل token عبر ثلاثة مصفوفات تعلمية Wq وWk وWv لاستخراج query (استعلام) وkey (مفتاح) وvalue (قيمة) على التوالي. يستخدم كل token query الخاص به لإجراء جداء داخلي مع key لكل token آخر، ما ينتج أوزانًا تُعبّر عن «كم من المعلومات يجب أن يسحبها هذا الـ token من غيره»، ثم يدمج value عبر ترجيح هذه الأوزان.
هنا تكمن «سحرية» attention: يقرر كل token بنفسه أي مواضع في السياق ينبغي أن يلتفت إليها، ويسحب المعلومات المفيدة إلى متجهه. ومع تكديس 32 طبقة، يستطيع النموذج تتبع الإشارات عبر آلاف من token. أما شبكة feed-forward التالية لـ attention فهي تحمل معظم «المعرفة» في النموذج، بينما يتولى attention نقل المعلومات، ويتولى feed-forward معالجة المعلومات.
Prefill وDecode: على نفس GPU، عنقاسان مختلفتان تمامًا
هذه هي الفاصل الأكثر أهمية في هذا المقال. عند توليد رد بطول 200 كلمة مثلًا، تكون المهمة عبارة عن عمليتين بخصائص مختلفة كليًا، لكنهما تعملان على نفس بطاقة GPU.
مرحلة Prefill—عندما تُرسل مطالبتك، يجب على النموذج أولًا تمرير جميع token الخاصة بالإدخال مرة واحدة قبل أن يولد token الأول. يمكن تنفيذ هذه الخطوة «بالتوازي» على جميع token المدخل: يُحسب Q وK وV لكل token في الوقت نفسه، وتُنفَّذ attention على شكل ضرب مصفوفات كبيرة matrix multiplication. صُممت GPU لهذا النوع من العمليات؛ وتكون وحدات الحساب (Tensor Cores) مشغّلة بكامل طاقتها، وتصبح عنق الزجاجة هنا «قوة الحساب». يُسمى مؤشر التأخير في هذه المرحلة TTFT (Time to First Token، زمن الوصول لأول token).
مرحلة Decode—بعد خروج أول token، يتحول النموذج إلى نمط مختلف. عند توليد الرمز رقم 51، فإنه لا يحتاج إلا إلى حساب Q وK وV للـ token الجديد فقط، بينما تكون K وV للـ 50 token السابقة قد حُسبت مسبقًا ولا داعي لإعادة حسابها. المشكلة أن كمية حساب كل token تكون صغيرة، لكن GPU ما زالت بحاجة إلى تحميل أوزان النموذج كاملة وسجل KV التاريخي من الذاكرة (VRAM) لإجراء عملية حسابية صغيرة ثم إعادة ذلك. هنا تنقلب عنق الزجاجة من «قوة الحساب» إلى «عرض/تردد الذاكرة (memory bandwidth)». يُسمى مؤشر التأخير في هذه المرحلة ITL (Inter-Token Latency، التأخير بين token)، وهو ما يحدد هل سيشعر المستخدم أن النموذج «يكتب» بسرعة أم لا.
لذلك: prefill عملية محكومة بالحساب compute-bound، بينما decode عملية محكومة بالذاكرة memory-bound—نفس النموذج ونفس العتاد، لكن خصائص الأداء مختلفة تمامًا.
KV Cache: تحسين محوري يجعل استدلال LLM ممكنًا
الاعتماد في مرحلة Decode على عدم إعادة حساب K وV للرموز السابقة يأتي عبر KV cache. كل طبقة transformer تحافظ على مصفوفَتين، تخزنان K وV لجميع token التاريخية؛ وبعد حساب K وV للرمز الجديد تُلحقه في النهاية، ثم يقرأ attention كامل التسلسل التاريخي مباشرة.
بدون KV cache، عند توليد رد من 1,000 token، يتطلب الأمر إعادة حساب كامل التسلسل المتنامي في كل خطوة، فتتفجر التعقيدية بصورة تربيعية. مع KV cache يمكن تسريع التوليد الطويل بما يزيد على 5 مرات. لكن المقابل هو أن الكاش يقيم في VRAM؛ فكلما تم توليد token إضافي، يزيد حجم الكاش بمقدار جزء جديد. في نموذج بحجم 13B، يستهلك كل token قرابة 1MB؛ وبالتالي يؤدي سياق بحدود 4K إلى حرق 4GB من الذاكرة لمجرد تخزين هذا الكاش.
هذه هي الحقيقة وراء «بطء سياق طويل وغاليه»—ليس لأن النموذج «لا يستطيع اللحاق»، بل لأن الكاش يستهلك الذاكرة حتى يَفنى ما تبقى من VRAM، فتتراجع قدرة GPU الواحدة على خدمة عدد المستخدمين بالتوازي. من أساليب التحسين الشائعة: تقليل حجم الكاش عبر quantization إلى INT8 أو INT4، أو استخدام sliding window لإسقاط token القديمة جدًا، أو employ grouped-query attention (GQA) لتمكين رؤوس attention متعددة من مشاركة K وV، أو مثل PagedAttention في vLLM لإدارة الكاش على هيئة صفحات (يشبه إدارة الذاكرة في نظام تشغيل).
ثورة التخزين المؤقت في DeepSeek V4: خفض الحجم إلى 10% تحت سياق 1M
تأتي التحسينات عبر التكميم والتقسيم إلى صفحات لتتعامل مع KV cache باعتباره «تكلفة ثابتة». تتبع سلسلة V4 التي عرضت DeepSeek في أواخر 2025 نهجًا أكثر حسمًا: إعادة تصميم attention من الأساس، بحيث يصبح الكاش صغيرًا منذ البداية.
تعتمد V4 آلية هجينة تجمع نسختين من ضغط attention: واحدة كثيفة وأخرى متفرقة، وكلاهما تعملان على تدفقات KV مضغوطة بدرجة كبيرة. تحت سياقات تصل إلى مليون token، أفادت تقارير V4-Pro أن حجم KV cache لا يتجاوز نحو 10% من سابقه، وأن تكلفة الحساب لكل token لا تزيد عن نحو 27%. المعنى ليس فقط أن DeepSeek «أرخص»، بل أن KV cache أصبح بالفعل عنق الزجاجة الرئيسي الذي يجري تحسينه في مجال LLM؛ فعندما تتم إعادة تصميم آلية attention لتقليص الكاش، فهذا يعني أن «قيد» التقنية قد انتقل بالكامل في المجتمع التقني.
وللقارئ في تايوان، المعلومات الأكثر عملية هي أن DeepSeek V4-Flash متاح الآن على Ollama Cloud وعلى خوادم في الولايات المتحدة (انظر تقرير abmedia بتاريخ 4/24)، ويمكن أيضًا ربط Claude Code وOpenClaw بنقرة واحدة، دون الحاجة لإعداد ذاتي، للتحقق من تفوق الجيل الجديد من attention في سيناريوهات السياق الطويل.
Quantization: استبدال الدقة بالسرعة والذاكرة
التدريب يحتاج إلى دقة أعلى، بينما الاستدلال لا يحتاج كذلك. تستبدل معظم عمليات النشر الرسمية FP16 أو BF16 بدلًا من FP32، ما يضاعف فورًا الذاكرة وthroughput. والخطوة الأكثر جرأة هي تكميم الأوزان إلى INT8، بل وحتى INT4.
أرقام توضح الصورة مباشرة: يحتاج نموذج 7B ضمن FP32 إلى 28GB، وضمن FP16 إلى 14GB، وضمن INT8 إلى 7GB، وضمن INT4 إلى 3.5GB فقط. ولهذا تستطيع حتى بطاقات الرسوميات في أجهزة الكمبيوتر المحمولة تشغيل نماذج بحجم 7B. تقوم طرق مثل GPTQ وAWQ باختيار معاملات التحجيم scaling لكل قناة، بحيث يكون فقدان الجودة الناتج عن الضغط المفقود أقل ما يمكن—تصميم INT4 جيد يمكنه أن يحقق أداءً في معظم المؤشرات القياسية يقل عن النسخة الأصلية بنقطة مئوية واحدة فقط ضمن الحدود.
ربط جميع الخطوات معًا: الرحلة الكاملة لمطالبة واحدة
عندما نصل بين كل ما سبق، فإن المسار الكامل للاستدلال في مرة واحدة هو: (1) Tokenize—تحويل النص إلى أرقام (IDs). (2) Embed—تحويل الـ IDs إلى متجهات وحقن معلومات الموضع. (3) Prefill—تشغيل جميع الطبقات على جميع token المدخل بالتوازي، وهي عملية compute-bound، ويتم إنشاء KV cache، وتوليد token الإخراج الأول. (4) حلقة Decode—في كل مرة يتم إسقاط (projection) token جديد فقط، ثم تنفيذ attention على K وV داخل cache، وتشغيل feed-forward، ثم أخذ عينة لاختيار الإخراج، وكتابة K وV الجديدين في cache، وهي عملية memory-bound. (5) Detokenize—تحويل token IDs إلى أحرف، ثم بث الإخراج إلى الشاشة.
تضيف أطر الخدمة مثل vLLM وTensorRT-LLM وText Generation Inference طبقات خارج هذه الحلقة، مثل: batching متتابع (تداخل token لمستخدمين مختلفين في خطوة GPU واحدة)، speculative decoding (نموذج صغير يكتب مسودته أولًا، والنموذج الكبير يتحقق)، وإدارة ذاكرة دقيقة—وهذا هو الطريق لخدمة عشرات المستخدمين على GPU واحدة.
الخلاصة العملية للمطورين: هل يجب أن تهتم بـ TTFT أم ITL؟
بعد فهم الصورة الكاملة لعملية الاستدلال، تظهر قرارات عملية عدة بشكل طبيعي:
- تُضخم المطالب الطويلة TTFT، وتُضخم المخرجات الطويلة ITL—مصدر الضغط مختلف، فلا تضع موارد التحسين على مؤشر خاطئ.
- ليست المساحة السياقية مجانية: مضاعفة السياق لا تعني حسابًا مضاعفًا فقط، بل إنها تضغط كذلك على حجم batches التي يمكن احتواؤها ضمن KV cache.
- يعد التكميم حاليًا أعلى «رافعة» لتحسين الكفاءة، إذ إن تبديل FP16 إلى INT8 غالبًا يخفض التأخير إلى النصف مع خسارة جودة صغيرة جدًا.
- غالبًا ما تكون GPU utilization مؤشرًا مضللًا: في مرحلة prefill يتم تحميل GPU بالكامل، بينما في decode قد لا يُستخدم سوى 30%؛ والحل ليس زيادة قوة الحساب، بل ذاكرة أسرع أو cache أصغر.
يجذب تصميم Transformer أكبر قدر من الاهتمام، لكن كفاءة الاستدلال تعيش في «تفاصيل مملة»: إعدادات الذاكرة، وإدارة الكاش، وعرض البتات. عندما يقول أحد «هذا النموذج بطيء»، فالسؤال التالي الذي ينبغي طرحه ليس «هل نبدله بGPU مختلف؟»، بل «هل البطء في مرحلة البدء (البداية) أم في مرحلة البث (الstreaming)؟». الإجابة تحدد مسار التحسين بالكامل.
هذا الدليل التعليمي الكامل لاستدلال LLM: ثورة KV cache وDeepSeek V4 ظهر لأول مرة على سلسلة أخبار 链新闻 ABMedia.
