模型都一样，为什么你推理慢？聊聊 openEuler 是怎么把“最后一公里”榨干的【华为根技术】

模型都一样，为什么你推理慢？聊聊 openEuler 是怎么把“最后一公里”榨干的

做机器学习、搞推理部署的人，十有八九都遇到过这个场景：

模型在开发机上跑得飞快
一上生产，怎么就慢了？

换模型？舍不得
加卡？领导不批

最后一句总结：
“算了，先凑合用吧。”

说句实在话——
很多推理慢的问题，根本不是模型的问题，而是操作系统没“配合好”。

而这，正是 openEuler 这种“为算力而生”的操作系统，真正能发挥价值的地方。

一、先讲清楚一件事：推理慢，慢在哪？

我们先别急着聊 openEuler，先把锅找准。

在真实生产环境里，模型推理速度，往往卡在这几类地方：

1. CPU 指令用不满
2. 内存访问抖动
3. 线程调度乱跳
4. NUMA 架构被忽略
5. 系统默认参数太“保守”

你会发现一个很扎心的事实：

模型只占了性能问题的一部分，剩下的，全是系统工程。

而 openEuler 的优势，恰恰就在这部分。

二、openEuler 到底“强”在哪？一句话概括

我先给你一个不官方、但很贴切的总结：

openEuler 干的事，就是让 CPU、内存、调度器“心往一处使”。

它不是帮你“发明新算子”，
而是让现有模型，在现有硬件上，少浪费一点性能。

而在推理这种高频、稳定、可预测的场景下，这点优化，特别值钱。

三、第一刀：CPU 指令与编译优化，别再用“通用二进制”跑推理

1️⃣ 很多人忽略的一件事

你现在用的推理框架，很可能是：

• pip 装的
• 通用 x86 编译
• 指令集最低公约数

结果就是：

CPU 明明支持 AVX512，你的推理代码却在用 SSE。

openEuler 在这方面，思路非常明确：
👉 编译期就吃满硬件能力

2️⃣ 用 openEuler 编译推理框架（示例）

dnf install gcc gcc-c++ cmake
dnf install openblas-devel

编译时明确指定：

export CFLAGS="-O3 -march=native"
export CXXFLAGS="-O3 -march=native"

这一步的意义是：

• 让编译器针对当前 CPU 生成指令
• 自动启用向量化
• 减少分支预测失败

很多场景下，光这一点就能白捡 10%～30%。

四、第二刀：NUMA 感知，让内存别再“跨山越海”

这是我在生产环境里见过最多被忽略、但收益巨高的一点。

1️⃣ 什么是 NUMA 问题？

简单说：

• 多路 CPU
• 各自有本地内存
• 跨 NUMA 访问，延迟暴涨

但默认情况下：

Linux 很可能把你的推理线程和内存分配到不同 NUMA 节点。

推理这种活，对内存访问极其敏感。

2️⃣ openEuler + NUMA 绑定示例

numactl --cpunodebind=0 --membind=0 python infer.py

或者更工程化一点：

numactl -C 0-15 -m 0 ./inference_server

效果是什么？

• CPU 在本地算
• 内存在本地拿
• Cache 命中率明显提升

我见过一个线上服务：

QPS 直接提升 25%，模型一行都没改。

五、第三刀：调度器与线程模型，别让推理线程“乱跑”

1️⃣ 推理服务的一个特点

和训练不一样，推理通常是：

• 长时间运行
• 线程数稳定
• 延迟敏感

但 Linux 默认调度策略是：

公平优先，不是延迟优先。

openEuler 在调度器、CPU 亲和性这块，给了你更多“精细控制”的空间。

2️⃣ 线程绑定示例（以 Python 为例）

import os

os.sched_setaffinity(0, {0,1,2,3,4,5,6,7})

或者启动时直接控制：

taskset -c 0-7 python infer.py

效果只有一句话：

推理线程别乱跳，缓存才有意义。

六、第四刀：内存与大页（HugePage），推理真的很吃这个

1️⃣ 推理为什么怕内存碎片？

因为：

• 模型参数大
• 访问模式稳定
• TLB Miss 非常致命

openEuler 对 HugePage 的支持非常成熟，而且配置成本低。

2️⃣ 开启 HugePage（示例）

echo 1024 > /proc/sys/vm/nr_hugepages

验证：

grep Huge /proc/meminfo

对某些模型（尤其是大 Embedding、Transformer 推理）来说：

延迟尾部（P99）会明显收敛。

七、第五刀：系统噪声治理，推理最怕“被打断”

你可能没意识到，系统里有很多“暗箭”：

• 定时任务
• 内核后台线程
• 不必要的服务

openEuler 在服务器场景下，默认就更“克制”。

我一般会额外做三件事：

systemctl stop firewalld
systemctl stop irqbalance

再配合 CPU 隔离（进阶）：

isolcpus=2-15 nohz_full=2-15 rcu_nocbs=2-15

一句话总结：

让推理像在“真空环境”里跑。

八、一个小结对比：openEuler 帮你做了什么？

九、Echo_Wish 的一点个人感受

说点掏心窝子的。

这些年我最大的体会是：

推理性能优化，80% 不在模型里，而在系统里。

很多团队：

• 天天调模型结构
• 调 batch
• 调量化

结果最后发现：

还不如好好把操作系统“喂饱”。

openEuler 的价值，不在于“炫技”，而在于：

• 把该榨干的性能榨干
• 把不确定性压到最低
• 让系统“像一台机器”，而不是“一堆偶然”

十、写在最后

如果你现在正在做：

• AI 推理服务
• 在线预测
• 边缘推理
• 高并发模型 API

我给你一句非常实在的建议：

别急着换模型，先把 openEuler 和系统层的潜力用完。

因为在生产环境里：

稳定 + 可预期 + 性能上线，才是真正的“工程胜利”。