TL;DR场景:GitHub Models 将于 2026-07-30 全面退役(Playground、Model Catalog、Inference API、BYOK Endpoint),7-23 还有一次 Brownout结论:正确的迁移对象不是某个 Base URL,而是完整的模型访问契约;OpenAI-compatible 只能减少客户端改造,不能证明语义、配额、治理兼容;迁移必须建立 Provider Capability Registry Capability Probe Shadow Traffic 分批 Cutover 可回滚产出:GitHub Models 四类角色拆解 迁移 Inventory 模板 AI Access Layer 内部契约 Provider Capability Registry YAML Capability Probe 12 项 5 步 Cutover Brownout 演练清单 7-20 到 7-30 实施日历 Provider 退出预案 13 项版本矩阵功能状态说明2026-06-16 GitHub Models 不再向新客户开放⚠️ 待官方公告核验原文母稿日期 2026-07-20;web 搜索未命中 2026 年 GitHub Models 退役官方公告,具体日期需以 GitHub Changelog 为准2026-07-16 第一次 Brownout⚠️ 待官方公告核验原文自述已过去;本文未取得用户系统的实测日志,需在 GitHub Changelog 核验2026-07-23 第二次 Brownout(请求返回错误)❓ 未公开母稿日期 7-20,此事件为未来,需主动探测2026-07-30 全面关闭(Playground/Catalog/Inference API/BYOK)❓ 未公开母稿日期 7-20,此事件为未来,需以当日官方公告为准关闭范围:Playground Model Catalog Inference API BYOK Endpoint⚠️ 按作者主张原文明确,需以 GitHub 官方公告为准现有客户同样受影响⚠️ 按作者主张原文明确,需以 GitHub 官方公告为准官方建议:模型目录、部署、推理 → Microsoft Foundry⚠️ 按作者主张原文明确,需以 GitHub/F5 官方公告为准官方建议:GitHub 工作流内 AI → GitHub Copilot⚠️ 按作者主张原文明确,需以 GitHub 官方公告为准GitHub Models REST API 曾支持 Streaming、JSON Schema、Tool Calling、组织归因✅ 已验证多源开发者文档 第三方迁移文章Microsoft Foundry 模型目录 部署 推理✅ 已验证Microsoft 官方 Azure AI Foundry 文档Vercel AI Gateway(统一 API 用量/预算 路由/Fallback)✅ 已验证Vercel 官方文档OpenRouter(多 Provider 路由 Fallback BYOK/ZDR)✅ 已验证OpenRouter 官方文档LiteLLM(开源 LLM Gateway,支持多 Provider)✅ 已验证LiteLLM 官方仓库4 类 GitHub Models 角色:Model Discovery / Playground / Inference API / BYOK✅ 已验证(作者分析)原文第二段,作为分析框架AI Access Layer 6 模块(Model Alias / Capability Registry / Policy / Routing / Telemetry / Credential Broker)✅ 已验证(作者架构)原文第四节,作为架构图OpenAI-compatible 14 维差异表✅ 已验证(作者分析)原文第七节表,作为兼容性测试清单Capability Probe 12 项✅ 已验证(作者设计)原文第八节,作为探测清单5 步 Cutover(0%/1%/5%/25%/50%/100%)✅ 已验证(作者设计)原文第十节,作为分批切换建议自动回滚 4 条件(error_rate/schema_invalid_rate/p95/cost)✅ 已验证(作者设计)原文第十节,作为示例Provider 退出预案 13 项(资产/Owner/Alias/Registry/第二 Provider/Probe/质量基线/Shadow/Flag/Key 轮换/数据导出/最长迁移/退出触发器)✅ 已验证(作者设计)原文第十五节,作为预案模板7-20 到 7-30 实施日历✅ 已验证(作者设计)原文第十四节,作为时间表Brownout 演练 5 项(错误/降级/状态/密钥/回滚)✅ 已验证(作者设计)原文第十一节,作为演练清单AscendLab Provider Capability Tester 工具机会(CLI Key 不写日志 可重复 Probe capability-registry.yaml Markdown)✅ 已验证(作者设计)原文第十六节,作为工具机会描述GHM-01 / GHM-02 / GHM-03 / FOUNDRY-01 / GW-01 / GW-02 / GW-03 来源链接⚠️ 待验证原文给出来源代号但未给完整 URL,需在 [S01] 链接核验GitHub Models 将于 2026 年 7 月 30 日全面退役,关闭 Playground、Model Catalog、Inference API 和 BYOK Endpoint;7 月 23 日还有一次 Brownout。GitHub 建议将模型目录与推理场景迁往 Microsoft Foundry,把 GitHub 工作流中的 AI 使用转向 GitHub Copilot。但这不是一对一替换:模型 ID、版本、鉴权、限流、Streaming、Tool Calling、Structured Output、多模态、Embedding、数据策略和计费都可能不同。正确的迁移对象不是某个 Base URL,而是完整的模型访问契约。团队需要先建立 Inventory,再把调用能力描述为 Provider Capability Registry;使用兼容探针验证接口和行为;通过 Shadow Traffic 对比质量、延迟、成本与失败;最后进行分批 Cutover 和可回滚切换。OpenAI-compatible只能减少客户端改造,不能证明语义、配额和治理兼容。GitHub Models 的退出也说明一个产品事实:通用模型入口若缺少独立工作流和治理价值,容易被更大的 Agent 产品、云平台或 AI Gateway 吸收。独立开发者应把 Provider 当作可替换依赖,并为平台退出建立标准预案。核心结论先拆解 GitHub Models 的四类角色:发现、试验、推理、BYOK。每类能力的替代方案不同。GitHub 官方迁移建议是方向,不是无损映射。Foundry 和 Copilot 的产品边界不同,不能替代所有自定义应用。OpenAI-compatible只是接口家族。Tool Schema、JSON 约束、错误、Streaming 事件、Usage、重试和费用仍需逐项测试。Brownout 是最有价值的演练窗口。应记录错误码、恢复时间、Retry 行为和业务降级,而不是等待 7 月 30 日直接切断。迁移必须可回滚:Feature Flag、双写、Shadow Traffic、Provider Registry、Key Rotation 和状态对账缺一不可。1. 官方时间线与关闭范围日期事件状态2026-06-16GitHub Models 不再向新客户开放已发生2026-07-16第一次 Brownout已过去;本文未取得用户系统的实测日志2026-07-23第二次 Brownout,请求返回错误未来2026-07-30全面关闭未来官方公告列出的关闭范围:Playground;Model Catalog;Inference API;BYOK Endpoint;现有客户同样受影响。官方方向:模型目录、部署与推理迁向 Microsoft Foundry;GitHub 工作流内的 AI 能力转向 GitHub Copilot。需要注意,GitHub Models REST API 曾支持 Streaming、JSON Schema、Tool Calling 和组织归因等能力。迁移清单不能只记录模型名称和 Prompt。2. GitHub Models 原本承担的四个角色Model Discovery Playground / Prompt Experiment Unified Inference API BYOK Endpoint GitHub Models Product Surface2.1 Model Discovery用户通过 Catalog 比较模型、能力、发布者和基础信息。替代它需要的是 Registry、筛选、能力说明和版本治理。2.2 Playground用于快速测试 Prompt、参数和输出。替代它需要保存实验配置、结果、成本和可复现性,而不只是另一个聊天界面。2.3 Inference API承担应用运行时调用。这里迁移风险最高,涉及:Endpoint 和鉴权;模型 ID 与版本;请求/响应 Schema;Streaming;Tool Calling;Structured Output;多模态与 Embedding;限流、错误、重试;Usage 和计费;数据处理和区域。2.4 BYOKBYOK 不只是把自己的 Key 放进去。它通常还涉及统一 Endpoint、路由、用量归因、失败回退和凭据托管。迁移时必须决定:继续使用 Gateway BYOK、直连 Provider,还是迁入云平台托管部署。3. 迁移 Inventory在改代码前,先列清所有使用点:application,owner,environment,endpoint,model_id,capability,requests_per_day,p95_latency_ms,max_tokens,tools,structured_output,streaming,embedding,byok_provider,data_classification,criticality,rollback_owner support-bot,cs-platform,prod,github-models,gpt-x,chat,120000,1800,4096,true,true,true,false,openai,internal,critical,alice content-pipeline,growth,prod,github-models,model-y,chat,8000,4200,8192,false,true,false,false,,public,medium,bob semantic-search,search,prod,github-models,embed-z,embedding,600000,350,,false,false,false,true,,internal,critical,carol必须补充的隐藏依赖:SDK 包和版本;CI/CD Secret;Terraform/Helm 配置;Prompt Template;Tool Schema;JSON Parser;Timeout/Retry;缓存 Key;评测基线;成本告警;合规文档;Dashboard 和日志字段。4. 目标架构:应用不直接绑定 ProviderApplication ↓ Stable Internal Contract AI Access Layer ├── Model Alias Registry ├── Capability Registry ├── Policy / Budget / Data Region ├── Routing / Retry / Fallback ├── Telemetry / Evaluation └── Credential Broker ↓ Foundry / Direct Provider / Vercel Gateway / OpenRouter / Other内部契约需要稳定,但不能过度抽象成最低公分母。建议把通用字段与 Provider Extension 分开:{model_alias:reasoning-medium,messages:[{role:user,content:...}],response_format:{type:json_schema,schema:{}},tools:[],policy:{data_classification:internal,region:us,max_cost_usd:0.08,fallback_allowed:true},provider_options:{reasoning_effort:medium}}provider_options应通过 Allowlist,避免业务随意把 Provider 私有参数渗透到所有代码。5. Provider Capability Registryproviders:foundry-prod:type:microsoft-foundryendpoint:${FOUNDRY_ENDPOINT}region:eastus2auth:managed-identitydataPolicy:enterprise-approvedvercel-gateway:type:vercel-ai-gatewayauth:api-keydataPolicy:review-requiredmodels:reasoning-medium:candidates:-provider:foundry-prodmodel:deployment-reasoning-v3capabilities:chat:truestreaming:truetools:trueparallel_tools:falsejson_schema:strictvision:falseembeddings:falsemax_input_tokens:128000usage_in_stream:verified-provider:vercel-gatewaymodel:provider-x/model-ycapabilities:chat:truestreaming:truetools:trueparallel_tools:unknownjson_schema:best_effortvision:trueembeddings:falsemax_input_tokens:200000usage_in_stream:unknownpolicy:primary:foundry-prodfallback:[vercel-gateway]allowedData:[public,internal]Registry 中的能力必须来自自动探针和人工评测,不能只抄营销页面。6.OpenAI-compatible能解决什么通常可以减少:Client 初始化差异;/chat/completions或/responses请求结构差异;Message、Temperature、Max Tokens 的基础映射;Streaming 的基本消费方式;Tool 定义的基础 Schema;常见 SDK 的替换成本。7.OpenAI-compatible不能保证什么维度可能差异模型 ID名称、版本、部署名、别名不同System/Developer Message支持程度和优先级不同Structured Output严格 Schema、Best-effort、拒绝行为不同Tool CallingTool Choice、并行调用、参数修复不同StreamingSSE Event、Delta、Usage、Finish Reason 不同多模态图片输入格式、大小、URL 支持不同Embedding维度、归一化、Batch 上限不同错误HTTP 状态、错误码、可重试性不同限流RPM/TPM/并发/动态配额不同TokenizerToken 数和费用估计不同Safety拒绝、过滤、内容策略不同数据治理保留、训练、区域、ZDR 不同费用输入/输出/缓存/工具/区域不同输出质量Prompt 对同类模型也可能漂移因此,迁移验收必须覆盖接口可调用和业务行为可接受两层。8. Capability Probe本内容包的tools/provider_probe.py提供一个最小探针。生产探针应覆盖:基础非 Streaming Chat;Streaming 首 Token、结束事件和 Usage;JSON Schema 严格符合率;单 Tool、并行 Tool、无效参数;长上下文边界;Unicode、中文和代码;图片输入;Embedding 维度、批量和确定性;429、5xx、Timeout 和连接中断;Request ID、Trace、Usage 和费用字段;数据区域和日志策略;Key 权限与失效行为。结果示例:{provider:foundry-prod,model:deployment-reasoning-v3,tested_at:2026-07-20T09:00:00Z,capabilities:{chat:{status:pass,p50_ms:1320},streaming:{status:pass,first_token_p50_ms:410},json_schema:{status:pass,valid_rate:1.0},parallel_tools:{status:fail,reason:single tool only}}}9. Shadow TrafficShadow Traffic 将生产请求复制到候选 Provider,但候选结果不返回用户。Production Request ├── Current GitHub Models → User Response └── Redacted Shadow Copy → Candidate Provider ↓ Evaluation Store必须控制去除或 Tokenize PII;只对允许的数据等级双写;Shadow 请求不触发真实 Tool 副作用;记录 Prompt Template、模型版本和参数;控制额外成本;避免把用户数据发到未批准区域;对 Streaming 与非 Streaming 分开评估。评估指标请求成功率;P50/P95 延迟、首 Token;JSON Schema 合规率;Tool Call 正确率;任务完成率;自动评测 人工盲评;输入/输出 Token 与实际费用;拒绝率;安全和数据策略事件;输出漂移。LLM-as-a-Judge 只能作为一层,应加入确定性验证、任务结果和人工抽样。10. Cutover 与 Rollback分阶段切流0% → Probe 1% → Internal / Synthetic 5% → Low-risk Tenants 25% → Broader Production 50% → Compare Capacity / Cost 100% → Primary → Keep Old Path Disabled-but-Ready until retirement由于 GitHub Models 将退役,旧路径的最终回滚窗口有限。迁移完成前应至少保留两个可用候选 Provider,而不是把单点从 GitHub 转移到另一个平台。自动回滚条件示例rollback:window:10mconditions:-metric:request_error_rateop:value:0.02-metric:schema_invalid_rateop:value:0.01-metric:p95_latency_msop:value:6000-metric:cost_per_success_usdop:value:0.12action:setPrimary:secondary-providerdisableNewProvider:truepage:ai-platform-oncall11. Brownout 演练2026-07-23 应把 Brownout 当成故障演练:从多个 Region 和应用执行 Canary;记录 HTTP 状态、错误 Code、Body、Header、Request ID;记录开始、恢复和间歇成功;检查 SDK 是否错误重试导致请求风暴;检查 Gateway 是否按策略 Fallback;检查 Queue、Timeout、熔断和用户提示;检查 Dashboard 和告警是否能区分 Provider 故障;保存日志用于 7 月 30 日前最终验收。不能提前写死具体错误码。实验模板见../research-bundles/2026-07-20-ai-engineering-content-pack/experiments/github-models-brownout-test-plan.md。12. Key 与凭据迁移不要复用旧 Key 语义GitHub Token、Provider Key、Foundry Managed Identity 和 Gateway Key 的权限模型不同;新系统应建立 Key Owner、用途、环境、创建/到期、轮换和撤销;BYOK Key 从旧平台移出后,应在 Provider 侧轮换,而不是长期保留同一 Key;应删除 CI、Secret Manager、日志和开发环境中的旧引用;应用不直接持有多个 Provider Key,优先通过 Credential Broker 或托管身份。轮换流程:Create New Credential ↓ Test In Non-prod Add To Gateway / Broker ↓ Shadow Traffic Switch Primary Credential ↓ Monitor Revoke Old Credential ↓ Search Residual References13. Foundry、Gateway、OpenRouter 与直连的比较维度方案优势风险/成本适合Microsoft Foundry企业部署、Azure 身份/网络/治理、模型目录云绑定、Deployment 管理、SDK/Endpoint 变化Azure 企业团队Vercel AI Gateway统一 API、用量/预算、路由/Fallback平台依赖、兼容需验证Web/AI SDK 生态、快速迁移OpenRouter多 Provider 路由、Fallback、BYOK/ZDR 选项Provider 链复杂、费用/数据策略需逐路由理解多模型探索与冗余LiteLLM/自建 Gateway控制强、可自托管、可定制策略运维、兼容、监控、安全责任有平台团队、强合规Provider 直连功能最完整、最少中间层业务耦合、凭据分散、退出成本高单 Provider、专有能力关键决策不应只看请求价格,还应看故障域、数据路径、审计、预算、延迟和退出能力。14. 迁移实施日历2026-07-20冻结新增 GitHub Models 依赖;完成 Inventory;建立模型 Alias;选择至少两个候选路径;部署 Capability Probe。2026-07-21—22迁移低风险开发/测试;运行 Shadow Traffic;完成 Key Rotation 预案;配置 Brownout 监控和 Fallback。2026-07-23记录 Brownout;验证自动降级;修复 Retry Storm、错误解析和告警缺口。2026-07-24—27分阶段生产切流;对账成功率、质量、延迟和成本;处理 Embedding 索引或 Tool Schema 差异。2026-07-28—29100% 切离;执行恢复演练;清理旧 Key 与 Endpoint;完成业务 Owner 签字。2026-07-30只做退役确认和残留扫描,不应再进行主迁移。15. 模型平台退出预案每个外部 Provider 都应有:资产清单;Owner 和严重度;模型 Alias 而非业务硬编码;Capability Registry;第二 Provider;兼容探针;质量基线;Shadow Traffic;Feature Flag;Key 轮换;数据导出;最长迁移时间;退出触发器;演练频率。退出触发器包括:退役公告、价格上涨、配额下降、区域/合规变化、模型删除、质量漂移、重大故障和公司风险。16. AscendLab 工具机会:Provider Capability Tester定位输入多个 OpenAI-compatible Endpoint、模型和 Key 环境变量,执行安全、无副作用的能力测试,输出:Chat/Streaming;JSON Schema;Tool Calling;多模态;Embedding;错误与重试;Usage/费用字段;Markdown 兼容报告。MVP本地 CLI;Key 不写日志;JSON/YAML Provider 配置;可重复 Probe Case;输出capability-registry.yaml和 Markdown;支持历史 Diff 和 CI 失败阈值。后续浏览器本地版;Provider 价格快照;Shadow Evaluation;Prompt/Tool Fixture 管理;Gateway Migration Checklist;SaaS 团队报表。17. 发布检查表7 月 23 日与 7 月 30 日写成未来时间。关闭范围包含 Playground、Catalog、Inference API、BYOK 和现有用户。不把 Foundry/Copilot 写成所有用例的一对一替代。Inventory 覆盖模型、工具、Structured Output、Streaming、Embedding、数据和成本。OpenAI-compatible差异逐项探测。Shadow Traffic 不触发真实 Tool 副作用。Cutover 有 Feature Flag 和自动回滚。Brownout 记录真实错误,不提前编造错误码。Key 迁移包含轮换与旧 Key 撤销。至少保留两个可行 Provider 路径。7 月 30 日前完成 100% 切离和残留扫描。18. 常见错误只换 Base URL可能在 Tool、JSON、Streaming、Tokenizer、Error 或 Usage 上静默失败。只做离线 Prompt 对比生产差异包括并发、限流、长尾延迟、网络、Tool 副作用和数据策略。Fallback 到不满足数据政策的 Provider高可用不能凌驾于数据等级和区域限制。在 Brownout 期间无限重试会造成请求风暴和费用放大。应使用熔断、指数退避和全局并发控制。把 Gateway 当成永久保险Gateway 自身也可能退役或故障。内部契约、导出和第二路径仍然必要。19. 限制与待验证Brownout 的具体错误行为需 2026-07-23 实测;各候选 Provider 的价格、模型和能力在发布前需刷新;Microsoft Foundry 的具体模型映射取决于 Region、Subscription 和 Deployment;GitHub Models 的用户用量导出方式需要账户级核验;Embedding 迁移可能需要重建索引,不能与 Chat Endpoint 同等处理。20. 延伸章节Provider Capability Registry 与自动探针。OpenAI-compatible 行为兼容 Benchmark。Shadow Traffic 与 LLM 输出对账。多 Provider Fallback 的数据政策。AI API 供应商退役演练。BYOK Key Broker 与短期凭据。参考来源GHM-01:GitHub Models 全面退役公告,2026-07-01。GHM-02:新客户停止开放公告,2026-06-16。GHM-03:GitHub Models Inference REST API 文档。FOUNDRY-01:Microsoft Foundry Models Endpoint 文档。GW-01:Vercel AI Gateway 文档。GW-02、GW-03:OpenRouter Routing 与 BYOK 文档。错误速查卡症状根因定位修复把 GitHub Models 退役当成 7-30 当天切换忽略 Brownout 演练窗口和 7-24 之后的分阶段切流查原文第十一节 Brownout 演练 第十四节实施日历改写为7-20 冻结 / 7-21-22 准备 / 7-23 演练 / 7-24-27 切流 / 7-28-29 切离 / 7-30 退役假设 Foundry / Copilot 是 GitHub Models 一对一替代Foundry / Copilot / GitHub Models / 直接 Provider 产品边界不同查原文第十三节比较表 核心结论第 2 条改写为Foundry 更接近企业云治理 / Copilot 更接近 GitHub 内 Agent 工作流 / 不能替代所有自定义应用只换 Base URL把 OpenAI-compatible 等同于行为兼容查原文第七节 14 维差异表改写为Tool Schema/JSON/Streaming/Tokenizer/Error/Usage/限流/数据治理 14 维需逐项探测把 Shadow Traffic 当成安全测一下忽略 PII 去除、数据等级、Tool 副作用、用户数据发到未批准区域查原文第九节 Shadow Traffic 必须控制 6 项改写为Shadow 也要 PII 处理 数据等级限制 工具不真触发 控制额外成本在 Brownout 期间无限重试没有熔断/退避/全局并发控制查原文第十八节常见错误改写为使用熔断 指数退避 全局并发控制,避免请求风暴和费用放大把 Gateway 当成永久保险Gateway 自身可能退役查原文第十八节 第十五节退出预案 13 项改写为内部契约 导出 第二路径仍然必要,Gateway 不是银弹用 model 字符串做能力判断同一 model 字符串在不同 Provider / Region / Deployment 行为可能不同查原文第五节 Provider Capability Registry 能力必须来自自动探针改写为Registry 中的能力必须来自自动探针和人工评测,不能只抄营销页面假设 Microsoft Foundry 的 Deployment 跟 GitHub Models 模型 ID 1:1同一模型在不同 Foundry Region / Subscription / Deployment 有差异查原文第十三节 Microsoft Foundry 风险栏 第十九节具体模型映射取决于 Region改写为Foundry Deployment 取决于 Region / Subscription / Deployment,需要按账户级核验用Provider 也支持 OpenAI API作为迁移标准忽略 Tool Schema / JSON / Streaming / Tokenizer / 错误 / 用量 / 限流 / 数据治理查原文第七节 14 维差异表改写为接口兼容 ≠ 行为兼容;14 维差异表必须逐项探测假设 Fallback Provider 自动满足数据政策Fallback Provider 可能不满足数据等级和区域查原文第十八节常见错误Fallback 到不满足数据政策的 Provider改写为Fallback 也要走 Capability Registry 数据政策 区域校验,不能凌驾于数据等级用 Capable but 慢的 Provider 作为 Primary没测延迟,只看能力查原文 Capability Probe 12 项 Shadow Traffic 评估指标改写为Capable 延迟 成本 数据政策多维评分,不只看功能假设 Brownout 期间能用同一 Key 重试同一 Key 在 Brownout 期间可能临时失效查原文第十二节 Key 轮换流程改写为Brownout 期间旧 Key 可能临时失效,Key Rotation 需提前演练假设 7-30 后 Gateway 会自动把数据从旧 Provider 导到新 Provider7-30 旧 Provider 关闭,Gateway 不会自动迁移查原文第十二节 Key 与凭据迁移 第十五节退出预案改写为7-30 前 100% 切离 Key 轮换 数据导出 残留扫描把 Embedding 和 Chat 混在同一 Gateway 路由Embedding 维度/归一化/Batch 上限不同查原文第七节 第十九节限制改写为Embedding 和 Chat 走不同 Capability Registry / Probe / Provider,Embedding 迁移可能重建索引假设用一个 SDK 跑通所有 Provider不同 Provider 的 SDK / 鉴权 / 路由不同查原文第四节 AI Access Layer 架构 第六节 OpenAI-compatible 范围改写为统一内部契约 Provider 适配层,而非用一个 SDK 跑通所有 Provider假设迁移完成 项目结束平台退出需要长期预案查原文第十五节退出预案 13 项改写为迁移完成 退出预案执行完成(资产清单/Owner/Alias/Registry/第二 Provider/Probe/质量/Shadow/Flag/Key 轮换/数据导出/最长迁移/退出触发器/演练频率)