GitHub Models Ngừng Toàn Bộ Từ 30/7/2026: Checklist Migration Sang Foundry Hoặc Copilot

GitHub Models ngừng toàn bộ dịch vụ từ ngày 30/7/2026. Đây không còn là một thông báo “sẽ thay đổi trong tương lai”: GitHub xác nhận Playground, model catalog, inference API và cơ chế bring your own key (BYOK) đều không còn khả dụng cho mọi khách hàng sau mốc này. Nếu một script, GitHub Actions workflow, bản demo nội bộ hoặc quy trình đánh giá mô hình của bạn vẫn gọi models.github.ai, việc cần làm không phải chỉ là đổi một URL. Bạn phải xác định phần nào thuộc lớp suy luận, phần nào thuộc prompt, dữ liệu kiểm thử, evaluator, quyền truy cập và cách theo dõi chi phí.

Bài này tập trung vào kế hoạch di chuyển thực tế cho developer, AI Creator, solopreneur và đội sản phẩm nhỏ. Mục tiêu là giữ lại những tài sản có giá trị đã xây trên GitHub Models, chọn đích thay thế phù hợp, giảm rủi ro lộ secret và chứng minh workflow mới cho kết quả tương đương trước khi xóa cấu hình cũ. Các dữ kiện về thời điểm ngừng dịch vụ và phạm vi ảnh hưởng được đối chiếu với thông báo chính thức của GitHub.

GitHub Models ngừng những gì?

GitHub liệt kê bốn thành phần chính bị ngừng: Playground, model catalog, inference API và BYOK. Phạm vi áp dụng gồm cả khách hàng đang sử dụng dịch vụ, không chỉ tài khoản mới. Hai đợt gián đoạn ngắn ngày 16 và 23/7 đóng vai trò brownout để các đội phát hiện phụ thuộc còn sót trước ngày ngừng hoàn toàn. Điều này quan trọng vì một hệ thống có thể “trông như vẫn chạy” nếu nhánh sử dụng mô hình chỉ được kích hoạt trong job định kỳ, fallback hiếm gặp hoặc môi trường staging ít traffic.

Đừng đồng nhất GitHub Models với GitHub Copilot. GitHub Models từng cung cấp lớp thử nghiệm và suy luận đa mô hình: chọn model từ catalog, thử prompt trong Playground, lấy đoạn mã gọi API, lưu prompt vào repository và chạy evaluation. GitHub Copilot là họ sản phẩm hỗ trợ phát triển phần mềm và agent workflow. GitHub khuyến nghị Microsoft Foundry cho nhu cầu truy cập model catalog rộng, hoặc Copilot cho workflow AI được tích hợp trực tiếp với GitHub. Hai hướng này giải quyết những nhu cầu khác nhau và không phải bản thay thế một-một.

Ở cấp độ kỹ thuật, bốn nhóm phụ thuộc cần được tìm riêng:

• Phụ thuộc giao diện: nhóm dùng Playground để thử model, chỉnh temperature, so sánh output hoặc lấy code mẫu.
• Phụ thuộc runtime: ứng dụng gọi endpoint inference, embeddings hoặc catalog bằng PAT/GitHub App token.
• Phụ thuộc repository: tệp .prompt.yml, test data, evaluator và workflow GitHub Actions dùng quyền models: read.
• Phụ thuộc quản trị: policy theo organization, danh sách publisher/model được cho phép, BYOK, attribution và báo cáo usage.

Một nhóm chỉ dùng Playground có thể hoàn tất di chuyển bằng cách xuất prompt, tham số và test case. Một sản phẩm gọi inference API trong production cần kế hoạch rộng hơn: endpoint, identity, model deployment, quota, observability, dữ liệu, timeout, retry, fallback và ngân sách. Vì vậy, hãy bắt đầu bằng inventory thay vì chọn ngay một nhà cung cấp mới.

Inventory: tìm mọi phụ thuộc trước khi sửa code

