Meta Token 激增让 Microsoft 成为其低调的 AI 供应商

据报道，Meta 每周通过 Microsoft 消耗数万亿 AI token，这使得 Llama 的开发者成为 Azure 最大的人工智能客户之一。

这一 Meta token 规模格外引人注目，因为 Meta 多年来一直在构建自己的模型、数据中心和开放权重 AI 战略。然而，该公司仍依赖让员工能够访问 OpenAI、Anthropic 及其他开发者竞争模型的基础设施。

Microsoft 则从这一逆转中获益。它不需要让每位客户都统一采用 Microsoft 的模型。无论企业是在比较模型、运行编程智能体，还是通过其托管平台调度工作负载，Azure 都能获得收入。

因此，核心矛盾不止于一份云服务合同。Meta 希望掌控其 AI 技术栈，而员工则希望立即使用最擅长处理当前任务的模型。

据报道的 Meta Token 规模改变了叙事

据报道，Meta 使用 Azure 并非为了进行有限试验。它已成为 Microsoft 托管 AI 模型的重要使用者。

8 月 20 日的一篇原始报道称，Meta 每年花费数亿美元，通过 Azure 获取模型访问权限。该报道援引了一位因事未公开姓名的知情人士。

据该消息人士称，Meta 每周通过该平台处理数万亿 token。Token 是 AI 模型在处理请求时读取或生成的文本小单位。

Meta 和 Microsoft 均未就该安排置评。这种沉默值得关注，因为头条数字仍仅归因于一位匿名消息人士，而非两家公司的公开披露。

该报道未说明确切的每周使用量、参与的 Meta 团队或模型组合。它也没有区分输入 token、生成的输出、缓存内容或重复的智能体活动。

这些差异可能实质性地改变任何 token 总量的成本与含义。一项漫长的编程工作流消耗的 token，可能远多于其可见答案所暗示的数量。

AI 智能体通常会在许多内部步骤中检查文件、生成代码、测试修改并修订工作成果。每一步都可能向模型发送额外上下文。

尽管如此，据报道的规模仍表明这是持续的生产级使用，而非偶尔的聊天机器人对话。即便“数万亿”所暗示的下限，也代表着极其庞大的模型交互次数。

这一时机也符合 Meta 内部更广泛的趋势。此前报道描述，员工每月通过内部 AI 工具消耗数十万亿 token。

Meta 一直鼓励工程师积极使用 AI，尤其是在软件开发中。编程是反复调用模型能够迅速累积的最典型场景之一。

该公司还试验过用于衡量员工 token 使用量的内部系统。此类追踪可以推动采用，但也可能让消耗量成为误导性的生产力替代指标。

更多 token 并不必然意味着更好的软件或更快的交付。一款配置不佳的智能体可能会反复检查同一代码仓库，却无法产出有用成果。

这种不确定性应影响读者对 Meta token 数字的解读。它衡量的是计算活动，而非商业价值。

不过，这一数字确实改变了竞争格局。Meta 不只是在构建专有 AI 供应商的替代方案；它也正通过 Microsoft 大规模购买这些供应商的访问权限。

这构成了本文的核心张力。这家在基础设施和模型层面追求独立的公司，在应用层面仍需要外部能力。

Meta 为何仍需要其他公司构建的模型

据报道，Azure 支出反映了这样一个现实缺口：拥有 AI 模型，并不等于能很好地满足每一位员工的工作流需求。

Meta 开发 Llama、运营大型计算集群，并将 Meta AI 嵌入其消费者服务。这些努力并不会自动让每位工程师在每项任务中都获得最佳工具。

编程助手需要的不只是一款强大的基础模型。它们还需要代码仓库访问、长上下文处理、工具执行、安全控制、身份管理和可靠可用性。

员工也会比较不同模型在规划、调试、研究和文档分析方面的表现。一款模型可能在某类工作负载中表现优异，却在另一类任务中遇到困难。

Azure 为企业买家提供了一条接入多个模型家族的托管路径。Microsoft 将其 Foundry 平台定位为围绕模型选择，而不是排他性依赖于单一供应商。

在 2026 财年第三季度电话会议上，Microsoft 表示，已有超过 10,000 名客户在 Foundry 上使用多个模型。该公司还称，Anthropic 和 OpenAI 模型的使用量均环比翻倍。

这些季度评论表明，即便客户自己开发模型，Microsoft 仍可受益。Azure 成为企业测试、治理和使用竞争性系统的控制层。

Meta 的内部模型战略解决的是另一个问题。Llama 让该公司能够影响模型架构、部署方式以及开放权重开发者社区。

