تصميم TrueFoundry على Azure: تكامل مستوى التحكم والحوسبة

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
بناء منصة ذكاء اصطناعي توليدي على Microsoft Azure يعني ربط عناصر الحوسبة والهوية والذكاء الاصطناعي الأساسية والمتميزة معًا. تقوم بتوفير السعة الخام عبر خدمة Azure Kubernetes (AKS) والأجهزة الافتراضية الفورية (Spot VMs)، وتتعامل مع الهوية عبر Entra ID، وتوجيه الطلبات إلى Azure OpenAI. تظهر الصعوبات عندما يتعين على فرق البنية التحتية تنسيق هذه الاتصالات يدويًا لكل عملية نشر نموذج جديدة.
يتم نشر TrueFoundry كطبقة بنية تحتية علوية داخل اشتراك Azure الخاص بك. نحن نتولى دورة حياة النشر، واتحاد الهوية، والتحجيم التلقائي. تشرح هذه المقالة أنماط التكامل الدقيقة التي نستخدمها لربط TrueFoundry بـ Azure، وتغطي نشر المستويين المنفصلين، وحدود الشبكة، وآليات هوية عبء العمل.
نموذج النشر: بنية المستويين المنفصلين
نستخدم بنية المستويين المنفصلين لعزل تنفيذ أعباء العمل عن إدارة المنصة. إذا كنت تبني منصات على Amazon EKS، سيبدو هذا النموذج مألوفًا لك: حيث تفصل سطح التحكم عن مستوى البيانات.
- مستوى التحكم: يعمل كخادم API ومخزن للبيانات الوصفية. ويحتوي على ملفات تعريف النشر، وتكوينات RBAC، وبيانات القياس عن بعد.
- مستوى الحوسبة: يعمل داخل مجموعة AKS الخاصة بك. ويتكون من وكيل TrueFoundry، ووحدات التحكم المحلية، وأوزان نموذجك الفعلي ووحدات معالجة الرسوميات (GPUs).
نربط المستويين باستخدام اتصال آمن، صادر فقط gRPC تدفق أو WebSocket. يبدأ الوكيل الموجود على جانب المجموعة الاتصال بمستوى التحكم لسحب ملفات التعريف ودفع السجلات. لا تفتح أي منافذ واردة على مجموعات أمان الشبكة (NSG) لشبكتك الافتراضية (VNET). ترفض شبكتك الافتراضية (VNET) الدخول الخارجي من الإنترنت بشكل افتراضي.

الشكل 1: بنية المستويين المنفصلين تعزل معالجة البيانات داخل الشبكة الافتراضية للعميل.
طوبولوجيا الشبكة وتدفق حركة المرور
نقوم بتكوين شبكة مستوى الحوسبة باستخدام Azure CNI لتعيين عناوين IP مباشرة على مستوى الـ Pod. تبقى موارد الحوسبة الخاصة بك في شبكات فرعية خاصة.
حركة المرور الواردة والصادرة
- حركة المرور الواردة: تصل حركة مرور التطبيق إلى بوابة تطبيق Azure أو موازن تحميل داخلي قياسي. تقوم البوابة بإنهاء TLS وتمرير حركة المرور إلى بوابة Istio للدخول التي تعمل داخل AKS.
- حركة المرور الصادرة: توجه عقد عامل AKS المكالمات الصادرة عبر بوابة Azure NAT. تستخدم هذا المسار لسحب الصور من سجل حاويات Azure واستقصاء مستوى التحكم.
تكامل نقطة النهاية الخاصة
لضمان حدود الامتثال الصارمة، نوجه حركة المرور عبر Azure Private Link. يتم توجيه الاتصالات من وحدات الـ Pods الخاصة بالاستدلال إلى Azure OpenAI و Key Vault و Blob Storage بالكامل عبر العمود الفقري لـ Microsoft.