Hãy tìm trong toàn bộ organization, không chỉ repository đang mở. Các chuỗi đáng kiểm tra gồm models.github.ai, github.com/marketplace/models, models: read, .prompt.yml, .prompt.yaml, tên SDK Azure AI Inference, biến môi trường chứa GitHub PAT và các bước CLI như gh models. Kiểm tra cả workflow tái sử dụng, composite action, secret cấp organization, Codespaces configuration, Docker image và tài liệu onboarding.

Mỗi kết quả nên được đưa vào một bảng inventory có tối thiểu các trường: owner, repository, môi trường, loại phụ thuộc, endpoint, model ID, phương thức xác thực, secret đang dùng, dữ liệu đầu vào, dữ liệu nhạy cảm, quota kỳ vọng, fallback, người phê duyệt và deadline. Nếu không có owner rõ ràng, coi dependency đó là rủi ro cao. “Không ai biết job này còn dùng không” không phải lý do để bỏ qua; đó là lý do phải quan sát hoặc tắt có kiểm soát.

Phân loại dependency theo mức độ ảnh hưởng:

Mức	Ví dụ	Hành động
Khẩn cấp	API nằm trên đường xử lý người dùng hoặc CI bắt buộc	Thay endpoint, test tương đương, triển khai có rollback
Cao	Workflow tạo issue, review PR, tóm tắt support theo lịch	Chuyển provider và giám sát lần chạy đầu
Trung bình	Playground dùng cho prototype hoặc prompt research	Xuất prompt, test data, tham số và ghi lại model
Thấp	Tài liệu, ảnh chụp, ví dụ không còn thực thi	Cập nhật nội dung để tránh hướng dẫn sai

Đừng chỉ tìm bằng tên “GitHub Models”. Nhiều workflow chỉ chứa endpoint hoặc quyền models: read. Một số repository có tệp prompt nhưng model ID được truyền qua secret hay input. Một số action gọi script trong package riêng. Hãy lần từ workflow tới script, client và nơi tạo token để tránh thay nửa chừng.

Tách prompt khỏi hạ tầng suy luận

Tài sản quan trọng nhất thường không phải endpoint mà là prompt đã được tinh chỉnh, bộ test đại diện và tiêu chí đánh giá. Nếu prompt chỉ tồn tại trong Playground hoặc preset cá nhân, hãy chuyển nó thành tệp được version-control. Ghi rõ system message, user template, biến đầu vào, model ID, sampling parameters, expected output và evaluator. Mục đích không phải giữ nguyên mọi chi tiết của GitHub Models, mà tạo một đặc tả có thể chạy trên nhiều backend.

Khi chuyển prompt, đừng giả định cùng một model name sẽ cho output giống nhau giữa hai nền tảng. Provider có thể khác về model snapshot, system message handling, tool schema, tokenization, content filter, JSON mode, streaming event và mặc định sampling. Hãy coi “cùng model” là điểm bắt đầu để kiểm thử, không phải bằng chứng tương đương.

Một đặc tả prompt di động nên tách thành bốn lớp:

1. Contract: input schema, output schema, trường bắt buộc và lỗi có thể trả về.
2. Instruction: system prompt, developer rules và quy tắc từ chối.
3. Runtime: model, temperature, max output, timeout, retry và tool choice.
4. Evaluation: test case, expected properties, rubric và ngưỡng phát hành.

Cấu trúc này giúp đổi backend mà không trộn thay đổi prompt với thay đổi hạ tầng. Nếu output xuống chất lượng, bạn biết cần kiểm tra provider adapter hay prompt behavior. Nếu schema không đổi nhưng latency tăng, bạn có thể điều chỉnh deployment mà không viết lại yêu cầu nghiệp vụ.

Giữ lại bộ so sánh và evaluator

