Arm Neoverse N4 128核｜智能体时代推理算力选型

我是 4sapi（https://4sapi.com），长期做 API 接入与算力成本这条赛道。今天这期，我聊 Arm 刚发布的 Neoverse CSS N4：单裸片最高 128 核，明确押注智能体时代的 CPU 需求。对跑智能体业务的人来说，这则消息比又一款新模型更值得细读——它直接指向推理集群里最容易被忽视的短板：CPU 侧容量。

一、今日现场：Arm Neoverse CSS N4 的 128 核宣言

Arm 发布了新一代 Neoverse Compute Subsystem（CSS）N4，单裸片最高 128 核，面向数据中心与 AI 推理场景。发布口径里最扎眼的一句话是：智能体负载不再只是大模型推理一次完成，还要并行处理大量请求调度、内存检索、上下文管理与工具调用。换句话说，Arm 已经把"智能体时代"写进了 CPU 的产品定义。

旁证也在持续出现。Arm 在 GPU 调度等方向的投入不断加码——例如 CNCF 旗下的 Karmada 多集群调度项目已经毕业，并已被用于多集群 AI 训练与 GPU 调度；硬件侧，光互连与 OCS（Optical Circuit Switching，光路交换）也在升温。CPU 核数、调度软件、光互连三条线同时推进，指向同一个判断：智能体负载的瓶颈正在从"算不算得出"转向"接不接得住"。

二、痛点：智能体请求把 CPU 侧容量吃穿

过去我在规划推理集群时，习惯把注意力全放在 GPU 上：模型多大、显存够不够、解码吞吐多少。这套思路在单次问答场景里够用，但在智能体场景里很快翻车。我见过不止一个团队，GPU 利用率还不到一半，CPU 侧却先被打满，首 token 延迟飙到十几秒，用户端体验直接崩掉。

原因在于智能体请求的形态。一次智能体任务不再是"发一个 prompt、收一个 response"，而是一连串密集的短调用：请求调度与路由、会话状态读写、向量检索、上下文窗口管理、工具调用编排、结果缓存。这些工作几乎全部落在 CPU 侧，而且并发度极高——几百上千个会话同时推进，每个会话都在轮询、都在检索、都在切换。GPU 在专心生成 token 的同时，CPU 已经把调度与内存带宽吃穿。容量规划不把 CPU 侧算进去，等于给推理集群装了一条看不见的窄喉咙。

三、原理速览：智能体负载的三段构成

先把智能体负载拆成三段：推理算力、CPU 侧上下文/工具调度、网络。图示如下：

智能体负载 = 推理算力 + CPU 侧上下文/工具调度 + 网络

        用户任务
           │
           ▼
   ┌────── 网关与调度（CPU 侧）──────┐
   │ 请求调度 · 会话路由 · 配额限流    │
   │ 工具调用编排 · 多模型分发          │
   └───────────┬──────────────────────┘
               │
   ┌───────────▼───────────┐
   │      GPU 推理侧         │
   │ 预填充（prefill）      │
   │ 解码（decode）token 生成│
   └───────────┬───────────┘
               │
   ┌───────────▼───────────┐
   │    CPU 侧上下文与调度    │
   │ 会话状态 · KV 缓存管理  │
   │ 向量检索 · 工具执行     │
   │ 历史摘要 · 结果缓存      │
   └───────────┬───────────┘
               │
   ┌───────────▼───────────┐
   │      存储与网络          │
   │ 向量库 · 文档 · 日志     │
   │ 请求往返 · 多集群调度    │
   └────────────────────────┘

三段互相牵制：GPU 生成越快，CPU 侧的调度与上下文管理越容易成为新的瓶颈；网络往返越多，会话占用的等待资源越多。容量规划必须三段一起估，而不是只盯 GPU 卡数。

四、推理链路分段算力表

把整条链路按段拆开，每段的负载、瓶颈与扩容信号如下：

链路分段	典型负载	主要算力消耗	扩容信号
token 生成（GPU 推理侧）	预填充 + 解码，模型前向计算	GPU 算力与显存带宽	显存占用高、解码吞吐触顶
CPU 侧（调度与上下文）	请求调度、会话路由、上下文管理、工具调用编排	CPU 核数与内存带宽	CPU 利用率长时高位、上下文切换频繁
存储侧（检索与快照）	向量检索、文档加载、会话快照、日志留存	磁盘 IOPS 与带宽、存储容量	检索延迟上升、IO 排队、容量告警
网络侧（往返与分发）	请求/响应往返、多集群调度、流式回传	带宽与连接数	首 token 延迟波动、连接数打满

