تقليل زمن استجابة نماذج LLM: التخزين المؤقت واستراتيجيات الحافة

يُعدّ تقليل زمن استجابة نماذج LLM أحد أكثر التحديات أهمية للمهندسين الذين يبنون تطبيقات ذكاء اصطناعي سريعة الاستجابة. وبينما تواصل نماذج اللغة الكبيرة (LLMs) تنامي قدراتها، فإن توليدها رمزًا تلو الآخر قد يخلق اختناقات مُحبِطة للمستخدمين النهائيين، كما تؤدي أوقات الانتظار الطويلة مباشرةً إلى انخفاض التفاعل وهجر التطبيقات. لذلك فإن تحسين مسارات الاستدلال لديك من أجل السرعة يمثّل متطلبًا أساسيًا للمطوّرين. يوضّح هذا الدليل كيفية إعداد التخزين المؤقت للموجهات، وتنفيذ بث الاستجابات، وهيكلة توجيه شبكة الحافة، واستخدام تكوينات بلا خادم لتقليص تأخيرات المعالجة.

[!TIP] نصيحة حول مقياس الأداء: عند قياس تأخيرات الواجهة البرمجية، افصِل زمن الوصول إلى أول رمز (Time to First Token، أو TTFT) عن سرعة التوليد الإجمالية. فانخفاض قيمة TTFT يجعل التطبيق يبدو فوريًا للمستخدم، حتى لو استغرق توليد المخرجات كاملةً عدة ثوانٍ، لأن النص يبدأ في الظهور على الفور.

أهم النقاط:

• التخزين المؤقت للموجهات: أعِد استخدام كتل البادئة الثابتة لتجاوز مراحل التحليل وتقليل TTFT بنسبة 80%.
• بث الاستجابات: ادفع الرموز عبر Server-Sent Events (SSE) ليرى المستخدمون توليد النص فوريًا.
• عمّال الحافة (Edge Workers): شغّل التفويض وتوجيه الطلبات في مراكز حافة إقليمية قريبة من المستخدمين.
• توجيه النماذج: حوّل طلبات المستخدمين المباشرة إلى نماذج خفيفة لتحسين السرعات.

مكوّنات زمن استجابة واجهة LLM البرمجية

لتقليل أوقات الاستجابة، يجب أولًا أن تفهم العناصر التي تحدّد التأخير الإجمالي للواجهة البرمجية. فزمن الاستجابة الإجمالي هو المجموع التراكمي لثلاثة متغيرات متمايزة.

أولًا، يقيس زمن العبور عبر الشبكة المدة التي يستغرقها الطلب في الانتقال من العميل إلى خادمك، ثم إلى الواجهة البرمجية لمزوّد النموذج. وهذا يجعل مسافة العبور اختناقًا رئيسيًا.

ثانيًا، يمثّل زمن الوصول إلى أول رمز (TTFT) المدة بين استلام النموذج للطلب وتوليده لأول رمز مخرَج، ولهذا يكتسب التخزين المؤقت للموجهات كل هذه الأهمية.

وأخيرًا، تقيس سرعة توليد الرموز المعدّل الذي يُخرج به العتاد الرموز اللاحقة. وتحدّد قيود العتاد سرعة التوليد، لكن يحتفظ المطوّرون بتحكّم كامل في زمن العبور وفي TTFT، لذا يمكن للتوجيه والتخزين المؤقت الذكيين تقليل زمن استجابة LLM بشكل كبير.

المتطلبات الأساسية

قبل أن تبدأ في إعداد التحسينات أدناه، تأكّد من توفّر ما يلي. لا شيء منها غريب أو نادر، لكن تجاهل أحدها عادةً ما يسبّب أعطالًا محيّرة لاحقًا.