GitHub Models cho phép chuyển từ Edit sang Compare, thêm nhiều cấu hình và chạy evaluator trên cùng test data. Khi dịch vụ ngừng, chính tư duy này nên được giữ lại: mọi migration cần chạy song song cấu hình cũ đã ghi nhận và cấu hình mới trên cùng một bộ dữ liệu. Không nên đánh giá bằng vài prompt “trông có vẻ ổn” do người triển khai tự chọn.

Bộ test nên bao gồm happy path, input rỗng, input quá dài, ngôn ngữ khác, dữ liệu nhiễu, prompt injection, yêu cầu ngoài phạm vi, tool failure và trường hợp không đủ bằng chứng. Với workflow tóm tắt, đừng chỉ chấm độ trôi chảy; cần đo mức độ giữ đúng dữ kiện và không thêm kết luận. Với workflow phân loại, cần confusion matrix hoặc ít nhất là tỷ lệ sai theo từng lớp. Với agent gọi tool, cần kiểm tra cả trace và trạng thái cuối, không chỉ câu trả lời.

GitHub Docs mô tả các nhóm evaluator như similarity, relevance, groundedness và custom prompt. Khi chuyển nền tảng, bạn có thể giữ tên metric nhưng phải kiểm tra cách tính. Hai hệ thống cùng gọi metric “groundedness” chưa chắc dùng cùng rubric, thang điểm hoặc model judge. Hãy lưu định nghĩa, prompt judge, phiên bản model judge và ngưỡng pass trong repository. Nếu dùng LLM-as-a-judge, thêm một lát cắt được người đánh giá thủ công để phát hiện judge bias.

Một migration gate hợp lý gồm: tỷ lệ schema hợp lệ không giảm; groundedness không giảm vượt ngưỡng đã thống nhất; latency p95 nằm trong ngân sách; lỗi 429/5xx có retry kiểm soát; chi phí mỗi tác vụ không vượt trần; và không có secret xuất hiện trong log. Kết quả nên được lưu như artifact của CI để review thay vì nằm trong tài khoản cá nhân.

Di chuyển inference API: những gì phải đổi

Ví dụ cũ của GitHub Models sử dụng endpoint thuộc miền models.github.ai và token GitHub có quyền models: read. Sau khi ngừng dịch vụ, endpoint, credential và policy đó không tự chuyển sang Microsoft Foundry. Nếu chọn Foundry, bạn cần tạo tài nguyên hoặc project phù hợp, chọn model từ catalog, tạo deployment hoặc endpoint theo loại model, cấp quyền và đổi client. Microsoft cũng hỗ trợ xác thực không dùng key qua Microsoft Entra ID cho các trường hợp phù hợp; đây là cơ hội giảm secret tĩnh thay vì bê nguyên PAT sang một API key mới.

Adapter mới nên gom các khác biệt provider vào một lớp nhỏ: tạo client, ánh xạ model alias, chuẩn hóa message, tools, response, usage và lỗi. Code nghiệp vụ không nên gọi SDK provider khắp nơi. Ví dụ, ứng dụng có thể dùng alias nội bộ như summary-fast, reasoning-high và embedding-default; file cấu hình môi trường ánh xạ alias sang deployment cụ thể. Khi model hoặc provider thay đổi, bạn sửa mapping và chạy evaluation thay vì sửa hàng chục module.

Kiểm tra từng điểm sau trước khi chuyển traffic:

• Base URL, API version và tên deployment/model.
• Phương thức xác thực, vòng đời token và quyền tối thiểu.
• Giới hạn input/output, định dạng image/audio và kích thước payload.
• Streaming event, tool calling, structured output và JSON schema.
• Timeout, retry-after, backoff, idempotency và circuit breaker.
• Region, data handling, logging, content filter và yêu cầu compliance.
• Quota, concurrency, token accounting và cảnh báo chi phí.

