GitHub Models 7 月 30 日关闭：迁移别只换 Base URL

推荐标题：GitHub Models 7 月 30 日关闭：迁移别只换 Base URL 备选标题1：GitHub Models 7 月 30 日全面关闭：迁移前必须知道的边界备选标题2：别等故障发生：GitHub Models 7 月 30 日全面关闭备选标题3：一张图看懂：GitHub Models 要关了，别只换 Base URL

GitHub Models 要关了，别只换 Base URL

日期：2026-07-20 状态：完整母稿时间边界：2026-07-23 第二次 Brownout 与 2026-07-30 全面退役均为未来事件。Brownout 的具体 HTTP 状态码和错误 Body 尚未由官方公告明确，必须主动探测。

摘要

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-16	GitHub 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 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_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. 目标架构：应用不直接绑定 Provider

Application
  ↓ 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 Registry

providers:
  foundry-prod:
    type: microsoft-foundry
    endpoint: ${FOUNDRY_ENDPOINT}
    region: eastus2
    auth: managed-identity
    dataPolicy: enterprise-approved

  vercel-gateway:
    type: vercel-ai-gateway
    auth: api-key
    dataPolicy: review-required

models:
  reasoning-medium:
    candidates:
      - provider: foundry-prod
        model: deployment-reasoning-v3
        capabilities:
          chat: true
          streaming: true
          tools: true
          parallel_tools: false
          json_schema: strict
          vision: false
          embeddings: false
          max_input_tokens: 128000
          usage_in_stream: verified
      - provider: vercel-gateway
        model: provider-x/model-y
        capabilities:
          chat: true
          streaming: true
          tools: true
          parallel_tools: unknown
          json_schema: best_effort
          vision: true
          embeddings: false
          max_input_tokens: 200000
          usage_in_stream: unknown
    policy:
      primary: foundry-prod
      fallback: [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 Calling	Tool Choice、并行调用、参数修复不同
Streaming	SSE Event、Delta、Usage、Finish Reason 不同
多模态	图片输入格式、大小、URL 支持不同
Embedding	维度、归一化、Batch 上限不同
错误	HTTP 状态、错误码、可重试性不同
限流	RPM/TPM/并发/动态配额不同
Tokenizer	Token 数和费用估计不同
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 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%  → 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: 10m
  conditions:
    - metric: request_error_rate
      op: ">"
      value: 0.02
    - metric: schema_invalid_rate
      op: ">"
      value: 0.01
    - metric: p95_latency_ms
      op: ">"
      value: 6000
    - metric: cost_per_success_usd
      op: ">"
      value: 0.12
  action:
    setPrimary: secondary-provider
    disableNewProvider: true
    page: 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-prod
Add To Gateway / Broker
  ↓ Shadow Traffic
Switch Primary Credential
  ↓ Monitor
Revoke Old Credential
  ↓ Search Residual References

Foundry 与 Copilot，不是一对一替代

13. 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—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 团队报表。

Brownout 前，把退出预案跑一遍

17. 发布检查表

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 文档。

完整 URL 与核验备注见 ../research-bundles/2026-07-20-ai-engineering-content-pack/source-ledger.md。

AI 调研与资料整理

适合读者

前置知识

你将收获

摘要