从算力供给到 Token 效率：华为云 Agentic Cloud 与灵衢昇腾 950 的落地视角

2026-09-18 24 预计阅读时间: 1 分钟
来源: oschina.net AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：12 分钟

华为云在全联接大会上把战略重心明确指向了“Agentic Cloud”。与传统云计算强调 CPU、GPU/NPU 数量和峰值算力不同，这次更值得关注的判断是：智能体时代的基础设施，需要“让每一个 Token 更高效”。与这一方向配套的灵衢昇腾 950 智算集群，摘要给出的商用节奏是国内 9 月 30 日、海外 11 月 30 日。

对开发团队来说，这不只是硬件升级。Agent 应用会反复调用模型、工具、知识库和其他智能体，基础设施必须同时解决推理吞吐、长上下文、任务成功率、故障恢复和成本可观测性等问题。

为什么不能只看峰值算力

普通在线推理通常可以抽象为“一次请求、一次响应”，但 Agent 工作流更像一张动态调用图：

  1. 模型理解目标并制定计划；
  2. 调用搜索、数据库或业务 API；
  3. 根据工具结果继续推理；
  4. 失败时重试或改写参数；
  5. 汇总上下文并生成最终结果。

一次用户任务可能触发十几次模型请求。此时，即使单次推理速度很快，过长的提示词、无效重试和膨胀的历史上下文仍会迅速消耗 Token。因此，“每一个 Token 更高效”至少应拆成以下几类指标：

  • 交互延迟：首 Token 延迟、单轮响应时间和完整任务耗时；
  • 有效吞吐：每秒生成 Token 数，以及单位时间完成的有效任务数；
  • 任务消耗：每个成功任务使用的输入、输出和缓存 Token；
  • 执行质量：工具调用成功率、任务成功率与人工接管率；
  • 恢复成本：超时、重试、模型切换造成的额外 Token；
  • 资源效率：不同并发量下的加速器利用率、队列等待时间和单位任务成本。

其中最容易误判的是吞吐量。一个系统即使能生成更多 Token，也不一定更高效；如果 Agent 因工具参数错误连续重试，增加的吞吐只是放大了浪费。生产评估应以“成功完成一个任务需要多少 Token、多少时间和多少次外部调用”为中心。

灵衢昇腾 950 应放在整条 Agent 链路中评估

从来源摘要可以确认的是，灵衢昇腾 950 智算集群是华为云 Agentic Cloud 战略中的关键基础设施，并给出了国内和海外的商用节点。摘要没有披露完整的硬件规格、网络拓扑或服务接口，因此不能仅凭名称推导具体性能。

更稳妥的评估方法，是把智算集群放进真实业务链路，而不是只运行单轮模型压测。测试集至少应覆盖：

  • 短对话与长上下文请求；
  • 高并发批量推理；
  • 多轮工具调用；
  • RAG 检索与文档重排；
  • 多智能体协作；
  • 节点故障、请求超时和限流场景；
  • 国内与海外区域的网络延迟和数据合规要求。

对于计划全球部署的团队，海外商用并不自动等于应用可以无差别迁移。还要确认模型版本、API 能力、区域配额、日志存储位置、密钥管理方式以及跨区域调用成本是否一致。

用任务级脚本测量 Token 效率

如果服务提供 OpenAI 兼容或相似的聊天接口，可以用下面的脚本建立一个最小基线。这里明确做一个实践假设：接口路径为 /v1/chat/completions，响应包含 usage.prompt_tokens、usage.completion_tokens 和 usage.total_tokens。实际接入灵衢昇腾 950 相关服务时，需要按照云端文档修改地址、模型名称、认证方式和响应字段。

运行前安装依赖并设置环境变量：

python -m pip install requests
export LLM_BASE_URL="https://your-endpoint.example.com"
export LLM_API_KEY="replace-with-your-key"
export LLM_MODEL="your-model-name"
python benchmark_agent_tokens.py

将下面内容保存为 benchmark_agent_tokens.py：

import math
import os
import statistics
import time

import requests

BASE_URL = os.environ["LLM_BASE_URL"].rstrip("/")
API_KEY = os.environ["LLM_API_KEY"]
MODEL = os.environ["LLM_MODEL"]
RUNS = int(os.getenv("BENCHMARK_RUNS", "5"))

TASK = """你是运维智能体。请分析以下告警，并只返回三项内容：
1. 最可能原因；
2. 两条验证命令；
3. 一条低风险恢复建议。
告警：订单服务过去 5 分钟 HTTP 5xx 从 0.2% 升至 8%，数据库连接池使用率为 98%。
"""


def percentile(values, ratio):
    ordered = sorted(values)
    index = max(0, math.ceil(len(ordered) * ratio) - 1)
    return ordered[index]


