كيف تتكامل TrueFoundry مع GCP: بنية مستوى التحكم

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
يتطلب نشر الذكاء الاصطناعي التوليدي على منصة جوجل السحابية (GCP) تنسيق مجموعة معقدة من العناصر الأساسية: محرك جوجل كوبيرنيتيس (GKE)، وحدات معالجة الموتر السحابية (Cloud TPUs)، و Vertex AI. بينما توفر GCP قوة الحوسبة الخام، فإن ربط هذه المكونات بمنصة مطور داخلية (IDP) متوافقة يتطلب هندسة مخصصة كبيرة.
تعمل TrueFoundry كطبقة بنية تحتية علوية. نحن نتولى التنسيق، مما يترك لك التحكم في شبكة VPC وموقع البيانات. توضح هذه المقالة أنماط تكاملنا مع GCP، وتحديداً فيما يتعلق ببنية المستوى المنفصل، اتحاد هوية عبء العمل، وإدارة وحدات معالجة الموتر (TPU).
نموذج النشر: بنية المستوى المنفصل
نستخدم بنية المستوى المنفصل لعزل واجهة الإدارة عن بيئة تنفيذ عبء العمل الخاصة بك.
- مستوى التحكم: خادم API ولوحة التحكم المستضافين لدينا. يتعامل مع البيانات الوصفية، والتحكم في الوصول المستند إلى الدور (RBAC)، وجدولة المهام.
- مستوى الحوسبة: الوكلاء ووحدات التحكم التي تعمل مباشرة على مجموعة GKE الخاصة بك. يتعامل مع أوزان النموذج، وبيانات العملاء، والاستدلال.
حدود الأمان لا نطلب قواعد جدار حماية واردة. يبدأ الوكيل في مجموعتك تدفق WebSocket أو gRPC آمنًا وصادرًا فقط إلى مستوى التحكم لدينا. يستعلم عن بيانات نشر التطبيقات ويدفع بيانات القياس عن بعد. تظل شبكة VPC الخاصة بك خاصة بحركة المرور الواردة الخارجية.

الشكل 1: بنية المستوى المنفصل تعزل معالجة البيانات داخل شبكة VPC الخاصة بالعميل.
طوبولوجيا الشبكة
لتحقيق أداء عالٍ، نقوم بتهيئة مستوى الحوسبة لاستخدام مجموعات VPC الأصلية باستخدام عناوين IP البديلة. جميع موارد الحوسبة توجد ضمن الشبكات الفرعية الخاصة.
الدخول (طلبات الاستدلال) تدخل حركة مرور التطبيق شبكة VPC عبر موازنة حمل السحابة (عادةً ما يكون ALB خارجيًا عالميًا). يقوم ALB بإنهاء TLS ويعيد توجيه الطلبات إلى بوابة دخول Istio التي تعمل ضمن مجموعة GKE.
الوصول الخاص إلى Google للحفاظ على الامتثال، يتم توجيه حركة المرور إلى واجهات برمجة تطبيقات Google (مثل Cloud Storage و Vertex AI) عبر الوصول الخاص إلى Google. هذا يحافظ على حركة المرور بين وحدات الاستدلال وخدمات GCP المدارة على العمود الفقري لشبكة Google، متجاوزة الإنترنت العام.
الخروج تتطلب عقد عامل GKE وصولاً خارجيًا لسحب صور الحاويات من سجل البيانات الاصطناعية. نقوم بتوجيه حركة المرور هذه عبر Cloud NAT متصلة بالشبكات الفرعية الخاصة.

