ai-platform-evolution

Cross-category topic | 2 sources
← All Topics

AI 平台演进：从 MaaS 卖 Token 到 AaaS 卖结果 #

1. 主题缘起 #

2023–2026 年，AI 服务平台经历了三次范式跃迁：IaaS 卖 GPU 算力 → MaaS 卖 Token → AaaS 卖结果。每一次跃迁都伴随着计费单位的抽象化、风险承担方的转移、以及基础设施栈的结构性重组。

2026 Q1 出现了结构性拐点：Fortune 500 企业在 AI Agent 上的支出首次超过新 SaaS seat 支出。Per-seat 定价的市场份额从 21% 降至 15%，混合订阅+用量模式从 27% 升至 41%。Salesforce 推出 Agentic Work Unit (AWU) 将 token 消耗抽象化，按"一个 agent 完成的离散任务"计费——AWU 季度环比增长 57%，Agentforce 业务线已超 $1.8B 营收。

与此同时，Token 价格呈现经典的 Jevons Paradox：GPT-4 级模型的 token 价格从 $20/M (2022) 降至 $0.40/M (2025)——50 倍降幅，但企业 AI 支出从 $11.5B 暴涨至 $37B——320% 增长。更便宜的 token 催生了更多消耗：reasoning 模型消耗 5-20x 更多 token（chain-of-thought）、agent 工作流链式乘法增长、context window 持续膨胀。

本 topic 从平台架构师的视角，系统梳理 AI 服务平台从 MaaS 到 AaaS 的演进路径，覆盖平台组件、商业模式、基础设施适配三个维度。与 agent-scheduling topic 的关系：agent-scheduling 聚焦 serving 引擎内部的调度算法（Router + KV Cache 管理），本 topic 聚焦 serving 引擎之上的平台层（Gateway、Billing、Orchestration、Payment）和之下的集群管理层（GPU 管理、K8s 编排）。两者在 Router/Gateway 层存在接口——Model Router（本 topic）调用 Serving Router（agent-scheduling），形成两级路由。

2. 平台演进链 #


IaaS → PaaS → SaaS → MaaS → AaaS/RaaS/AGaaS
(卖机器)  (卖平台)  (卖软件)  (卖 Token)  (卖结果)
阶段计费单位风险承担方代表市场规模 (2026E)
IaaSGPU-hours, VM用户AWS EC2, CoreWeave, Lambda Labs>$300B
PaaS / AI-PaaS部署单元, API call用户Vercel, Azure App Service~$140B
SaaSPer-seat / license用户 (shelfware risk)Salesforce CRM, ServiceNow~$650B (正在被侵蚀)
MaaS$/M tokens用户 (prompt 质量)OpenAI API, Bedrock, Together, Fireworks~$30.5B (CAGR 36%)
AaaS / RaaS完成的任务 / 结果厂商 (没完成不收费)Intercom Fin, Sierra AI, Salesforce AWU新兴

2.1 关键转变机制 #

SaaS → MaaS：核心驱动力是"build vs buy 的数学被算力碾碎"。托管一个 1T+ 参数前沿模型的年化成本（GPU + 电力 + 工程师）远超通过 MaaS API 调用的成本。MaaS 提供商通过多租户架构将基础设施开销分摊到数百万用户。对平均企业而言，$0.20-$5.00/M tokens 的 API 调用 vs 数百万美元的自建成本——经济账一目了然。

MaaS → AaaS：核心驱动力是"Token 度量计算而非价值"。一个人类 30 秒完成的任务可能消耗数千 token，一个人类数小时的任务可能只需很少 token——compute cost 和 customer value 完全脱耦。AWU 的设计意图是"抽象掉 token 消耗，把定价绑定到客户真正关心的结果上"。

风险转移是最深层的变化：SaaS 时代用户承担 shelfware 风险（买了软件不用是你的问题），AaaS 时代厂商承担效果风险（agent 没完成任务不收费）。这消灭了"feature bloat"——厂商不再堆砌无用功能凑清单，只构建直接驱动 billable outcome 的能力。

3. MaaS 平台组件全景 #

一个完整的 MaaS 平台包含 7 层组件：