• طبقة وسيطة (middleware) أو بيئة تشغيل حافة تتحكّم بها. تستخدم الأمثلة Cloudflare Workers، لكن تصلح أي منصة بلا خادم قادرة على تمرير الطلب كوكيل. أنت بحاجة إلى موضع يقع بين المتصفح ومزوّد النموذج.
• بيانات اعتماد واجهة برمجية لمزوّد يدعم البث والتخزين المؤقت. كلٌّ من OpenAI وAnthropic يدعمه. خزّن المفتاح كسِرّ (سِرّ في Wrangler أو متغيّر بيئة)، ولا تضعه أبدًا في كود جانب العميل.
• Node.js 18 أو أحدث إذا أردت اختبار Workers محليًا باستخدام wrangler dev. تتوفّر واجهتا fetch وReadableStream العالميتان المستخدمتان في كامل الدليل ضمن بيئة التشغيل هذه وفي المتصفحات الحديثة.
• قياس مرجعي (baseline). سجّل زمن الوصول إلى أول رمز ووقت الاستجابة الإجمالي الحاليين قبل تغيير أي شيء، لتتمكّن من إثبات أن كل تحسين قد ساعد فعلًا. يوضّح قسم قياس الأداء أدناه كيفية ذلك.
• الإلمام بـ Server-Sent Events (SSE). تصل استجابات البث كسلسلة من أسطر data:، وستحلّلها على جانب العميل.

تنفيذ التخزين المؤقت للموجهات

التخزين المؤقت للموجهات هو الطريقة الأكثر فعالية لتحسين TTFT في التطبيقات المبنية حول موجهات نظام كبيرة. فعندما يحتوي الطلب على كتلة تعليمات ثابتة طويلة (مثل موجه نظام لوكيل أو مستند مرجعي لـ RAG)، يجب على مزوّد النموذج تحليل تلك الرموز وترميزها في كل تنفيذ. ويدعم كلٌّ من Anthropic وOpenAI التخزين المؤقت للموجهات، الذي يحفظ حالات الرموز المحلَّلة في الذاكرة. عندئذٍ تتجاوز الطلبات اللاحقة التي تشترك في البادئة نفسها مرحلة التحليل، ما يقلّل TTFT بنسبة تصل إلى 80%.

تتفاوت مدد بقاء التخزين المؤقت بين المزوّدين. فيحتفظ Anthropic بالتخزين المؤقت لنحو خمس دقائق من الخمول، بينما يستخدم OpenAI نموذج اضمحلال ديناميكيًا. لذا فإن جدولة نبضات جلب (ping) دورية في الخلفية يمكن أن تُبقي تعليمات النظام الحرجة نشطة في ذاكرة الخادم.

تختلف الآلية اختلافًا طفيفًا بين المزوّدين، وضبط بنية الطلب بشكل صحيح هو ما يحدّد ما إذا كان التخزين المؤقت سيعمل فعلًا. مع Anthropic، تضع علامة على نقطة فصل للتخزين المؤقت صراحةً باستخدام cache_control. فكل ما يسبق نقطة الفصل يُخزَّن، لذا يجب أن يأتي المحتوى الثابت المستقر أولًا وأن يأتي المحتوى المتغيّر الخاص بكل طلب أخيرًا:

 1import Anthropic from "@anthropic-ai/sdk";
 2
 3const anthropic = new Anthropic();
 4
 5const response = await anthropic.messages.create({
 6  model: "claude-opus-4-8",
 7  max_tokens: 1024,
 8  system: [
 9    {
10      type: "text",
11      text: SYSTEM_INSTRUCTIONS       // small, sent on every request
12    },
13    {
14      type: "text",
15      text: KNOWLEDGE_BASE,           // large, static reference block
16      cache_control: { type: "ephemeral" }
17    }
18  ],
19  messages: [
20    { role: "user", content: userQuestion }   // volatile — after the breakpoint
21  ]
22});
23
24// Confirm the cache is working
25console.log(response.usage.cache_read_input_tokens);