الشكل 2: تدفق حركة مرور الشبكة يوضح الاتصال الوارد والخاص.
اتحاد الهوية
نفرض إزالة مفاتيح حساب الخدمة الثابتة (ملفات .json). TrueFoundry تطبق هوية عبء عمل GKE لجميع مصادقة أعباء العمل.
تسلسل المصادقة
- الإنشاء: عند نشر خدمة، ننشئ حساب خدمة Kubernetes (KSA).
- الربط: نُعلِّم KSA لربطه بحساب خدمة Google (GSA) عبر ربط roles/iam.workloadIdentityUser.
- التبادل: الـ خادم بيانات تعريف GKE يعترض الطلبات، مبادلاً رمز KSA المميز برمز وصول Google Cloud مميز قصير الأجل.
- الوصول: يستخدم الـ pod هذا الرمز المميز للمصادقة بشكل أصلي (ADC) مع موارد مثل BigQuery أو Vertex AI.
إذا تم اختراق pod، فإن نطاق الضرر يقتصر بشكل صارم على أدوار IAM الممنوحة لحساب GSA المحدد هذا.

الشكل 3: تدفق مصادقة هوية عبء عمل GKE.
الحوسبة: تحسين TPU و Spot.
نتكامل مع تجمعات عقد GKE لتنسيق وحدات معالجة الرسوميات NVIDIA ووحدات معالجة الموتر السحابية.
تنسيق TPU تتطلب الجدولة على وحدات معالجة الموتر (TPUs) التعامل مع قيود طوبولوجيا محددة. تدير TrueFoundry محدد العقد (nodeSelector) والتسامحات (tolerations) اللازمة لجدولة الحاويات (pods) على شرائح TPU (مثل v4-8، v5e). نقوم تلقائيًا بحقن برامج التشغيل الضرورية وحدود الموارد في بيان النشر، مما يجرّد إعداد Kubernetes منخفض المستوى.
إدارة Spot VM لأعباء عمل المعالجة الدفعية أو التطوير، نقوم بإدارة أجهزة Spot الافتراضية لتقليل التكاليف (عادةً 60-90% مقارنةً بالطلب الفوري).
- التزويد: نقوم بتنسيق تجمعات العقد (Node Pools) مع تمكين التزويد الفوري.
- معالجة الإنهاء: نراقب إشعار الإخلاء المسبق لمدة 30 ثانية. عند الكشف، نقوم بعزل العقدة ونشغل المجدول لنقل الحاوية (pod) إلى تجمع احتياطي عند الطلب أو عقدة Spot بديلة.
بوابة الذكاء الاصطناعي: واجهة موحدة
تتسبب إدارة مفاتيح مميزة لنماذج مثل Gemini Pro في زيادة الأعباء التشغيلية. توفر TrueFoundry بوابة ذكاء اصطناعي تعمل كواجهة برمجة تطبيقات (API) موحدة.
- مصادقة موحدة: قم بالمصادقة مرة واحدة مقابل البوابة. نتولى تبادل هوية أعباء العمل (Workload Identity) مع Vertex AI.
- تبديل النماذج: التحويل من Gemini Pro إلى Llama-3-70b مستضاف ذاتيًا بتغيير معلمة تهيئة واحدة. لا يلزم إعادة كتابة أي كود.
- تحديد مصادر التكلفة: نسجل استخدام الرموز (tokens) لكل مشروع، مما يتيح لك ربط تكاليف Vertex AI المشتركة بمراكز التكلفة الداخلية.
مقارنة تشغيلية
ملخص
يتيح هذا التكامل لفريقك الاستفادة الكاملة من مزايا أجهزة GCP — وتحديداً وحدات معالجة الموتر (TPUs) والشبكات عالية الإنتاجية — دون الانغماس في التعقيدات التشغيلية لإدارة Kubernetes الخام. تعمل TrueFoundry كمضاعف قوة لبنيتك التحتية: نحن نجرد تعقيد تنسيق GKE بينما تحتفظ أنت بالسلطة المطلقة على الأمن وموقع البيانات. يتيح لك هذا التوازن تشغيل أعباء عمل الذكاء الاصطناعي التوليدي (GenAI) على الفور، محولاً البنية التحتية من قيد إلى ميزة سرعة تنافسية.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI

















.png)
.webp)










.webp)






