零一万物开放平台进入关停倒计时

零一万物大模型开放平台正式进入关停倒计时。

8 月 10 日，零一万物宣布调整面向开发者和普通用户的开放平台服务：即日起停止新用户注册与余额增购，2026 年 9 月 3 日 24:00 起停止模型在线体验、API 调用及相关服务，账户余额退还申请则开放至 12 月 3 日 24:00。

大模型开放平台是向开发者提供模型试用、API 接入、用量计费和账户管理的一站式服务。 对已经把 Yi 系列模型接入生产环境的团队来说，这次变化并不是一次普通的产品改版，而是底层模型供应商退出公共开发者服务：业务如果不迁移，最迟在 9 月 3 日之后就可能无法继续获得模型响应。

IT之家援引零一万物公告称，此次调整源于公司产品与服务体系升级，以及进一步聚焦企业级人工智能解决方案。官方表示会预留过渡期，并提供余额退还和账号处理通道。

三个时间点，真正关键的是 9 月 3 日

零一万物此次服务调整分为停止新增、停止调用和结束退款三个阶段。 截至今天，距离模型体验与 API 正式停止只剩约 24 天，这个窗口对于个人项目尚算充裕，但对有回归测试、合规审批和灰度发布流程的企业应用并不宽松。

| 时间节点 | 平台变化 | 用户仍可进行的操作 | 开发者建议 | |---|---|---|---| | 2026 年 8 月 10 日起 | 停止新用户注册及余额增购 | 账号登录、账单查询、调用明细查询 | 立即盘点密钥、模型、用量和依赖业务 | | 2026 年 9 月 3 日 24:00 起 | 停止模型在线体验、API 调用及相关服务 | 公告未承诺完整保留所有历史查询能力 | 在此之前完成生产流量切换和数据导出 | | 2026 年 12 月 3 日 24:00 前 | 余额退还申请窗口继续开放 | 按平台指引提交申请和账号处理材料 | 不要把余额处理拖到窗口最后几天 |

9 月 3 日才是技术团队必须盯住的硬截止时间。 12 月 3 日只是余额退还窗口的结束日期，不能被理解为 API 还能继续使用三个月；从 9 月 3 日到 12 月 3 日相隔约 91 天，这段时间主要用于财务和账户善后，而不是业务迁移。

平台暂时保留账单与调用明细查询，不等于这些数据会被无限期保存。 公告没有披露 9 月 3 日之后查询页面的长期可用性，也没有给出历史日志的统一保留周期，因此更稳妥的做法是在迁移前导出账单、调用明细、错误记录、模型参数配置和内部评测结果。

这不是模型下线，而是公共平台退场

此次关停针对的是面向用户的开放平台服务，并不等同于零一万物停止所有模型研发或企业业务。 现有公告明确提到在线体验、API 调用和账户相关服务，但没有宣布 Yi 开源模型仓库消失，也没有表示公司退出基础模型或 AI Agent 研发。

API 是应用程序之间按约定格式交换请求与结果的接口。 对大模型应用而言，API 不只是一个网络地址，它还绑定模型名称、上下文长度、并发限制、流式输出、结构化结果、工具调用、内容安全策略和计费方式；即便替代平台采用相似的请求格式，也不能据此判断迁移可以无测试完成。

在线体验与生产 API 的影响范围也不相同。 前者主要影响临时试用、Prompt 调试和模型展示，后者则可能直接影响客服机器人、知识库问答、内容生成、数据抽取、工作流 Agent 等线上功能。一个内部演示页面失效通常可以延期处理，但嵌入业务流程的模型调用一旦中断，就可能导致订单审核、报告生成或客户响应链路整体阻塞。

现阶段也不应把此次调整解读为 Yi 系列模型本身被彻底放弃。 零一万物在 2024 年形成过开源与闭源并行的产品布局，开源侧包括 Yi-1.5 的 6B、9B 和 34B 版本，闭源侧则推出过 Yi-Large，并围绕模型构建个人生产力产品和开发者平台。2026 年的公告改变的是公共服务交付方式，而不是自动撤销此前发布的模型资产。

从抢开发者到做企业项目，方向已经反转