Không copy nguyên retry policy từ GitHub Models. Nếu provider mới trả 429 theo quota deployment, retry đồng loạt có thể làm tình hình tệ hơn. Dùng exponential backoff có jitter, giới hạn tổng thời gian và phân biệt lỗi có thể thử lại với lỗi input/policy. Với tác vụ nền, queue và dead-letter giúp tránh mất việc. Với request tương tác, hãy có thông báo rõ và fallback an toàn.

Prompt Editor và tệp .prompt.yml sau migration

Tệp .prompt.yml vẫn có giá trị như tài liệu có thể review, dù backend GitHub Models không còn chạy nó. Bạn có thể giữ format cũ trong một thư mục archive và chuyển sang schema nội bộ hoặc framework evaluation mới. Quan trọng là không để hai bản prompt cùng tồn tại mà không rõ bản nào là nguồn sự thật.

Chọn một source of truth duy nhất: prompt file trong repository, registry prompt có version hoặc package cấu hình phát hành cùng ứng dụng. Mọi thay đổi phải qua pull request, review và evaluation. Thêm metadata như owner, use case, dữ liệu được phép, model class, ngày đánh giá gần nhất và liên kết tới dashboard. Với prompt quan trọng, dùng semantic version và ghi breaking change khi output schema hoặc policy thay đổi.

Việc commit cấu hình không chỉ để lưu lịch sử. Nó tạo điểm nối giữa code, prompt, test và kết quả evaluation. Một pull request đổi prompt nên cho reviewer thấy diff instruction, test case mới, metric trước–sau và tác động chi phí. Nếu người không chuyên kỹ thuật cần duyệt nội dung, tạo preview đọc được nhưng vẫn giữ file canonical trong repository.

GitHub Actions: thay runtime, giữ nguyên cổng kiểm soát

Nếu workflow cũ gọi GitHub Models bằng GITHUB_TOKEN và quyền models: read, đừng chỉ thay token trong cùng YAML rồi kết thúc. Hãy xem lại trust boundary. GitHub token được cấp theo workflow và repository; credential của provider mới có thể là secret dài hạn, federated identity hoặc token lấy qua cloud login. Mỗi lựa chọn tạo ra bề mặt tấn công khác nhau.

Ưu tiên identity ngắn hạn và quyền theo môi trường nếu nền tảng hỗ trợ. Tách job evaluation khỏi job deploy. Không cho workflow chạy trên pull request không tin cậy đọc secret production. Pin action theo commit SHA khi rủi ro chuỗi cung ứng đáng kể. Chặn log request body nếu input có dữ liệu khách hàng. Đặt concurrency và budget guard để một vòng lặp lỗi không gọi model vô hạn.

Để migration có thể rollback, triển khai adapter mới sau feature flag. Chạy shadow traffic với dữ liệu được phép hoặc replay một tập input đã khử nhạy cảm. So sánh output và metric, sau đó tăng traffic theo từng nấc. Giữ đường cũ chỉ trong thời gian cần thiết; khi GitHub Models đã ngừng, “rollback” phải trỏ tới một deployment dự phòng hoặc chế độ giảm tính năng, không phải endpoint đã chết.

Nếu workflow chủ yếu là coding agent trên GitHub, hãy đánh giá Copilot thay vì dựng một inference stack tổng quát. Bài GitHub Copilot Cloud Agent tích hợp Linear cho thấy một workflow issue-to-PR được quản lý khác hẳn API gọi model thô. Với automation viết bằng Markdown và chạy trong Actions, xem thêm GitHub Agentic Workflows thực chiến. Không nên dùng Foundry chỉ để tái tạo một tính năng agent mà Copilot đã cung cấp ở cấp sản phẩm.

BYOK và quản trị organization không tự được chuyển

BYOK của GitHub Models từng cho organization thêm key và kiểm soát model được phép. Khi dịch vụ bị ngừng, hãy thu hồi key khỏi GitHub Models, kiểm tra audit log ở provider và xóa secret không còn dùng. Nếu cùng key còn được dùng ở nơi khác, đừng rotate mù; lập bản đồ consumer, tạo key mới, chuyển từng consumer rồi thu hồi key cũ.

