首页 文章 精选 留言 我的

精选列表

搜索[AI填充],共10000篇文章
优秀的个人博客,低调大师

GitHub 亲手关掉了自己的 AI 模型入口:留给开发者只剩 8 天

![](https://developer.qcloudimg.com/http-save/yehe-1566631/ba13d18d3d20009b6e84a57883b8ac88.png) 7 月 1 日,GitHub 在 Changelog 里发了一条只有一分钟阅读量的通知。 但这条通知的影响,比很多产品发布都大:**GitHub Models 将在 2026 年 7 月 30 日全面退役。** 不是停止拉新,也不是某几个模型下架。 Playground、模型目录、推理 API、BYOK 端点以及相关 UI,都会一起消失。GitHub 还特意强调,这次影响所有客户,包括仍在活跃使用的老用户。 从今天算起,迁移窗口只剩 8 天。 ## 最容易被低估的,不是“换一个模型” 很多团队最初使用 GitHub Models,只是为了快速试模型:用 GitHub 身份进入 Playground,挑一个模型,拿 Token 调几次 API。 问题是,Demo 一旦开始被内部脚本、CI 任务、评测平台或机器人调用,它就不再是 Demo。 真正形成的耦合至少有五层: - endpoint 写进了代码或配置; - GitHub Token 被当成模型服务凭据; - 模型 ID、参数和结构化输出依赖现有实现; - 限流、超时、重试策略按原服务调过; - 测试样本和效果基线默认原模型仍然存在。 所以这次退役不是“把 URL 换成 Microsoft Foundry”这么简单。GitHub 官方给出了 Foundry 和 GitHub Copilot 两个方向,但没有承诺它们是原接口的无损替代品。 ## 先花 30 分钟,把隐藏依赖全部找出来 不要先开迁移会,先在代码库和部署配置里搜索。 ``` rg -n "GitHub Models|models\.inference|MODEL_ENDPOINT|MODEL_ID|GITHUB_TOKEN|BYOK" . ``` 然后把结果按四类归档: 1. 生产调用:直接影响用户请求或业务任务。 1. 自动化调用:CI、定时任务、评测、内容生成。 1. 人工工具:开发者本机脚本、Notebook、内部页面。 1. 已废弃残留:代码还在,但已经没有真实流量。 这一步的价值不是统计文件数,而是找到**关停当天谁会先报错、报错后会不会自动重试、重试是否会放大故障**。 ![](https://developer.qcloudimg.com/http-save/yehe-1566631/0627afda90ac7675fe97d011a5a11087.png) ## 最小迁移改造:先做一个供应商适配层 如果业务代码里到处直接初始化某家模型 SDK,这次迁移会非常痛苦。 最小可行改造不是引入一个大框架,而是收口成一个足够小的接口: ``` typeModelRequest = { model: string; messages: Array; timeoutMs: number; }; typeModelResult = { text: string; usage?: { inputTokens: number; outputTokens: number }; provider: string; rawId?: string; }; interfaceModelProvider { invoke(request: ModelRequest): Promise; } ``` 业务只依赖 `ModelProvider`。鉴权、endpoint、模型参数映射、错误归一化和 usage 解析,都留在供应商实现内部。 这样做并不会自动解决迁移问题,但它能把后续风险从“改整个系统”缩小成“替换一个实现”。 ## 7 月 23 日的 brownout,应该被当成一次免费演练 GitHub 已安排两次短时服务中断。7 月 16 日已经过去,7 月 23 日还有一次。 在 brownout 期间,请求会临时返回错误,随后服务恢复。这不是普通维护窗口,而是一次接近真实关停的故障注入机会。 至少验证四件事: - 原模型调用失败后,应用是否在预期时间内超时; - 自动重试是否有次数、退避和总时长上限; - 替代模型能否接管,而不是返回另一种格式把下游打崩; - 告警能否明确指出供应商故障,而不是只报“业务接口 500”。 ![](https://developer.qcloudimg.com/http-save/yehe-1566631/3a0fe07f5f70cf57eb3cb0dede5bfbda.png) 一个危险的假成功是:请求重试几次后恢复了,于是大家认为系统扛住了。 但 7 月 30 日之后,旧入口不会恢复。真正要验证的是,**没有旧服务时,业务能否持续运行。** ## 不要只比较回答看起来像不像 模型迁移最常见的验收方式,是人工打开十几个结果,觉得“差不多”。这对生产系统远远不够。 建议保留一组脱敏黄金样本,同时记录: - 任务成功率; - JSON 或函数调用字段完整率; - P50、P95 延迟; - 超时、限流和重试比例; - 输入、输出 Token 与单次成本; - 需要人工兜底的比例。 如果模型用于分类、抽取、路由或生成测试数据,还要加入确定性的规则校验。不能把另一个模型的打分直接当成唯一结论。 ![](https://developer.qcloudimg.com/http-save/yehe-1566631/228eac44876f7b74ac65ca60022cf75c.png) ## 13 天,够不够? 如果只是一个没人使用的 Playground Demo,够。 如果已经进入生产,但依赖集中、样本完整、能灰度切流,也可能够。 如果 endpoint 散落在多个仓库、Token 所有人不清楚、没有成本监控、没有回归样本,那 13 天不是迁移周期,而是风险暴露周期。 我会把完成标准写得非常具体: 1. 所有生产流量已转到新入口。 1. 旧模型 Token 和 endpoint 已从部署配置移除。 1. 新旧结果差异有记录,有明确接受人。 1. 超时、限流、成本和失败率已经进入监控。 1. 回滚开关指向可用方案,而不是已经退役的 GitHub Models。 ![](https://developer.qcloudimg.com/http-save/yehe-1566631/5e27b2f81bcaa9c00f40b0114295258f.png) ## 最后 GitHub Models 的退出提醒了一件事:开发者体验再顺滑的平台入口,也可能快速结束生命周期。 真正可靠的不是“永远不会关停”的供应商,而是你的系统始终保留三种能力:供应商可替换、行为可回归、故障可降级。 这三件事如果现在还没有,7 月 30 日只是第一次提醒。 ## 参考资料 - GitHub Changelog:GitHub Models 将于 2026 年 7 月 30 日全面退役 - Microsoft Foundry

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册