‏چطور Databricks بیش از ۱۲۰ تریلیون توکن در ماه سرو می‌کنه

Databricks در یک پست فنی مفصل توضیح داده که چطور inference پلتفرمش — که هم مدل‌های متن‌باز مثل Kimi و Qwen و هم مدل‌های اختصاصی مثل OpenAI، Gemini و Claude رو سرو می‌کنه — برای مقیاس واقعی طراحی شده. این پلتفرم الان بیش از ۱۲۰ تریلیون توکن در ماه پردازش می‌کنه و زیرساخت inference اپلیکیشن‌های بزرگی مثل Superhuman رو تأمین می‌کنه.

یکی از بزرگ‌ترین چالش‌ها اینه که هزینه پردازش هر request خیلی متغیره و از قبل نمی‌شه دقیق تخمین زد. یک درخواست با context طولانی می‌تونه چندین برابر یک درخواست کوتاه روی GPU فشار بیاره. برای حل این مشکل، تیم Databricks مفهومی به اسم «model unit» ابداع کردن — یه واحد انتزاعی شبیه به VM ابری که نشون می‌ده هر request چقدر ظرفیت مصرف می‌کنه. هزینه هر request با یه تابع چندبُعدی تخمین زده می‌شه که طول input، طول output و نوع مدالیته رو در نظر می‌گیره.

بر پایه model unit، دو سیستم مهم ساخته شدن. اول load balancer هوشمند: به‌جای روش‌های آماری سنتی مثل P2C که فقط تعداد request در صف رو نگاه می‌کنن، Databricks از ابزار Dicer استفاده می‌کنه که request ها رو بر اساس بار واقعی سرور به واحد model unit توزیع می‌کنه. این سیستم routing چسبنده (stateful session) هم داره که نرخ cache hit رو برای workload هایی مثل coding agent بالا نگه می‌داره. دوم autoscaler هوشمند: وقتی نسبت مصرف model unit به آستانه‌ای نزدیک می‌شه، scale-up آغاز می‌شه و برعکس. این رویکرد برای ترافیک bursty بیش از ۸۰٪ صرفه‌جویی در GPU نسبت به ظرفیت ثابت داشته.

در بخش reliability، یکی از مشکلات رایج silent hang بود — یعنی سرور بدون هیچ پیام خطایی از کار می‌افتاد، مخصوصاً برای structured output یا ورودی‌های multimodal. راه‌حل: health check های دوره‌ای به‌صورت black-box که یه request کوچک واقعی می‌فرستن و اگر جواب نگرفتن، liveness probe کوبرنتیز سرور رو ری‌استارت می‌کنه. نکته مهم اینه که این health check ها بالاترین اولویت scheduling رو دارن تا زیر بار سنگین هم timeout نشن. با این تغییر، خطاهای false liveness probe از چند بار در هفته به صفر رسید و کل چرخه تشخیص تا بازیابی زیر ۵ دقیقه شد.

مشکل دیگه کندی پردازش تصویر بود. وقتی batch های بزرگ از request های multimodal می‌رسیدن، نرخ خطا اوج می‌گرفت. پروفایل Python نشون داد که resize و normalization تصویر ۱۰ برابر کندتر از بقیه عملیات CPU مثل base64 decoding هستن. علاوه بر این، مقدار پیش‌فرض OMP_NUM_THREADS در محیط‌های containerized با تعداد vCPU هاست تنظیم می‌شه نه container — مثلاً ۱۹۲ به‌جای ۱۲ — که باعث throttling شدید CPU می‌شد. با دو تغییر — استفاده از image processor مبتنی بر Torchvision (به‌جای PIL) و تنظیم درست OMP_NUM_THREADS — تعداد request های کامل‌شده در ثانیه بیش از ۳ برابر شد.

نکات کلیدی:

• model unit یه واحد انتزاعی برای تخمین هزینه واقعی هر LLM request روی GPU‌ه
• load balancing و autoscaling بر پایه model unit بیش از ۸۰٪ هزینه GPU رو نسبت به ظرفیت ثابت کاهش داده
• health check های black-box با اولویت بالا، silent hang های سرور رو زیر ۵ دقیقه تشخیص و رفع می‌کنن
• اشتباه پیش‌فرض OMP_NUM_THREADS در container می‌تونه CPU throttling جدی ایجاد کنه
• تغییر image processor از PIL به Torchvision به‌تنهایی throughput رو ۳ برابر کرد