零一万物两年前还在积极争夺公共 API 市场，如今的选择已经明显转向高客单价企业项目。 2024 年 OpenAI 调整部分地区服务范围后，零一万物曾推出“Yi API 二折平替计划”，向新客户提供 100 元试用额度，购买额度可额外增加 50%，并宣称部分从 GPT-4 Turbo 迁移至 Yi-Large-Turbo 的场景成本能够下降 90% 以上。

两年前的竞争核心是低价格、兼容性和迁移速度，两年后的竞争核心变成了行业数据、交付能力与经营结果。 零一万物当前对外强调的产品包括老板 AI、销冠 AI、投资官 AI、万智企业大模型平台，以及制造、能源、供应链、农业和教育等行业方案，这套产品组合已经不是典型的“开发者选择模型并按量调用”逻辑。

企业级 AI 解决方案是围绕特定组织的数据、流程和业务目标交付的完整系统。 它通常包含模型、知识库、Agent、权限体系、数据治理、系统集成和持续运营，而不是只提供一个通用模型接口。企业客户购买的也不只是若干 Token，而是销售转化率、决策效率、风险识别速度等可衡量结果。

FDE 共创是零一万物企业战略中的重要交付方式。 FDE 即前沿部署工程师，指深入客户现场，把模型能力与真实业务系统、数据和流程连接起来的工程角色；这种模式比公共 API 更重，但更容易形成长期合同、组织协同和行业壁垒。

公共 API 商业模式没有失效，但它对独立模型公司的规模与运营能力要求越来越高。 大型云厂商可以把模型服务与算力、数据库、对象存储、网络、安全和企业采购体系捆绑销售，模型调用本身即便利润有限，也能带动整套云资源消费。独立模型公司则需要单独承担推理成本、服务稳定性、开发者支持和持续降价压力。

零一万物此次退场更像是资源重新集中，而不是一次单纯的技术故障。 公共开发者市场需要稳定的模型迭代节奏、可预测的价格、充足的并发资源和长期服务承诺；企业方案则允许厂商围绕少数高价值客户深度交付。对零一万物而言，后者显然更符合当前的产品叙事，但对依赖其公共平台的开发者而言，这也意味着供应连续性预期被重新定价。

开发者不能只替换模型名称

迁移期是旧服务仍然可用、用户需要把业务切换到新系统的有限时间窗口。 零一万物给出的迁移期约为 24 天，因此生产用户现在就应该把原平台视为进入弃用状态，而不是继续增加新的业务依赖。

第一步是建立完整的依赖清单。 技术团队需要查清哪些应用正在调用 Yi 模型、使用了哪些模型版本、每天消耗多少输入和输出 Token、峰值并发是多少、是否启用了流式响应，以及失败后有没有降级逻辑。密钥存在配置中心、自动化工作流或第三方 SaaS 中的情况，也应一并核对。

第二步是保存平台侧数据和内部配置。 建议至少留存以下内容：

• 历史账单、调用明细和余额截图；
• 模型名称、温度、最大输出长度、停止词等参数；
• 系统提示词、Prompt 模板和结构化输出约束；
• 典型成功样本、失败样本与人工修正记录；
• 超时率、首字延迟、完整响应时间和错误码统计；
• 与知识库、搜索、工具调用相关的编排配置。

第三步是用真实业务样本做替代模型评测。 通用跑分只能说明模型在标准题库上的能力，不能证明它适合企业自己的合同抽取、客服回复或投研总结。更可靠的方法是从生产日志中脱敏抽取 100 至 500 条代表性任务，分别比较正确率、格式遵循率、人工接受率、延迟和单次任务成本。

第四步是检查接口之外的行为差异。 不同模型对系统提示词的服从程度、JSON 输出稳定性、工具参数生成方式、敏感内容处理和超长上下文截断策略可能完全不同。一个在 Yi 模型上稳定返回固定字段的 Prompt，换模型后可能增加解释文字、遗漏字段，甚至改变日期和数字格式。

第五步是采用灰度切流而不是一次性替换。 较稳妥的节奏是先导入 5% 非关键流量，观察错误率和响应时间，再逐步提高到 20%、50% 和 100%；如果业务涉及财务、医疗、法律或关键经营决策，还需要保留人工复核和快速回滚能力。

替代方案要看连续性，不要只看单价

开发者选择下一家模型服务时，服务连续性应该与模型能力放在同等位置。 此次事件已经说明，最低的每百万 Token 价格并不代表最低的长期成本；如果半年后再次迁移，重新评测、修改 Prompt、处理故障和协调业务部门的隐性成本可能远高于推理费用差额。

