Written with AI assistance from the source video. The video is the authority.
9:38Better Stack
Log in to leave a comment
No posts yet
عند استخدام نماذج منخفضة التكلفة مثل DeepSeek Chat و GPT-4o-mini و Gemini 2.5 Flash، تنخفض تكاليف واجهة برمجة التطبيقات (API) بشكل ملحوظ. المشكلة هي أنه حتى مع تدفق طفيف لحركة المرور، ترتفع أوقات الاستجابة من 10 ثوانٍ إلى 60 ثانية. عندما يحدث هذا التأخير في بنية طلبات HTTP التزامنية العادية، تتعطل عمليات خادم الويب بسبب وقت الانتظار، وتفشل واجهة المستخدم (Frontend) مع ظهور خطأ مهلة.
بالنسبة للمطورين المستقلين الذين ينشئون مشاريع جانبية بمفردهم أو ذوي الميزانيات المحدودة، فإن تعطل الخادم يعتبر أمراً كارثياً. ومع ذلك، لا يمكن العودة إلى النماذج الباهظة الثمن. يجب عليك بدلاً من ذلك قطع الاتصال التزامن المباشر بين العميل و LLM، وبناء بنية فصل غير متزامنة (Asynchronous Decoupled Architecture) تنقل مخرجات النموذج الرديئة بأمان إلى واجهة المستخدم.
يجب ألا تجعل خادم الويب ينتظر حتى يكتمل استدلال LLM مباشرةً. يجب استخدام FastAPI كبوابة API (API Gateway)، والجمع بين وسيط رسائل Redis وعامل Celery الموزع لفصل استقبال الطلبات عن عمليات الاستدلال الفعلية تماماً. عندما يرسل المستخدم طلباً، يعيد الخادم معرف المهمة (Job ID) فوراً ويقطع الاتصال.
إذا قمت تشغيل Celery بالإعدادات الافتراضية، فقد تفقد المهام أو يتم تنفيذها بشكل متكرر عند تعطل العامل. لاستيعاب أوقات المهام الطويلة بطبيعتها في استدلال LLM، من الضروري زيادة visibility_timeout إلى 3600 ثانية، وتعيين task_acks_late = True بحيث يتم إرسال تأكيد الاستلام فقط عند انتهاء المهمة بنجاح. كما يُعد تعيين worker_prefetch_multiplier = 1 أمراً أساسياً لمنع عامل واحد من الاستحواذ على مهام ثقيلة متعددة في وقت واحد والتسبب في الاختناقات.