GitHub Models 7-30 退役全拆：Inventory Capability Probe Shadow Traffic Brownout

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 项

版本矩阵

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 当作可替换依赖,并为平台退出建立标准预案。

核心结论

1. 先拆解 GitHub Models 的四类角色:发现、试验、推理、BYOK。每类能力的替代方案不同。
2. GitHub 官方迁移建议是方向,不是无损映射。Foundry 和 Copilot 的产品边界不同,不能替代所有自定义应用。
3. OpenAI-compatible 只是接口家族。Tool Schema、JSON 约束、错误、Streaming 事件、Usage、重试和费用仍需逐项测试。
4. Brownout 是最有价值的演练窗口。应记录错误码、恢复时间、Retry 行为和业务降级,而不是等待 7 月 30 日直接切断。
5. 迁移必须可回滚:Feature Flag、双写、Shadow Traffic、Provider Registry、Key Rotation 和状态对账缺一不可。

1. 官方时间线与关闭范围

官方公告列出的关闭范围:

• 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 Surface

2.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 BYOK

BYOK 不只是"把自己的 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_ownersupport-bot,cs-platform,prod,github-models,gpt-x,chat,120000,1800,4096,true,true,true,false,openai,internal,critical,alicecontent-pipeline,growth,prod,github-models,model-y,chat,8000,4200,8192,false,true,false,false,,public,medium,bobsemantic-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. 目标架构:应用不直接绑定 Provider

Application↓ Stable Internal ContractAI 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 Registry

providers: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 不能保证什么

因此,迁移验收必须覆盖"接口可调用"和"业务行为可接受"两层。

8. Capability Probe

本内容包的 tools/provider_probe.py 提供一个最小探针。生产探针应覆盖:

1. 基础非 Streaming Chat;
2. Streaming 首 Token、结束事件和 Usage;
3. JSON Schema 严格符合率;
4. 单 Tool、并行 Tool、无效参数;
5. 长上下文边界;
6. Unicode、中文和代码;
7. 图片输入;
8. Embedding 维度、批量和确定性;
9. 429、5xx、Timeout 和连接中断;
10. Request ID、Trace、Usage 和费用字段;
11. 数据区域和日志策略;
12. 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 Traffic

Shadow 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%→ Probe1%→ Internal / Synthetic5%→ Low-risk Tenants25% → Broader Production50% → Compare Capacity / Cost100% → 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-oncall

11. 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-prodAdd To Gateway / Broker↓ Shadow TrafficSwitch Primary Credential↓ MonitorRevoke Old Credential↓ Search Residual References

13. Foundry、Gateway、OpenRouter 与直连的比较维度

决策不应只看请求价格,还应看故障域、数据路径、审计、预算、延迟和退出能力。

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—29

• 100% 切离;
• 执行恢复演练;
• 清理旧 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 文档。

错误速查卡