الطريقة الأكثر فاعلية لخفض تكلفة نماذج اللغة الكبيرة (LLM) ليست البحث عن نموذج أرخص، بل معرفة ما يُنفق عليه كل طلب وإزالة الرموز (tokens) التي لا يحتاجها النظام. عمليًا، يأتي معظم التوفير من خمسة مصادر: التخزين المؤقت للسياق المتكرر، وتوجيه المهام السهلة إلى نماذج أصغر، وتقليص السياق المرسل إلى النموذج، وتشغيل المهام غير العاجلة على دفعات، وتشغيل النماذج مفتوحة الأوزان على خوادمك الخاصة عندما يبرر الحجم ذلك. ولا يمكن إدارة أي من ذلك بشكل صحيح ما لم تُقَس التكلفة لكل مهمة ناجحة لا لكل استدعاء.
هذا الدليل موجّه إلى مالكي المنتجات والقادة التقنيين ومديري التقنية (CTO) الذين لديهم ميزة ذكاء اصطناعي تعمل في بيئة الإنتاج ويفكرون فيما يجب فعله مع تزايد الفاتورة. نتناول أولًا مصادر التكلفة الفعلية، ثم متى تؤتي كل تقنية تحسين ثمارها ومتى تبدأ في الإضرار بالجودة. جميع الأرقام في هذا المقال توضيحية؛ فأسعار المزودين تتغير كثيرًا، لذا أجرِ حساباتك وفق قائمة الأسعار الحالية.
من أين تأتي تكلفة نماذج اللغة الكبيرة بالضبط؟
قد تُظهر الفاتورة سطرًا واحدًا باسم "الرموز"، لكن تكلفة الذكاء الاصطناعي هي مجموع عدة بنود مختلفة. والتحسين دون معرفة أكبرها يعني غالبًا الاستثمار في المكان الخطأ.
- رموز المدخلات: تعليمات النظام، وتعريفات الأدوات، وأجزاء المستندات المسترجعة عبر RAG، وسجل المحادثة، وسؤال المستخدم. في معظم أنظمة الإنتاج هذا هو البند الأكبر، لأن السياق الطويل نفسه يُرسل من جديد مع كل طلب.
- رموز المخرجات: النص الذي يولّده النموذج. سعر الوحدة فيها عادةً أعلى من المدخلات. والإجابات الطويلة بلا داعٍ والصيغ التي تطلب الشرح ورموز التفكير كلها تضخّم هذا البند.
- إعادة المحاولة والأخطاء: الاستدعاءات الثانية والثالثة بسبب JSON غير صالح أو انتهاء المهلة أو إجابات لا تجتاز التحقق. غير مرئية لكنها تتراكم.
- حلقات الوكلاء: قد يُجري وكيل يستدعي الأدوات عشرة استدعاءات للنموذج أو أكثر لطلب مستخدم واحد. ويكبر السياق في كل خطوة، لذا ترتفع التكلفة أسرع من عدد الخطوات.
- التضمينات (embeddings) والبحث: تحويل المستندات إلى متجهات، وقاعدة بيانات المتجهات، ونماذج إعادة الترتيب (reranking).
- الاستضافة والتشغيل: إذا كنت تشغّل النماذج بنفسك، فهناك وحدات GPU والتوسع والمراقبة ووقت المناوبة.
- المراجعة البشرية: وقت الفريق المستغرق في تصحيح الإجابات منخفضة الثقة. وكثيرًا ما تختبئ هنا التكلفة الحقيقية لنموذج يبدو رخيصًا على الورق.
لماذا يجب قياس التكلفة لكل مهمة ناجحة لا لكل استدعاء؟
التكلفة لكل استدعاء مضللة، لأن الاستدعاء الرخيص الذي يفشل في أداء مهمته ليس مجانيًا. المقياس الصحيح هو التكلفة الإجمالية لنتيجة تحل مهمة المستخدم فعلًا، بما في ذلك المحاولات الفاشلة وإعادة الاستدعاء والتصحيح البشري.
مثال حسابي (بأرقام افتراضية): في مهمة تصنيف مستندات، يكلّف النموذج A وحدة واحدة لكل استدعاء والنموذج B أربع وحدات. ينجز النموذج A سبعين بالمئة من المهام بشكل صحيح، ويصحّح خبير الثلاثين بالمئة المتبقية بوقت تبلغ تكلفته عشر وحدات. أما النموذج B فينجز سبعة وتسعين بالمئة بشكل صحيح. متوسط التكلفة لكل مهمة هو 1 + 0.30 × 10 = 4 وحدات للنموذج A، و4 + 0.03 × 10 = 4.3 وحدات للنموذج B. النموذج الأرخص بأربع مرات على الورق يكلّف تقريبًا المبلغ نفسه لكل مهمة، ويترك لفريقك عبء تصحيح أكبر بكثير. وكلما ارتفعت تكلفة الخطأ مال الميزان لصالح النموذج الأغلى.
يتطلب هذا الحساب أمرين: مجموعة اختبار تقيس الدقة، وطبقة مراقبة تسجّل المهمة التي ينتمي إليها كل طلب وما إذا نجح. ومن دونهما لا يمكنك قياس أثر أي من التقنيات التالية أيضًا.
كيف يخفّض التخزين المؤقت تكلفة نماذج اللغة الكبيرة؟
التخزين المؤقت يعني ببساطة ألا تدفع مقابل العمل نفسه مرتين. وله ثلاثة أنواع، يحمل كل منها خطرًا مختلفًا.
التخزين المؤقت للموجّه (prefix caching)
يخزّن معظم مزودي النماذج الكبار السياق الذي يبدأ بالطريقة نفسها تمامًا في الطلبات المتتالية، ويعالجون ذلك الجزء بسعر أقل أو بسرعة أكبر. إذا كانت تعليمات النظام وتعريفات الأدوات والمستندات المرجعية الثابتة متطابقة في كل طلب، فهذا أسهل توفير ممكن دون أي خسارة في الجودة. القاعدة بسيطة: المحتوى الثابت في بداية السياق، والمحتوى المتغير (سؤال المستخدم، التاريخ، بيانات الجلسة) في نهايته. ومن الأخطاء الشائعة وضع طابع زمني دقيق حتى الثانية في أعلى تعليمات النظام، مما يكسر التخزين المؤقت مع كل طلب. تختلف مدة التخزين والحد الأدنى للطول والتسعير بين المزودين، لذا راجع وثائق مزودك وتابع نسبة الإصابة في السجلات.
التخزين المؤقت للإجابات المطابقة
في المهام التي يجب أن ينتج فيها المدخل نفسه الإجابة نفسها (توليد وصف منتج، ترجمة نص ثابت، تلخيص مستند مرة واحدة)، فإن تخزين الإجابة ذاتها يعني عدم استدعاء النموذج إطلاقًا. يجب أن يجمع المفتاح بين بصمة المدخل واسم النموذج وإصدار الموجّه والمعاملات، بحيث تُلغى الإجابات القديمة تلقائيًا عند تغيير الموجّه.
التخزين المؤقت الدلالي
يطابق التخزين المؤقت الدلالي الأسئلة غير المتطابقة حرفيًا لكنها متقاربة في المعنى عبر تشابه التضمينات، ويعيد الإجابة السابقة. يمكن أن يحقق توفيرًا كبيرًا حيث تُطرح الأسئلة نفسها بكلمات مختلفة، كما في روبوت الدعم، لكنه أخطر أنواع التخزين المؤقت. فسؤال "هل يمكنني إلغاء طلبي؟" وعبارة "لا أستطيع إلغاء طلبي" يبدوان متشابهين لكنهما يحتاجان إجابتين مختلفتين. وقد تصل إجابات تحتوي على بيانات شخصية إلى مستخدم آخر، وهي مشكلة جدية من منظور قوانين حماية البيانات الشخصية. استخدم التخزين المؤقت الدلالي فقط لإجابات المعلومات العامة، مع عتبة تشابه صارمة، وللسجلات الخالية من بيانات المستخدم، ومع انتهاء صلاحية زمني. وحدّد العتبة بمجموعة اختبار من أزواج أسئلة حقيقية، لا بالتخمين.
كيف يعمل توجيه النماذج والاستدعاء المتدرّج؟
إرسال كل طلب إلى أقوى نموذج يشبه شحن كل طرد بالطائرة. فجزء كبير من المهام الواردة يتمثل في التصنيف أو استخراج الحقول أو التلخيص القصير أو تحويل الصيغ، وهي مهام تؤديها النماذج الأصغر بسهولة. هناك نمطان شائعان:
- التوجيه (routing): يُرسل الطلب منذ البداية إلى النموذج المناسب بحسب نوعه. يمكن ذلك بمجموعة قواعد بسيطة (نوع المهمة، طول المدخل، فئة العميل) أو بنموذج تصنيف صغير. البدء بالقواعد رخيص وسهل التصحيح.
- الاستدعاء المتدرّج (cascade): يذهب الطلب أولًا إلى النموذج الصغير. فإن اجتازت الإجابة فحصًا (التحقق من المخطط، قاعدة عمل، درجة ثقة، فحص سريع ثانٍ) تُستخدم؛ وإلا يُصعَّد الطلب إلى النموذج الكبير. تنتهي معظم المهام السهلة في الطبقة الرخيصة، وتحصل المهام الصعبة مع ذلك على الإجابة الصحيحة.
ثمن التوجيه هو القياس. فتحديد المهام التي يمكن تركها للنموذج الصغير يجب أن يتم بمجموعة اختبار لا بالحدس. وعندما يطلق المزود إصدارًا جديدًا، تُعاد مجموعة الاختبار نفسها وتُحدَّث قواعد التوجيه. والشرط المسبق لهذه المرونة هو طبقة استدعاء مستقلة عن النموذج (واجهة داخلية واحدة خلفها مزودون قابلون للاستبدال).
ماذا تحقق ميزانية الرموز وتقليص السياق؟
لا تدفع مقابل رموز لا ترسلها. فيما يلي الأسباب المعتادة لتضخم السياق في أنظمة الإنتاج وحلولها:
- أجزاء كثيرة في RAG: إرسال عشرين جزءًا من المستندات "احتياطًا" يرفع التكلفة وخطر الاعتماد على المقطع الخطأ معًا. واختيار أكثر الأجزاء صلة عبر إعادة الترتيب يكون عادةً أرخص وأدق.
- سجل محادثة غير محدود: في المحادثات الطويلة، لخّص الرسائل القديمة أو احتفظ فقط بآخر بضع جولات والمعلومات المهمة الدائمة.
- تعريفات أدوات غير مستخدمة: بدلًا من إرسال تعريفات أربعين أداة مع كل طلب، أعطِ الوكيل المجموعة الفرعية المتعلقة بنوع المهمة.
- مخرجات غير مضبوطة: حدّد طولًا أقصى للمخرجات، واطلب مخرجات منظمة (مخطط JSON)، واستخدم التعليمات التي تطيل الإجابة مثل "اشرح خطوة بخطوة" فقط حيث تلزم فعلًا.
- حد لخطوات الوكيل: امنح كل مهمة وكيل ميزانية للخطوات والرموز. وعند تجاوزها يتوقف الوكيل ويحيل الأمر إلى إنسان؛ فالوكيل العالق في حلقة قد يستهلك ميزانية شهر كامل في ليلة واحدة.
يجب دائمًا قياس أثر تقليص السياق على الجودة بمجموعة الاختبار. فالتقليص المفرط ينتج إجابات رخيصة لكنها خاطئة، ويكشف مقياس التكلفة لكل مهمة ناجحة ذلك فورًا.
متى تكون المعالجة على دفعات منطقية؟
كل مهمة لا ينتظر المستخدم إجابتها فورًا مرشحة للمعالجة على دفعات (batch): تصنيف المستندات ليلًا، وإثراء كتالوج المنتجات، ووسم السجلات التاريخية، وإعادة توليد التضمينات، وجولات التقييم. يقدّم معظم المزودين الكبار واجهة مخفّضة لطلبات الدفعات التي تقبل تسليم النتائج خلال بضع ساعات. والنقطة المهمة هنا أن يكون سير العمل قادرًا فعلًا على الانتظار: فإذا كان المستخدم ينتظر أمام الشاشة فالدفعات غير مناسبة. كما تحتاج مهام الدفعات إلى إعادة إدراج السجلات الفاشلة في الطابور والتحقق من النتائج.
متى تكون النماذج مفتوحة الأوزان على خوادمك أرخص؟
تحسّنت النماذج مفتوحة الأوزان كثيرًا خلال العام الماضي. فمع Qwen 3.8 صدر لأول مرة نموذج من فئة Max بأوزان مفتوحة، واقتربت نماذج مثل Kimi K3 من النماذج المغلقة في بعض المهام. وهذا يجعل سؤال "واجهة API أم خوادمنا الخاصة؟" سؤال تكلفة حقيقيًا.
هيكلا التكلفة مختلفان جذريًا. في الـ API تكون التكلفة متغيرة: تدفع بقدر ما تستخدم، ولا شيء حين لا تستخدم. أما على خوادمك فالتكلفة ثابتة في معظمها: خادم GPU، ووقت المهندسين لإبقائه يعمل، والمراقبة، والتكرار الاحتياطي، تُدفع سواء وُجدت حركة أم لا. لذلك لا تصبح الاستضافة الذاتية أرخص إلا عند حجم مرتفع ومنتظم.
مثال حسابي (بأرقام افتراضية): لنقارن إعدادًا بتكلفة شهرية ثابتة قدرها 100 وحدة (شاملة GPU والتشغيل والمراقبة) مع واجهة API تتقاضى وحدتين لكل مليون رمز. نقطة التعادل هي 50 مليون رمز شهريًا. دونها تكون الـ API أرخص؛ وفوقها يصبح إعدادك الخاص أفضل ما دامت سعة الخادم كافية. وفي الحساب الحقيقي خذ في الاعتبار متوسط إشغال الخادم أيضًا: فتكلفة GPU خامل ليلًا تقع على طلبات النهار.
إلى جانب التكلفة، قد يرجّح سببان خوادمك الخاصة: الحالات التي يجب ألا تخرج فيها البيانات الشخصية إلى مزود أجنبي بسبب قواعد حماية البيانات أو توطينها، ومتطلبات زمن الاستجابة أو التوافر. والبنية التي نوصي بها غالبًا هجينة: المهام الحساسة أو كبيرة الحجم والبسيطة نسبيًا تعمل على نموذج مفتوح في خوادمك، والمهام النادرة والصعبة تذهب إلى نموذج قوي عبر API. وتجمع طبقة التوجيه الاثنين خلف واجهة واحدة.
كيف تراقب تكلفة نماذج اللغة الكبيرة؟
ما لا يُقاس لا يُدار. لكل استدعاء نموذج يجب تسجيل الحقول التالية على الأقل: الميزة أو سير العمل الذي أُجري من أجله، والعميل أو المستأجر الذي ينتمي إليه، والنموذج وإصدار الموجّه المستخدمان، وعدد رموز المدخلات والمخرجات والرموز المقروءة من التخزين المؤقت، وزمن الاستجابة، وعدد مرات إعادة المحاولة، وما إذا نجحت النتيجة. ومن هذه السجلات تُستخرج ثلاث رؤى:
- التكلفة لكل ميزة: كم تنفق كل ميزة في المنتج وما تكلفتها لكل مهمة ناجحة.
- التكلفة لكل عميل: خاصة في منتجات SaaS، تُظهر ما إذا كان تسعيرك يغطي تكلفة الذكاء الاصطناعي. فعميل واحد كثيف الاستخدام قد يشوّه المتوسط.
- تنبيهات الشذوذ والميزانية: تنبيه عند تجاوز الإنفاق اليومي حدًّا معينًا، وحصص لكل وكيل أو مستخدم. يجب اكتشاف الخطأ أو الحلقة قبل وصول الفاتورة.
بدلًا من تثبيت أسعار المزودين داخل الشيفرة، احتفظ بها في جدول أسعار ذي إصدارات، حتى لا تفسد التقارير السابقة عند تغيّر الأسعار وتُحسب الأرقام الجديدة بالسعر الصحيح. وإذا احتوت بيانات المراقبة على بيانات شخصية، فحدّد الإخفاء ومدة الاحتفاظ مسبقًا.
قائمة تحقق لتحسين تكلفة نماذج اللغة الكبيرة
- هل تقيس التكلفة لكل مهمة ناجحة لا لكل استدعاء؟
- هل يُسجَّل كل استدعاء مع الميزة والعميل والنموذج وإصدار الموجّه؟
- هل لديك مجموعة اختبار تقيس الدقة وتُعاد مع كل تغيير؟
- هل السياق الثابت (تعليمات النظام، تعريفات الأدوات) في البداية ليستفيد من التخزين المؤقت للموجّه؟
- هل يُستخدم التخزين المؤقت للإجابات المطابقة مع المدخلات المتكررة؟
- إن وُجد تخزين مؤقت دلالي، فهل الإجابات التي تحتوي على بيانات شخصية مستبعدة منه؟
- هل تُوجَّه المهام السهلة إلى نموذج صغير أو تُحل بالاستدعاء المتدرّج؟
- هل عدد أجزاء RAG وسجل المحادثة محدودان؟
- هل الطول الأقصى للمخرجات والمخرجات المنظمة محددة؟
- هل لدى الوكلاء ميزانية للخطوات والرموز؟
- هل تعمل المهام التي تحتمل الانتظار عبر واجهة الدفعات؟
- هل قارنت بين الـ API والنماذج مفتوحة الأوزان لحجم استخدامك بالأسعار الحالية؟
- هل تنبيهات الميزانية اليومية والشذوذ مفعّلة؟
كيف تتعامل Detartech مع تكلفة الذكاء الاصطناعي؟
نناقش التكلفة في بداية المشروع لا في نهايته. عند تصميم ميزة ذكاء اصطناعي، نوثّق أولًا كتابيًا كيف سيُقاس النجاح وما التكلفة المقبولة لكل مهمة. ثم نبني طبقة استدعاء مستقلة عن النموذج، وسجلًّا للتكلفة والجودة لكل استدعاء، ومجموعة اختبار، ونتخذ قرارات التخزين المؤقت والتوجيه والتقليص بناءً على هذه القياسات. وحيث تكون البيانات حساسة، ندرس أيضًا البنى الهجينة التي تشغّل النماذج مفتوحة الأوزان على بنيتك التحتية. وللاطلاع على الأسئلة المتعلقة بضبط التكلفة التي ينبغي طرحها عند اختيار شريك، راجع دليلنا حول كيفية اختيار شركة لتكامل الذكاء الاصطناعي.
إذا كانت فاتورة الذكاء الاصطناعي لديك تنمو أسرع من منتجك، أو أردت ضبط تكلفة ميزة جديدة بشكل صحيح من البداية، فاطّلع على طريقة عملنا في صفحة حلول الذكاء الاصطناعي أو املأ نموذج عرض السعر السريع. في الاجتماع الأول نحدد معًا أين يُنفق استخدامك الحالي.
الأسئلة الشائعة
ما هو تحسين تكلفة نماذج اللغة الكبيرة؟ هو العمل على خفض تكلفة استخدام النماذج في نظام قائم على الذكاء الاصطناعي دون خفض جودته. ويشمل تقنيات مثل التخزين المؤقت وتوجيه النماذج وتقليص السياق والمعالجة على دفعات، والانتقال عند الحاجة إلى نماذج مفتوحة الأوزان، ويتم دائمًا مع قياس الدقة.
هل يخفّض الانتقال إلى نموذج أرخص التكلفة؟ ليس دائمًا. فإذا كان النموذج الأرخص يخطئ أكثر، فقد ترفع إعادة المحاولة والتصحيح البشري التكلفة لكل مهمة ناجحة. يجب اتخاذ القرار بمقارنة دقة النموذجين والتكلفة الإجمالية لكل مهمة على مجموعة الاختبار نفسها.
هل يؤثر التخزين المؤقت للموجّه على الجودة؟ لا. فهو يمنع النموذج من إعادة معالجة السياق نفسه ولا يغيّر محتوى الإجابة. ولكي يكون فعّالًا، يجب أن يكون المحتوى الثابت في بداية السياق والمحتوى المتغير في نهايته.
متى يكون تشغيل النماذج على خوادمنا الخاصة منطقيًا؟ عندما يكون حجم الاستخدام مرتفعًا ومنتظمًا، أو يجب ألا تغادر البيانات البلد، أو تكون متطلبات زمن الاستجابة والتوافر صارمة. أما مع الحجم المنخفض والمتذبذب فالـ API أرخص عادةً، لأن تكلفة خادمك ثابتة حتى إن لم تستخدمه.
كيف نتابع تكلفة الذكاء الاصطناعي لكل عميل؟ بتسجيل كل استدعاء نموذج مع معرّف العميل أو المستأجر. تُظهر هذه السجلات حجم التكلفة التي يولّدها كل عميل وما إذا كان تسعيرك يغطيها، وتُبنى الحصص والتنبيهات من البيانات نفسها.