الخطأ الأكثر شيوعًا على الإطلاق هو وضع ختم زمني أو معرّف طلب أو أي سلسلة نصية خاصة بكل طلب قبل الكتلة المخزَّنة مؤقتًا. ولأن التخزين المؤقت يعتمد على مطابقة البادئة، فإن تغيّر بايت واحد في أي موضع قبل نقطة الفصل يُبطل كل ما يليه، ولا يصيب التخزين المؤقت أبدًا في صمت. تحقّق من عمله بقراءة usage.cache_read_input_tokens من الاستجابة: فإذا بقيت هذه القيمة عند الصفر عبر طلبات متطابقة، فقد تسلّل شيء ديناميكي إلى البادئة. ولاحظ أيضًا أن البادئة المخزَّنة مؤقتًا يجب أن تتجاوز حدًّا أدنى من الطول (في حدود 1,024 إلى 4,096 رمزًا حسب النموذج) قبل أن يعمل التخزين المؤقت أصلًا.

يتبع OpenAI نهجًا أبسط: فالتخزين المؤقت تلقائي للموجهات التي تتجاوز نحو 1,024 رمزًا، دون أي راية cache_control لتضبطها. ومع ذلك، ما يزال الانضباط نفسه ساريًا. أبقِ كتلة التعليمات الثابتة في مقدّمة مصفوفة الرسائل تمامًا، وألحِق مدخل المستخدم المتغيّر في النهاية، بحيث تبقى البادئة القابلة لإعادة الاستخدام متطابقة بايتًا ببايت بين الطلبات.

للاطّلاع على هياكل التسعير والمعاملات الخاصة بالتخزين المؤقت للموجهات، راجع دليل Anthropic للتخزين المؤقت للموجهات .

الحوسبة على الحافة والتوجيه بلا خادم

معالجة طلبات LLM على خادم مركزي وحيد تُدخِل قفزات شبكية هائلة للمستخدمين حول العالم. أما نشر الطبقة الوسيطة لواجهتك البرمجية على شبكات حافة بلا خادم (مثل Cloudflare Workers) فيُقصّر تلك المسارات بشكل جذري.

يستقبل عامل الحافة طلب العميل، ويفوّض الجلسة، ويوجّهها إلى أقرب مركز بيانات لمزوّد النموذج. وتوصِّل هذه البنية بلا خادم الرموز إلى شاشة المستخدم في اللحظة التي تُحسَب فيها، فتبدو الواجهة عالية الاستجابة. توضّح الطبقة الوسيطة بلغة JavaScript أدناه كيفية تكوين استجابات البث مباشرةً من بيئة تشغيل حافة:

 1export default {
 2  async fetch(request, env) {
 3    const payload = await request.json();
 4
 5    // Call the streaming LLM endpoint
 6    const response = await fetch("https://api.openai.com/v1/chat/completions", {
 7      method: "POST",
 8      headers: {
 9        "Authorization": `Bearer ${env.OPENAI_API_KEY}`,
10        "Content-Type": "application/json"
11      },
12      body: JSON.stringify({
13        model: "gpt-4o-mini",
14        messages: payload.messages,
15        stream: true
16      })
17    });
18
19    // Forward the stream directly to the client browser
20    return new Response(response.body, {
21      headers: { "Content-Type": "text/event-stream" }
22    });
23  }
24};

توصِّل هذه البنية بلا خادم الرموز إلى شاشة المستخدم فورًا فور حسابها. ولتتعلّم كيفية بناء واجهات خلفية مُحسَّنة للحافة، اقرأ دليلنا حول بناء واجهة برمجية بلا خادم باستخدام Cloudflare Workers .

تحليل البث على جانب العميل

تمرير البث من الحافة ليس سوى نصف المهمة. فما يزال على المتصفح أن يقرأ تلك الأجزاء (chunks) فور وصولها ويعرض كل رمز، وإلا تراكمت الاستجابة في مخزن مؤقت وظهرت دفعةً واحدة، ما يُبطل الغرض. هذه هي الخطوة التي تتجاهلها معظم الأدلة، وهي الموضع الذي يُكسَب فيه الأداء المُدرَك أو يُخسَر فعلًا.

