1. 为什么要在什么都跑得动这件事上死磕做端侧推理这几年我最大的感受是模型精度卷到最后真正卡住项目落地的往往不是算法而是这台机器到底跑不跑得起来。客户现场给你一台五年前的办公本、一台工控机、甚至一块只有几个核心的嵌入式板子你总不能要求人家为了你的模型去换硬件。Julia-1 这个 decision model 的出发点就特别对我胃口——它不追求在顶配 GPU 上刷榜而是把目标定成almost anything也就是从服务器到老旧笔记本、从 x86 到 ARM只要有个像样的 CPU 就能把决策推理跑起来。这里说的 decision model不是那种生成式的大语言模型而是做决策判断的模型给定一段输入文本、结构化特征、或者混合信号输出一个类别、一个动作选择、或者一个打分。这类模型在风控、工单分流、意图识别、设备状态判定这些场景里需求量极大而且往往要求低延迟、可离线、可私有化部署。Julia-1 选择的技术路线是mmBERT-small 作为骨干 PyTorch 训练导出 CPU 优先推理整套组合的核心诉求就一个字稳。稳到什么程度稳到你在没有独显的机器上也能拿到可接受的吞吐。我先把这篇要讲的东西交代清楚免得你读半天发现不是自己要的。下面会围绕四块展开第一为什么是 mmBERT-small 而不是别的骨干这个选型背后的取舍逻辑第二PyTorch 训练到 CPU 推理这条链路里哪些环节最容易翻车第三怎么针对 CPU 做真正有效的优化而不是嘴上说说第四跨平台x86、ARM、老架构部署时我踩过的那些坑和对应的排查链路。适合谁看如果你正在做端侧 NLP、做私有化决策服务、或者被客户机器太烂跑不动模型折磨过这篇应该能帮你省不少时间。提示本文所有性能数字都来自我自己的实测环境不同机器差异会很大重点看方法和思路别死抠具体数值。2. mmBERT-small 这个骨干到底图什么2.1 决策任务对骨干的真实需求很多人一上来就想用大模型觉得参数越多效果越好。但 decision model 和生成任务不一样它的输出空间通常很小——可能就十几个类别或者一个回归分数。这种任务对骨干的要求其实是语义表征够用就行别过度。你用一个 7B 的模型去做三分类意图识别精度可能比 small 模型高一个点但推理成本高几十倍这笔账在端侧根本算不过来。mmBERT-small 的定位刚好卡在这个甜点区。它是多语言 BERT 的小型化版本参数量控制在千万级别隐藏层维度和层数都做了压缩但保留了多语言能力。对 decision model 来说这意味着两件事一是模型体积小量化之后能压到几十 MB塞进内存紧张的设备毫无压力二是前向计算量小CPU 上单条推理能压到几十毫秒级别。我实测过在一台 i5-8250U 的老笔记本上序列长度 128 的情况下单条推理大概在 40 到 70 毫秒之间浮动批量处理还能更快。这里有个容易被忽略的点decision model 的输入往往比生成任务短。工单标题、设备告警、用户 query大多在几十个 token 以内。序列短意味着注意力的计算量跟序列长度平方相关大幅下降这正是 small 骨干能在 CPU 上跑得动的关键。你要是拿它去处理长文档那 CPU 上照样会跪所以场景匹配很重要。2.2 small 骨干的精度损失怎么补用 small 骨干大家最担心的就是精度掉太多。我的经验是decision model 的精度损失可以通过三个手段补回来而且成本都不高。第一个是任务头设计。别直接用 [CLS] 向量接一个线性层就完事可以试试在 [CLS] 基础上拼接 mean pooling 和 max pooling 的结果再过一个两层的 MLP。这个改动几乎不增加推理成本但在分类任务上经常能涨一两个点。原因是 mean pooling 保留了全局语义分布max pooling 抓了显著特征跟 [CLS] 的注意力汇聚形成互补。第二个是领域数据微调。small 骨干的预训练表征是通用的但你的决策任务一定有领域特性。哪怕只有几千条标注数据做一轮微调也能明显改善。我一般会用较小的学习率2e-5 到 5e-5训练 3 到 5 个 epoch早停盯着验证集的 F1。第三个是蒸馏或者伪标签。如果手头有个大模型可以拿它给无标注数据打伪标签再用这些数据去微调 small 模型。这个做法在数据稀缺的场景下特别有效我做过一次意图识别用大模型蒸馏之后 small 模型的 F1 从 0.86 提到了 0.91。2.3 为什么不用更小的模型有人会问既然要省为什么不直接用蒸馏版的小模型比如 TinyBERT 那种我的看法是decision model 的精度底线比生成任务高。生成任务输出有点瑕疵用户能忍但决策错了可能直接导致业务事故。TinyBERT 这类模型在简单分类上还行一旦类别多、边界模糊精度掉得就很明显。mmBERT-small 算是小但还够用的平衡点再往下压就要牺牲可靠性了对决策场景不划算。3. PyTorch 训练到 CPU 推理这条链路的暗礁3.1 训练阶段就要为 CPU 推理埋好伏笔很多人训练的时候用 GPU导出的时候才发现 CPU 上跑不动然后回头改特别浪费时间。我的习惯是训练阶段就按 CPU 推理的约束来设计。具体来说有几个动作。第一固定序列长度。训练时如果用动态 padding导出后 CPU 推理会遇到变长输入每次都要重新分配内存延迟抖动很大。我一般会把序列长度固定成 128 或 256短了补 pad长了截断。这样推理时内存布局稳定速度也稳。第二慎用那些 CPU 不友好的算子。比如某些自定义的注意力实现、复杂的 mask 操作在 GPU 上很快但 CPU 上可能没有优化实现会拖慢整体。训练时尽量用标准算子导出前用torch.jit.trace或者torch.jit.script检查一遍有没有警告。第三把预处理逻辑也考虑进去。tokenizer 在 CPU 上也是要耗时间的尤其是多语言 tokenizer。如果推理服务 QPS 要求高tokenizer 可能成为瓶颈。我一般会把 tokenizer 的并行关掉TOKENIZERS_PARALLELISMfalse避免多线程争抢反而更稳。3.2 导出环节的三种方式和各自适用场景PyTorch 模型导出到 CPU 推理主流有三条路TorchScript、ONNX、还有直接 eager 模式。我一个个说。TorchScript是最省事的torch.jit.trace一把梭导出后是个独立的序列化文件加载不依赖原始模型代码。缺点是 trace 对控制流不友好如果你的模型里有 if/for 依赖输入trace 会把它固化死。decision model 一般结构简单trace 基本够用。ONNX的优点是跨框架、跨运行时可以用 ONNX Runtime 来跑而 ONNX Runtime 在 CPU 上的优化做得相当好尤其是 int8 量化支持成熟。缺点是导出时算子兼容性偶尔出问题需要调 opset 版本。我一般优先试 ONNX跑不通再退回 TorchScript。Eager 模式就是直接加载 PyTorch 模型跑最灵活但性能最差而且部署时要带整个 PyTorch 依赖包体积大。除非是快速验证否则我不推荐生产用。下面是我常用的 ONNX 导出代码注意几个关键参数import torch model.eval() dummy_input { input_ids: torch.randint(0, 30000, (1, 128)), attention_mask: torch.ones(1, 128, dtypetorch.long), } torch.onnx.export( model, (dummy_input[input_ids], dummy_input[attention_mask]), julia1_decision.onnx, input_names[input_ids, attention_mask], output_names[logits], dynamic_axes{ input_ids: {0: batch, 1: seq}, attention_mask: {0: batch, 1: seq}, logits: {0: batch}, }, opset_version14, do_constant_foldingTrue, )opset_version我一般用 14兼容性和算子支持比较平衡。dynamic_axes把 batch 和 seq 都设成动态方便后面批量推理。do_constant_folding打开能把一些常量计算提前折叠掉减小图体积。3.3 量化CPU 提速最狠的一刀CPU 推理想提速量化是绕不开的。FP32 转 int8理论上能快 2 到 4 倍模型体积还能压到四分之一。但量化有坑搞不好精度掉得你怀疑人生。我推荐用ONNX Runtime 的动态量化因为它不需要校准数据集直接对权重做量化对 decision model 这种结构简单的模型效果通常不错。代码就几行from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( model_inputjulia1_decision.onnx, model_outputjulia1_decision_int8.onnx, weight_typeQuantType.QInt8, )动态量化只量化权重激活值在推理时动态量化所以不需要校准数据。代价是激活量化的开销还在提速幅度不如静态量化。如果你追求极致可以做静态量化但需要准备一批校准数据而且要注意校准集的分布要贴近真实输入否则精度会崩。我实测下来动态量化在 mmBERT-small 这种模型上精度损失通常在 0.5 个点以内速度提升 1.8 到 2.5 倍。这个性价比非常高基本是必做项。注意量化后一定要在验证集上重新评估精度别直接上线。我见过量化后某个类别召回率暴跌的情况原因是那个类别的样本在权重分布里占比太小被量化误差淹没了。4. 让 Julia-1 在 CPU 上真正跑快的几个硬招4.1 线程数和批大小的调参逻辑CPU 推理的性能线程数和批大小是两个最关键的旋钮而且它们互相影响。很多人直接默认设置结果要么没吃满 CPU要么线程争抢反而变慢。先说线程数。ONNX Runtime 默认会用满所有物理核心但在多服务共存的机器上这会导致争抢。我的经验是线程数设成物理核心数的 70% 到 80%比较稳留点余量给系统和其他进程。设置方式是import onnxruntime as ort sess_options ort.SessionOptions() sess_options.intra_op_num_threads 6 # 单个算子内部的并行线程 sess_options.inter_op_num_threads 2 # 算子之间的并行线程 sess_options.execution_mode ort.ExecutionMode.ORT_SEQUENTIAL session ort.InferenceSession( julia1_decision_int8.onnx, sess_optionssess_options, providers[CPUExecutionProvider], )intra_op_num_threads控制单个算子比如矩阵乘用几个线程inter_op_num_threads控制不同算子之间的并行。对 BERT 这种以矩阵乘为主的模型intra_op是主力inter_op设小一点1 到 2就行因为算子之间依赖强并行空间不大。再说批大小。CPU 上批处理能提升吞吐但会增加单条延迟。decision model 如果是在线服务延迟敏感批大小设 1 到 4 比较合适如果是离线批量打分可以设到 32 甚至 64吞吐能翻好几倍。我一般会做一个压测找到吞吐和延迟的平衡点。批大小单条延迟(ms)吞吐(条/秒)适用场景14522在线实时46066在线批量16130123离线打分32220145离线大批量这张表是我在一台 8 核机器上的实测可以看到批大小从 1 到 32吞吐提升了 6 倍多但单条延迟也涨了将近 5 倍。所以选哪个完全看你的场景。4.2 内存布局和缓存友好性CPU 推理和 GPU 最大的区别是CPU 有缓存层级内存访问模式对性能影响巨大。BERT 类模型的计算主要是矩阵乘如果内存布局不友好缓存命中率低性能会大打折扣。一个实用的技巧是把权重矩阵转成连续内存。PyTorch 导出的模型有时候权重是转置存储的ONNX Runtime 加载后如果发现不连续会做一次拷贝增加开销。导出前可以用model.half()或者手动contiguous()处理一下。不过这个优化比较底层一般 ONNX Runtime 会自动处理除非你发现加载后第一次推理特别慢才需要关注。另一个是避免频繁的内存分配。推理服务如果每条请求都重新分配输入输出张量GC 压力会很大。我的做法是预分配一批 buffer循环复用。ONNX Runtime 的io_binding就是干这个的io_binding session.io_binding() io_binding.bind_cpu_input(input_ids, input_ids_array) io_binding.bind_cpu_input(attention_mask, attention_mask_array) io_binding.bind_output(logits) session.run_with_iobinding(io_binding)用io_binding能省掉输入输出的拷贝在高 QPS 场景下提升明显。我实测过QPS 从 200 提到 260 左右大概 30% 的提升。4.3 多语言 tokenizer 的隐藏开销Julia-1 用 mmBERT 骨干意味着它要处理多语言输入。多语言 tokenizer 的词汇表通常很大十几万tokenize 一条文本的开销比英文 tokenizer 高不少。在 CPU 上如果 QPS 高tokenizer 可能占到总耗时的 20% 到 30%。优化手段有几个。一是用 fast tokenizerHuggingFace 的tokenizers库是 Rust 实现的比纯 Python 快很多。二是限制最大长度别让 tokenizer 处理超长文本提前截断。三是批量 tokenize把多条请求攒一批一起处理摊薄开销。我做过一个对比单条 tokenize 一条 50 字的文本fast tokenizer 大概 0.3 毫秒纯 Python 的要 2 毫秒以上。QPS 1000 的时候这个差距就是 1.7 秒的 CPU 时间很可观。5. 跨平台部署时那些让人头大的坑5.1 x86 和 ARM 的算子差异Julia-1 号称almost anything那 ARM 平台肯定要覆盖。ARM 上跑 ONNX Runtime最大的问题是某些算子在 ARM 上没有优化实现会 fallback 到通用实现速度慢很多。我遇到过最典型的是 LayerNorm 和 GELU在 x86 上有 AVX 优化ARM 上如果没有 NEON 优化性能差好几倍。解决办法是用针对 ARM 编译的 ONNX Runtime 版本。官方有 ARM64 的预编译包但有时候不够新。如果性能不达标可以考虑自己编译打开 NEON 和 FP16 支持。自己编译比较折腾但一次搞定能省很多事。另一个坑是浮点精度。ARM 和 x86 的浮点运算结果可能有微小差异如果模型对数值敏感比如某些归一化层可能导致输出不一致。我一般会在两个平台上跑同一批测试数据对比输出差异如果差异在 1e-4 以内就认为可接受。5.2 老 CPU 的指令集兼容性almost anything意味着要兼容老 CPU。但老 CPU 可能不支持 AVX2甚至不支持 AVX。ONNX Runtime 默认编译版本可能要求 AVX2在老机器上直接崩。这时候需要用兼容性更好的构建版本或者自己编译时关掉高级指令集。我踩过一次坑在一台老 Xeon 上部署程序启动就报 illegal instruction。排查半天发现是 ONNX Runtime 用了 AVX2 指令而那台机器只支持到 AVX。后来换了一个 baseline 构建版本才解决。所以部署前一定要确认目标机器的 CPU 指令集用lscpu或者cat /proc/cpuinfo看一下 flags。提示如果目标环境不确定宁可牺牲一点性能用兼容性最好的构建版本。稳定运行比跑得快重要。5.3 依赖打包和版本锁定CPU 部署最烦的是依赖管理。PyTorch、ONNX Runtime、tokenizers、numpy每个都有自己的版本要求稍不注意就冲突。我的做法是用虚拟环境 锁版本把所有依赖的精确版本写进 requirements.txt部署时严格按这个装。另外如果只是推理其实不需要装完整的 PyTorch。可以用torch的 CPU-only 版本体积小很多。ONNX Runtime 也有 CPU-only 的包别装成 GPU 版本否则会拖一堆 CUDA 依赖进来白白增大体积。我一般会做一个最小化部署包只包含 ONNX Runtime、tokenizers、numpy 三个核心依赖加上模型文件和推理脚本整个包能压到 100MB 以内拷贝到目标机器解压就能跑特别省心。6. 我踩过的三个真实故障和排查链路6.1 推理结果忽好忽坏线程安全问题有一次上线后发现同一个输入推理结果偶尔会变。不是精度问题是同一个输入两次调用输出不一样。这种问题最吓人因为不可复现。排查链路是这样的先确认模型本身没问题用单线程跑一百次结果完全一致。然后怀疑是多线程问题把intra_op_num_threads设成 1问题消失。定位到是 ONNX Runtime 的多线程在某些情况下有竞态。后来查文档发现如果多个线程共享同一个InferenceSession而 session 的配置里execution_mode设成了并行可能会有状态竞争。解决办法是每个线程用独立的 session或者把execution_mode设成ORT_SEQUENTIAL。我选了后者性能损失不大但稳定性上来了。这个坑的教训是推理服务的线程模型一定要想清楚。如果你的服务是多线程的要么每个线程独立 session要么确保 session 是线程安全的。别想当然。6.2 内存缓慢增长tokenizer 缓存泄漏另一个坑是服务跑几天后内存涨到几个 G重启就好。用 memory profiler 抓了一下发现是 tokenizer 的缓存没释放。HuggingFace 的 tokenizer 默认会缓存一些中间结果如果输入文本种类特别多缓存会一直涨。解决办法是设置tokenizer.model_max_length限制长度并且定期清理缓存或者干脆用tokenizers库直接构造绕过 HuggingFace 的缓存机制。我后来换成了直接加载tokenizer.json内存就稳定了。6.3 首次推理特别慢懒加载和预热最后一个坑是服务刚启动时第一条请求特别慢要好几秒。这是因为 ONNX Runtime 是懒加载的第一次推理才真正初始化算子和内存。解决办法是启动时做一次预热用假数据跑几条推理把该初始化的都初始化掉。# 预热 warmup_input { input_ids: np.zeros((1, 128), dtypenp.int64), attention_mask: np.ones((1, 128), dtypenp.int64), } for _ in range(3): session.run(None, warmup_input)预热三条基本就够了能把首次延迟从几秒降到几十毫秒。这个动作很小但对线上体验影响很大千万别省。7. 关于 Julia-1 这套方案我的一些个人体会做端侧 decision model 这几年我越来越觉得能跑比跑得准更难。Julia-1 这套 mmBERT-small PyTorch CPU 推理的组合本质上是在精度和可部署性之间找平衡。它不惊艳但足够稳稳到你可以放心把它丢到各种奇怪的硬件上。如果你要复现这套方案我的建议是先把训练和导出链路跑通别急着优化然后用 ONNX Runtime 的动态量化拿到第一波提速最后再针对目标平台调线程数和批大小。整个过程里量化后的精度验证和跨平台的指令集兼容性是最容易翻车的两个点多留点时间给它们。另外别迷信 benchmark 上的数字。同一份模型在不同 CPU 上的表现可能差好几倍。真正靠谱的做法是在目标硬件上实测用真实数据压测找到适合那台机器的配置。我见过太多人拿着服务器上的测试结果去部署到工控机然后发现完全不是一回事。最后分享一个小技巧如果你的部署环境特别杂可以考虑准备两套模型——一套 int8 量化版给新机器一套 FP32 版给老机器兜底。启动时探测一下 CPU 指令集自动选合适的版本。这样既能在新硬件上跑得快又不会在老硬件上直接崩。这个策略我在几个项目里用过省了很多现场支持的麻烦。