معماری مسیر داغ بدون Postgres در زوپیر: Failover زیر ۲۵ میلی‌ثانیه و مدارقطع‌کن توزیع‌شده
چگونه گیت‌وی استنتاج زوپیر را طوری طراحی کردیم که بدون هیچ کوئری دیتابیسی در مسیر درخواست، احراز هویت کلید، رزرو اعتباری نانو-دلار و جابه‌جایی خودکار بین ارائه‌دهندگان را انجام دهد.
۱. چرا کوئری‌های دیتابیس نباید در مسیر استنتاج باشند؟
وقتی یک اپلیکیشن در حال استریم کردن توکن‌ها از مدل زبانی است، هر میلی‌ثانیه تأخیر پیش از دریافت اولین توکن مستقیماً توسط کاربر نهایی حس می‌شود. گیت‌وی‌های سنتی برای بررسی کلید API، موجودی کیف پول و قیمت مدل، چندین کوئری به دیتابیس رابطه‌ای می‌زنند.
در زوپیر، مسیر اصلی پردازش درخواست (Hot Path) هیچ تماسی با Postgres ندارد. اسنپ‌شات کاتالوگ مدل‌ها، قوانین قیمت‌گذاری و تنظیمات ارائه‌دهندگان از طریق Redis Pub/Sub در حافظهٔ پردازش کش می‌شوند و بررسی Rate Limit و رزرو اعتبار با اسکریپت‌های اتمیک Lua در Redis انجام می‌گیرد.
۲. مدارقطع‌کن پنجرهٔ لغزان و جابه‌جایی خودکار پیش از اولین بایت
ارائه‌دهندگان بالادستی هوش مصنوعی روزانه با محدودیت‌های لحظه‌ای ظرفیت (خطای 429 یا 503) روبه‌رو می‌شوند. زوپیر برای هر اندپوینت یک پنجرهٔ لغزان ۶۰ ثانیه‌ای در Redis نگه می‌دارد که در صورت ۵ خطای متوالی یا نرخ خطای بالای ۵۰٪، مدار آن اندپوینت را موقتاً باز می‌کند.
اگر اندپوینت اول پیش از ارسال اولین بایت به کلاینت با خطا یا تایم‌اوت مواجه شود، درخواست به‌صورت شفاف به اندپوینت سالم بعدی یا مدل جایگزین در آرایهٔ models هدایت می‌شود.
{
"model": "deepseek/deepseek-v4.1-flash",
"models": ["google/gemini-3.8-flash", "qwen/qwen-3.8-max-prime"],
"provider": {
"sort": "latency",
"allow_fallbacks": true
},
"messages": [{ "role": "user", "content": "Generate a SQL migration." }]
}۳. محاسبات دقیق نانو-دلار (BigInt) و دفتر کل دوطرفه
استفاده از اعداد اعشاری (Float) در محاسبهٔ هزینهٔ میلیون‌ها توکن باعث خطای گرد شدن می‌شود. در زوپیر تمامی مبالغ به صورت عدد صحیح ۶۴ بیتی نانو-دلار (هر ۱ دلار برابر ۱٬۰۰۰٬۰۰۰٬۰۰۰ نانو) ذخیره و محاسبه می‌شوند.
پیش از ارسال درخواست، سقف هزینهٔ احتمالی رزرو (Hold) شده و بلافاصله پس از پایان استریم (یا حتی قطع شدن اتصال توسط کاربر)، تنها هزینهٔ توکن‌های تولیدشده کسر و مابقی در همان لحظه آزاد می‌شود.