جسم الاستجابة هو ReadableStream من بايتات خام. تصل إطارات SSE كأسطر data:، لكن جزء الشبكة الواحد قد يحتوي على عدة إطارات، أو قد يقسّم إطارًا واحدًا على جزأين، لذا يجب أن تخزّن الأسطر الجزئية مؤقتًا بدلًا من افتراض أن كل جزء رسالة كاملة:

 1async function streamCompletion(messages, onToken) {
 2  const response = await fetch("/api/chat", {
 3    method: "POST",
 4    headers: { "Content-Type": "application/json" },
 5    body: JSON.stringify({ messages })
 6  });
 7
 8  const reader = response.body.getReader();
 9  const decoder = new TextDecoder();
10  let buffer = "";
11
12  while (true) {
13    const { value, done } = await reader.read();
14    if (done) break;
15
16    buffer += decoder.decode(value, { stream: true });
17    const lines = buffer.split("\n");
18    buffer = lines.pop();              // keep the trailing partial line
19
20    for (const line of lines) {
21      if (!line.startsWith("data: ")) continue;
22      const payload = line.slice(6).trim();
23      if (payload === "[DONE]") return;
24
25      try {
26        const json = JSON.parse(payload);
27        const token = json.choices?.[0]?.delta?.content;
28        if (token) onToken(token);
29      } catch {
30        // ignore keep-alive comments and malformed partial frames
31      }
32    }
33  }
34}

إن buffer.split("\n") المتبوع بـ lines.pop() هو التفصيل المهم: فهو يحتفظ بأي سطر غير مكتمل حتى يُكمِله الجزء التالي. ويحافظ تغليف JSON.parse داخل try/catch على استمرار الحلقة عند وصول تعليق keep-alive أو إطار مستلَم جزئيًا. بعد ذلك يُلحق ردّ النداء onToken كل شظية بالـ DOM، فيظهر النص في اللحظة نفسها التي يُنتجه فيها النموذج.

قياس زمن الاستجابة وتقييمه مرجعيًا

لا يمكنك تحسين ما لم تقِسه. قبل كل تغيير وبعده، سجّل زمن الوصول إلى أول رمز ووقت التوليد الإجمالي لتتمكّن من عزو التحسّن إلى سببه الصحيح. وأسرع طريقة لأخذ عيّنة من TTFT هي عبر curl، باستخدام time_starttransfer كمقياس تقريبي وثيق لوصول أول بايت إلى العميل:

1curl -w "TTFT: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
2  -X POST https://your-worker.example.com/chat \
3  -H "Content-Type: application/json" \
4  -d '{"messages":[{"role":"user","content":"Hello"}]}' \
5  -o /dev/null -s

للحصول على أرقام على مستوى التطبيق، جهّز محلّل جانب العميل بالقياس مباشرةً. اضبط الساعة عند مغادرة الطلب ومرة أخرى عند وصول أول رمز:

1const start = performance.now();
2let firstTokenAt = null;
3
4await streamCompletion(messages, (token) => {
5  if (firstTokenAt === null) firstTokenAt = performance.now();
6  render(token);
7});
8
9console.log(`TTFT: ${Math.round(firstTokenAt - start)}ms`);

نفّذ كل قياس عدة مرات وخُذ الوسيط بدلًا من عيّنة واحدة، إذ إن تباين الشبكة والبدايات الباردة قد يشوّهان القراءات المفردة. يقدّم الجدول أدناه نطاقات توضيحية لأين يذهب الوقت عادةً في طلب عالمي حسن السلوك؛ تعامل معها كشكل للمقارنة، لا كأرقام ثابتة، لأن أرقامك الخاصة ستعتمد على المنطقة والنموذج وحجم الموجه.

