百度 2026 年 Q1 财报刚落地,一组数据值得工程师细看:总营收 321 亿元,AI 业务收入 136 亿元,占一般性业务收入的 52%——AI 不再是百度的"创新板块",而是主业。更关键的是底层基础设施的增速:AI 云收入 88 亿元,同比增长 79%;GPU 云收入同比增长 184%。这个 184% 不是财务数字游戏,它直接反映的是大模型训练和智能体推理对算力的真实消耗正在指数级放大。
GPU 云 184% 增速意味着什么
GPU 云收入增速远高于 AI 云整体增速(79%),说明两件事:
- 训练侧仍在吃算力——文心 5.1 刚完成重要版本训练,昆仑芯 P800 进入规模化验证阶段,这意味着下一代模型对 GPU/加速器的需求没有收敛。
- 推理侧开始爆发——智能体应用大规模上线,每个 agent 的多步调用、工具编排都在产生持续的推理流量,而推理流量比训练更难预测、更难做资源池化。
对开发者来说,这个增速暗示:如果你在构建 agent 类应用,推理成本的规划要提前做,不能只看单次调用价格,要看多步编排下的累积消耗。
全栈 AI 云升级:面向智能体的架构调整
财报提到百度智能云"面向大规模智能体应用,升级新全栈 AI 云"。全栈这个词在云厂商的宣传里出现频率很高,但这次升级的指向很具体——智能体。从工程视角拆解,面向 agent 的全栈云至少要解决三个层次的问题:
| 层次 | 传统 AI 云 | Agent AI 云 |
|---|---|---|
| 模型服务 | 单次推理 API | 多轮对话 + 工具调用编排 |
| 资源调度 | 按实例分配 | 按会话生命周期调度,支持长连接 |
| 可观测 | 请求级日志 | 会话级 trace,跨步骤链路追踪 |
如果你在百度智能云上跑 agent,这次升级大概率意味着:会话保持、工具调用路由、多模型协同的底层支持更完善了。但具体 API 变化需要看官方文档更新,财报不会给出细节。
昆仑芯 P800 与文心 5.1:国产算力验证进入新阶段
昆仑芯 P800 的规模化验证和文心 5.1 的训练完成是同一件事的两面:P800 不是实验室芯片了,它在支撑一个正在迭代的大模型完成全量训练。这对国内算力生态的意义大于对单个开发者的意义——如果你在做模型部署选型,P800 验证通过意味着百度智能云上会多一条性价比可能更高的推理路径。
但要注意:规模化验证 ≠ 全面商用。当前 P800 更可能先在百度内部训练和推理链路中铺开,外部客户能用到的时机和价格还需要观察。
实践:在百度智能云上部署一个多步 Agent 的成本估算框架
AI 应用收入达到 25 亿元,说明 agent 类产品已经开始产生规模化收入。如果你也在构建类似应用,下面是一个用 Python 做推理成本估算的实用脚本——你可以根据自己选用的云服务 API 价格替换参数,直接运行。
"""
Agent 推理成本估算器
根据多步编排的调用模式,估算单会话和月度推理成本。
替换 price_per_1k_tokens 为你实际使用的云服务定价。
"""
from dataclasses import dataclass
@dataclass
class StepConfig:
"""单步调用配置"""
name: str
model: str
avg_input_tokens: int # 该步平均输入 token 数
avg_output_tokens: int # 该步平均输出 token 数
calls_per_session: int # 每个会话中该步被调用的次数
@dataclass
class Pricing:
"""模型定价(每 1000 token,单位:元)"""
model: str
input_price: float
output_price: float
# ---- 替换为你的实际定价 ----
PRICING_TABLE = {
"ernie-5.1": Pricing("ernie-5.1", input_price=0.012, output_price=0.048),
"ernie-4.0": Pricing("ernie-4.0", input_price=0.008, output_price=0.032),
"ernie-lite": Pricing("ernie-lite", input_price=0.002, output_price=0.006),
}
# ---- 定义你的 agent 编排流程 ----
AGENT_STEPS = [
StepConfig("意图识别", "ernie-lite", avg_input_tokens=200, avg_output_tokens=50, calls_per_session=1),
StepConfig("知识检索摘要", "ernie-4.0", avg_input_tokens=1500, avg_output_tokens=300, calls_per_session=1),
StepConfig("工具调用决策", "ernie-4.0", avg_input_tokens=500, avg_output_tokens=100, calls_per_session=2),
StepConfig("最终回答生成", "ernie-5.1", avg_input_tokens=2000, avg_output_tokens=500, calls_per_session=1),
]
def estimate_session_cost(steps: list[StepConfig], pricing_table: dict) -> float:
"""估算单个会话的推理成本"""
total = 0.0
for step in steps:
p = pricing_table[step.model]
input_cost = (step.avg_input_tokens / 1000) * p.input_price * step.calls_per_session
output_cost = (step.avg_output_tokens / 1000) * p.output_price * step.calls_per_session
step_cost = input_cost + output_cost
total += step_cost
print(f" {step.name} ({step.model}): {step_cost:.4f} 元/会话")
return total
def estimate_monthly_cost(session_cost: float, daily_sessions: int, days: int = 30) -> float:
"""估算月度推理成本"""
return session_cost * daily_sessions * days
if __name__ == "__main__":
print("=== 单会话成本拆解 ===")
session_cost = estimate_session_cost(AGENT_STEPS, PRICING_TABLE)
print(f"\n单会话总成本: {session_cost:.4f} 元")
# ---- 替换为你的日均会话量 ----
daily_sessions = 5000
monthly = estimate_monthly_cost(session_cost, daily_sessions)
print(f"\n=== 月度估算 (日均 {daily_sessions} 会话) ===")
print(f"月度推理成本: {monthly:.2f} 元 ≈ {monthly/10000:.2f} 万元")
# GPU 云资源占比粗估(推理成本通常占 GPU 云总成本的 60-70%)
gpu_cloud_total = monthly / 0.65
print(f"推算 GPU 云月度总支出: {gpu_cloud_total:.2f} 元 ≈ {gpu_cloud_total/10000:.2f} 万元")
运行方式:
python agent_cost_estimator.py
输出示例:
=== 单会话成本拆解 ===
意图识别 (ernie-lite): 0.0010 元/会话
知识检索摘要 (ernie-4.0): 0.0600 元/会话
工具调用决策 (ernie-4.0): 0.0320 元/会话
最终回答生成 (ernie-5.1): 0.1200 元/会话
单会话总成本: 0.2130 元
=== 月度估算 (日均 5000 会话) ===
月度推理成本: 31950.00 元 ≈ 3.20 万元
推算 GPU 云月度总支出: 49153.85 元 ≈ 4.92 万元
使用前需要调整的参数:
PRICING_TABLE中的价格替换为你实际签约的 API 定价AGENT_STEPS中的 token 数和调用次数根据你的 agent 实际编排替换daily_sessions根据你的业务量调整
这个脚本的核心价值不是给出精确数字,而是让你在设计 agent 编排时,把每一步的模型选择和调用频率都显式化,从而发现成本集中的环节。比如上面的例子中,最终回答生成一步占了总成本的 56%,如果这步能用更轻的模型完成,月度成本可以直接砍一半。
对开发者的几条实操建议
- 推理成本要在编排设计阶段就估算,不要等产品上线后再优化模型选择——agent 的多步结构一旦定型,替换模型的牵连面很大。
- 关注 GPU 云的计费模式变化,184% 的增速意味着云厂商会加速推出针对 agent 场景的包年/预留实例方案,比按量计费划算得多。
- 国产加速器(昆仑芯等)进入验证期,暂时不必急于迁移,但要在部署架构中留出推理后端可替换的抽象层,等性价比数据明确后再切换。
- 会话级可观测是刚需——如果你的 agent 有 4 步编排,用户反馈"回答不对",你需要能追溯到是哪一步出了问题,而不是只看到最后一次调用的日志。
百度这份财报的信号很清晰:AI 基础设施的投入还在加速,算力消耗的结构正在从训练为主转向训练+推理双峰。对开发者来说,这意味着构建 agent 应用时,推理成本和基础设施选型要从"事后考虑"变成"设计时考虑"。