AMD Helion：一份把 Agent 执行放到 CPU 上的机架蓝图

2026 年 10 月 12 日，AMD 发布了 AMD Helion Agentic AI 机架：一套面向 Agent 基础设施的开放蓝图，基于开放计算项目（OCP）的规格设计，并由 AMD 算力驱动。最引人注目的配置是一个纯 CPU 机架，采用第六代 AMD EPYC 处理器，最多支持 32,768 个核心。这个数字值得读两遍，因为它是一份不太寻常的押注：AMD 卖给你的不是更多 GPU，而是一个专门跑 Agent 的地方，紧挨着那些服务 Agent 所调用模型的 GPU。

Agent 执行的瓶颈已经从算力转到了调度与电力

AMD 到底发布了什么

两种机架形态，一份蓝图。第一种是纯 CPU 机架，由第六代 EPYC 处理器驱动，最多支持 32,768 个核心，面向希望获得专属 Agent 执行容量、并连接到独立模型推理基础设施的超大规模客户。第二种是一体化机架，把 EPYC CPU 节点、Instinct MI350P GPU 节点与通用算力放进同一平台，面向企业级 Agentic AI。两者都基于 OCP 规格设计，都可风冷或液冷，都内置一个 token 路由器，用来把 Agent 的模型调用分发到前沿模型与开源模型之间。AMD 表示会把该规格贡献给 OCP，相关配置计划于 2026 年 11 月上市。

# Size the rack before you buy the rack.
# A Helion CPU-only configuration tops out at 32,768 EPYC cores.
AGENT_VCPU_PER_SESSION = 0.25   # a tool-calling agent is mostly waiting
SESSIONS_PER_CORE      = 1 / AGENT_VCPU_PER_SESSION

CORE_BUDGET = 32768
MAX_SESSIONS = CORE_BUDGET * SESSIONS_PER_CORE

print(f'cores={CORE_BUDGET} concurrent agent sessions={int(MAX_SESSIONS):,}')

# The number that matters is not peak. It is the tail.
def sessions_you_can_hold(utilization=0.65, retries_per_hour=1.8, avg_minutes=4.0):
    peak = MAX_SESSIONS * utilization
    offered = peak * retries_per_hour * (avg_minutes / 60)
    return {'sustainable': int(peak), 'headroom_after_retries': int(peak - offered)}

print(sessions_you_can_hold())

为什么纯 CPU 机架才是重点

Agent 执行的大部分时间都在等待。一个调用工具的执行循环会规划、调 API、等待、解析、重试、再对结果做推理；这个循环里的算术，比起模型调用本身微不足道。所以一个塞满核心却没有 GPU 的机架不是疏忽，而是一句关于「成本在哪里」的陈述。AMD 的说法很直接：纯 CPU 机架提供专门的 Agent 执行容量，并连接到独立的模型推理基础设施。AMD 计算与企业 AI 高级副总裁兼总经理 Dan McNamara 的表述是：Agentic AI 不是单一负载，它横跨个人 Agent、企业应用、代码执行与复杂工作流，每一种的算力需求都不同。这个设计带来的结果是实打实的：你可以在不重新采购推理的前提下扩并发。

# The blueprint is an OCP spec-design, so it lands as structured config.
# Keep your own rack inventory machine-readable and diff it in CI.
import json, yaml

BLUEPRINT = '''
rack:
  name: helion-cpu-only
  standard: ocp-spec-design
  compute:
    cpu: EPYC 6th-gen
    max_cores: 32768
  cooling: [air, liquid]
  inference: external
  token_router: integrated
'''

spec = yaml.safe_load(BLUEPRINT)
print(json.dumps(spec['rack']['compute'], indent=2))

def validate(blueprint):
    problems = []
    if blueprint['rack']['compute']['max_cores'] > 32768:
        problems.append('core count above the published CPU-only ceiling')
    if blueprint['rack']['cooling'] == 'liquid' and 'facility' not in blueprint:
        problems.append('liquid cooling declared with no facility data')
    return problems or ['ok']

print(validate(spec))

32,768 个核心不是营销数字，是电力与调度问题

token 路由器才是最该抄的部分

Helion 内置一个 token 路由器，把 Agent 的模型调用分发到前沿模型与开源模型。先把硬件放一边。路由出现在基础设施层，意味着路由不再是应用层的事后补丁，而是一条被声明的策略。这一点很重要，因为没被路由的 Agent 流量正是预算的死因：一个并不需要前沿模型的摘要调用，会心甘情愿地用掉前沿模型，而且每小时成千上万次。正确的做法是先给调用分类，再选层级。规划与批判类步骤值得用前沿推理；工具参数生成是 schema 形状的，而且验证成本低；摘要与分类体量大，可以容忍更小的开源模型。硬件只是意味着你可以在不必让每个服务团队各自重写一遍的情况下执行这个划分。