┌─────────────────────────────────────────────────────────┐
│ ① API Gateway                                           │
│    TLS终止, 认证鉴权, 全局限流, 多租户隔离               │
├─────────────────────────────────────────────────────────┤
│ ② Model Registry / Catalog                              │
│    模型注册, 版本管理, 元数据, 能力描述, 部署配置         │
├─────────────────────────────────────────────────────────┤
│ ③ Intelligent Router (Model Router)                     │
│    模型选择, provider fallback, 质量-成本路由, A/B 实验   │
├─────────────────────────────────────────────────────────┤
│ ④ Inference Engine                                      │
│    vLLM/SGLang, Continuous Batching, Prefix Caching, PD分离│
├─────────────────────────────────────────────────────────┤
│ ⑤ Rate Limiting & Quota                                 │
│    Token Bucket, per-tenant 配额, RPM/TPM, 背压          │
├─────────────────────────────────────────────────────────┤
│ ⑥ Metering & Billing                                    │
│    Token 用量采集 → 聚合 → 计费引擎                      │
├─────────────────────────────────────────────────────────┤
│ ⑦ Observability & Governance                            │
│    日志, Trace, 成本归因, guardrails, 内容安全, 审计      │
└─────────────────────────────────────────────────────────┘

3.1 MaaS 平台格局 #

第一梯队：Cloud 大厂 #

平台特点2026 新能力
Azure AI FoundryOpenAI 独家 + 开源模型, PTU 保障吞吐Model Distillation GA, Global Standard 跨区路由
AWS Bedrock最广模型选择, Nova 自研Prompt Routing 自动选模型, AgentCore 支付, Batch 50% 折扣
Google Vertex AIGemini 独家, TPU 原生Gemma 4 TPU 优化

第二梯队：推理专精平台 #

平台Llama 70B 价格核心优势UptimeTTFT P50
Groq (LPU)$0.59/M tok极低延迟, 420 tok/s99.4%65ms
Fireworks AI$0.90/M tok可靠性+Function Calling, 已上 Azure Foundry99.8%150ms
Together AI$0.88/M tok200+模型, 最成熟 Fine-tuning99.7%220ms
ReplicateVariable2000+模型, 图像/视频最强——

关键经济学：开源模型 $0.10-$0.50/M vs 前沿模型 $30-$60/M → 100-600x 价差。智能路由（multi-model routing）可实现 30-85% 成本削减，保持 95% 质量。路由是 MaaS 平台的核心 margin 杠杆。

3.2 设计原则 #

  1. Rate Limiting（执行）和 Metering（记账）分离：限流是实时决策，计量可以异步。Metering 走 Kafka/NATS 队列，不在推理热路径上增加延迟。
  2. 单一 OpenAI-compatible endpoint：屏蔽后端 provider 差异，所有现有 SDK/工具零改动接入。
  3. Tier-based 访问控制：free / standard / premium → 不同的模型访问权限、速率限制、SLA 保证。

    4. 4. Agent 工作负载对 MaaS 各层的冲击 #

    Agent 工作负载系统性地打破了 MaaS 每一层的设计假设：

    层被打破的核心假设冲击所需修改
    API Gateway无状态 request-responseAgent session 持续分钟~小时，burst 式 tool loopSession-id 路由 + delegation credential + 心跳超时
    Model Registry用户手动选单一模型一个 workflow 混用 3-5 个模型Capability schema + multi-model workflow 声明
    Intelligent Routerper-request 独立路由KV Cache 在哪, 请求必须去哪Cache-aware routing + 两级路由 (Model Router + Serving Router)
    Inference EngineKV Cache 与请求同生命周期Session 持续增长, per-turn re-queue 占 58.2% 延迟Workflow-aware memory manager + PPD 动态路由
    Rate Limiting固定窗口 RPM/TPMAgent burst 被误拦; 长 session 挤压短请求Session budget + AIMD admission + WFQ 公平调度
    Metering/Billing(input_tokens, output_tokens)一个 workflow 跨模型跨 tool, token ≠ 价值AWU + workflow cost roll-up + credit wallet
    Observability单请求 traceWorkflow 跨 10+ requests + tool callsSession-level trace + agent loop 行为追踪

    4.1 Router 层的两级分化 #

    MaaS 到 AaaS 的核心架构变化是 Router 从一级变为两级：

    级别职责决策信号实现方
    L1 Model Router选模型 + provider + region任务复杂度, 成本约束, SLA 要求平台层 (本 topic)
    L2 Serving Router选 worker + 管 KV CacheCache 驻留状态, prefix 匹配, 负载, session 亲和Serving 层 (agent-scheduling topic)

    L1 和 L2 之间需要双向信息传递：L1 告诉 L2 "这个 session 预计 20 turns"，L2 反馈 L1 "KV Cache 压力大，建议降级模型"。当前无标准接口。Bedrock 的 Prompt Routing 是 L1 的初步尝试，但完全不感知 L2 的 cache 状态。

    4.1.1 L4 Agent Orchestration 层的新兴形态 #

    两级路由之上还在形成第三层挑战：agent orchestration 本身的系统化。Qualixar OS [ref:2604.06392] 是这一方向的极端案例——它在应用层构建了 12 种执行拓扑、Forge 自动团队设计、三层模型路由（meta-layer bandit → strategy → POMDP belief）和 8 模块质量保障流水线，试图将 agent 编排从框架级代码提升为 OS 级抽象。其 L3 分析揭示了关键张力：orchestration 层的丰富性（12 拓扑 + Forge + judge pipeline）与 serving 层的感知完全脱节——Qualixar OS 的 model-call.ts 对 KV cache 状态毫无感知，每次 LLM 调用都是无状态 HTTP 请求。这意味着 L4 Orchestration 和 L5 Inference Engine 之间存在与 L1-L2 Router 类似的信息断裂：编排层知道 workflow 的拓扑和预期 step 数，但无法将这些先验传递给推理层做 cache 预热或 TTL 预估。

    4.2 计费层的结构性升级 #

    从 (input_tokens, output_tokens) 扩展为：

    