Policy “model nào được phép” cần được tái tạo ở tầng mới bằng deployment allowlist, IAM, policy-as-code hoặc gateway. Đừng dựa vào tài liệu nhớ tay. Ghi rõ model/publisher được phép, region, loại dữ liệu, môi trường, owner, quota, thời hạn review và ngoại lệ. Nếu dùng nhiều provider, một gateway nội bộ có thể thống nhất logging và quota, nhưng nó cũng trở thành điểm tập trung quyền lực; cần hardening, audit và phương án khi gateway lỗi.

Đội nhỏ không nhất thiết phải xây platform phức tạp. Một cấu hình tối thiểu tốt hơn gồm: một project riêng cho production, identity riêng cho CI, secret không dùng chung với local, budget alert, dashboard lỗi/latency/token, danh sách model được phê duyệt và quy trình thay model qua pull request. Chỉ thêm gateway hoặc multi-provider khi có nhu cầu thực, không vì migration là dịp “làm lại tất cả”.

Chọn Microsoft Foundry hay GitHub Copilot?

GitHub nêu hai hướng thay thế, nhưng quyết định nên dựa trên intent:

Nhu cầu chính	Hướng phù hợp hơn	Lý do
Ứng dụng cần gọi model qua API	Microsoft Foundry hoặc provider API phù hợp	Có endpoint, deployment, identity, quota và catalog cho runtime
Developer cần chat, completion, agent hoặc review code	GitHub Copilot	Tích hợp vào GitHub, IDE và quy trình phát triển
So sánh nhiều model cho use case riêng	Foundry cộng hệ thống eval độc lập	Chủ động chọn deployment và giữ bộ test
Tự động xử lý issue đến pull request	Copilot coding agent hoặc agent workflow	Giải quyết bài toán ở cấp workflow, không chỉ inference
Cần local/self-hosted model	Provider/local runtime phù hợp, có thể kết nối công cụ hỗ trợ BYOK	Kiểm soát dữ liệu và hạ tầng, đổi lại phải tự vận hành

Foundry không phải lựa chọn duy nhất. Nếu ứng dụng đã dùng trực tiếp API của một provider và chỉ mượn GitHub Models để prototype, đi thẳng tới provider có thể ít lớp hơn. Nếu cần khả năng chuyển model, hãy cân nhắc adapter chuẩn hóa. Nếu dữ liệu không được rời hạ tầng, local hoặc self-hosted có thể cần thiết nhưng kéo theo vận hành GPU, cập nhật model, monitoring và security.

Đối với coding workflow, hãy bắt đầu từ bài toán thay vì model. Bài so sánh terminal agent, IDE agent và cloud agent giúp phân biệt quyền truy cập, độ trễ và bề mặt review. Nếu đội cần một workflow giao việc, đọc diff và chạy test xuyên app, CLI và IDE, có thể tham khảo quy trình Codex từ giao việc đến review. Những nội dung này bổ sung cho quyết định migration mà không biến GitHub Models thành một cuộc thi model.

Kế hoạch chuyển đổi trong một ngày

Nếu vẫn còn dependency hoạt động, hãy chia công việc thành các mốc ngắn:

1. Giờ 0–1: đóng băng thay đổi prompt và model; tìm endpoint, quyền, prompt file, workflow và secret; chỉ định owner.
2. Giờ 1–3: chọn đích theo intent; tạo endpoint/deployment hoặc bật workflow sản phẩm thay thế; cấu hình identity tối thiểu.
3. Giờ 3–5: viết adapter; ánh xạ request/response/error; chuyển prompt và test data; không tối ưu prompt cùng lúc.
4. Giờ 5–7: chạy regression trên golden set; kiểm tra schema, groundedness, latency, token, error và content policy.
5. Giờ 7–9: triển khai staging; chạy smoke test và failure test; xác nhận log không chứa secret hoặc dữ liệu nhạy cảm.
6. Giờ 9–11: chuyển traffic có kiểm soát; theo dõi dashboard; giữ phương án giảm tính năng.
7. Giờ 11–12: xóa quyền models: read không còn dùng, thu hồi BYOK/PAT cũ, cập nhật runbook và thông báo stakeholder.

