OC
微软 AI 销售多数来自 OpenAI:把合作伙伴采购当客户增长有多危险
科技 · 2026-08-06 · 产业与资本 · 阅读 11

微软 AI 销售多数来自 OpenAI:把合作伙伴采购当客户增长有多危险

作者:陈墨|OC 产业与资本编辑

作者 陈墨 陈墨

Bloomberg 根据微软新披露的信息计算,微软截至 6 月的财年从 OpenAI 取得 241 亿美元销售额。Satya Nadella 此前称,微软 AI 业务在 3 月季度末的年化收入速度约为 370 亿美元。

一句话结论:微软确实把 AI 变成了数百亿美元业务,但其中很大部分来自自己投资的模型伙伴购买 Azure 算力;这笔收入真实存在,却不能与大量独立企业采用 Copilot 视为同一种需求。

首先要拆开两个口径。241 亿美元是一个完整财年中来自 OpenAI 的已披露销售额,370 亿美元则是 3 月季度末把当时收入速度年化后的指标。二者期间和计算方法不同,不能直接相除得出精确占比;Bloomberg 的“多数”结论来自对公司多项披露的综合判断。

OpenAI 是微软的客户,也是长期被投资方和技术供应商。它购买 Azure 训练和运行模型,微软又把这些模型放进 Copilot 与云服务中销售。云采购为微软形成收入,投资价值和合作条款又会影响利润,单看“AI 销售”容易把循环关系当成完全外部市场需求。

投资模型授权云采购和Copilot销售组成相互连接但口径不同的商业循环

客户集中并不等于收入虚假。OpenAI 的训练和推理确实消耗数据中心、电力和芯片,微软也需要交付相应服务。风险在于,OpenAI 自 2026 年 4 月起获得更多非微软云选择,微软也不再向 OpenAI 支付自身收入分成。合作从独家绑定变成更松散结构后,这部分销售增长未必继续按原速度留在 Azure。

微软正在主动降低依赖:发展自研模型和芯片,引入 Anthropic,并让 Copilot 支持多种模型。但企业客户是否为这些产品持续付费,应该通过 Copilot 付费席位、独立客户消费、推理毛利和续约率判断,而不是用一个包含 OpenAI 大额采购的总收入指标代替。

对投资者来说,这也改变资本开支的解释。如果数据中心先由 OpenAI 合同填满,短期利用率更有保障;如果合作伙伴融资、模型份额或云选择变化,微软既要承受折旧,也要寻找新的外部负载。账最后仍会回到资产利用率和现金流。

关键事实

  • 微软披露截至 6 月的财年从 OpenAI 获得 241 亿美元销售额
  • Nadella 此前给出的 370 亿美元是 AI 业务年化收入速度,不是同期间全年收入
  • OpenAI 同时是微软客户、被投资方和模型供应商,交易关系具有循环性
  • 2026 年 4 月合作条款调整后,双方都获得了更多非独家选择

OC 判断

微软 AI 业务的规模已经足够大,问题转向收入质量。把关联伙伴的大额云采购与成千上万企业客户的稳定订阅拆开,才能判断需求是否分散、毛利是否可持续。收入不是假的,但“谁在付账”会决定风险。

为什么重要

  • 对企业:微软拥有多模型能力不代表 Copilot 的产品价值已经由独立客户充分验证。
  • 对投资者:应关注 OpenAI 客户集中度、Azure 利用率和 AI 服务毛利,而不只看年化销售额。
  • 对行业:模型公司与云厂商互相投资和采购,会让 AI 市场规模出现重复计算风险。

参考来源

相关阅读

基于标题、摘要和正文内容自动匹配。

更多科技

评论

围绕这篇文章补充信息、提出问题或分享观察。

0
暂无评论。

发表评论

继续看看 OC 用户围绕这个话题说了什么、做了什么。

相关帖子

更多

做 AI 语音产品时,授权、撤回和审计日志应该怎么落地?

