GitHub Models فردا تعطیل می شود؛ راهنمای مهاجرت بدون قطعی

GitHub Models در 30 ژوئیه 2026 به طور کامل خاموش می شود؛ نه فقط Playground، بلکه Model Catalog، Inference API و مسیرهای BYOK نیز برای کاربران فعلی از دسترس خارج خواهند شد. اگر برنامه، CI یا محیط آزمایش شما هنوز به این سرویس متصل است، مسئله یک خبر عمومی نیست؛ یک Deadline عملیاتی است. در این راهنما مسیر مهاجرت را از Inventory تا Cutover، کنترل هزینه و Rollback مرحله به مرحله می چینیم.

دقیقاً چه چیزی در 30 ژوئیه متوقف می شود؟

اطلاعیه GitHub صریح است: GitHub Models به طور کامل بازنشسته می شود و این مرحله همه مشتریان، از جمله حساب هایی را که مصرف فعال دارند، دربر می گیرد. پس از تاریخ اعلام شده، Playground برای آزمایش تعاملی، Model Catalog برای انتخاب مدل، Inference API برای فراخوانی برنامه ای و Endpointهای Bring Your Own Key دیگر قابل استفاده نیستند. رابط های مرتبط نیز از GitHub حذف می شوند. این دامنه وسیع یعنی حتی تیمی که فقط برای تست Prompt از Playground استفاده می کند باید جایگزین داشته باشد؛ درحالی که تیمی با Production Traffic با ریسک قطعی مستقیم روبه رو است.

GitHub پیش از خاموشی دو Brownout کوتاه در 16 و 23 ژوئیه اجرا کرده بود تا وابستگی پنهان کاربران آشکار شود. اگر در آن زمان خطای موقت دیده اید ولی علت را دنبال نکرده اید، همان خطا فردا دائمی می شود. نخستین کار، جست وجوی نام Host، SDK، Secret، Environment Variable، GitHub Action، Notebook و Scriptهایی است که به GitHub Models وابسته اند. Dependency فقط داخل کد Backend نیست؛ ممکن است در Demo، تست Snapshot، ابزار تیم محصول یا Job زمان بندی شده پنهان باشد.

مرحله اول: Inventory کامل وابستگی ها

مهاجرت ناموفق معمولاً از یک Endpoint فراموش شده شروع می شود. Inventory را در چهار سطح انجام دهید: کد، زیرساخت، داده و عملیات. در کد به دنبال Base URL، نام Package، Headerهای اختصاصی، نام مدل و Helperهای Streaming بگردید. در زیرساخت Secret Store، Variableهای Repository و Organization، فایل های Terraform، Pipelineها و Container Configuration را بررسی کنید. در داده، Promptهای ذخیره شده، Eval Datasetها، Golden Outputها و Logهای مقایسه را فهرست کنید. در عملیات نیز Dashboard، Alert، Runbook و Budgetهای مرتبط را ثبت کنید.

برای هر وابستگی سه ویژگی بنویسید: Criticality، حجم مصرف و Owner. یک اسکریپت آزمایشی که ماهی یک بار اجرا می شود با API اصلی محصول یکسان نیست. Critical Path باید زودتر Cutover شود، اما Dependency کم استفاده نیز نباید حذف شود؛ چون معمولاً بعد از خاموشی، درست هنگام Incident موردنیاز می شود. Inventory را در یک جدول مشترک نگه دارید تا تیم های Backend، DevOps، Data و Product وضعیت یکسانی ببینند.

Microsoft Foundry یا GitHub Copilot؛ کدام جایگزین چه کاری است؟

GitHub دو مسیر را پیشنهاد کرده، اما آن ها جایگزین های هم معنا نیستند. Microsoft Foundry برای ساخت محصولی است که برنامه شما مستقیماً مدل را صدا می زند، پاسخ را پردازش می کند و مسئولیت Authentication، Deployment، Quota، Logging و هزینه را برعهده دارد. GitHub Copilot برای جریان توسعه داخل GitHub و IDE مناسب است؛ یعنی Chat، Coding Agent، CLI، Review و سایر Workflowهای توسعه. اگر GitHub Models را به عنوان Backend محصول مشتری استفاده کرده اید، Copilot معمولاً جایگزین API عمومی برنامه شما نیست.