这张表的核心结论：token 生成只是整条链路上的一段，CPU 侧与存储侧才是智能体场景里最容易先到极限的环节。

五、从单次推理到会话级负载：估算模型变了

单次推理的容量模型是"QPS × 单请求 token 数"，估算简单直接。智能体场景必须换成会话级模型：一个会话从开始到结束可能横跨几分钟甚至几小时，期间发起几十次模型调用、几十次工具调用，上下文反复重放。容量不再是"同时多少个请求"，而是"同时多少个会话在推进、每个会话占多少常驻资源"。

两个指标必须重新定义。第一是并发会话数而不是 QPS：QPS 只描述每秒新起多少任务，稳态并发 = QPS × 平均会话时长，后者才是真正占用资源的口径。第二是单会话内存占用而不是单请求 token 数：会话上下文、检索结果、工具状态都会常驻内存，几千个会话同时在线，内存消耗直接决定节点规模。

六、旁证：Karmada 与 GPU 调度，Arm 押注的不只是核数

128 核只是表面，Arm 的布局里还有两条暗线。一是 GPU 调度方向持续加码：开源多集群调度项目 Karmada 已被用于多集群 AI 训练与 GPU 调度，并且已在 CNCF 毕业——调度层软件开始把 GPU 当成与 CPU 同级的可调度资源来管理。二是硬件侧的光互连与 OCS 在升温：跨节点通信、多集群协同都在把网络从"配角"变成"瓶颈候选"。

把三条线放在一起读，Arm 押注的是整套"智能体算力底座"：核数负责并行吞吐，调度软件负责把算力分给不断变化的负载，光互连负责让集群之间不拖后腿。对做容量规划的人来说，信号很直接：CPU 侧与网络侧将长期是智能体集群的兵家必争之地，选型时不能只比较 GPU。

七、容量规划方法：并发 × 会话时长 × 内存余量

落地的估算方法只有一条主线：并发会话数 × 单会话资源 × 余量系数。稳态并发会话 = QPS × 平均会话时长；内存需求 = 并发会话 × 单会话内存 × 内存余量；核心需求 = 并发会话 ÷ 每核可承载会话数。以下是一个可以直接套用的 Python 估算片段：

# capacity_plan.py —— 智能体 CPU 侧容量估算
# 输入：QPS（每秒新起会话）、平均会话时长、单会话内存占用

QPS                 = 20      # 峰值每秒新起会话数
AVG_SESSION_SECONDS = 600     # 平均会话时长（秒），长任务取 P95
MEM_PER_SESSION_MB  = 512     # 单会话常驻内存：上下文 + 检索结果 + 工具状态

CONCURRENT_SESSIONS = QPS * AVG_SESSION_SECONDS        # 稳态并发会话数
MEM_TOTAL_GB        = CONCURRENT_SESSIONS * MEM_PER_SESSION_MB / 1024
MEM_HEADROOM_GB     = MEM_TOTAL_GB * 1.3               # 预留 30% 内存余量

SESSIONS_PER_CORE   = 1.5     # 每核可并行承载的会话数（含调度与工具调用开销）
CORES_NEEDED        = CONCURRENT_SESSIONS / SESSIONS_PER_CORE
N4_DIES_NEEDED      = CORES_NEEDED / 128               # 按 Neoverse CSS N4 单裸片 128 核折算

print(f"稳态并发会话: {CONCURRENT_SESSIONS:.0f}")
print(f"内存需求: {MEM_TOTAL_GB:.0f} GB，含余量 {MEM_HEADROOM_GB:.0f} GB")
print(f"CPU 核心需求: {CORES_NEEDED:.0f} 核，约 {N4_DIES_NEEDED:.1f} 个 128 核裸片")

这些参数要从线上实测取得而不是拍脑袋：QPS 与平均会话时长从网关日志取峰值与 P95，单会话内存用容器 cgroup 指标实测，每核可承载会话数靠压测标定。4sapi（https://4sapi.com）的接入控制台会暴露每个模型的并发与延迟指标，这些数据可以直接喂给上面的估算函数。

八、容量规划参数表

把估算里用到的参数汇总成一张表，便于逐项核对取值：