Nếu không thể hoàn tất trong ngày, ưu tiên an toàn: tắt tính năng phụ thuộc bằng feature flag, queue tác vụ có thể chạy lại và thông báo trạng thái rõ ràng. Đừng để ứng dụng retry vô hạn vào endpoint đã ngừng hoặc âm thầm trả nội dung mặc định như thể model vẫn hoạt động.

Checklist xác nhận migration hoàn tất

• Không còn code, workflow hoặc tài liệu đang hoạt động trỏ tới models.github.ai.
• Không còn secret GitHub Models/BYOK không có consumer hợp lệ.
• Mọi prompt quan trọng có owner, version và source of truth.
• Golden set chạy được trên backend mới và kết quả được lưu.
• Schema, tool call, streaming và error handling đã được kiểm thử.
• Quota, latency, token và chi phí có dashboard hoặc cảnh báo.
• Policy model/publisher được tái tạo ở đích mới.
• Workflow từ fork hoặc pull request không tin cậy không đọc được secret.
• Runbook ghi rõ fallback, rollback và người chịu trách nhiệm.
• Tài liệu onboarding không còn hướng dẫn mở Playground hoặc catalog đã ngừng.

Câu hỏi thường gặp

GitHub Copilot có bị ngừng cùng GitHub Models không?

Không theo thông báo này. Thông báo nêu GitHub Models, gồm Playground, catalog, inference API và BYOK. GitHub còn đề xuất Copilot cho các workflow AI trực tiếp trên GitHub. Tuy nhiên, tính năng và model khả dụng trong Copilot phụ thuộc plan, client và policy tổ chức; cần kiểm tra tài liệu Copilot hiện hành thay vì suy ra từ GitHub Models.

Tệp .prompt.yml có còn dùng được không?

Tệp vẫn là tài sản hữu ích để lưu prompt, test data và evaluator, nhưng runtime GitHub Models dùng để chạy nó đã bị ngừng. Bạn cần adapter, runner hoặc hệ thống evaluation mới. Hãy giữ lịch sử Git và chuyển có kiểm soát, không xóa trước khi xác nhận bộ test đã chạy trên đích mới.

Chỉ đổi endpoint sang Microsoft Foundry có đủ không?

Thường là không. Bạn còn phải xử lý identity, deployment/model ID, API version, quota, response schema, tool calling, streaming, content filter, observability và chi phí. Cùng một SDK hoặc giao thức tương tự không bảo đảm hành vi giống nhau.

Có nên đổi model trong lúc migration?

Nên hạn chế. Thay provider, endpoint và model cùng lúc làm khó xác định nguyên nhân khi chất lượng thay đổi. Nếu có thể, giữ model class tương đương, hoàn tất hạ tầng và regression trước; sau đó tối ưu model như một thay đổi riêng có benchmark.

Star hoặc mức độ phổ biến có giúp chọn nền tảng thay thế không?

Không đủ. Star là tín hiệu quan tâm đối với repository, không chứng minh chất lượng runtime, bảo mật, SLA hay phù hợp production. Quyết định nên dựa trên dữ liệu, quyền riêng tư, khả năng vận hành, evaluation, chi phí và yêu cầu workflow cụ thể.

GitHub Models kết thúc, nhưng prompt, dataset, evaluator và những bài học từ quá trình thử nghiệm không cần biến mất theo. Một migration tốt không chỉ khiến request chạy lại; nó biến các tài sản từng nằm rải rác trong Playground thành hệ thống có version, quyền rõ, test lặp lại và đường thay model an toàn hơn.