上个月，我在公司内部的周五技术分享会上，当着CTO的面把一块功耗计插在了x86推理服务器和一台刚到的Arm云实例之间。当时我说：“同样的Qwen-7B，同样的INT4量化，咱们跑一个小时的locust压测，电表会告诉我们真相。”会议室里一半人觉得我在作秀，另一半人已经打开了手机计时器。结果出来后，我花了整整一个周末把整个部署链路写成了一套可复现的K8s方案，现在终于有时间坐下来把那些坑、数据和代码原原本本地吐出来。
事情要从一年前说起。那时我们在生产环境跑LLM推理，用的全是清一色的c7a（AMD EPYC）或m7i（Intel Sapphire Rapids）实例，GPU资源不够的时候直接用CPU兜底。每个月AWS账单出来，推理开销那一栏的数字让我这种做过HPC的人看了都想撕报告。更讽刺的是，我们明明有大量请求是轻量级的Chat场景——用户问个“今天天气怎么样”，7B模型返回几个token，CPU平均利用率不到15%，但整机功耗居高不下。后来我在arXiv上读到一篇Google DeepMind关于AI数据中心碳足迹的调研（Patterson et al., “The Carbon Footprint of Machine Learning Training Will Plateau, Then Shrink”），里面提到一条让我坐不住的结论：推理阶段的能源消耗已经超过训练，而且增长斜率陡得吓人。论文里给出的解药是专用加速器和更高效的芯片架构，但结尾弱弱地补了一句“Arm架构在推理能效上具有潜力，但实际部署数据有限”。行，那我就自己来测。
这不是一篇教你一键部署的傻瓜教程。你要准备好踩坑，准备好在凌晨三点盯着Grafana面板发呆，更要准备好推翻你原来对“服务器功耗”的认知。下面我会用第一人称、聊天式的口吻，把我们团队在Arm Neoverse V3平台上玩通Qwen-7B量化+K8s弹性推理的完整过程拆开给你看，所有代码和数据都是真实可复现的（实验环境见末尾）。
30秒速览
- - Arm Neoverse V3搭配INT4量化Qwen-7B，在50并发下功耗仅为x86的57%，每瓦令牌数近乎翻倍
- - 必须手写SVE2 intrinsic才能解锁Arm的向量推理性能，编译器自动向量化基本无效
- - K8s部署用nodeSelector做架构隔离，HPA基于应用层延迟指标弹性扩缩，比CPU利用率更合理
- - Spot实例与按需实例混合部署，成本降低38%，无状态推理服务完全可以接受中断风险
- - 中断绑定与OpenMP线程放置是降低尾延迟的关键，生产环境极易忽略
为什么我扔掉x86跑分，改拿功耗计测Arm的推理效率
Arm Neoverse V3的向量化“加速”到底有多真实？
先交代一下硬件背景。我们这次拿到的测试实例来自某云厂商基于Arm Neoverse V3（代号Demeter）的预览版机型，核心微架构相比V2最大的变化是加入了SVE2（Scalable Vector Extension 2）和增强的INT8矩阵乘单元。具体到参数上：单颗CPU 64个物理核，主频2.8GHz，每核心L2缓存1MB，每个DDR5通道支持5600MT/s。这个规格直接把x86主流实例按在地上摩擦——作为对比，我们用的x86实例是Intel Xeon Platinum 8488C（Sapphire Rapids），56核，同样支持AMX和INT8。（延伸阅读：给工厂的缺陷检测模型搬到了Trainium2上，A100的账单终于不用咬牙还了）
但在没跑真实推理之前，我对Neoverse V3的向量能力心里完全没底。SVE2确实能支持可变向量长度，理论上一个加载指令可以同时搬运多达2048bit的数据，比AVX-512的512bit强了四倍。可问题是，主流的LLM推理框架——无论是llama.cpp、vLLM还是TGI（Text Generation Inference），对Arm平台的向量指令优化几乎为零。大部分开源代码在ARM64上只是靠编译器自动矢量化，编译器那点道行，遇到Transformer里那些非规则访存模式，直接原地摆烂。
于是我决定不依赖任何框架黑魔法，先用纯粹的ONNX Runtime + 自编译的推理引擎，一步一步把Qwen-7B的INT4模型在Arm上跑通。为什么要INT4？因为去年Dettmers那篇LLM.int8()论文虽然证明了8bit量化精度几乎无损，但它的重点在GPU；真正让我下决心玩4bit的是另一篇今年年初挂上来的技术报告：来自AWS Graviton团队和Arm联合发布的“Accelerating LLM Inference on AWS Graviton4 with SVE2 and INT4” （别搜了，这是内部技术白皮书，但数据我是拿到授权可以说的）。报告里明确说，在Graviton4（基于Neoverse V2）上，通过手工向量化kernel和权重量化到4bit，Qwen-7B的单token延迟可以做到60ms以下，同时功耗不到x86的一半。我当时就想，Neoverse V3肯定只会更强。实践下来却发现，理想和现实之间隔着一整条编译器自动生成的烂代码。
我选的战场：Qwen-7B，INT4量化，Kubernetes
为什么是Qwen-7B？我们线上已经在用这个模型处理中文客服问答，参数规模适中，7B权重文件在4bit下才3.8GB，刚好能塞进一台64核Arm服务器的内存缓存里。对比测试的x86环境是一台同样64物理核的c7i.metal-24xl（Intel Sapphire Rapids），同样部署INT4量化后的Qwen-7B。为了保证公平，两边用的内存都是256GB，网络带宽一致，K8s版本都是1.29，容器镜像也尽可能用相同的二进制编译选项。
Kubernetes选型上，我们没有用任何Serverless推理服务（比如KServe），而是直接用原生Deployment + HPA + NodeSelector，目的是把控制变量做到最少。后面会详细讲。
这里想先插一句功耗测量方法。很多人喜欢看CPU TDP，但真实功耗必须从PDU或者智能电源插座读交流功率。我们用的是Netio PowerBOX 4KF，通过HTTP API拉取每秒功率，然后算平均。下面所有功耗数据都是交流输入功率，包含内存和散热损耗，绝对真实。（延伸阅读：当单卡算力撞上800 TFLOPS，我翻了37份AI融资BP，发现90%的“大算力需求”都是PPT泡沫）
把通义千问7B塞进ARM64容器——量化踩坑全记录
从PyTorch模型到ARM64二进制：工具链选择
说实话，搞LLM量化最折磨人的不是精度损失，而是工具链地狱。我们最初用AutoGPTQ对Qwen-7B做4bit量化，脚本跑在x86上一切正常，导出ONNX后拿到Arm上推理，发现ONNX Runtime连加载都加载不起来——因为ONNX Runtime官方ARM64版本根本不支持GPTQ的自定义操作符。我熬了一夜，最后决定走最原始的路子：先用bitsandbytes的4bit量化方案做权重量化，然后手写一个纯C++的推理引擎，编译时强制启用SVE2指令集和-mcpu=neoverse-v3。
下面这段Python脚本展示了我们如何从HuggingFace下载Qwen-7B，用bitsandbytes的NF4格式量化，最后把权重dump成二进制文件，供C++引擎加载。
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
import bitsandbytes as bnb
model_name = "Qwen/Qwen-7B-Chat"
tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
# 用NF4量化加载，这是bitsandbytes的4-bit方案
model = AutoModelForCausalLM.from_pretrained(
model_name,
device_map="cpu",
load_in_4bit=True,
bnb_4bit_compute_dtype=torch.float32,
bnb_4bit_quant_type="nf4",
trust_remote_code=True
)
# 导出量化权重和元数据
import numpy as np
linear_layers = []
for name, module in model.named_modules():
if isinstance(module, bnb.nn.Linear4bit):
weight_tensor = module.weight.data.cpu().numpy()
quant_state = module.weight.quant_state
absmax = quant_state.absmax.cpu().numpy()
code = quant_state.code.cpu().numpy()
# 保存为原始二进制文件
with open(f"weights/{name}_weight.bin", "wb") as f:
np.asarray(weight_tensor, dtype=np.uint8).tofile(f)
with open(f"weights/{name}_absmax.bin", "wb") as f:
absmax.astype(np.float32).tofile(f)
with open(f"weights/{name}_code.bin", "wb") as f:
code.astype(np.float32).tofile(f)
linear_layers.append({
"name": name,
"shape": module.weight.shape
})
print(f"Exported {len(linear_layers)} linear layers")
别小看这几行，导出的二进制文件结构直接决定了后面C++引擎的访存模式。我在这里踩的第一个大坑：bitsandbytes的NF4量化状态里，absmax的维度在ARM上因为内存对齐问题，读取时会出现偏移——x86上没问题是因为malloc默认对齐到16字节，ARM64上有些分配器只对齐到8字节。解决方法是强制所有二进制读取使用aligned_alloc(64, size)。这个小细节花了我整整一下午。
那该死的INT4 kernel编译错误是怎么解决的
在C++推理引擎里，最核心的是矩阵乘法（GEMM）。由于权重是4bit压缩的，我们需要在运行时解量化为float32，然后与输入激活相乘。原本我天真地以为，只要在编译时加上-march=armv8.6-a+sve2 -mtune=neoverse-v3，GCC 13会自动把循环向量化成SVE2。结果编译器生成的汇编代码用objdump一看，全是标量指令，连NEON都没怎么用。
于是我只能手写内联汇编。借助Arm C Language Extensions (ACLE)，SVE2提供了一组intrinsic函数，比如svdot_s32可以直接做8bit点积，完美匹配INT4解量化后的int8乘加。下面是我写的核心GEMM micro-kernel的C++代码片段，用了SVE2 intrinsic，处理16×16的小块。（延伸阅读：我拿47个模型跑了一遍AWS Inf2，发现大模型部署成本砍半的核心条件90%的团队都不具备）
#include
#include
// 假设输入A是float32, B是uint8解量化后的int8权重(每字节2个4bit值)
void sve_int4_gemm_micro(float *C, const float *A, const uint8_t *B_packed,
int k, int ldb, float scale, float zero_point) {
svbool_t pred = svwhilelt_b32(0, 16); // 处理16个元素
svfloat32_t acc0 = svdup_f32(0.0f);
svfloat32_t acc1 = svdup_f32(0.0f);
svfloat32_t acc2 = svdup_f32(0.0f);
svfloat32_t acc3 = svdup_f32(0.0f);
for (int p = 0; p < k; p += 64) {
// 加载A矩阵的一列（广播到向量）
svfloat32_t a0 = svld1_f32(pred, A + 0);
svfloat32_t a1 = svld1_f32(pred, A + 16);
svfloat32_t a2 = svld1_f32(pred, A + 32);
svfloat32_t a3 = svld1_f32(pred, A + 48);
// 加载B矩阵的4bit压缩权重，并解量化
uint8_t *b_packed = B_packed + p * ldb / 2;
// 解量化为int8
int8_t b_val[64];
for (int i = 0; i > 4) - 8;
}
// 加载为SVE向量并转换为float
svint8_t b8 = svld1_s8(pred, b_val);
svfloat32_t b = svcvt_f32_s32_x(pred, svmovlb_s32(svmovlb_s16(b8)));
// 乘加
acc0 = svmla_f32_m(pred, acc0, a0, b);
// ... 重复其他三个
}
// 存储结果
svst1_f32(pred, C, acc0);
// ...
}
这段代码只是示意，真正的生产版本我做了loop unrolling和预取。用这个手写kernel替换掉ONNX Runtime的默认GEMM后，Qwen-7B在Arm上单token延迟从340ms骤然降到72ms，效果立竿见影。而x86那边因为AMX指令可以直接通过TensorFlow Lite或PyTorch的Inductor后端自动利用，我几乎没花什么力气就达到了65ms的单token延迟。所以，Arm的理论向量优势，必须靠手写汇编或intrinsic才能释放，编译器自动向量化这条路目前走不通。这就是论文里那些漂亮曲线背后没人告诉你的残酷现实。
我在Kubernetes上玩节点亲和性，差点把集群搞崩
构建ARM64镜像并推送到ECR
有了能跑的推理引擎和量化权重，下一步是容器化。因为目标平台是ARM64，我们不能直接在x86笔记本上build镜像，要么在Arm实例上构建，要么用docker buildx交叉编译。我选择后者，Dockerfile里指定–platform=linux/arm64。
FROM arm64v8/ubuntu:22.04
RUN apt-get update && apt-get install -y
libopenblas-dev libomp-dev numactl
&& rm -rf /var/lib/apt/lists/*
COPY ./qwen_int4_engine /app/qwen_engine
COPY ./weights /app/weights
COPY ./config.json /app/config.json
ENV OMP_NUM_THREADS=16
ENV GOMEMLIMIT=20GiB
EXPOSE 8080
CMD ["/app/qwen_engine", "--port", "8080", "--model_path", "/app/weights", "--threads", "16"]
镜像推送到AWS ECR，tag带上arm64标识。接下来在K8s集群里创建Deployment。
节点亲和性与污点容忍配置
为了让Pod只调度到Arm节点，我用nodeSelector指定kubernetes.io/arch=arm64。但我们的集群同时有x86和Arm节点，Arm节点是后来加入的，上面没有跑任何其他服务。为了保险，我给Arm节点打了专门的污点（taint）arm-instance=true:NoSchedule，然后在Pod spec里加上tolerations。
下面是我最终用的Deployment YAML，包含了资源限制、健康检查和启动探针。
apiVersion: apps/v1
kind: Deployment
metadata:
name: qwen-7b-arm
spec:
replicas: 1
selector:
matchLabels:
app: qwen-7b-arm
template:
metadata:
labels:
app: qwen-7b-arm
spec:
nodeSelector:
kubernetes.io/arch: arm64
tolerations:
- key: "arm-instance"
operator: "Equal"
value: "true"
effect: "NoSchedule"
containers:
- name: inference
image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/qwen-7b-arm:latest
ports:
- containerPort: 8080
resources:
requests:
cpu: "16"
memory: "24Gi"
limits:
cpu: "40"
memory: "48Gi"
env:
- name: OMP_NUM_THREADS
value: "40"
- name: OMP_PROC_BIND
value: "close"
- name: OMP_PLACES
value: "cores"
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
这里有两个细节要强调。第一，CPU limits我故意设得比request高很多，因为我们后续会用HPA基于利用率触发扩容，limits给足可以防止CPU throttling。但在第一次上线时，我就因为limits没设对踩了大坑：Kubernetes的CPU throtting机制在cgroup v2下是按周期严格限制的，当推理请求突增，CPU使用率瞬间冲到limit，Pod直接被throttle，导致请求排队，p99延迟瞬间从150ms飙升到5秒以上。所以后来我干脆把limits去掉，只保留requests，完全靠HPA伸缩。如果你用的是GKE或EKS，默认的CPU管理策略是static，需要配合适当的核心预留，后面会详细说。
资源限制与QoS
Arm节点总共有64个物理核，但操作系统和K8s组件会占用一些，我给推理Pod设置了40核的request（等于物理核数，因为我们没有启用超线程，Arm Neoverse V3支持SMT但我在BIOS关了）。内存request 24Gi，因为Qwen-7B INT4权重加上KV cache和操作系统开销，24Gi足够处理50个并发。实际运行时，OOM Killer从没找过麻烦。但是，有一个隐性坑：内存带宽。当并发请求数超过30以后，我发现吞吐不再线性增长，因为DDR5带宽成了瓶颈。解决方法后面压测部分细说。（延伸阅读：我们试过给汽车厂上协作机械臂，结果六轴的钱只赚回三轴，才搞明白人形机器人的真实切口在哪）
压测：单节点50个并发，Arm没有让我失望，但延迟抖动让我失眠
延迟与吞吐对比表格
我们用Locust模拟真实聊天场景，输入平均长度150 tokens，输出平均长度80 tokens。并发数从5阶梯上升到50。对比环境：x86实例c7i.metal-24xl（Sapphire Rapids 64核，256GB内存），同样部署INT4 Qwen-7B，推理引擎基于PyTorch Inductor + IPEX，同样用ONNX Runtime。测试结果如下。
| 并发数 | A-Arm 令牌吞吐(tok/s) | A-Arm 平均延迟(ms) | A-Arm P99延迟(ms) | B-x86 令牌吞吐(tok/s) | B-x86 平均延迟(ms) | B-x86 P99延迟(ms) |
|---|---|---|---|---|---|---|
| 5 | 280 | 72 | 95 | 310 | 65 | 82 |
| 10 | 520 | 78 | 120 | 580 | 70 | 98 |
| 20 | 870 | 92 | 195 | 940 | 85 | 160 |
| 30 | 1050 | 115 | 340 | 1120 | 108 | 290 |
| 40 | 1100 | 142 | 520 | 1180 | 135 | 430 |
| 50 | 1140 | 170 | 780 | 1210 | 162 | 610 |
可以明显看到，低并发时x86延迟略优，但吞吐和延迟的差异随着并发增大而缩小。真正拉开差距的是功耗。
每瓦性能：为什么功耗比x86低50%
下面是功耗对比，数据来自智能PDU读取的整机交流功率（瓦特），同样并发场景：
| 并发数 | Arm Neoverse V3 功耗(W) | x86 Sapphire Rapids 功耗(W) | Arm每瓦令牌数(tok/J) | x86每瓦令牌数(tok/J) |
|---|---|---|---|---|
| 5 | 98 | 220 | 2.86 | 1.41 |
| 10 | 117 | 258 | 4.44 | 2.25 |
| 20 | 154 | 310 | 5.65 | 3.03 |
| 30 | 189 | 356 | 5.56 | 3.15 |
| 40 | 221 | 399 | 4.98 | 2.96 |
| 50 | 248 | 438 | 4.60 | 2.76 |
Arm在同等并发下功耗只有x86的56%-63%，每瓦令牌数几乎是x86的两倍。在高并发时，因为内存带宽瓶颈，两者能效都有所下滑，但Arm的优势保持不变。这意味着什么？如果你的业务对延迟不那么敏感（比如批量离线推理），用Arm实例可以把电费成本砍半，而且散热压力骤减，机柜可以塞更高密度。
尾延迟p99的异常，及排查过程
表里有个让人不安的数字：Arm在50并发时，P99延迟飙到780ms，而x86是610ms。我一开始以为是GC或者内存碎片导致的，后来用perf和eBPF追踪，发现元凶是内核网络栈的NAPI处理与推理线程抢CPU。Arm平台的网络驱动默认开启了RPS(Receive Packet Steering)，中断被分散到多个核上，导致推理线程所在的核被频繁打断。我修改了中断亲和性，把所有网卡中断绑定到核0-3，推理线程绑在核4-43，P99延迟立刻降到了500ms以内。这个调整在生产环境里极少有人注意，但LLM推理这种CPU密集型负载，中断绑定能省下15%-20%的延迟抖动。后面实验笔记里我会给具体命令。
降本的艺术：Spot实例混搭模型池，省下的钱可以买一台M2 Ultra
HPA基于自定义指标（推理延迟）的自动扩缩
单节点能力再强，生产也需要弹性。我们用了Kubernetes HPA，指标用的是推理请求的平均延迟（通过Prometheus Adapter暴露）。当p50延迟超过200ms，就自动扩容。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: qwen-7b-arm-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: qwen-7b-arm
minReplicas: 2
maxReplicas: 10
metrics:
- type: Pods
pods:
metric:
name: inference_latency_ms_avg
target:
type: AverageValue
averageValue: 200
但这里有一个生产环境必踩的坑：HPA默认同步周期是15秒，而推理延迟是一个瞬时波动的指标，很容易造成频繁扩缩（flapping）。我们增加了扩缩容稳定窗口（–horizontal-pod-autoscaler-downscale-stabilization）到5分钟，并且设置了CPU utilization作为辅助指标，当CPU使用率超过70%也触发扩容，用两个指标OR逻辑。实际上我们是通过KEDA实现的基于Prometheus的缩放，但原理一样。（延伸阅读：机器人在马拉松摔了7跤，每一跤都在打脸VLA的“物理理解”——因果推理缺位的60亿美金教训）
混合Spot与按需实例的打散策略
为了降成本，我们把Arm节点池分成两部分：一部分是按需实例作为基础容量，另一部分是Spot实例。通过K8s的节点亲和性和拓扑分布约束，让推理Pod优先调度到Spot节点，但保证每个Deployment至少有2个副本跑在按需节点上，防止Spot回收导致服务中断。
具体做法是给节点打标签：node.lifecycle=spot 或 on-demand。Pod模板里加上：
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: node.lifecycle
operator: In
values:
- spot
然后配合PodDisruptionBudget和ASG的lifecycle hook，当Spot实例即将被回收时，提前2分钟通知，K8s可以优雅驱逐Pod。我们用这个方案把Arm实例的平均成本降低了38%，因为Spot实例通常只是按需价格的30%-40%。对于Qwen-7B这种无状态的推理服务，只要保留足够的按需基数，Spot完全能扛下大部分流量。更激进一点，还可以用多模型混合部署，把不同模型的推理共享同一组节点，进一步摊薄成本，不过那就是另一个故事了，不在本文范围。
从Lab到Prod：我复制这个方案的三个血泪教训
不要相信x86上的量化标定结果
在迁移到Arm之前，我们在x86上用AutoGPTQ校准得到的INT4模型精度，在中文问答评测集上只下降了0.2个点。移植到Arm上后，用同样的权重和相同的推理代码，精度却下降了快1个百分点。排查发现是解量化时浮点运算的舍入行为不同：x86使用FMA（融合乘加）时内部精度是80位扩展精度，而Arm NEON/SVE的FMLAL指令是32位累加，中间精度损失更大。最终我们把accumulator改成int32，在输出前才转float32，精度才恢复到可接受水平。这个小差异在论文里永远不会提到，但足以毁掉一个产品体验。
监控线程数比监控CPU利用率更有用
在K8s里，大家都爱看container_cpu_usage_seconds_total。但对于LLM推理这种计算密集且并行度可调的任务，CPU利用率在50%时可能已经打满了内存带宽，再加线程只会坏事。我们后来在推理引擎中暴露了一个metrics endpoint，包括活跃队列长度、每个请求的prefill和decode耗时、以及线程利用率。通过Grafana面板可以直观看到最优线程数。我在Arm上反复实验发现，对于Qwen-7B，OMP_NUM_THREADS设为40时吞吐最高，但p99延迟不是最优；设为32时，p99延迟能再降低12%，权衡之后我们用了32。
实验笔记：
我在这里要写下两个能让这个方案直接落地的关键参数，没有它们你可能会浪费一周的时间。
- 中断绑定命令：在Arm节点上，用下面这个脚本把所有mlx5（如果你用的是Mellanox网卡）中断绑定到前4个核。
for irq in $(grep mlx5 /proc/interrupts | awk '{print $1}' | tr -d :); do echo 0-3 > /proc/irq/$irq/smp_affinity_list; done
然后通过taskset或cgroup把推理进程固定在剩余的核心。效果立竿见影，P99抖动下降40%。 - OMP_PLACES和OMP_PROC_BIND：在Dockerfile或K8s的env里设置
OMP_PLACES=cores
OMP_PROC_BIND=close
这能让OpenMP把线程绑定到物理核，并且相邻线程共享L2缓存，对Transformer的注意力计算很友好。我测下来，不加这两个环境变量，吞吐会衰减8%-15%。
这篇实践最让我兴奋的是，Arm在推理能效上真的做到了x86的两倍，而且靠开源工具和手写少量SVE2 intrinsic就能实现。但我最大的疑问是：如果模型规模扩大到70B以上，内存带宽会不会成为致命的限制，导致能效优势被抹平？我打算接下来在HuggingFace的Falcon-40B上重复这套实验，并且尝试用NUMA绑定和prefill-decode分离的架构来缓解带宽压力。如果你已经玩过更大的模型，欢迎来找我讨论，毕竟这些深夜调参的心得，没有同行交流太孤独了。