参数	含义	获取方式	对容量的影响
QPS（会话级）	每秒新起的任务会话数	网关日志按秒聚合，取峰值	线性决定稳态并发会话数
平均会话时长	单个任务从开始到结束的秒数	端到端埋点，取 P95	与 QPS 相乘决定稳态并发
单会话内存占用	上下文 + 检索结果 + 工具状态	容器 cgroup 实测	决定内存总量与节点规模
每核可承载会话数	单核并行承载的会话数	压测标定，含调度开销	决定核心数需求
token 生成速率	每秒输出 token 数	推理引擎指标	独立于 CPU 侧，决定 GPU 卡数
内存余量系数	应对尖峰与 GC 抖动的预留比例	按峰值波动幅度取 1.2–1.5	决定最终节点数

这张表配合上面的代码，就能把"智能体集群要多少 CPU"从感觉变成数字。

九、托管推理与自建组合策略

算清容量之后是选型。纯自建和纯托管都有各自的坑，我的建议是组合：稳态基线走自建或长租，尖峰弹性走托管。

自建的成本结构要算全：硬件采购与折旧、机房电力与散热、运维与值班人力、驱动与版本迭代、模型升级后的重新压测。风险同样要算全：利用率不足时闲置成本照付、硬件换代快导致折旧压力大、单一故障点影响面大。自建的优势是边际成本低——负载稳定时，单位 token 成本可以明显低于按量付费。

托管的优势是弹性与免运维：突发流量不用提前囤机器，模型升级由服务方负责。风险是单价结构不透明、峰值时段可能限流、长期用量下总成本偏高。组合策略的落点：用托管承接不可预测的尖峰，用自建或承诺用量承接稳定基线，两层之间用统一网关分发。接入侧只需要一个 OpenAI 兼容协议：

from openai import OpenAI

# 4sapi 合法中转接入：统一 OpenAI 兼容协议，托管与自建网关共用一套代码
client = OpenAI(
    api_key="sk-4sapi-xxxx",          # 在 4sapi 控制台申请
    base_url="https://4sapi.com/v1",  # 中转端点
)

网关层统一之后，切模型、切供应商、切自建集群都只是配置变化，不碰业务代码。

十、成本与风险提示：峰值合同与存储账单

算力选型里最容易被合同坑住的是峰值付费。一类是承诺用量合同：签了固定量，就按承诺量计费，实际跑不满时钱照付，跑超时又按更高单价结算。另一类是峰值计费模型：按当月最高一小时的用量定价，一次流量尖峰可能让整月账单上一个台阶。我的建议：承诺量只签稳定基线部分，尖峰一律走按量或托管弹性，宁可单价略高，也不把不可预测的部分锁进合同。

存储侧的风险同样不可忽视。智能体场景天然产生大量会话快照、上下文日志与检索索引，数据存储与带宽在整体预算里的占比持续上升，存储与带宽的计费压力会间接传导到应用成本上。容量规划时把存储与带宽一起算进去，日志分级留存（热数据、温数据、归档），会话快照定期清理，存储就不该成为账单里的隐形大头。

十一、合规与接入注意

容量规划与选型之外，接入合规是底线。全部模型调用都应走官方合法 API 或合规中转渠道，不碰任何来路不明的代理与非法镜像；多集群、多供应商调度时，确认数据流向符合接入方的数据使用条款；会话日志与检索索引涉及用户数据时，做好脱敏与访问控制。计费优化必须在合规框架内进行——合法接入、容量规划、计费优化三者缺一不可，省钱的底线是不违规。

十二、验收清单

容量方案落地后，我用这份清单逐项验收：

稳态并发会话数按 QPS × 平均会话时长测算，取 P95 而非平均值
单会话内存占用来自线上实测，内存余量系数取 1.2–1.5
CPU 侧与 GPU 侧分别规划，二者都有独立扩容信号
存储与带宽计入容量预算，日志分级留存与快照清理已上线
承诺用量只覆盖稳定基线，尖峰流量走按量或托管弹性
托管与自建共用统一网关，切换只改配置不动代码
全部模型调用走官方合法 API 或合规中转，数据流向有据可查
压测覆盖 CPU 高位与首 token 延迟，阈值告警已接入

八项全部通过，算力选型才算闭环。

十三、总结

Arm Neoverse CSS N4 的单裸片 128 核，把智能体时代的 CPU 需求摆到了台面上：负载重心从"一次推理"转向"并行调度 + 上下文管理 + 工具调用"，容量规划的口径也从 QPS 换成会话级并发，CPU 侧与存储侧成了新的瓶颈候选。我的做法是先按并发会话 × 会话时长 × 内存余量估算，再以托管承接尖峰、自建承接基线的组合方式落地，同时管住峰值合同与存储账单这两类隐性成本。4sapi（https://4sapi.com）会持续跟进推理算力与接入侧的变化，也欢迎在评论区聊聊各自的算力选型经验。