ما الذي تكلفه فعليًا تشغيل LLMs في الإنتاج

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

التكلفة الظاهرة هي الصغيرة

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

التكاليف التي تتراكم فعليًا

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

التكلفة التي تتضاءل أمامها البقية

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

لماذا تكذب النماذج الأولية بشأن التكلفة؟

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

كيف تضع ميزانية لهذا قبل أن تبني؟

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

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

كيف تبدو الميزانية الجيدة؟

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