از نوت‌بوک تا Production — چرخه عمر کامل مدل‌های یادگیری ماشین، روی زیرساخت بومی و GPUهای داخلی

بله، GITA MLOps کاملاً MLflow-compatible است. تمام `mlflow.log_metric`، `mlflow.log_artifact` و API‌های Registry بدون تغییر یک خط کد کار می‌کنند. فقط `MLFLOW_TRACKING_URI` به endpoint ما اشاره می‌کند. مهاجرت آزمایش‌های قبلی هم با ابزار import خودکار انجام می‌شود.

ما روی Feast یک لایه enterprise اضافه کرده‌ایم: point-in-time correctness به‌صورت built-in، materialization scheduled با Argo، lineage مرکزی، RBAC، PII masking خودکار و online store روی ScyllaDB با latency زیر ۵ms. خود-میزبانی Feast تمام این‌ها را به دوش تیم Platform شما می‌اندازد.

data drift با مقایسه توزیع featureها بین training و production با PSI و KS-test سنجیده می‌شود. concept drift نیاز به delayed labels دارد — پلتفرم وقتی label واقعی برمی‌گردد (مثلاً نتیجه واقعی default مشتری بعد از ۶۰ روز)، performance را مجدد محاسبه می‌کند و افت آن را الگو می‌کند، بدون اینکه data drift وجود داشته باشد.

برای LLM از vLLM با PagedAttention و continuous batching استفاده می‌کنیم که throughput را ۵ تا ۱۰ برابر افزایش می‌دهد. autoscaling بر اساس KV-cache utilization انجام می‌شود نه QPS. tensor parallelism برای مدل‌های بزرگ‌تر از ظرفیت یک GPU built-in است. مدل‌های tabular روی KServe یا Triton serve می‌شوند که latency p95 آن‌ها زیر ۵۰ms است.

هر مدل در Registry می‌تواند چند نسخه فعال هم‌زمان داشته باشد. در حالت Shadow، نسخه جدید تمام trafficای که به نسخه قدیمی می‌رود را می‌بیند اما پاسخش به مشتری نمی‌رسد — فقط برای مقایسه offline ثبت می‌شود. در حالت A/B، ترافیک بر اساس percentage یا feature flag بین نسخه‌ها split می‌شود و metricها side-by-side نمایش داده می‌شوند.

سه trigger اصلی: زمانی (مثلاً هر هفته یا هر ماه)، مبتنی بر داده (وقتی X رکورد جدید رسید) و مبتنی بر drift (وقتی PSI از threshold عبور کرد). pipeline retraining همان Kubeflow Pipeline اصلی است که فقط با artifact جدید اجرا می‌شود و در پایان، اگر مدل جدید روی validation set بهتر بود به Staging promote می‌شود.

ما از Kueue و Volcano روی Kubernetes استفاده می‌کنیم. هر تیم quota مشخصی از GPU-hour دارد. اگر تیمی از quota خود استفاده نکند، تیم‌های دیگر می‌توانند با priority پایین‌تر استفاده کنند (borrowing). در صورت برگشت quota، job های با priority پایین preempt می‌شوند. gang scheduling تضمین می‌کند تمام GPU های یک training توزیع‌شده هم‌زمان آماده شوند.

بله. برای مدل‌های tabular از TreeSHAP و KernelSHAP استفاده می‌کنیم. برای deep learning، DeepSHAP و Integrated Gradients پشتیبانی می‌شوند. برای CV، Grad-CAM و SHAP image. برای LLM، attention visualization و prompt-attribution. تمام این‌ها از طریق یک API واحد در دسترس هستند.

بله. تمام مولفه‌ها روی Kubernetes اجرا می‌شوند و هیچ وابستگی به اینترنت ندارند. برای محیط Air-Gapped، یک registry داخلی برای container images و یک artifact store داخلی برای package های Python pre-populated ارائه می‌شود. به‌روزرسانی‌ها از طریق media فیزیکی منتقل می‌شوند.

برای سازمانی که قبلاً مدلی ساخته اما deploy نکرده، معمولاً ۳ تا ۵ هفته از روز نصب پلتفرم. این شامل setup، آموزش تیم، یکپارچگی با SSO، اجرای pipeline و عبور از gateهای governance است. سازمان‌هایی که هنوز مدلی نساخته‌اند، در فاز Discovery نقشه راه دقیق‌تری دریافت می‌کنند.