الشكل 2: تدفق حركة مرور الشبكة يوضح تفاصيل الدخول والاتصال الخاص بخدمات Azure PaaS.
اتحاد الهوية: Entra Workload ID
تتسبب الأسرار الثابتة المكتوبة برمجيًا وكيانات الخدمة في عبء كبير عند التدوير. نصادق أحمال العمل ديناميكيًا باستخدام Microsoft Entra Workload ID. إذا كنت تدير بيئات AWS، فهذا هو مكافئ Azure لـ AWS IAM Roles for Service Accounts (IRSA).
عند نشر مسار عمل، ننفذ هذا التسلسل:
- إنشاء حساب خدمة: نقوم بتوفير حساب خدمة Kubernetes في مساحة اسم عبء العمل.
- الاتحاد: نربط حساب الخدمة هذا بهوية مُدارة معينة من قبل المستخدم في Entra ID.
- تبادل الرمز المميز: يطلب الجراب رمزًا مميزًا موقّعًا من AKS جهة إصدار OIDC. يقوم Azure SDK بتبديل هذا الرمز المميز برمز وصول Entra عبر OpenID Connect نقطة النهاية.
- الوصول إلى الموارد: يستخدم الجراب هذا الرمز المميز لجلب النماذج من Blob Storage أو الوصول إلى Azure OpenAI.
نستخدم DefaultAzureCredential في رمز التطبيق. وهذا يحد من نطاق الضرر بشكل صارم على أذونات RBAC الممنوحة لتلك الهوية المُدارة المحددة.

الشكل 3: تدفق مصادقة Entra Workload ID.
تنسيق الحوسبة: تكامل Spot VM
غالبًا ما يؤدي تشغيل الاستدلال في الحالة المستقرة على الأجهزة الافتراضية عند الطلب إلى تكاليف أساسية أعلى. نحن نتكامل مباشرة مع مجموعات عقد AKS لتنسيق الأجهزة الافتراضية الفورية من Azure (على غرار استخدام مثيلات Amazon EC2 الفورية).
نحن ندير سعة Spot باستخدام الآلية التالية:
- التوفير: نقوم بإنشاء مجموعات عقد ثانوية بأولوية=Spot وسياسة إخلاء=Delete.
- معالجة الإخلاء: يستطلع المتحكم الخاص بنا خدمة بيانات تعريف مثيل Azure. عندما نكتشف إشعار إخلاء (تحذير مدته 30 ثانية)، نقوم بعزل العقدة وتفعيل Kubernetes Cluster Autoscaler لإعادة جدولة الـ pod إلى عقدة احتياطية عند الطلب.
للفرق التي تقوم بتشغيل الاستدلال الدفعي أو تقديم واجهة برمجة تطبيقات (API) متسامحة مع الأخطاء، يمكن لهذا الإعداد — تمامًا مثل تشغيل Karpenter على AWS — أن يقلل تكاليف مثيلات الحوسبة بنسبة تصل إلى 80% حسب مرونة عبء العمل.
بوابة الذكاء الاصطناعي: توحيد النماذج
إن إدارة مفاتيح API مميزة وحدود الرموز في الدقيقة (TPM) عبر مناطق Azure متعددة يخلق عبئًا تشغيليًا. تعمل بوابة TrueFoundry للذكاء الاصطناعي على تجريد هذا الأمر. على غرار توجيه الطلبات عبر Amazon Bedrock، يصل المطورون إلى نقطة نهاية API داخلية واحدة.
- التوجيه الذكي: نوازن الحمل على الطلبات عبر مناطق Azure. إذا فرضت منطقة شرق الولايات المتحدة قيودًا على معدل طلبك، تعيد البوابة المحاولة في منطقة أوروبا الغربية.
- تجاوز الفشل: إذا حدث انقطاع في خدمة Azure PaaS، يمكن للبوابة تحويل حركة المرور إلى مثيل Llama 3 أو Mistral مستضاف مباشرة على مستوى الحوسبة الخاص بـ AKS لديك.
توافقية البنية التحتية كتعليمات برمجية
نتوافق مع ممارسات GitOps و IaC القياسية. يمكنك توفير بيئة Azure الأساسية باستخدام ما نقوم بصيانته تيرافورم وحدات.
تدير حالة Terraform الخاصة بك شبكات VNETs ومجموعة AKS وجهات إصدار OIDC وقواعد بيانات PostgreSQL الأساسية. تتطابق طبقة TrueFoundry ببساطة مع هذه الموارد الأصلية، مما يحافظ على بنيتك التحتية قابلة للتدقيق ومتوافقة.
مقارنة تشغيلية
ملخص
يؤدي نشر TrueFoundry على Azure إلى عزل تنفيذ الحوسبة والبيانات لديك بينما ندير نحن دورة حياة التطبيق. تحتفظ بسلطة مباشرة على شبكات VNETs وNSGs ونطاقات إقامة البيانات الخاصة بك. نتولى نحن التنسيق. من خلال تجريد الترابط المعقد بين AKS وEntra ID وAzure OpenAI، نسمح لفرق الهندسة لديك بالتركيز على تسليم النماذج بدلاً من محاربة البنية التحتية.
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)