# The integrated token router is the part worth copying in software.
# Route each agent call by task class instead of by which model you like.
ROUTES = {
    'plan':        {'tier': 'frontier', 'max_tokens': 2048, 'why': 'reasoning quality dominates'},
    'tool_args':   {'tier': 'mid',      'max_tokens': 1024, 'why': 'schema-shaped, cheap to check'},
    'summarize':   {'tier': 'open',     'max_tokens': 512,  'why': 'high volume, tolerant of small models'},
    'classify':    {'tier': 'open',     'max_tokens': 64,   'why': 'labels only'},
}

def route(task_class, request):
    rule = ROUTES.get(task_class)
    if rule is None:
        raise KeyError(f'unrouted task class: {task_class}')
    request = dict(request, **rule)
    return request

print(route('summarize', {'model_pool': ['frontier', 'mid', 'open']}))

# An unrouted task class is an unbounded bill. Make it fail loudly.

两个数字决定你需要哪一种机架

在比较机架形态之前，先算 Agent 会话与模型 token 之间的比值。已公布的纯 CPU 配置是 32,768 个核心；如果一个调用工具的 Agent 在等待时大约占用四分之一个 vCPU，那么满占用时量级在十万级并发会话，按 60% 到 70% 的现实占用率算则明显更少。然后在同一时间窗口内算你的 token 需求。如果约束是 token 需求，那么带 MI350P GPU 节点的一体化机架才匹配你的形态。如果你的约束是同时在飞的 Agent 循环数量，而推理已经跑在你不打算替换的集群里，那么 CPU 主导的机架才是诚实答案。电力是第三个输入，而且通常是最先决定答案的那个。

# Epyc cores per rack are a power question as much as a compute question.
RACK = {'cores': 32768, 'watts_per_core': 1.9, 'pue': 1.15, 'kw_per_rack_budget': 90}

def power_plan(rack):
    it_load_kw = rack['cores'] * rack['watts_per_core'] / 1000
    facility_kw = it_load_kw * rack['pue']
    racks = facility_kw / rack['kw_per_rack_budget']
    return {'it_kw': round(it_load_kw, 1),
            'facility_kw': round(facility_kw, 1),
            'racks_at_budget': round(racks, 2),
            'verdict': 'air-coolable with headroom' if racks <= 1 else 'split across racks'}

print(power_plan(RACK))

# Fill in the real TDP and PUE from your own facility before you present it.

先算容量，再谈机架形态

公告里没有的东西

Helion 上 Agent 执行的性能基准没有公布，价格没有公布，除了 Cisco、Dell、鸿海、HPE、联想、QCT、Supermicro、Wiwynn 的生态表态之外，也没有承诺具体的合作伙伴配置。向 OCP 贡献规格被描述为「计划中」而非已完成，上市时间是 2026 年 11 月；在基础设施领域，这意味着：先看规格有没有真的落进代码仓库，再谈采购订单。诚实的总结是：这是一份论证清晰的参考设计，发布方在这个论证里有利益。请把核心数当作可以用来规划的设计上限，而不是今天就能写进容量模型的已交付保证。

# Availability is announced for November 2026. Plan the cutover, do not assume it.
from datetime import date

CAPACITY_PLAN = {
    'rack_shape': 'cpu-only',
    'agent_execution': {'owner': 'platform', 'slo_p95_ms': 400},
    'model_inference': {'owner': 'ml-platform', 'location': 'existing fleet'},
    'rollback': 'route agent execution back to the current cluster',
    'ga_date': date(2026, 11, 30),
}

def preflight(plan):
    checks = {
        'execution_and_inference_are_separate': 'model_inference' in plan,
        'slo_is_attached_to_a_tier': 'slo_p95_ms' in plan['agent_execution'],
        'rollback_is_a_sentence_an_oncall_can_follow':
            len(plan['rollback']) > 20,
    }
    return {k: ('pass' if v else 'fail') for k, v in checks.items()}

print(preflight(CAPACITY_PLAN))
# A rollback plan with no latency budget is a wish, not a plan.

能穿越厂商的那条教训

把 Agent 执行面与模型推理面分开，并各自按自己的曲线扩容。执行规模随并发增长，瓶颈是空闲时的内存与调度；推理规模随 token 增长，瓶颈是加速器显存带宽。把两者捆进一次采购决策，结果就是便宜的那个维度被昂贵的那个维度拖着走。无论最终你的机房会不会放进一台 AMD 芯片的机架，这条分离才是这次发布值得一读的原因：它点出了大多数团队至今仍当成一条曲线来建模的两条曲线。在下一次基础设施评审之前，先把你自己的负载比值写下来，和厂商的对话会短得多。