开放权重模型会向开发者分发经过训练的参数，开发者可在其许可范围内运行或定制这些参数。但这并不能消除企业部署所需的运营工作。

大型企业必须管理容量、延迟、权限、数据边界和模型升级。与其为每个新兴模型调整内部系统，购买托管访问可能更快。

当 AI 模型排名快速变化时，这种权衡更为重要。员工可能偏好一款模型用于代码生成，另一款模型则用于复杂推理。

将他们限制在 Llama 上可以减少外部支出，但也可能拖慢那些使用其他模型效果更好的团队。

因此，Meta 面临一个经典的平台决策：它可以围绕内部控制进行优化，也可以保留选择空间，并接受对外部供应商的依赖。

据报道，Meta 的选择偏向于访问能力。它似乎愿意向 Microsoft 付费，而不是强制所有工作流都使用自有模型和基础设施。

这并不能证明 Llama 失败了。消费者助手、推荐系统、广告产品和内部编程工具有着不同的技术要求。

这一决定反而表明，模型所有权和模型消费已发生分离。一家公司可以创建重要的模型家族，同时仍是其竞争对手的重要客户。

Meta token 激增正是这种分离的结果之一。Meta 的员工可以使用托管平台提供的任何模型，即使这些选择会壮大另一家公司的 AI 业务。

当客户拒绝只选一个模型时，Microsoft 获胜

Microsoft 的优势并不局限于拥有一款胜出的模型。市场不愿收敛到单一选择时，它同样能够获利。

这个故事中显而易见的对立，是 Meta 推动 AI 独立性，与 Microsoft 成为难以绕开的模型市场之间的冲突。

Meta 希望进一步掌控计算、模型和产品分发；Microsoft 则希望 Azure 持续成为企业访问和管理几乎所有所需模型的场所。

这些目标并不直接互斥。当 Meta 的需求为 Microsoft 带来收入、使用数据和企业 AI 分发方面的影响力时，它们便形成竞争关系。

Microsoft 的模型目录涵盖专有系统和开放权重系统。客户可以通过统一的云服务关系，为不同工作负载调度模型，而无需分别协商基础设施安排。

这种方式降低了押注单一实验室的战略风险。如果 OpenAI 在某项基准测试中失利，或 Anthropic 更适合编程，Azure 仍可继续服务客户。

Microsoft 在财报电话会议中强调了这种广度。该公司表示，Foundry 客户正在使用 OpenAI、Anthropic、开源和区域性模型。

它还称，超过 300 家客户有望在当年处理逾一万亿 token。Meta 据报道的每周消耗量，将远远超过这一年度门槛。

这些数字并非完全可比。Microsoft 的公开表述指的是达到年度基准的客户，而 Meta 的报道描述的是每周总活动量。

不过，这种对比仍说明了 Meta 可能的规模。据报道的工作负载，即使置于 Microsoft 不断扩大的企业客户群中，也会使其成为使用强度异常高的客户。

Microsoft 也在构建自有 MAI 模型，并为第一方产品调整 OpenAI 技术。但 Azure 并不要求这些系统在每次技术比较中都获胜。

云平台凭借处理访问、计费、安全和容量来巩固自身地位。这与早期云竞争类似，当时基础设施供应商也能从自己并不拥有的软件中获利。

这一地位给 Amazon 和 Google 带来压力。两者都提供广泛的模型目录、托管 AI 服务和自有基础模型。

Amazon 已将 Anthropic 置于其战略核心，而 Google 则将 Gemini 与 Vertex AI 平台结合。Microsoft 可以通过跨多个模型家族分布的客户需求来应对。

Meta 的存在强化了这一叙事，因为它并非传统企业买家。它是另一家拥有庞大内部基础设施的超大规模科技公司。

据报道，Meta 决定购买模型访问权限，表明即使对于能够自行构建庞大系统的企业，云平台仍具价值。

Microsoft 还可以利用聚合需求，为更多数据中心和加速器采购提供依据。更高的利用率会改善那些原本昂贵且利用不足的容量的经济性。

这种优势也伴随风险。Microsoft 必须确保足够的计算资源可用，管理供应商关系，并防止模型访问沦为低利润率的大宗商品。

目前，据报道的 Meta token 消耗支持了其市场战略。Microsoft 无需说服 Meta 用单一受 Microsoft 控制的模型取代 Llama，便可赢得交易。

Meta 的 AI 独立性存在昂贵的例外

这种逆转在于，Meta 的规模并未消除对外部的依赖，反而使获得每一款有用模型的访问权限更具价值。