تصمیم را با سؤال «کاربر نهایی چه کسی است؟» آغاز کنید. اگر کاربر توسعه دهنده تیم است و مسئله تولید کد، Review یا کار Agentic داخل Repository است، Copilot منطقی است. اگر کاربر مشتری محصول شماست و مدل بخشی از Feature تجاری محسوب می شود، به یک Platform استقرار مدل مانند Foundry یا Provider مستقیم نیاز دارید. ممکن است هر دو را هم زمان داشته باشید: Foundry برای Product API و Copilot برای افزایش بهره وری تیم.

جایگزین درست را براساس مرز محصول انتخاب کنید؛ نه صرفاً اینکه کدام سرویس فهرست مدل بیشتری نمایش می دهد.

یک لایه Adapter بسازید تا Provider به هسته محصول نچسبد

بزرگ ترین درس این خاموشی آن است که Contract کسب وکار نباید با Contract یک Provider یکی شود. اگر Controller شما مستقیماً نوع Response، نام Role، Format خطا و Streaming Event سرویس را مصرف کند، هر مهاجرت به Refactor گسترده تبدیل می شود. یک Interface داخلی تعریف کنید که نیاز واقعی محصول را بیان کند: GenerateText، GenerateStructured، Stream، Embed یا InvokeTools. سپس Adapter هر Provider تبدیل ورودی و خروجی را انجام دهد.

Adapter باید تفاوت هایی مانند نام مدل، Max Token، Timeout، Retry، Rate Limit، Content Filter، Tool Schema و Usage را Normalize کند، اما تفاوت واقعی را پنهان نکند. برای مثال اگر Provider جدید Structured Output را با ضمانت متفاوت ارائه می دهد، Capability Flag داشته باشید. هدف ساختن کمترین Contract مشترک نیست؛ هدف آن است که تصمیم Provider در یک نقطه کنترل شود و بخش های دیگر محصول به جزئیات Transport وابسته نباشند.

public interface IAiModelGateway {
  Task<AiResponse> GenerateAsync(
    AiRequest request,
    CancellationToken cancellationToken
  );
}

public sealed record AiRequest(
  string TaskType,
  IReadOnlyList<AiMessage> Messages,
  string? ModelHint
);

Contract رفتاری را قبل از تغییر Provider ثبت کنید

فقط موفق شدن HTTP 200 معیار مهاجرت نیست. خروجی مدل ممکن است طولانی تر، محافظه کارتر، خلاق تر یا از نظر JSON ناپایدارتر شود. پیش از Cutover، نمونه های واقعی را از Logهای مجاز و Datasetهای تست جمع کنید. برای هر Task معیار تعیین کنید: Parse Success، Factual Accuracy، Tool Selection، Latency، Token Usage، Safety و Human Rating. این Dataset باید حالت های آسان، معمولی، مرزی و مخرب را شامل شود.

نام یکسان مدل نیز تضمین رفتار یکسان نیست. Provider می تواند نسخه Snapshot، System Layer، Safety Filter، Default Parameter یا ابزار متفاوت داشته باشد. بنابراین Migration Test باید روی Endpoint مقصد اجرا شود، نه بر اساس Benchmark عمومی. Golden Output در کارهای مولد همیشه تطابق متن به متن نیست؛ بهتر است Rule، Schema Validator، Unit Test یا Judge کنترل شده برای کیفیت داشته باشید.

Authentication، کلیدها و BYOK را دوباره طراحی کنید

با حذف BYOK Endpointهای GitHub Models، کلیدهای قبلی دیگر مسیر اجرایی معتبر نیستند. Secret جدید را در Secret Manager سازمان نگه دارید و از قراردادن آن در Repository، فایل تنظیمات یا Prompt جلوگیری کنید. Identity مبتنی بر سرویس و Credential کوتاه عمر، در صورت پشتیبانی Platform، از Token بلندعمر بهتر است. Scope باید حداقلی باشد و محیط Development، Stage و Production کلید جدا داشته باشند.

پس از Cutover، Secret قدیمی را فقط غیرفعال نکنید؛ ابتدا Usage آن را بررسی، سپس Revoke و از تمام Storeها پاک کنید. Audit کنید که Log یا Artifact شامل مقدار Secret نباشد. اگر GitHub Action قبلاً Token را مصرف می کرد، Permission Workflow و Environment Protection را بازبینی کنید. مهاجرت Provider فرصت خوبی برای اصلاح بدهی امنیتی است، نه فقط جایگزینی نام Variable.

