GitHub Models已于2026年7月30日正式停止服务.
原有的模型Playground、模型目录、推理API和BYOK接口均不再可用。开发者接下来迁移到哪里，取决于原来的使用方式。
如果原来通过GitHub Models开发AI应用，可以优先迁移到Microsoft Foundry；
如果主要用于辅助写代码，可以改用GitHub Copilot；
如果希望直接控制模型、账单和API Key，也可以连接OpenAI、Anthropic、Gemini等模型提供商，或者部署本地模型。
一、GitHub Models具体停止了哪些服务？
截至2026年7月30日，GitHub Models已经停止提供：
-
模型Playground；
-
模型目录；
-
推理API；
-
Bring Your Own Key（BYOK）；
-
相关管理页面。
这次调整影响所有用户，包括此前仍有活跃调用的现有账号。GitHub Models与GitHub Copilot是两个独立产品，因此GitHub Models停止服务并不影响Copilot继续使用。
如果原来的程序仍在调用GitHub Models接口，应尽快更换API端点和认证信息，否则相关请求将无法继续执行。
二、应该迁移到哪里？先看结论
| 原来的使用场景 | 推荐迁移方向 |
|---|---|
| 开发聊天机器人、RAG或AI应用 | Microsoft Foundry |
| 在GitHub、IDE或终端中辅助编程 | GitHub Copilot |
| 需要直接调用某一家模型 | 对应模型厂商API |
| 需要同时切换多个模型提供商 | Copilot BYOK或模型网关 |
| 对隐私和离线运行要求较高 | Ollama、LM Studio等本地模型 |
| 已经使用Azure企业体系 | Microsoft Foundry |
| 已经使用AWS或Google Cloud | Bedrock、Gemini API或对应云平台 |
GitHub官方目前给出的两个主要方向也很明确：
-
需要继续访问 模型 和 开发AI应用 ，转向Microsoft Foundry；
-
希望在GitHub中使用 AI开发工作流 ，转向GitHub Copilot。
三、路线一：迁移到Microsoft Foundry
如果原来使用GitHub Models的推理API开发正式应用，Microsoft Foundry是最直接的迁移路线。
Foundry不仅提供模型目录，还支持：
-
模型部署；
-
按Token计费；
-
批处理和预配吞吐量；
-
自定义速率限制；
-
内容安全过滤；
-
Microsoft Entra ID无密钥认证；
-
Azure权限和账单管理。
微软的迁移文档说明，对于使用兼容调用方式的项目，部署好Foundry模型后，主要需要替换新的密钥和端点，原有业务代码通常不需要大规模重写。迁移后的用量会根据部署类型计入Azure订阅。
适合哪些开发者？
-
已经准备将AI应用投入生产；
-
需要多模型目录；
-
需要企业权限和审计；
-
需要稳定配额；
-
已经在使用Azure；
-
希望统一管理模型、数据库和云服务。
基本迁移流程
创建或确认Azure订阅
↓
进入Microsoft Foundry
↓
创建项目和模型资源
↓
部署需要使用的模型
↓
获取新端点和认证信息
↓
替换原GitHub Models配置
↓
测试响应、Token和速率限制
需要注意，GitHub Models以前已经预先配置好可用模型，而Foundry需要开发者先选择并部署模型，之后才能在代码中调用。不同区域能够部署的模型也可能不同。
四、路线二：迁移到GitHub Copilot
如果原来使用GitHub Models的主要目的，是比较模型、理解代码、修改仓库或辅助开发，那么不一定需要迁移到一个新的模型API平台。
这种情况更适合直接使用GitHub Copilot。
目前Copilot可以在GitHub、IDE、CLI和桌面应用中完成：
-
阅读项目代码；
-
修改多个文件；
-
处理Issue；
-
运行终端命令；
-
编写和检查代码；
-
进行Agent开发任务；
-
在不同模型之间切换。
Copilot App已经向所有Copilot套餐开放，包括Copilot Free。没有Copilot订阅的用户，也可以通过BYOK连接自己的模型提供商。
GitHub Models与Copilot的区别
GitHub Models
→ 提供模型目录和推理API
→ 更接近通用模型试验平台
GitHub Copilot
→ 直接理解代码仓库
→ 在IDE和终端中完成开发任务
→ 更接近日常编程Agent
如果项目并不需要自行开发AI接口，只是希望让AI帮助写代码，迁移到Copilot通常更简单。
五、路线三：通过BYOK连接自己的模型
GitHub Models停止后，BYOK功能并没有完全消失，而是被整合到了Copilot产品中。
Copilot App目前可以连接：
-
OpenAI；
-
Anthropic；
-
Azure OpenAI；
-
Microsoft Foundry；
-
Ollama；
-
LM Studio；
-
OpenAI兼容接口。
添加模型提供商后，可以在模型选择器中直接选择对应模型。API Key保存在本地操作系统的密钥链中。
Copilot CLI同样支持连接Azure OpenAI、Anthropic及其他OpenAI兼容端点，也支持Ollama、vLLM和Foundry Local等本地模型。使用自己的提供商时，可以继续使用Copilot的终端Agent体验，同时由模型提供商直接计算调用费用。
BYOK更适合哪些情况？
-
已经有OpenAI或Anthropic API账号；
-
希望自己选择模型；
-
需要按Token控制费用；
-
不想把模型调用全部绑定在Copilot套餐中；
-
需要使用公司自己的云账户；
-
需要连接内部模型网关。
使用BYOK后，GitHub只负责提供开发交互界面，模型账单、配额、地区和数据规则由实际模型服务商决定。
六、路线四：直接迁移到模型厂商API
如果原来的项目只是通过GitHub Models调用某个固定模型，也可以跳过中间平台，直接使用模型厂商API。
例如：
-
OpenAI API；
-
Anthropic API；
-
Gemini API；
-
Azure OpenAI；
-
其他OpenAI兼容服务。
Gemini API目前支持Python、JavaScript和REST调用，也提供文本、多模态、工具调用和Agent等能力。
直接连接模型厂商的优点是：
-
API文档更新更及时；
-
可以第一时间使用新模型；
-
价格和Token账单更直接；
-
不依赖GitHub的中间接口；
-
更容易排查模型侧报错。
缺点也很明显：
-
不同厂商的SDK和字段不完全一致；
-
需要分别管理API Key；
-
账单分散；
-
切换模型时可能需要修改代码。
如果未来可能频繁切换模型，建议在项目中增加一层统一接口，不要把某一家厂商的请求格式写死在业务代码里。
七、路线五：迁移到其他云模型平台
如果项目本来就运行在其他云平台，也没有必要为了接替GitHub Models专门迁移到Azure。
Amazon Bedrock
Bedrock可以通过控制台和API访问多家基础模型，并支持OpenAI兼容API、Anthropic Messages API以及AWS自己的Converse API。
更适合：
-
已经使用AWS；
-
需要IAM权限管理；
-
需要在AWS内部统一结算；
-
希望同时使用多家模型。
Gemini API或Google Cloud
如果应用大量使用Google Cloud、Firebase或Google生态，可以直接使用Gemini API，减少跨云管理成本。
选择云平台时，不要只比较单次Token价格，还要考虑：
-
项目部署在哪个云；
-
数据所在区域；
-
网络延迟；
-
权限体系；
-
日志和监控；
-
团队是否熟悉该平台；
-
账单是否容易统一。
八、本地模型适合替代GitHub Models吗？
部分场景可以，但不能简单理解成完全替代。
Copilot CLI现在支持Ollama、vLLM和Foundry Local等本地模型，还可以在离线模式下关闭GitHub遥测，只与本地配置的模型通信。
本地模型适合：
-
代码不能上传到外部平台；
-
网络环境受限；
-
需要离线运行；
-
调用量较大且硬件充足；
-
可以接受自行维护模型。
但开发者需要自己承担：
-
GPU或服务器成本；
-
模型更新；
-
推理速度；
-
并发管理；
-
安全维护；
-
上下文和工具调用兼容性。
个人开发者如果只是偶尔调用模型，云API通常比专门部署GPU服务器更省事。
九、迁移时不要只换API地址
一次完整迁移，至少要检查以下内容：
1. 模型是否仍然可用
同名模型在不同平台上的版本、上下文长度和区域可能不同。
2. 请求参数是否兼容
重点检查：
-
model； -
max_tokens或max_output_tokens； -
Tool Calling；
-
JSON结构化输出；
-
流式响应；
-
图片和文件输入。
3. 重新设置API Key
不要继续沿用已经失效的GitHub Models Token。
新的密钥应放在环境变量或密钥管理服务中，不要提交到Git仓库。
4. 重新测试费用
即使模型名称相同，不同平台的输入、输出、缓存、工具和批处理价格也可能不同。
5. 增加备用模型
不要再把应用绑定到单一模型接口。
可以预留：
主模型不可用
↓
切换同平台备用模型
↓
切换第二模型提供商
↓
返回降级结果
6. 重新设置预算预警
迁移后，费用可能从GitHub账单转移到Azure、OpenAI、Anthropic或其他云平台，需要重新设置：
-
月度预算；
-
费用提醒；
-
Token上限；
-
API Key权限；
-
自动停机规则。
十、迁移后的付款和账单怎么管理？
GitHub Models停止后，最大的变化之一，是账单可能不再集中在GitHub。
例如，一个开发者可能同时产生：
GitHub Copilot订阅费
Microsoft Foundry模型费用
OpenAI或Anthropic API费用
其他SaaS工具订阅费
如果全部绑定在同一张付款卡上，后期不容易判断某笔扣款属于哪个项目。
个人开发者或小团队可以按用途拆分：
| 付款用途 | 建议管理方式 |
|---|---|
| GitHub Copilot | 单独记录固定订阅费 |
| 模型API | 设置月度预算和Token预警 |
| 测试项目 | 使用较低额度 |
| 生产项目 | 独立付款方式和告警 |
| 临时工具 | 项目结束后及时取消 |
在目标平台支持虚拟卡的前提下，也可以按照平台或项目分配不同卡片。
例如：
GitHub及开发工具 → 一张卡
模型API费用 → 一张卡
测试项目 → 一张低额度卡
正式业务 → 独立付款卡
这样做的好处是：
- 某个平台费用异常时更容易定位；
- 可以分别设置卡片额度；
- 项目停止后可以单独停用对应卡片；
- 避免一张卡失效影响全部开发工具；
- 月底进行费用归集时更加清楚。
如果同时使用多个海外AI工具和开发者服务，可以了解MXK8虚拟卡的项目分卡和海外软件订阅场景。开卡前建议先说明目标平台、账号地区、结算币种、预计消费金额以及是否需要自动续费，由服务人员确认具体适用范围。
需要注意，虚拟卡只是付款和账单管理工具，不能替代模型平台自身的Token限额、预算预警和API权限控制。最终是否能够付款成功，也会受到平台规则、卡片类型、发卡地区和支付验证方式影响。
十一、个人开发者怎么选？
可以直接按照这个判断：
只想让AI辅助写代码
→ GitHub Copilot
正在开发需要上线的AI应用
→ Microsoft Foundry或现有云平台
只使用一个固定模型
→ 直接连接模型厂商API
需要在多个模型之间切换
→ Copilot BYOK或统一模型网关
代码不能发送到外部平台
→ 本地模型
已经深度使用AWS或Google Cloud
→ 优先使用对应云模型服务
不要为了追求“平台最多”同时开通所有服务。先根据业务选择一个主平台，再准备一个备用接口，通常已经足够。
十二、总结
GitHub Models停止服务后，没有一个适合所有开发者的统一替代方案。
更合理的选择是：
-
GitHub内的编程任务迁移到Copilot；
-
生产级AI应用迁移到Microsoft Foundry或现有云平台；
-
固定模型调用直接连接模型厂商API；
-
多模型开发使用BYOK或统一网关；
-
高隐私场景考虑本地模型。
迁移时不要只修改API端点，还要重新检查模型版本、请求参数、密钥管理、费用预算和备用模型。
从长期来看，最重要的不是找到一个与GitHub Models界面完全相同的平台，而是让自己的应用不再依赖某一个模型、某一个端点或某一种付款方式。这样下一次模型下线或平台调整时，迁移成本才不会再次失控。
扫一扫
437
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