Meta 已构建了一些全球最大的 AI 训练系统。其自身的基础设施介绍称，数十个 AI 集群正为数百个团队和数千项日常训练任务提供服务。

这些基础设施支持推荐系统、广告、生成式产品和模型开发。Meta 计划部署相当于数十万张先进 GPU 的容量。

这些资源本应让 Meta 比大多数公司更少依赖外部云服务。Azure 报道说明，这一结论过于简单。

训练和推理是不同的工作负载。训练用于创建或更新模型，而推理则运行现有模型以响应请求。

Meta 可以拥有大量训练基础设施，同时购买其无法控制的模型的推理访问权限。它也可以在内部供应无法满足短期需求时使用外部容量。

该公司不断扩大的 AI 预算为此提供了更多背景。根据其最新的支出展望，Meta 预计 2026 年资本支出将在 1300 亿至 1450 亿美元之间。

这笔投资覆盖的远不止模型训练。数据中心还需要网络、电力、冷却、存储和服务器，而这些设施的部署都需要时间。

外部模型访问可以弥合员工需求与内部算力之间的缺口。它也让 Meta 无需等待自家模型在每一项专业能力上都实现匹配。

这正是核心转变。更大的内部投入，并未造就一个封闭且自给自足的环境。

相反，激进的采用策略带来了超出单一模型家族所能满足的需求。Meta 在同一条 AI 供应链中同时扮演竞争者和客户的角色。

这种安排类似于云计算的早期阶段。大型科技公司一边建设内部基础设施，一边为特定服务或需求高峰租用外部容量。

AI 又增加了一层复杂性，因为租用的资产不仅是服务器，还包括模型能力。员工关注的是输出质量、工具使用能力和可靠性，而非底层的所有权结构。

这带来了组织层面的挑战。Meta 必须决定，外部 token 是暂时的过渡方案，还是员工工作流中的长期组成部分。

如果使用是暂时的，内部模型和基础设施最终应吸收更多需求。如果这种使用持续存在，Microsoft 就将在 Meta 的 AI 运营中获得持久角色。

这一差异也会影响 Llama 的竞争意义。Llama 可以继续保持影响力，而不必成为 Meta 唯一的内部标准。

开放权重通过支持定制化和本地部署来吸引开发者。当托管的专有模型能够节省时间时，内部团队仍可选择它们。

对于开发者和企业买家而言，这也是一个有益的提醒：不要把模型战略视为单一供应商的决策。现实部署越来越多地涉及在多个系统之间路由任务。

这种路由也带来了自身的知识管理问题。团队必须跨工具保存提示词、决策、评估和输出。

可搜索的 AI knowledge base 可以帮助梳理这些上下文。不过，它无法解决底层模型支出是否带来可衡量生产力的问题。

这个问题的答案需要看结果，而不是 token 总量。

Token 数字无法证明什么

数万亿 token 表明了规模，但并不能证明 Meta 从其支出中获得了成比例的价值。

核心数据尚未得到任何一家公司验证。它们来自一名熟悉内部安排的匿名人士。

Meta 和 Microsoft 均拒绝置评，多个基本问题仍未得到解答。双方都没有披露确切模型、协商条款、工作负载或统计周期。

不同系统的 token 统计方式也可能不同。供应商可能以不同方式计算提示词、输出、缓存上下文、工具结果或内部推理。

因此，每周 token 总量无法直接换算为员工活动量。它也无法揭示其中有多少流量实际进入了生产系统。

部分使用量可能来自自动化评估。团队通常会将同一提示词发送给多个模型，以比较准确性、延迟和安全性。

其他流量可能来自反复读取大型代码库的编程智能体。这类系统在执行一项由工程师只需审查一次的任务时，就可能产生极其庞大的 token 数量。

缓存进一步增加了判断难度。供应商可以复用此前处理过的上下文，即使计费记录仍涉及大量 token，实际计算工作也会减少。

模型规模同样重要。较小的模型处理 token 所需的计算量，可能低于前沿推理模型。

因此，对能耗的估计应保持谨慎。Microsoft 自身的推理分析指出，单次查询的能耗取决于模型、硬件、软件、数据中心和工作负载特征。

该研究针对特定数量的对话式查询估算了能耗。它无法为 Meta 据称产生的流量提供可靠的换算依据。

成本数据也存在类似的不确定性。企业合同可能包含预留容量、折扣、承诺用量，以及不同模型的不同费率。

Meta 的年度支出和每周 token 数量不应被简单相除，以得出一个通用的单 token 成本。这样得出的结果会混合尚未披露的模型和合同条款。

