المكاسب:
- القدرة على تقييم المفاضلات بين واجهة برمجة التطبيقات المُدارة وVPC والاستضافة المحلية
- القدرة على اتخاذ قرار بشأن الاستضافة بناءً على سيادة البيانات والحجم والقدرة التشغيلية
- القدرة على حساب التكلفة الإجمالية للملكية (TCO) مع العناصر الكاملة والتصميم المعماري المختلط
بالنسبة لبعض المؤسسات، يعد "إرسال البيانات إلى مزود الخدمة" - بغض النظر عن مدى أمانها - أمرًا غير مقبول. في صناعة الدفاع والسيناريوهات العامة والمصرفية وبعض السيناريوهات الصحية، لا ينبغي أبدًا أن تتجاوز البيانات حدود المؤسسة. في هذه المرحلة، تظهر استضافة النموذج الخاص بك في المقدمة: النماذج ذات الوزن المفتوح، التي تعمل في شبكتك السحابية (VPC) أو على خوادمك الخاصة (محليًا). في هذه الوحدة، سوف نتعلم المفاضلات بين واجهة برمجة التطبيقات المُدارة والاستضافة الذاتية، عندما يكون ذلك منطقيًا، والتكلفة الإجمالية للملكية (TCO).
المفاهيم
- واجهة برمجة التطبيقات المُدارة: تعمل على البنية التحتية لموفر النموذج؛ يمكنك إرسال طلب والحصول على الرد. النفقات التشغيلية ضئيلة، ولكن البيانات تذهب إلى الموفر.
- نموذج الوزن المفتوح: يمكن تنزيل معلمات النموذج (الأوزان)؛ يمكنك تشغيله على أجهزتك الخاصة. إنه ليس بالضرورة نفس "المصدر المفتوح" (قد يكون الترخيص مختلفًا).
- استضافة VPC (السحابة الخاصة الافتراضية): تشغيل النموذج في شبكتك السحابية المعزولة؛ تظل البيانات عند حدود شبكتك، لكن البنية التحتية لا تزال في السحابة.
- محليًا (محليًا): تشغيل النموذج بالكامل على الأجهزة الموجودة في مركز البيانات الخاص بك؛ أعلى تحكم، أعلى حمل تشغيلي.
تحذير: مقولة "الاستضافة الخاصة أكثر أمانًا دائمًا" هي فكرة خاطئة. يعتمد الأمان بشكل أقل على المكان الذي تحتفظ فيه بالبيانات، ويعتمد بشكل أكبر على مدى جودة إدارتك لها. يعد الخادم المحلي غير المصحح والمكون بشكل سيئ أكثر خطورة من واجهة برمجة التطبيقات المُدارة الناضجة.
محور القرار: أي متى؟
ثلاثة أسئلة توجه القرار:
- سيادة البيانات: هل يحظر القانون أو العقد مغادرة البيانات للمؤسسة/البلد؟ إذا كانت الإجابة بنعم، فسيتم دفعك نحو VPC/on-prem.
- الحجم والتكلفة: هل الاستخدام مرتفع جدًا ويمكن التنبؤ به؟ يمكن للكميات الكبيرة جدًا من الاستضافة الذاتية أن تقلل من تكاليف الوحدة؛ تكون واجهة برمجة التطبيقات المُدارة بكميات منخفضة/غير منتظمة رخيصة دائمًا تقريبًا.
- القدرة التشغيلية: هل لديك فريق للحفاظ على البنية التحتية لوحدة معالجة الرسومات وتحديث النموذج والقياس والتصحيح الأمني؟ وإلا فإن الاستضافة الخاصة بك هي تكلفة مخفية.
جدول المقايضة
الحجم
واجهة برمجة التطبيقات المُدارة
VPC
محلي (الوزن المفتوح)
سيادة البيانات
ثق بالمزود
عالي (عند حدود شبكتك)
الأعلى (لا يرتفع أبدًا)
حمل التشغيل
منخفض جدًا
متوسطة
عالية
التكلفة الأولية
منخفض (الدفع حسب الاستخدام)
متوسطة
عالية (الأجهزة)
التحجيم
تلقائي
تمكنت
مسؤوليتك
جودة النموذج/العملة
الأحدث، تلقائي
يعتمد
قمت بالتحديث
التحكم
منخفض
عالية
كامل
خطوة بخطوة: قرار الاستضافة
- تحديد فئة البيانات. على أي مستوى من السرية سيتم معالجة البيانات؟
- التحقق من القيد القانوني. هل يمكن أن تخرج البيانات؟ (KVKK، تنظيم القطاع، العقد.)
- تقدير الحجم. حجم الطلب/الرمز المميز ومنحنى النمو الشهري.
- حساب التكلفة الإجمالية للملكية. ليس فقط وحدة معالجة الرسومات؛ الطاقة، الصيانة، الفريق، الأمن، التكرار.
- فكر في الهجين. غالبًا ما يكون النموذج المختلط الذي يعالج البيانات الحساسة في VPC المحلي/VPC والبيانات غير الحساسة في واجهة برمجة التطبيقات المُدارة هو الأكثر استقرارًا.
أربعة قوالب قابلة للنسخ
استضافة قرار سريع:
قرر الاستضافة للاستخدام التالي: {{سيناريو }}الأسئلة:- ما هي فئة الخصوصية للبيانات المراد معالجتها؟ (عام / داخلي / سري / سري للغاية) - هل يسمح القانون / العقد بنقل البيانات خارج المنظمة؟ - توقعات الحجم الشهري وإمكانية التنبؤ به؟ - هل هناك قدرة عمليات / فريق GPU؟ التوصية: "واجهة برمجة التطبيقات المُدارة / VPC / المحلية / المختلطة" + التبرير.
قائمة عناصر التكلفة الإجمالية للملكية (للاستضافة الذاتية):
احسب التكلفة الإجمالية للملكية عن طريق: - شراء/استئجار الأجهزة (GPU) - الطاقة والتبريد - الإنسان: عمليات MLOps + وقت فريق الأمان - تحديث النموذج واختبار القوى العاملة - التكرار/التعافي من الكوارث - التصحيح الأمني والمراقبة قارن هذا بالفاتورة الشهرية لواجهة برمجة التطبيقات المُدارة على مدى أفق 12-24 شهرًا.
قاعدة التوجيه الهجين:
قم بتوجيه كل طلب بناءً على فئة البيانات: - البيانات "السرية / السرية للغاية" -> نموذج محلي/VPC - البيانات "العامة / الداخلية" -> واجهة برمجة التطبيقات المُدارة (أكثر قوة/أرخص) اكتب قرار إعادة التوجيه وفئة البيانات إلى سجل التدقيق.
مطالبة فحص أمان الوزن المفتوح:
تقييم نموذجنا المستضاف ذاتيًا: - هل يسمح الترخيص بالاستخدام التجاري وفي السيناريو الخاص بنا؟ - أوزان النموذج من مصدر موثوق، تم التحقق من التكامل (التجزئة)؟ - هل تم تثبيت تصحيح الخادم، وعزل الشبكة، والتحكم في الوصول؟ - هل المراقبة والتسجيل ناضجة مثل واجهة برمجة التطبيقات المُدارة؟ ضع علامة على أي عناصر مفقودة على أنها "ON".
موجه ضعيف / موجه قوي
نهج الفقراء
نهج قوي
"المتجر الداخلي أكثر أمانًا، استخدمه دائمًا"
القرار يعتمد على سيادة البيانات + الحجم + السعة
مجرد النظر إلى تكلفة GPU
التكلفة الإجمالية للملكية الكاملة (الطاقة، الطاقم، التحديثات، الأمان)
أن تكون مقيدًا بنموذج استضافة واحد
هجين: التوجيه حسب فئة البيانات
الجري دون إنزال الوزن المفتوح والتحقق منه
الترخيص + النزاهة + التصحيح + التحكم في التتبع
ثلاث حالات صغيرة
الحالة الأولى - كان التفويض المحلي هو القرار الصحيح. كان على مقاول الدفاع معالجة وثائق سرية للغاية؛ يحظر العقد أخذ البيانات خارج البلاد. تمت إزالة واجهة برمجة التطبيقات المُدارة من البداية. تم إنشاء نموذج الوزن المفتوح محليًا. كانت التكلفة مرتفعة، لكنها كانت الخيار الوحيد المتوافق.
الحالة 2 - قرار إلغاء التكلفة الإجمالية للملكية السري. خططت إحدى الشركات الناشئة للتحول إلى الاستضافة الذاتية لأن "واجهة برمجة التطبيقات (API) باهظة الثمن". في حساب التكلفة الإجمالية للملكية، لا تقوم بتضمين وحدة معالجة الرسومات فقط؛ أضف مهندسي MLOps بدوام كامل، وتحميل التحديث، والتكرار، وسيصبح إجمالي 24 شهرًا ضعف إجمالي واجهة برمجة التطبيقات المُدارة. لقد ظلوا في واجهة برمجة التطبيقات لأن أحجامهم كانت منخفضة ومتفرقة.
الحالة 3 - أعطى الهجين الأفضل. كان مساعد مركز الاتصال التابع للبنك يعالج نوعين من البيانات: الأسئلة العامة عن المنتج وبيانات الحساب الخاصة بالعميل. يتم توجيه بيانات الحساب إلى النموذج داخل VPC، ويتم توجيه الأسئلة العامة إلى واجهة برمجة التطبيقات المُدارة القوية. لم يتم نشر البيانات الحساسة مطلقًا، وتم استخدام أقوى نموذج للأسئلة العامة؛ تم تحسين التكلفة والملاءمة معًا.
نصيحة: ليس من الضروري أن يكون القرار ثنائيًا (كل شيء أو لا شيء). تعمل البنية المختلطة - توجيه البيانات حسب الفئة - على حل مشكلة الامتثال والتكلفة في معظم سيناريوهات المؤسسات في الوقت نفسه.
الأخطاء الشائعة
- افترض أن "الاستضافة الخاصة أكثر أمانًا تلقائيًا"؛ بينما يعتمد الأمن على جودة الإدارة.
- معتقدًا أن التكلفة الإجمالية للملكية هي مجرد تكلفة وحدة معالجة الرسومات؛ الفريق والطاقة والتحديث ونسيان الأمن.
- التحول إلى الاستضافة الذاتية بكميات منخفضة/غير منتظمة وزيادة تكلفة الوحدة.
- استخدام نموذج الوزن المفتوح دون التحقق من الترخيص والنزاهة (التجزئة).
- عدم تثبيت المراقبة/التسجيل الناضج مثل واجهة برمجة التطبيقات المُدارة على الخادم المحلي.
- اتخاذ قرار ثنائي دون النظر إلى الخيار المختلط على الإطلاق.
في ملخص
- تعد واجهة برمجة التطبيقات المُدارة هي الأسهل من الناحية التشغيلية، لكن البيانات تذهب إلى الموفر؛ تحتفظ VPC/on-prem بالبيانات على حدودك.
- وهناك ثلاثة أسئلة تدفع القرار: سيادة البيانات، والقدرة على التنبؤ بالحجم/التكلفة، والقدرة التشغيلية.
- "الاستضافة الذاتية أكثر أمانًا" فكرة خاطئة؛ لا يعتمد الأمان على المكان الذي تحتفظ فيه بالبيانات، بل على مدى جودة إدارتك لها.
- قم بحساب التكلفة الإجمالية للملكية بشكل دقيق: الطاقة، والفريق، والتحديث، والتكرار، والأمان، بالإضافة إلى وحدة معالجة الرسومات.
- تعمل البنية المختلطة (توجيه البيانات حسب الفئة) على موازنة الامتثال والتكلفة في معظم سيناريوهات المؤسسة في نفس الوقت.
مهمة التطبيق
اختر استخدامًا للذكاء الاصطناعي وافصل البيانات المراد معالجتها في فئة خصوصية. قم بإنشاء توصية مع موجه قرار الاستضافة. ثم قم بملء قائمة عناصر TCO لاستضافتك الخاصة وقارن إجمالي 24 شهرًا بفاتورة API المُدارة. أخيرًا، اكتب مسودة قاعدة توجيه هجينة: ما هي البيانات التي تذهب إلى أين؟
قائمة مرجعية
- [ ] لقد قمت بتحديد فئة السرية والقيود القانونية للبيانات المراد معالجتها.
- [ ] لقد اتخذت قرار الاستضافة بناءً على السيادة + الحجم + السعة.
- [ ] لقد قمت بحساب التكلفة الإجمالية للملكية باستخدام العناصر الكاملة (بما في ذلك العناصر غير التابعة لوحدة معالجة الرسومات).
- [ ] لقد تحققت من الترخيص والنزاهة والتصحيح والمراقبة على الاستضافة الذاتية.
- [ ] لقد فكرت في خيار التوجيه المختلط.
- [ ] لقد قمت بتوثيق القرار وأسبابه.