الصفّان الجديران بالتأمّل هما رقما TTFT مع التخزين المؤقت ومن دونه. فهذه الفجوة هي أكبر مكسب مفرد متاح لمعظم التطبيقات، ولهذا يقع التخزين المؤقت للموجهات على رأس قائمة التحسين. أما سرعة التوليد، على النقيض، فيحدّدها المزوّد، لذا يظلّ توجيه الطلبات الأبسط إلى نموذج أصغر هو الرافعة الوحيدة هناك.

سير عمل التحسين خطوة بخطوة

لتحسين سرعة تطبيقك البرمجي، ابدأ بفصل تعليمات النظام الثابتة عن مدخلات المستخدم الديناميكية. يتيح لك هذا الفصل استهداف نقاط دخول التخزين المؤقت بنظافة.

بعد ذلك، فعّل رايات التخزين المؤقت للموجهات داخل حمولات واجهتك البرمجية لضمان أن يحفظ مزوّد النموذج رموزك النصية في الذاكرة.

اضبط دائمًا بث الاستجابات باستخدام نقاط نهاية SSE القياسية. وبكتابة محلّلات أمامية خفيفة تعالج الأجزاء فور وصولها، تُحسّن الأداء المُدرَك من قِبل المستخدم. ثم أنشئ مسارات احتياطية للنماذج: وجّه المدخلات الأساسية للعملاء إلى نماذج أصغر، مع حجز نماذج الاستدلال الأكبر للمهام المتقدّمة. وأخيرًا، حلّل قفزات الشبكة للتأكّد من أن العمال بلا خادم يقلّلون تأخيرات العبور. للاطّلاع على تفاصيل تحسين قواعد البيانات، راجع دليلنا حول WordPress مقابل تطوير الويب المخصّص .

المزالق الشائعة واستكشاف الأخطاء وإصلاحها

تظهر حفنة من الأعطال مرارًا وتكرارًا عندما تطرح الفرق البث والتخزين المؤقت لأول مرة. والتعرّف على العَرَض يوفّر ساعات من التخمين.

ثمة فخّ أكثر دقّة هو التخزين المؤقت عند الحافة نفسها. فإذا استدعيت await response.text() داخل العامل قبل الإعادة، فقد حوّلت بهدوء استجابة بث إلى استجابة حاجبة من جديد. مرّر دائمًا جسم البث كما هو مباشرةً. وبالمثل، راقب حدود المعالج (CPU) للعامل: إذ يُضاف العمل الثقيل لكل طلب في الطبقة الوسيطة مباشرةً إلى TTFT، لذا أبقِ منطق التفويض والتوجيه في حده الأدنى وأجّل كل ما هو مكلف.

اعتبارات الإنتاج

تشغيل عرض توضيحي للبث في متصفح أمر مباشر؛ أما تشغيله بموثوقية تحت حركة مرور حقيقية فيتطلّب بعض الضمانات الإضافية.

اضبط مهلة طلب معقولة على الاستدعاء القادم من المصدر بحيث لا يمكن لاتصال مزوّد متعثّر أن يُبقي عاملًا مفتوحًا إلى ما لا نهاية، واقرنها بإعادة محاولة تتراجع إلى مزوّد ثانٍ أو نموذج أصغر عند انتهاء مهلة المزوّد الأساسي. ولأن التخزين المؤقت للموجهات يفرض علاوة بسيطة على عمليات الكتابة في التخزين المؤقت وخصمًا كبيرًا على عمليات القراءة، فإنه لا يؤتي ثماره إلا عند إعادة استخدام البادئة؛ ونبضة خلفية كل بضع دقائق تُبقي موجه نظام نشطًا مقيمًا دون دفع تكلفة إعادة كتابته في كل طلب مستخدم.

جهّز القياس على نحو مستمر لا عند الإطلاق فحسب. سجّل TTFT وعدد الرموز في الثانية لكل طلب، ونبّه عندما ينحرف الوسيط، إذ سيظهر أي تراجع من جانب المزوّد أو أي تغيّر في حجم الموجه هناك أولًا. وأخيرًا، احترم حدود معدّل المزوّد: إذ قد تتسبّب دفقة من عمليات البث المتزامنة في تجاوزها، لذا صُفّ الحمل في طابور أو تخلّص منه بأناقة بدلًا من ترك الطلبات تفشل في صمت. تحوّل هذه التدابير نموذجًا أوليًا سريعًا إلى تطبيق يبقى سريعًا حين يهمّ الأمر.