Streaming، Timeout و Error Handling را آزمایش کنید

تفاوت Providerها در مسیر خطا بیشتر از مسیر موفقیت آشکار می شود. Streaming Event ممکن است شکل دیگری داشته باشد؛ قطع ارتباط ممکن است Partial Output تولید کند؛ Rate Limit می تواند Header و زمان Retry متفاوت داشته باشد. برنامه باید Cancellation کاربر، Timeout سمت سرور، Retry محدود با Backoff و Idempotency مناسب را مدیریت کند. برای درخواست مولد، Retry کور ممکن است دو Action یا دو هزینه ایجاد کند.

خطاها را به دسته های قابل عمل تبدیل کنید: Authentication، Quota، Rate Limit، Invalid Request، Safety Refusal، Provider Error و Timeout. به کاربر پیام مناسب بدهید و در Log، Correlation ID، مدل، Provider، Latency و Usage را ثبت کنید؛ بدون ذخیره داده حساس. Dashboard قدیمی GitHub Models نیز جایگزین می خواهد و باید Metricهای مقصد پیش از Cutover فعال باشند.

Shadow Traffic و Canary؛ مسیر امن تغییر

در Shadow Mode درخواست واقعی به Provider جدید نیز ارسال می شود، اما پاسخ آن به کاربر نمایش داده نمی شود. این روش اجازه می دهد Latency، Cost و Quality روی توزیع واقعی ورودی سنجیده شود. داده حساس باید مطابق سیاست سازمان مدیریت شود و Shadow نباید باعث اجرای Tool یا Action واقعی شود. برای کارهای Agentic، فقط مرحله Reasoning یا Planning را Shadow کنید یا ابزارها را Mock نگه دارید.

پس از پذیرش نتایج، Canary را با درصد کم آغاز کنید. Provider Selection را با Feature Flag کنترل کنید تا Rollback بدون Deploy ممکن باشد. درصد را براساس نرخ خطا و کیفیت افزایش دهید، نه صرفاً گذشت زمان. اگر محصول چند Task دارد، همه را هم زمان منتقل نکنید؛ ممکن است Summary خوب باشد ولی Structured Extraction مشکل داشته باشد.

هزینه و Quota را قبل از مهاجرت تخمین بزنید

هزینه جدید فقط قیمت یک میلیون توکن نیست. Context بزرگ، Retry، Cache، Tool Call، Output طولانی و درخواست Shadow روی عدد نهایی اثر می گذارند. Usage واقعی GitHub Models را استخراج و به Input، Output، تعداد درخواست و Peak تقسیم کنید. سپس با قیمت و Quota مقصد مدل کنید. برای Taskهای ساده از مدل کوچک تر استفاده کنید و Routing را براساس پیچیدگی بسازید.

Budget Alert و Hard Limit را پیش از Production فعال کنید. یک باگ Loop یا Prompt Injection می تواند مصرف را ناگهان بالا ببرد. هزینه هر «کار موفق» را بسنجید، نه هر درخواست؛ مدلی ارزان که چند بار Retry می شود یا خروجی آن نیازمند اصلاح انسانی است ممکن است گران تر تمام شود. همچنین Region و ظرفیت Provider را برای Peak Traffic بررسی کنید.

پرامپت ها و Evaluationها را به Repository مستقل منتقل کنید

اگر Promptها فقط در UI سرویس نگهداری می شدند، اکنون باید آن ها را به Artifact نسخه بندی شده تبدیل کنید. Prompt، Schema، Example، Model Setting و Eval Dataset باید کنار هم Commit شوند. Secret یا داده شخصی نباید در Exampleها قرار بگیرد. هر تغییر Prompt مانند کد Review شود و نتیجه Eval در Pull Request نمایش داده شود.

هدف فقط نجات دادن متن Prompt نیست. باید بدانید هر Prompt برای چه Task، چه مدل و چه نسخه ای معتبر بوده است. Metadata شامل Owner، تاریخ آخرین ارزیابی، معیار کیفیت و محدودیت ها را اضافه کنید. این کار وابستگی به UI Provider را کاهش می دهد و در مهاجرت بعدی، مقایسه قابل تکرار خواهد بود.

برنامه Cutover و Rollback برای روز خاموشی