def invoke():
    started = time.perf_counter()
    response = requests.post(
        f"{BASE_URL}/v1/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": MODEL,
            "messages": [{"role": "user", "content": TASK}],
            "temperature": 0,
            "max_tokens": 300,
        },
        timeout=120,
    )
    latency = time.perf_counter() - started
    response.raise_for_status()
    data = response.json()
    usage = data.get("usage", {})

    return {
        "latency": latency,
        "prompt_tokens": usage.get("prompt_tokens", 0),
        "completion_tokens": usage.get("completion_tokens", 0),
        "total_tokens": usage.get("total_tokens", 0),
        "answer": data["choices"][0]["message"]["content"],
    }


def main():
    results = []
    for number in range(1, RUNS + 1):
        try:
            result = invoke()
            results.append(result)
            print(
                f"run={number} latency={result['latency']:.2f}s "
                f"tokens={result['total_tokens']}"
            )
        except Exception as exc:
            print(f"run={number} failed: {exc}")

    if not results:
        raise SystemExit("No successful request")

    latencies = [item["latency"] for item in results]
    total_tokens = sum(item["total_tokens"] for item in results)
    total_time = sum(latencies)

    print("\n--- summary ---")
    print(f"success_rate={len(results) / RUNS:.2%}")
    print(f"latency_p50={statistics.median(latencies):.2f}s")
    print(f"latency_p95={percentile(latencies, 0.95):.2f}s")
    print(f"avg_tokens_per_request={total_tokens / len(results):.1f}")
    print(f"aggregate_tokens_per_second={total_tokens / total_time:.2f}")
    print("\nlast_answer:\n" + results[-1]["answer"])


if __name__ == "__main__":
    main()

这个脚本适合验证接口连通性和建立初始基线，但它还不是完整的 Agent 评测。接入真实工具后，建议为每次任务补充以下字段：

{
  "task_id": "incident-2025-001",
  "task_success": true,
  "model_calls": 4,
  "tool_calls": 3,
  "retry_count": 1,
  "input_tokens": 6820,
  "output_tokens": 940,
  "duration_ms": 12840,
  "human_handoff": false
}

随后可以直接计算每个成功任务的平均 Token 数：

tokens_per_successful_task = 总 Token 数 / 成功任务数

相比单纯报告每秒 Token，这个指标更接近 Agent 系统的实际业务效率。还可以继续加入正确性评分、单位任务价格和缓存命中率，避免模型通过缩短答案换取表面上的低消耗。

真正的优化通常发生在模型之外

基础设施决定效率上限，应用架构则决定团队能否接近这个上限。常见的 Token 优化手段包括：

  • 对工具返回值做字段裁剪，不把完整数据库记录塞回上下文；
  • 将固定系统提示词模板化，利用服务支持的提示词缓存；
  • 对长对话做结构化摘要，而不是无限追加历史消息；
  • 给工具调用设置明确的超时、重试次数和幂等键；
  • 用小模型完成分类、路由和参数检查，把复杂推理交给更强模型；
  • 对 RAG 设置召回数量上限，并通过重排减少无关文档；
  • 为不同任务设置独立的最大输出 Token，避免统一使用过大的默认值。

这些措施往往比单纯提高硬件配额更直接。比如，把一次工具返回从 50 KB 裁剪到 5 KB，不仅减少输入 Token，也降低网络传输、上下文解析和后续推理负担。

上线前的决策清单

灵衢昇腾 950 智算集群的国内与海外商用安排，为需要跨区域部署的 Agent 应用提供了新的基础设施选项。不过，是否迁移或采用，仍应通过业务负载验证。

上线前可以逐项确认：

  • 是否使用真实 Agent 任务，而非只做单轮文本生成压测；
  • 是否同时记录延迟、任务成功率、Token 消耗和工具调用次数；
  • 模型、SDK 与 API 是否具备可迁移性，是否绑定特定接口；
  • 峰值并发下是否存在排队、限流或重试放大；
  • 国内外区域在模型版本、配额和功能上是否一致；
  • 日志、提示词、工具结果是否满足数据驻留和隐私要求；
  • 故障时能否切换区域、模型或推理端点；
  • 成本核算是否落实到“每个成功任务”，而不是只看资源单价。

Agentic Cloud 的关键变化，并不是给传统云服务换一个新名字，而是把基础设施评价单位从“拥有多少算力”推进到“完成多少有效智能任务”。对工程团队而言，最有价值的动作是尽早建立任务级基线：同一批数据、同一套工具、同一个成功标准，然后比较不同模型、集群和工作流的 Token 效率。

# AI # LLM # 全栈 # 开源 # 开源中国

相关推荐