أهم النقاط

• استهدف زمن الوصول إلى أول رمز (TTFT) وزمن العبور لتقليل زمن استجابة LLM.
• استفِد من التخزين المؤقت للموجهات على واجهات النماذج البرمجية لتجاوز العبء النظامي لتحليل التعليمات.
• استخدم بث الاستجابات لتوصيل الرموز في الزمن الحقيقي، ما يحسّن السرعة المُدرَكة.
• انشُر الطبقة الوسيطة للواجهة البرمجية على بيئات تشغيل حافة بلا خادم لتقصير مسارات الشبكة العالمية.
• وجّه استعلامات المستخدمين الأبسط إلى نماذج خفيفة لتحسين سرعات التنفيذ.
• أعدِد أدوات مراقبة الأداء لتحليل زمن الاستجابة وتقليله باستمرار في ظل ظروف الاستخدام الحقيقية.

الأسئلة الشائعة (FAQ)

كيف أقلّل زمن استجابة LLM في الإنتاج؟ لتقليل زمن استجابة LLM في الإنتاج، ينبغي أن تنفّذ التخزين المؤقت للموجهات للتعليمات الثابتة، وتفعّل بث الرموز، وتنشر عمّال حافة لتحسين توجيه الطلبات. وبنشر بيئات تشغيل تنسيق بلا خادم أقرب إلى العملاء حول العالم، يتجاوز المطوّرون قفزات توجيه شبكي متعددة ويوصّلون أول رمز استجابة في الزمن الحقيقي.

ما هو التخزين المؤقت للموجهات؟ التخزين المؤقت للموجهات ميزة في الواجهة البرمجية تخزّن حالات النص المحلَّلة في ذاكرة الخادم، ما يسمح للطلبات اللاحقة التي تستخدم البادئة نفسها بأن تعمل أسرع بكثير. وبتجاوز دورة التحليل النظامية لمجموعات التعليمات الكبيرة، يقلّل هذا التحسين زمن الوصول إلى أول رمز (TTFT) بنسبة تصل إلى ثمانين بالمئة.

هل يؤثّر حجم النموذج في زمن الاستجابة؟ نعم، تتمتّع النماذج الأصغر بسرعات توليد رموز أسرع بكثير، ما يجعلها مثالية للمهام البسيطة التي يكون فيها زمن الاستجابة الشاغل الأساسي. ويضمن توجيه طلبات التصنيف أو الاستخراج المباشرة إلى نماذج حافة متخصّصة أوقات إنجاز سريعة، مع حجز النماذج الكثيفة لمهام الاستدلال.

كيف يساعد بث Server-Sent Events (SSE) في تقليل زمن الاستجابة المُدرَك؟ يدفع بث SSE رموز مخرجات النص من مضيف النموذج إلى شاشة العميل في الزمن الحقيقي أثناء تجميعها. ومع أن هذا لا يقلّل مدة التنفيذ الإجمالية، فإنه يقلّل زمن الوصول إلى أول رمز (TTFT) ويمنح المستخدم واجهة تطبيق سريعة الاستجابة ونشطة.

كيف أخزّن استجابات LLM الديناميكية مؤقتًا عند الحافة؟ يمكنك تخزين الاستجابات الديناميكية مؤقتًا عند الحافة باستخدام قواعد بيانات KV أو نُسخ Redis بحدود TTL (مدة البقاء) قصيرة. والتخزين المؤقت للاستجابات الديناميكية فعّال للاستعلامات المتكرّرة للمستخدمين أو نوايا خدمة العملاء الشائعة، إذ يمنع استدعاءات الشبكة إلى مزوّد النموذج تمامًا.