در روز Cutover، تغییرات غیرمرتبط را Freeze کنید. Health Check مقصد، Quota، Secret، Dashboard و Alert را پیش از انتقال نهایی بررسی کنید. Feature Flag را تغییر دهید و درصد خطا، Latency، Parse Failure، Safety Refusal و هزینه را در بازه کوتاه مانیتور کنید. تیم مسئول باید در دسترس باشد و مسیر ارتباط Incident مشخص باشد.

Rollback فقط بازگشت به GitHub Models نیست؛ چون پس از خاموشی آن مسیر وجود ندارد. Rollback باید به Provider دوم، مدل ساده تر، Queue کردن درخواست یا غیرفعال کردن موقت Feature اشاره کند. برای قابلیت غیرحیاتی، Graceful Degradation بهتر از خطای 500 است. پیام کاربر باید شفاف باشد و داده درخواست از بین نرود.

جدول انتخاب مسیر جایگزین

ممکن است معماری نهایی بیش از یک مسیر داشته باشد. مهم این است که محصول و ابزار داخلی تیم را با یک Contract اشتباه نگیرید و هرکدام Budget، امنیت و SLA مناسب خود را داشته باشند.

محدودیت ها، ریسک ها و نکات مهم

چک لیست اضطراری مهاجرت از GitHub Models

1. تمام Endpointها، Secretها و Workflowهای وابسته را Inventory کنید.
2. مقصد مناسب را برای Product API و Developer Workflow جدا انتخاب کنید.
3. Adapter مستقل از Provider ایجاد کنید.
4. Dataset ارزیابی و Baseline فعلی را ذخیره کنید.
5. Authentication، Quota، Streaming و Error Mapping را پیاده کنید.
6. Shadow Test و سپس Canary اجرا کنید.
7. Dashboard هزینه و کیفیت را فعال کنید.
8. مسیر Rollback مستقل از GitHub Models تعریف کنید.
9. Secretها و دسترسی های قدیمی را پس از Cutover Revoke کنید.

برای Dependency کم اهمیت نیز Owner و تصمیم مشخص ثبت کنید. عبارت «بعداً درست می کنیم» پس از خاموشی به Incident تبدیل می شود.

پرسش های متداول

GitHub Models دقیقاً چه زمانی بسته می شود؟

خاموشی کامل برای 30 ژوئیه 2026 اعلام شده و سرویس برای کاربران جدید و فعلی از دسترس خارج می شود.

آیا فقط Playground حذف می شود؟

خیر. Playground، Model Catalog، Inference API، BYOK Endpointها و رابط مرتبط حذف می شوند.

جایگزین رسمی چیست؟

GitHub برای دسترسی گسترده به مدل ها Microsoft Foundry و برای جریان های توسعه داخل GitHub، GitHub Copilot را پیشنهاد می کند.

آیا نام یکسان مدل یعنی خروجی یکسان؟

نه. نسخه، System Instruction، ابزار، فیلتر، پارامترها و Provider می توانند رفتار را تغییر دهند.

چگونه بدون قطعی مهاجرت کنیم؟

با Adapter، Shadow Traffic، Eval خودکار، Canary و نگه داشتن مسیر Rollback تا تثبیت سرویس جدید.

جمع بندی سریع

• Dependencyهای GitHub Models را امروز Inventory کنید.
• Provider جایگزین را براساس محصول واقعی انتخاب کنید، نه شباهت نام مدل.
• یک Adapter مستقل از Provider بسازید تا مهاجرت بعدی ارزان تر شود.
• ترافیک را مرحله ای منتقل و نتیجه را با Eval واقعی مقایسه کنید.
• کلیدها، Logها و مسیرهای BYOK قدیمی را پس از Cutover پاک سازی کنید.

امروز یک Issue اضطراری باز کنید، مالک مهاجرت را تعیین کنید و پیش از پایان روز مسیر اصلی و مسیر Rollback را روی محیط Stage اجرا کنید.

منابع رسمی

اطلاعیه رسمی تعطیلی GitHub Models — تاریخ، دامنه خاموشی و گزینه های پیشنهادی GitHub

مستندات رسمی GitHub Models — شناخت قابلیت های قبلی مانند Catalog، Prompt و Evaluation

Microsoft Foundry — گزینه پیشنهادی GitHub برای دسترسی به Catalog مدل ها