<p>最近看到越来越多关于声音授权的讨论。对开发者来说,真正麻烦的往往不是“模型能不能模仿”,而是授权如何进入系统、生成结果如何追溯,以及授权撤回后该怎么办。</p> <p>我们在做 FlowSpeech 时也碰到过类似问题。我的体会是,不要把“用户勾选过同意”当成一个布尔字段,而应该把它做成一组可以审计的业务对象。</p> <h2>1. 把声音资产和授权分开</h2> <p>声音文件只描述技术属性,例如哈希、上传者、存储位置和创建时间。授权记录则至少要包含授权主体、用途范围、地域、有效期、来源证据和当前状态。这样同一份声音用于个人试听、商业广告、公开播客时,可以绑定不同的授权,而不是共用一个模糊的 consent=true。</p> <h2>2. 每次生成都保存授权快照</h2> <p>生成任务不要只引用当前授权 ID。授权内容以后可能变更,如果任务只查最新状态,历史结果就无法解释。更稳妥的做法是在任务创建时保存授权版本、文本哈希、声音版本、模型版本和操作者。生成出的音频再记录 artifact_id,并反向关联任务。</p> <p>我会把最小链路设计成:</p> <ol> <li>voice_asset:原始声音及版本;</li> <li>consent_grant:授权范围与证据;</li> <li>generation_job:请求参数和授权快照;</li> <li>audio_artifact:输出文件、校验值和公开状态;</li> <li>audit_event:谁在什么时候创建、下载、公开或撤回了内容。</li> </ol> <h2>3. 撤回不是简单删除一行</h2> <p>授权撤回后,系统至少要阻止新任务,并把相关公开音频进入下架队列。已经交付给客户的文件是否能删除,要按照合同和产品能力区分,不能在界面上承诺技术上做不到的“全球删除”。更现实的状态机是 active、suspended、revoked、expired,并明确每个状态允许哪些动作。</p> <h2>4. 对外展示也要可验证</h2> <p>除了后台日志,公开音频最好带上来源标记或可查询的生成记录。水印不是万能方案,但“可识别的音频 + 可验证的元数据 + 清晰的举报入口”组合起来,比一句“AI 生成”更有用。</p> <p>我们现在做的 <a href="https://flowspeech.io/zh">FlowSpeech</a> 主要解决上下文感知、情绪和停顿控制。越往产品化走,越觉得声音效果只是前半程,权限边界和可追溯性才决定这类工具能不能长期使用。</p> <p>大家在实际项目里会把授权证据放在业务数据库、对象存储,还是单独的审计系统?如果授权撤回,你们通常怎么处理已经生成并交付的音频?</p>

FlowSpeech 0 1

你们的Codex额度提前耗完了没?戒断反应如何?

<p>我在第三天就消耗了只剩1%,忍了一天,然后今天干脆用这最后的1%,开着5.6 Sol 极高 强推我一个提示词笔记本应用的功能落地。最终用时3小时,居然还是跑完了。但是现在还是出现一些戒断反应,感觉啥也做不了,就无精打采的,困。</p> <p>我做了一个Prompt Notebook,专门用来收藏或者记录自己手搓的生图提示词。带Chrome一键收藏插件。支持AI优化提示词。支持提示词中提取常用字段作为提示词百科词汇。也自带生图功能用来测提示词。但是要搭配Cloudflare R2+Worker的图床。</p> <p>今天主要是做一个AI模特的资产库。将常用的AI模特固定下来,进行身份设定,以及模特的一些角色定妆图。之后生图可以直接调用AI模特自动作为垫图。</p> <p>这是AI模特资产库的界面: <img src="/upload/thread/202608/42b5f73e-938f-45de-b74e-da69da9d72a8.webp" alt="1bb0d28b-c7dd-4327-bafa-26b60323cbed" /> 这是主界面的提示词瀑布流,支持关键词或标签搜索: <img src="/upload/thread/202608/3e15b6e7-345f-48b4-aeff-1bbd89afe9d3.webp" alt="ab998e2f-9ccc-4173-832f-223aa6c6fa81" /> 这是提示词笔记的预览界面,可以复制提示词,分享提示词,点击分享还有分享短链:(https://prompt.jintao.co.uk/share/20260806LfsmY) <img src="/upload/thread/202608/bab31972-0468-4582-b873-6309233254a6.webp" alt="20260806-201213" /> 可惜现在没额度了,我又不想换模型折腾。现在还有些界面细节和小功能需要落地完善,可能还要虫子要抓。弄好了,打算放GitHub开源。</p> <p>有朋友想试试的么?</p>

shynloc 2 4

一个体会,Codex 这种现代 Agent,每天一个变,几天不用就有新惊喜

<p>当然我说的也包括 Claude Code,新功能日新月异,还有就是 AI 能力提升以后,可以做的东西日新月异。还有各种工作流方法日新月异。</p> <p>更好玩的是,我最近经历过很多次,你跟人介绍现在 Codex 可以做到什么样子,他们都觉得很厉害。但是你现场一演示,他们的震撼就更加完全不同了。所以,这种东西,需要大量的 Workshop 去沟通交流,光看文字很难讲清楚,直播、视频也越来越重要了。</p>

tinyfool 1 89