| 迁移路线 | 主要优势 | 主要风险 | 更适合的用户 | |---|---|---|---| | 大型云平台的模型服务 | 采购体系成熟，通常具备监控、权限、合规和资源配套 | 平台绑定较深，不同产品的模型更新节奏不一致 | 已有云资源和企业采购合同的团队 | | 独立模型厂商开放平台 | 模型迭代直接，产品决策速度通常较快 | 需要重点评估长期运营、容量和服务承诺 | 对特定模型效果敏感的应用 | | 开源模型本地或专有环境部署 | 数据控制能力强，可自行固定模型版本 | GPU、推理优化、监控和运维成本较高 | 有基础设施团队或严格数据要求的企业 | | 企业级定制方案 | 可深入接入组织数据与业务流程 | 实施周期长，前期需求梳理和交付成本高 | 有明确 ROI 场景的大中型客户 |

总成本应按完整业务链路计算，而不是只比较输入和输出单价。 一套实际的成本模型至少要加入缓存、向量检索、联网搜索、推理加速、失败重试、峰值容量、内容审核、日志存储和工程维护费用。对 Agent 应用来说，一次用户请求可能触发多轮模型调用，标价便宜 30% 的模型未必能让最终任务成本降低 30%。

双供应商设计值得从可选项变成生产系统的默认能力。 应用内部可以建立统一的模型适配层，把业务逻辑与特定厂商的模型名称、请求字段和错误码分开，并为关键任务准备经过评测的备用模型。适配层不能消除模型行为差异，但能把下一次切换从全面重构降为可控的配置和测试工作。

模型版本也需要像数据库和依赖库一样被锁定和审计。 团队应记录每次上线使用的具体模型、Prompt 版本、评测集结果和发布日期，避免供应商更新默认模型后，线上输出悄然发生变化。对于无法固定模型版本的平台，则应建立定期回归评测和告警机制。

对个人用户和企业用户，处理优先级不同

个人开发者的首要任务是导出记录并避免继续沉淀新项目。 如果只是偶尔使用在线体验，可以在 9 月 3 日前保存重要对话、Prompt 和结果；如果运行机器人、插件或自动化任务，则需要尽快替换依赖，避免截止日当天集中处理。

小型团队的首要任务是找出没有降级方案的核心链路。 很多项目表面上只有一个模型调用，实际却把摘要、分类、检索改写和最终回答都交给同一供应商，一旦接口不可用，整条工作流都会失败。团队应优先迁移直接面向客户、影响收入或每天自动运行的任务。

企业用户的首要任务是同时启动技术、法务和财务流程。 技术部门负责评测与切流，法务和安全团队确认新供应商的数据处理方式，财务部门则核对账单与余额退还材料。若等技术迁移结束后才启动采购审批，24 天很可能不够走完整个流程。

一次明确的战略收缩，也是一次供应商风险提醒

零一万物关闭公共开放平台，意味着其增长重心已经从广泛服务开发者转向深度服务企业客户。 这种选择未必对公司不利：在模型价格持续下探、云厂商掌握基础设施入口的市场里，聚焦高价值行业和经营决策场景，可能比维持一个面向所有开发者的平台更容易形成收入与交付闭环。

这次调整对现有用户却很难算利好。 官方提供了明确时间表和约三个月的余额处理窗口，程序上留出了善后空间；但 API 用户真正可用的技术迁移时间只有约 24 天，对已经进入生产环境的企业服务来说仍然偏紧。

开发者现在最合理的动作不是等待更多解释，而是立即开始迁移。 8 月 10 日完成资产盘点，8 月中旬确定候选模型并建立评测集，8 月下旬开始灰度切流，9 月 3 日前完成旧平台依赖清零，才是风险最低的安排。

零一万物的变化也再次提醒行业：模型能力决定应用能不能做出来，供应连续性决定应用能不能长期运行。 下一次选择模型供应商时，除了效果、速度和成本，服务期限、版本策略、数据导出、退出机制和备用方案都应该进入同一张评估表。

参考来源

• IT之家：零一万物开放平台将逐步停止在线体验与 API 等服务——整理了零一万物 2026 年 8 月 10 日公告及三个关键时间节点。