UsageEvent {
  session_id:         string,
  turn_index:         int,
  model_id:           string,
  input_tokens:       int,
  cached_input_tokens: int,    // prefix cache hit
  output_tokens:      int,
  reasoning_tokens:   int,     // chain-of-thought
  tool_calls:         int,
  tool_types:         string[],
  latency_ms:         int,
  kv_cache_hit_rate:  float,
  outcome_completed:  bool,    // AWU: 任务是否完成
}

    5. AaaS 新范式 #

    5.1 定价模型演进 #

    模型机制代表适用场景
    Per-resolutionAgent 成功解决才收费Intercom Fin ($0.99/resolved conversation, 67% resolution rate)客服
    Per-outcome按完成的业务结果计费Sierra AI ($150M ARR), Legal AI (per contract analyzed)垂直领域
    AWUToken 抽象化为"一个离散任务"Salesforce Agentforce通用 CRM/SaaS
    Hybrid基础平台费 + 结果溢出大多数厂商的最终落点需要收入可预测性
    Credit Wallet预付 credit pool, 跨产品/模型/agent 共享2026 年标准化中多供应商生态

    5.2 Agent 支付基础设施 #

    Agent 正在成为独立经济参与者，需要专用支付基础设施：

    层协议/平台机制
    支付协议x402HTTP 402 微支付标准, exact/upto scheme, 支持 crypto+fiat
    支付编排AWS AgentCore Payments单一 processPayment 接口 + 可配置消费护栏
    计量Neverminedper-token/per-API-call/per-GPU-cycle 精细计量
    身份Bounded Delegation IdentityAgent 持有加密签名凭证, 限定消费范围/上限/有效期
    钱包Credit Wallet (2026 标准化)预付 pool, 跨供应商消费, 大平台提供

    5.3 Agent 协议标准化：从工具调用到开放互联网 #

    AaaS 平台除了需要支付基础设施，还需要 agent 间通信的协议基础设施。Agent Interoperability Protocols survey [ref:2505.02279] 首次系统梳理了四层协议栈，从工具访问到开放互联网逐层扩展：

    阶段协议定位成熟度
    Stage 1: Tool AccessMCP (Anthropic)Agent ↔ Tool 的 JSON-RPC 标准接口生产级（Claude Code、OpenAI Agents SDK、Cursor 均已采用）
    Stage 2: Agent MessagingACP (IBM BeeAI)Agent ↔ Agent 的 session-aware MIME 消息传递早期（社区规模小）
    Stage 3: Enterprise CoordinationA2A (Google)跨组织 agent 发现（Agent Card）+ 任务委派（Task lifecycle）Early-adopter（2025-04 发布，无大规模生产部署）
    Stage 4: Open InternetANPDID 身份 + 去中心化 agent 发现研究原型

    对 AaaS 平台架构的影响：§6 的 L4 Agent Orchestration 层需要原生支持至少 MCP（工具接入）和 A2A（跨 agent 协调）。采用曲线呈 power law：MCP >> A2A > ACP ≈ ANP。当前市场现实更可能是 MCP 一家独大 + A2A 在 enterprise 赛道小范围采用，而非 survey 乐观假设的四层全面铺开。

    5.4 SaaS 沙漏效应 #

    价值分布正在形成沙漏形状——顶部和底部集中，中间被掏空：

    
      ┌─ 编排/Orchestration (高价值) ─┐
      │  Agent 理解意图、协调系统、执行结果  │
      │  "System of Action"             │
      └────────────────────────────────┘
                    ▲ 价值集中
      ┌────────────────────────────────┐
      │  中间层 (被掏空)                │
      │  传统 UI-centric workflow SaaS  │
      │  Agent 直接跳过 UI 操作底层数据  │
      └────────────────────────────────┘
                    ▼ 价值集中
      ┌────────────────────────────────┐
      │  数据/Infrastructure (高价值)   │
      │  专有数据、系统记录、GPU 集群    │
      │  "Data Gravity"                │
      └────────────────────────────────┘

    6. AaaS 平台技术栈 #

    从零搭建 AaaS 平台的 7 层架构：

    层组件开源选型商业选型
    L1 InfrastructureK8s + GPU Operator + GPU Scheduler + AutoscalerK8s + NVIDIA GPU Op + KAI Scheduler + Kueue + KEDARun:ai, CoreWeave
    L2 ObservabilityMetrics + Tracing + GuardrailsPrometheus + Grafana + DCGM + OpenTelemetryDatadog, Langfuse
    L3 Metering/Billing事件采集 + 聚合 + 计费Kafka/NATS + OpenMeter + 自建Stripe Billing, Orb
    L4 Agent OrchestrationWorkflow Engine + Tool Registry + State Store + Agent Protocol StackLangrove (LangGraph 自托管) + MCP Registry + PG/RedisLangGraph Cloud, Dify, Qualixar OS
    L5 Inference EngineServing + KV Cache + PD 分离vLLM/SGLang + LMCache + KubeRayFireworks, Together
    L6 Intelligent RouterModel Router + Session Manager + Serving Router自建 + mori-schedulerPortkey, Vercel AI Gateway
    L7 API GatewayTLS + Auth + Rate Limit + Agent DelegationEnvoy + Kuadrant/Authorino + RedisZuplo, Kong

    6.1 GPU 集群管理 #

    推理服务用 K8s（服务型负载），训练可以 Slurm。关键组件：

    • NVIDIA GPU Operator（或 AMD 对应的 ROCm Device Plugin）：驱动管理 + 设备发现
    • KAI Scheduler：Gang scheduling + 拓扑感知 + 分数 GPU 共享
    • Kueue：多租户配额管理 + job queuing + 借用/抢占
    • KubeRay：分布式推理协调（TP/PP 跨节点）
    • Karpenter / KEDA：GPU-aware 弹性伸缩（基于 GPU 利用率/队列深度，而非 CPU）
    • Storage：RWX (NFS/CephFS) 共享模型权重 + Local NVMe 缓存 KV

    6.2 分阶段建设路线 #

    Phase目标周期核心交付
    0Minimal MaaS2-4 周单模型 OpenAI-compatible API
    1Multi-Model MaaS4-8 周多模型 + 路由 + 基础计量 + 用户面板
    2Cache-Aware MaaS8-12 周PD 分离 + KV Cache 管理 + session sticky + PPD
    3AaaS 升级12-20 周Agent 编排 + Tool Registry + Outcome 计费 + Credit Wallet
    4差异化20+ 周Workflow-aware scheduling + 预测性缓存 + 投机执行

    7. 共识与分歧 #

    共识 #

    1. Token 是过渡态，Outcome 是终态：Token 定价正在被 AWU / per-resolution 等结果定价取代，但底层仍需 token-level 的精细计量。计量和计费是两个独立问题——计量永远是 token 级，计费可以是 outcome 级。
      1. 智能路由是 MaaS 平台的核心 margin 杠杆：100-600x 的模型价差意味着路由策略直接决定 gross margin（AI 应用公司 50-60% vs 传统 SaaS 80-90%）。谁的路由更智能，谁的 margin 更高。
        1. 中间层 SaaS 被掏空：Agent 直接操作底层 API 和数据，跳过传统 UI-centric workflow。价值向编排层（上）和数据/基础设施层（下）两端集中。
          1. Agent 需要独立金融基础设施：x402、AgentCore、Credit Wallet 正在构建 agent 作为独立经济体的支付能力。2026 年 credit wallet 从实验走向标准基础设施。
            1. MaaS 最难改的两层（Router + Engine）恰好是 agent-scheduling topic 集中攻击的方向：平台上层（Gateway、Billing、Observability）的修改相对独立，但真正的竞争壁垒在 serving 层的 agent-aware scheduling。

              2. 分歧 #

              1. Token 定价 vs Outcome 定价的落地路径：纯 outcome 定价对厂商收入不可预测，纯 token 定价对用户价值不透明。市场可能收敛于 hybrid（基础平台费 + outcome 溢出），但最终比例未定。
                1. 平台 vs 垂直的竞争格局：通用 MaaS 平台（OpenAI、Bedrock）是否会被垂直 AaaS（Sierra AI for customer support、Harvey for legal）瓦解？Bessemer 认为"最成功的 AI 公司不是在收费技术，而是在收费完成的工作"。
                  1. 自建 vs 外购 inference：MaaS 推动"不要自建"，但 agent 的状态性要求（KV Cache 亲和、session sticky）让自建推理集群重新有了理由——你无法在第三方 MaaS API 上做 cache-aware routing。
                    1. "MCP 独大" vs "四层协议生态"：Claude Code 仅用 MCP（JSON-RPC + Stdio）就实现了完整生产级 agent，覆盖 tool invocation、context management、multi-session persistence [ref:2604.14228]。Agent Interop Survey [ref:2505.02279] 则主张 MCP/ACP/A2A/ANP 四层缺一不可。实证天平倾向前者：OpenAI Agents SDK 同样仅 MCP + handoff 即可做 multi-agent workflow；survey 未给出任何 "只有 MCP 不够" 的 concrete failure case。但长期看，跨组织 agent 协作（enterprise A2A 场景）可能确需超越 MCP 的发现和委派语义。Qualixar OS 的 Claw Bridge [ref:2604.06392] 则提供了第三条路径——在应用层用 adapter 兼容多框架，绕开协议层标准化博弈，但面临 N² adapter 维护成本。

                      2. 8. Open challenges #

                      8.1 L1-L2 Router 接口标准化 #

                      Model Router (L1) 和 Serving Router (L2) 之间缺乏标准化接口。L1 的 "session 预计 20 turns" 信息无法传递给 L2，L2 的 "KV Cache 压力过大" 信号无法反馈 L1。当前两者独立运作，形成跨层优化盲区。难度：1-2 年（工程问题 + 标准化博弈）。

                      8.2 跨模型 KV Cache 共享 #

                      Agent workflow 混用多模型时，每个模型需要独立 KV Cache，导致内存爆炸。ICaRus 和 PrefillShare 正在探索跨模型 KV 共享，但需要模型架构层面的适配。难度：2-3 年。

                      8.3 Credit Wallet 跨供应商互操作 #

                      单供应商 credit wallet 已经可行。但真实 agent workflow 跨多供应商——一个 wallet 管理多种 credit 类型、不同的 pooling/rollover 规则、跨供应商结算。需要生态级标准。难度：3-5 年。

                      8.4 Outcome 度量的客观性 #

                      Outcome-based 定价需要客观度量"任务是否成功完成"。当 agent 的结果和用户内部流程交织时，归因争议不可避免。需要可验证的 outcome attestation 机制。难度：2-3 年。

                      8.5 Agent 协议互操作与组合开销 #

                      Agent Interop Survey [ref:2505.02279] 识别了协议层碎片化（MCP/ACP/A2A/ANP 四套独立标准）是规模化多 agent 系统的根本瓶颈，但协议组合本身引入新问题：

                      • 协议栈开销：MCP→ACP→A2A 链式调用的每一层都增加 JSON-RPC parsing、auth handshake、session state management。在 agent 多轮场景中（平均 925ms tool-call 间隙），协议栈 overhead 可能抵消互操作收益。CPU-Centric 分析已证明 tool 执行占 E2E 延迟 35%–88%——新增协议层会进一步放大 CPU-side overhead。
                      • Protocol composition vs adapter composition：协议层标准化（survey 路线）要求所有参与者原生实现标准接口，集成成本 O(N) 但前期投入高；应用层 adapter（Qualixar OS Claw Bridge 路线）集成速度快但面临 O(N²) 维护成本。两条路径的 break-even point 未被量化。
                      • 安全威胁扩大：MCP 已被识别出 14 个安全威胁（Tool Poisoning、Cross-Server Shadowing、Tool Redefinition 等），A2A 另有 5 个。多协议组合使攻击面呈乘法增长，但当前无统一的跨协议安全模型。

                      难度：2-4 年（技术 + 标准化博弈 + 安全验证）。

                      9. 邻接 topic #

                      Topic关系
                      agent-scheduling强关联——agent-scheduling 覆盖 L2 Serving Router + L5 Inference Engine 内部的调度算法，本 topic 覆盖之上的平台层和之下的集群管理层。两者在两级路由（L1 Model Router ↔ L2 Serving Router）处接口
                      cluster-llm-deployment强关联——cluster-llm-deployment 覆盖部署拓扑（xPyD、TP/EP/PP 选择），本 topic 的 L1 Infrastructure 层直接依赖其内容
                      agent-system中关联——agent-system 覆盖 agent 从模型到框架的全栈架构，本 topic 聚焦 agent 如何被"服务化"交付
                      agent-context-lifecycle弱关联——context lifecycle 影响 Metering（cached_tokens 需要被正确计量）和 Billing（compacted context 的计费归属）

                      10. 参考 #

                      本 topic 基于 web research 综合整理，尚无 L1/L2 层论文深度解读。主要信息源：

                      来源关键贡献
                      Zylos Research "AI Agent Platform Economics" (2026-03)Token Jevons Paradox 量化; per-seat 21%→15% 下降; hybrid 模式 41% 占比
                      Salesforce Agentforce AWU 公告 (2026-05)AWU 定义; 57% QoQ 增长; $1.8B 营收
                      Bessemer "AI Pricing & Monetization Playbook" (2026)Copilot/Agent/AI-Service 三种商业模式; 2026 renewal cliff
                      Areza "SaaS to GaaS" (2026)Intercom Fin $0.99/resolved; Sierra AI $150M ARR; hybrid 定价
                      Ibbaka "B2B SaaS Agentic AI Pricing" (2026)Credit wallet 标准化; 跨供应商 credit 互操作
                      Red Hat MaaS Architecture (ODH)K8s-native MaaS 参考架构; Kuadrant policy engine
                      vLLM Production StackHelm 一键部署参考实现; Router + Engine + LMCache + Observability
                      Augment Code "Agentic Infrastructure Stack"5 层 agent 基础设施; compute/orchestration/context/observability/security
                      AWS AgentCore Payments (2026-05)processPayment 接口; x402 v1/v2 协议适配; 支出护栏
                      x402 Protocol (open standard)HTTP 402 微支付; exact/upto scheme; 多链支持
                      Nevermined "AI Agent Payment Statistics" (2026)$3-5T agentic commerce 2030E; 微交易计量基础设施
                      QubitTool "LLM Gateway Architecture"Gateway 组件详解; semantic cache + fallback chain + cost tracker
                      Vercel "Agentic Infrastructure Stack"AI Gateway + Sandbox + Flags + Microfrontends 四原语
                      Qualixar OS (2604.06392) [ref:2604.06392]应用层 agent 编排 OS：12 种拓扑 + Forge 自动团队设计 + 三层模型路由 + 8 模块质量保障；L4 Orchestration 层的 maximalist 参考实现，揭示 orchestration 与 serving 层的信息断裂
                      Agent Interoperability Protocols Survey (2505.02279) [ref:2505.02279]首篇 MCP/ACP/A2A/ANP 四协议全景对比；提出 Tool Access → Messaging → Enterprise Coordination → Open Internet 四阶段成熟度路线图；识别协议组合开销和安全威胁扩大问题