با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
برای آماده سازی خطوط لوله ML خود برای تولید، باید موارد زیر را انجام دهید:
منابع محاسباتی را برای خطوط لوله خود فراهم کنید
ثبت، نظارت و هشدار را اجرا کنید
تامین منابع محاسباتی
اجرای خطوط لوله ML به منابع محاسباتی مانند RAM، CPU و GPU/TPU نیاز دارد. بدون محاسبه کافی، نمی توانید خطوط لوله خود را اجرا کنید. بنابراین، مطمئن شوید که سهمیه کافی برای تامین منابع مورد نیاز خطوط لوله خود را برای اجرای تولید به دست آورده اید.
خدمات، آموزش، و خطوط لوله اعتبار سنجی . این خطوط لوله به TPU، GPU یا CPU نیاز دارند. بسته به مورد استفاده‌تان، ممکن است روی سخت‌افزارهای مختلف آموزش داده و خدمت کنید یا از سخت‌افزار مشابهی استفاده کنید. به عنوان مثال، ممکن است آموزش روی CPU ها اتفاق بیفتد، اما سرویس دهی ممکن است از TPU ها استفاده کند یا برعکس. به طور کلی، تمرین بر روی سخت افزار بزرگتر و سپس ارائه بر روی سخت افزارهای کوچکتر معمول است.
هنگام انتخاب سخت افزار، موارد زیر را در نظر بگیرید:
آیا می توانید با سخت افزار ارزان تر تمرین کنید؟
آیا تعویض سخت افزارهای مختلف باعث افزایش عملکرد می شود؟
اندازه مدل چقدر است و کدام سخت افزار عملکرد آن را بهینه می کند؟
چه سخت افزاری بر اساس معماری مدل شما ایده آل است؟
خطوط لوله داده خطوط لوله داده به سهمیه RAM و CPU نیاز دارندشما باید تخمین بزنید که خط لوله شما به چه مقدار سهمیه برای تولید آموزش و مجموعه داده های آزمایشی نیاز دارد.
ممکن است برای هر خط لوله سهمیه ای اختصاص ندهید. در عوض، ممکن است سهمیه ای را که خطوط لوله به اشتراک می گذارند اختصاص دهید. در چنین مواردی، بررسی کنید که سهمیه کافی برای اجرای تمام خطوط لوله خود را دارید، و نظارت و تغییر را تنظیم کنید تا از مصرف تمام سهمیه خط لوله منفرد و اشتباه جلوگیری کنید.
تخمین سهمیه
برای تخمین سهمیه ای که برای داده ها و خطوط لوله آموزشی به آن نیاز دارید، پروژه های مشابهی را بیابید تا برآوردهای خود را بر اساس آنها انجام دهید. برای تخمین سهمیه خدمت، سعی کنید درخواست های سرویس را در هر ثانیه پیش بینی کنید. این روش ها یک پایه را ارائه می دهند. همانطور که نمونه سازی یک راه حل را در مرحله آزمایش شروع می کنید، تخمین سهمیه دقیق تری را دریافت خواهید کرد.
هنگام تخمین سهمیه، به یاد داشته باشید که سهمیه را نه تنها برای خطوط لوله تولید خود، بلکه برای آزمایشات در حال انجام نیز در نظر بگیرید.
درک خود را بررسی کنید
هنگام انتخاب سخت‌افزار برای ارائه پیش‌بینی‌ها، همیشه باید سخت‌افزار قدرتمندتری نسبت به آنچه برای آموزش مدل استفاده می‌شد انتخاب کنید.
نادرست
درست است. به طور معمول، آموزش به سخت افزار بزرگتر از خدمت نیاز دارد.
درست است
ورود به سیستم، نظارت و هشدار
ثبت و نظارت بر رفتار مدل تولید بسیار مهم است. زیرساخت‌های نظارتی قوی تأیید می‌کند که مدل‌های شما پیش‌بینی‌های قابل اعتماد و باکیفیت را ارائه می‌کنند.
شیوه های ثبت و نظارت خوب به شناسایی پیشگیرانه مسائل در خطوط لوله ML و کاهش تأثیر بالقوه تجاری کمک می کند. هنگامی که مشکلات رخ می دهد، هشدارها به اعضای تیم شما اطلاع می دهند و گزارش های جامع تشخیص علت اصلی مشکل را تسهیل می کنند.
برای شناسایی مشکلات زیر در خطوط لوله ML باید ثبت و نظارت را اجرا کنید:
خط لوله
نظارت کنید
در حال خدمت کردن
انحراف یا انحراف در داده های ارائه شده در مقایسه با داده های آموزشی
انحراف یا انحراف در پیش بینی ها
مشکلات نوع داده، مانند مقادیر گم شده یا خراب
استفاده از سهمیه
معیارهای کیفیت مدل
داده ها
انحراف و تغییر در مقادیر ویژگی
انحراف و تغییر در مقادیر برچسب
مشکلات نوع داده، مانند مقادیر گم شده یا خراب
نرخ استفاده از سهمیه
حدود سهمیه در حال رسیدن است
آموزش
زمان آموزش
شکست های آموزشی
استفاده از سهمیه
اعتبار سنجی
انحراف یا رانش در مجموعه داده های آزمایشی
همچنین می‌خواهید برای موارد زیر ثبت‌نام، نظارت و هشدار دهید:
تاخیر چه مدت طول می کشد تا یک پیش بینی ارائه شود؟
قطعی ها آیا مدل ارائه پیش بینی ها را متوقف کرده است؟
درک خود را بررسی کنید
کدام یک از موارد زیر دلیل اصلی ثبت و نظارت بر خطوط لوله ML شماست؟
قبل از اینکه روی کاربران تاثیر بگذارد، مشکلات را به طور فعال شناسایی کنید
ردیابی سهمیه و استفاده از منابع
مشکلات امنیتی احتمالی را شناسایی کنید
همه موارد بالا
درست است. ثبت و نظارت بر خطوط لوله ML شما به پیشگیری و تشخیص مشکلات قبل از جدی شدن آنها کمک می کند.
استقرار یک مدل
برای استقرار مدل، باید موارد زیر را مستند کنید:
تأییدیه های لازم برای شروع استقرار و افزایش عرضه.
چگونه یک مدل را وارد تولید کنیم.
جایی که مدل مستقر می شود، برای مثال، اگر محیط های صحنه یا قناری وجود داشته باشد.
اگر استقرار با شکست مواجه شد چه باید کرد.
چگونه می توان مدلی را که قبلاً در حال تولید است برگردانید.
پس از آموزش خودکارسازی مدل، می‌خواهید اعتبارسنجی و استقرار را خودکار کنید. استقرار خودکار مسئولیت ها را توزیع می کند و احتمال اینکه استقرار توسط یک نفر با تنگنا مواجه شود را کاهش می دهد. همچنین خطاهای بالقوه را کاهش می دهد، کارایی و قابلیت اطمینان را افزایش می دهد و چرخش در تماس و پشتیبانی SRE را فعال می کند.
معمولاً مدل‌های جدید را برای زیرمجموعه‌ای از کاربران مستقر می‌کنید تا بررسی کنید که مدل مطابق انتظار رفتار می‌کند. اگر چنین است، به استقرار ادامه دهید. اگر اینطور نیست، استقرار را برگردانید و شروع به تشخیص و رفع اشکال کنید.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[[["\u003cp\u003eProduction ML pipelines require sufficient compute resources like RAM, CPUs, and GPUs/TPUs for serving, training, data processing, and validation.\u003c/p\u003e\n"],["\u003cp\u003eImplement robust logging, monitoring, and alerting to proactively detect data and model issues (e.g., data drift, prediction skews, quality degradation) across all pipeline stages.\u003c/p\u003e\n"],["\u003cp\u003eEstablish a clear model deployment strategy outlining approvals, procedures, environments, and rollback mechanisms, and aim for automated deployments for efficiency and reliability.\u003c/p\u003e\n"],["\u003cp\u003eEstimate quota needs based on similar projects and service predictions, and factor in resources for both production and ongoing experimentation.\u003c/p\u003e\n"]]],[],null,["# Productionization\n\nTo prepare your ML pipelines for production, you need to do the following:\n\n- Provision compute resources for your pipelines\n- Implement logging, monitoring, and alerting\n\nProvisioning compute resources\n------------------------------\n\nRunning ML pipelines requires compute resources, like RAM, CPUs, and GPUs/TPUs.\nWithout adequate compute, you can't run your pipelines. Therefore, make sure\nto get sufficient quota to provision the required resources your pipelines\nneed to run in production.\n\n- **Serving, training, and validation pipelines**. These pipelines require\n TPUs, GPUs, or CPUs. Depending on your use case, you might train and serve\n on different hardware, or use the same hardware. For example, training might\n happen on CPUs but serving might use TPUs, or vice versa. In general, it's\n common to train on bigger hardware and then serve on smaller hardware.\n\n \u003cbr /\u003e\n\n When picking hardware, consider the following:\n - Can you train on less expensive hardware?\n - Would switching to different hardware boost performance?\n - What size is the model and which hardware will optimize its performance?\n - What hardware is ideal based on your model's architecture?\n\n | **Note:** When switching models between hardware, consider the time and effort to migrate the model. Switching hardware might make the model cheaper to run, but the engineering effort to do so might outweigh the savings---or engineering effort might be better prioritized on other work.\n- **Data pipelines**. Data pipelines require quota for RAM and CPU\n\n You'll need to estimate how\n much quota your pipeline needs to generate training and test datasets.\n\nYou might not allocate quota for each pipeline. Instead, you might\nallocate quota that pipelines share. In such cases, verify\nyou have enough quota to run all your pipelines, and set up monitoring and\naltering to prevent a single, errant pipeline from consuming all the quota.\n\n### Estimating quota\n\nTo estimate the quota you'll need for the data and training pipelines, find\nsimilar projects to base your estimates on. To estimate serving quota, try to\npredict the service's queries per second. These methods provide a baseline. As\nyou begin prototyping a solution during the experimentation phase, you'll begin\nto get a more precise quota estimate.\n\nWhen estimating quota, remember to factor in quota not only for your production\npipelines, but also for ongoing experiments.\n\n### Check Your Understanding\n\nWhen choosing hardware to serve predictions, you should always choose more powerful hardware than was used to train the model. \nFalse \nCorrect. Typically, training requires bigger hardware than serving. \nTrue \n\nLogging, monitoring, and alerting\n---------------------------------\n\nLogging and monitoring a production model's behavior is critical. Robust\nmonitoring infrastructure confirms your models are serving reliable,\nhigh-quality predictions.\n\nGood logging and monitoring practices help proactively identify issues in ML\npipelines and mitigate potential business impact. When issues do occur, alerts\nnotify members of your team, and comprehensive logs facilitate diagnosing the\nproblem's root cause.\n\nYou should implement logging and monitoring to detect the following issues\nwith ML pipelines:\n\n| Pipeline | Monitor |\n|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Serving | - Skews or drifts in the serving data compared to the training data - Skews or drifts in predictions - Data type issues, like missing or corrupted values - Quota usage - Model quality metrics Calculating a production model's quality is different than calculating a model's quality during training. In production, you won't necessarily have access to the ground truth to compare predictions against. Instead, you'll need to write custom monitoring instrumentation to capture metrics that act as a proxy for model quality. For example, in a mail app, you won't know which mail is spam in real time. Instead, you can monitor the percentage of mail users move to spam. If the number jumps from 0.5% to 3%, that signals a potential issue with the model. | Note that comparing the changes in | the proxy metrics is more insightful than their raw numbers. |\n| Data | - Skews and drifts in feature values - Skews and drifts in label values - Data type issues, like missing or corrupted values - Quota usage rate - Quota limit about to be reached |\n| Training | - Training time - Training failures - Quota usage |\n| Validation | - Skew or drift in the test datasets |\n\nYou'll also want logging, monitoring, alerting for the following:\n\n- **Latency**. How long does it take to deliver a prediction?\n- **Outages**. Has the model stopped delivering predictions?\n\n### Check Your Understanding\n\nWhich of the following is the main reason for logging and monitoring your ML pipelines? \nProactively detect issues before they impact users \nTrack quota and resource usage \nIdentify potential security problems \nAll of the above \nCorrect. Logging and monitoring your ML pipelines helps prevent and diagnose problems before they become serious.\n\nDeploying a model\n-----------------\n\nFor model deployment, you'll want to document the following:\n\n- Approvals required to begin deployment and increase the roll out.\n- How to put a model into production.\n- Where the model gets deployed, for example, if there are staging or canary environments.\n- What to do if a deployment fails.\n- How to rollback a model already in production.\n\nAfter automating model training, you'll want to automate\nvalidation and deployment. Automating deployments distributes\nresponsibility and reduces the likelihood of a deployment being bottlenecked by\na single person. It also reduces potential mistakes, increases efficiency and\nreliability, and enables on-call rotations and SRE support.\n\nTypically you deploy new models to a subset of users to check that the model is\nbehaving as expected. If it is, continue with the deployment. If it's not,\nyou rollback the deployment and begin diagnosing and debugging the issues."]]
