الفصل 15 — واجهات API بلا خادم مقابل البنية التحتية المخصَّصة

تم النشر في: 1447-11-20 آخر تحديث في: 1448-01-23 الإصدار: 1
الفصل 15 — واجهات API بلا خادم مقابل البنية التحتية المخصَّصة

الفصل 15 — واجهات API بلا خادم مقابل البنية التحتية المخصَّصة

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


لماذا يوجد هذا الفصل

ترك الفصل 14 الفريق يحمل صورة نظيفة ممَّا تُصنَع منه فاتورة API، وشكاً هادئاً بأنها قد تكون أرخص. السؤالُ التالي الطبيعي هو ما إذا كان يجب على الفريق الدفع لكل رمز أصلاً. البديل إعادة الاستدلال إلى الداخل، تشغيل نموذج مفتوح الأوزان على المكدس الذي وصفته الفصول السابقة، والدفع لكل ساعة GPU بدلاً. للمقايضة نقطة تعادل نظيفة. ما هو أقل نظافة، وما تُقلِّل أغلب الفرق شأنه، هو كل ما على الجانب المخصَّص من دفتر الحسابات ليس على فاتورة GPU — هندسة المنصة، وترقيعات الأمان، وكوريغرافيا ترقية النموذج، وصفحة 3 صباحاً حين تسقط عقدة من الأسطول. يأخذ الفصل 15 كلا الجانبَين بجدية ويستنتج متى تكون الاستضافة الذاتية هي الإجابة الصحيحة.

في سطر واحد: بند إيجار GPU يُقرِّر حسابيات الرمز؛ وبند هندسة المنصة يُقرِّر الصفقة — والثاني دالة درجيَّة تقلب عتبة التعادل كلما أُطلقت.

15.1 صيغة التعادل نظيفة، وفي أغلبها خدعة

GPU تُنتج إنتاجية × استخدام × 3,600 رمز مُخرَج في الساعة. كلفتها لكل مليون رمز هي (ساعة gpu / رموز في الساعة) × 1,000,000. التعادل مقابل API هو حيث يتساوى ذلك الرقم مع سعر API لكل مليون. نموذج 70B بدقة FP8 على H100 عند 3$/ساعة، يعمل عند 800 رمز في الثانية إجمالياً باستخدام 60 بالمئة، يخرج بنحو 1$ لكل مليون رمز مُخرَج. API الطليعة تشحن 15$. الوفورات الظاهرة 14× — حجَّة للاستضافة الذاتية يحبها القسم المالي وتفتقد البند الثاني الأكبر. يعتمد التعادل أيضاً على الاستخدام؛ تحت استخدام 20–30 بالمئة ترتفع كلفة الاستضافة الذاتية لكل مليون فوق سعر API وتصير GPU أغلى من البديل الذي كان يُفترَض بها إزاحته. الاستخدام، بدوره، دالة في شكل حركة المرور، وجودة التوسع التلقائي، وما إذا كان الفريق يستطيع تعبئة أكثر من عبء عمل على نفس الأسطول.

15.2 هندسة المنصة هي البند الذي يُقرِّر الصفقة

فاتورة GPU هي النصف الأصغر. النصف الأكبر هو الفريق الذي يُبقي الأسطول عاملاً: المحركات، وبرامج التشغيل، والتنسيق، والتوسع التلقائي، وقابلية الرصد، والأمان. يدفع فريق API هذه الكلفة ضمنياً عبر السعر لكل رمز؛ ويدفعها فريق الاستضافة الذاتية في العدد. قاعدة إبهام مفيدة: أسطول تخديم GPU واحد — تنوُّع نموذج أو اثنَين، توسع تلقائي، قابلية رصد، مناوبة، ترقيات ربع سنوية — يتطلَّب تقريباً مهندس منصة واحداً بدوام كامل زائد جزء من SRE. أسطول أكثر تنوعاً — عدة محركات، عدة نماذج، جدولة متعدِّدة المستأجرين — يتطلَّب اثنين إلى أربعة. عند 300$ ألف مُحمَّلاً كاملاً لكل مهندس، فاتورة المنصة السنوية 300$ ألف إلى 1.2$ مليون. حركة المرور الشهرية للتعادل حيث تُسدِّد الاستضافة الذاتية في مكان ما بين 200 مليون ومليار رمز مُخرَج شهرياً. تحت ذلك، نفقات الهندسة تفوق وفورات الرموز والفريق يجب أن يبقى على API. فوقه، تُهيمن الوفورات. تأتي هندسة المنصة أيضاً بدوال درجيَّة لا منحنيات ملسة: أول توظيف يُقلع الأسطول، الثاني يحصل لأن الأول لا يستطيع تغطية مناوبة عطلة نهاية الأسبوع، الثالث حين ينمو الأسطول إلى متعدِّد المناطق.

15.3 الموقف الواقعي هجين، والمُوجِّه هو القطعة الحاملة

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

يجدر بنا تذكُّره: إيجار مقابل شراء لا تُقرِّرها حسابيات الرمز. تُقرِّرها ما إذا كانت حركة مرور الفريق الشهرية تعبر دالة درجة هندسة المنصة، وما إذا كان عبء عمل ثانٍ يستطيع مشاركة GPU، وما إذا كان شكل حركة المرور يسمح باستخدام فوق عتبة التعادل.

ما يُمهِّد له الفصل 15

سمَّى الفصل 15 فئة عبء عمل قدَّمها الوكلاء لا تُلائم «استدعاء API» ولا «تخديم نموذج»: بيئة تنفيذ الكود المُولَّد من LLM، التي تعيش على دوال بلا خادم، أو MicroVM (Firecracker وgVisor)، أو صناديق WASM بحسب العزل ومرونة الحزم التي يحتاجها الوكيل. يُغلق الفصل 16 المجلد بكتالوج حركات خفض التكلفة التي تُطبَّق على أي جانب من خط الموقف: التوجيه الذكي للنموذج، وضغط السياق على مستوى التطبيق، وواجهات API الدُّفعية، والتخزين المؤقت الدلالي — الحركات التي تتراكم إلى ثلث أو نصف فاتورة الشهر الماضي.


التالي — الفصل 16: استراتيجيات خفض التكلفة في الإنتاج. الحركات المتراكمة التي تُحوِّل فاتورة الشهر الماضي إلى وفورات الشهر القادم.

هل تريد الصورة الكاملة؟ يشمل فصل الكتاب فئتَي البيانات SelfHostProfile وPlatformOverhead القابلتَين للتشغيل، ودالتَي breakeven_utilization وbreakeven_monthly_tokens، والمثال المشروح للموقف الهجين، ورسم صندوق MicroVM لتنفيذ الكود المُولَّد من الوكيل. اطّلع على LLM Primer VI على أمازون ←

SHO
SHO
مدير التكنولوجيا والمؤسس لشركة RECEIPTROLLER. يركز على البيانات، مدفوع بالابتكار، دائم الفضول.