生产力同样是一个问题。内部激励机制可能促使员工最大化可见使用量，而不是最大化有用产出。

基于 token 的排行榜可能会奖励冗长提示词和低效智能体。更好的评估方式应衡量已完成任务、被接受的代码、缺陷率和节省的时间。

安全与治理同样仍是关注点。向外部模型发送企业上下文，需要权限、数据控制、日志记录和保留政策。

Azure 可以提供受管理的边界，但管理并不能消除风险。Meta 仍须决定每种工具可以访问哪些代码库和文档。

因此，最有力的结论比标题所暗示的更有限。据报道，尽管拥有内部资源，Meta 仍在以巨大规模购买外部 AI 容量。

最缺乏依据的结论则是，token 消耗证明 Microsoft 的模型优于 Llama。现有证据并不支持这一说法。

这同样不能表明 Meta 计划减少对 Llama 的投入。其外部使用可以与持续的内部模型开发并存。

读者应将据报道的 Meta token 数量视为依赖关系的证据，而不是技术失利的证据。

三个信号将揭示这种依赖是否会持续

下一阶段将由工作负载结果、Meta 内部模型的采用情况，以及 Microsoft 将 token 增长转化为可持续利润率的能力决定。

第一个信号是 Meta 是否改变员工对外部模型的访问方式。新的预算、限制或默认模型规则，将表明管理层认为不受控制的消耗已经成为财务问题。

转向内部模型将强化独立性的论点。继续保持广泛访问则会支持 Microsoft 的市场地位。

第二个信号来自 Meta 的下一次模型和基础设施发布。关键问题并不在于 Meta 是否宣布推出另一个 Llama 版本。

真正有意义的衡量指标是，内部团队是否将生产工作负载迁移到它之上。Meta 内部的采用将表明，该公司能够将模型投资转化为实际替代能力。

如果员工在一次重大发布后仍偏好竞争系统，那么据报道的 Azure 关系看起来就将是结构性的，而非暂时性的。

第三个信号将出现在 Microsoft 的财务披露中。投资者应关注 AI 容量、Azure 增长、毛利率，以及有关多模型 Foundry 采用情况的表述。

根据其公开财报说明，Microsoft 的 AI 收入年化运行率在其第三财季超过了 370 亿美元。该公司还报告称，大型 Foundry 客户的 token 增长迅速。

这些数字支持需求旺盛的叙事，但基础设施成本依然很高。Microsoft 必须先采购加速器并建设设施，之后这些容量才能产生收入。

像 Meta 这样的客户可以提升利用率。不过，如果模型服务成本的下降速度慢于合同费率，大规模协商使用量仍可能对利润率构成压力。

因此，这种关系考验着两家公司。Meta 必须证明，购买外部模型能够加快有用工作的推进，而不会削弱其内部战略。

Microsoft 则必须证明，服务数万亿 token 带来的是有吸引力的经济效益，而不只是令人印象深刻的活跃度。

Amazon、Google 和专业模型供应商将影响这两种结果。更低的费率或更好的模型可能会将 Meta 的工作负载从 Azure 吸走。

Microsoft 可以通过容量、治理能力和模型广度来捍卫其地位。它不能假定今天的首选模型到下个季度仍然是首选。

对开发者而言，实际教训是模型选择仍在不断变化。系统应保留评估结果，并让工作负载能够迁移，而无需重建所有周边流程。

企业买家也应要求结果指标。token 数量是一种运营投入，类似于计算时间或存储。

更好的问题关乎交付速度、质量、可靠性和收入。团队应知道智能体是否解决了问题，而不只是它消耗了多少 token。

据报道的 Meta token 激增，让企业 AI 采用的规模变得可见。它也揭示了，公众对于这种规模所创造的价值知之甚少。

未来数月，请关注 Meta 的默认模型、内部工作负载迁移，以及 Microsoft 的云业务利润率。这些信号共同将表明，Azure 对 Meta 而言究竟是一座桥梁，还是其 AI 技术栈中的永久层。

如果你的团队正在扩大模型使用规模，应先追踪哪些工作流获得改善，哪些只是产生了更多活动。保留支撑上下文，记录模型决策，并比较重复任务中的结果。询问每个系统是否缩短审查时间、提升质量，或处理了此前一直未能完成的工作。这种纪律比追逐更大的 token 总量更重要。Meta 据报道的消耗量提供了一个罕见视角，让人得以观察极端规模下的采用情况，但它本身并不能提供模板。真正的基准将是 Meta 能否将这些 token 转化为更好的产品，同时降低对其竞争对手供应方的依赖。