长上下文推理在最近一年已经成为 NLP 落地中最常见的需求之一合同审查、论文摘要、客服工单分类、RAG 检索后的精排打分都需要把几百甚至几千 token 的文本一次性送入模型。这类需求在 GPU 上可以靠显存和 Tensor Core 硬扛但到了 CPU 部署场景显存没有了并行度下降了推理耗时和内存占用会被成倍放大。LFM2.5-Encoders 作为一类面向长文本的编码器模型系列正是在这种背景下进入 CPU 推理选型视野的。它与 decoder-only 模型在计算模式上有明显差异更适合做长文本编码、分类、向量化等任务同时又有快速长上下文推理的潜力。这篇文章不聊抽象的理论而是围绕 CPU 推理的瓶颈把环境准备、最小推理示例、性能调优参数和常见故障排错方法逐一展开帮助你在 CPU 机器上把该模型系列的推理流程跑起来并把耗时和内存控制在合理范围。1. 长上下文推理在 CPU 上的瓶颈到底是什么1.1 自注意力计算量随文本长度平方增长标准 Transformer 中自注意力需要计算 query 与所有 key 的点积。对于长度为 n 的输入注意力矩阵规模是 n × n计算复杂度为 O(n²)。当 n 从 128 增长到 4096理论计算量增长约 1000 倍。GPU 可以用大规模并行单元去摊平这种增长CPU 则要依赖有限的物理核心和向量指令宽度因此长文本带来的计算量增幅在 CPU 上会更加直接地变成耗时增长。下表给出的是不同长度下自注意力理论点积次数数量级对比用于理解长度增长的放大效应输入长度注意力点积次数量级相对 128 token 的倍数128约 1.6×10^41512约 2.6×10^5161024约 1.0×10^6642048约 4.2×10^62564096约 1.7×10^7约 1000实际耗时还受算子实现、内存布局和是否使用加速指令影响但数量级关系不会变。长上下文 CPU 推理的第一个优化思路就是想办法降低注意力部分的计算总量比如使用稀疏注意力、局部窗口或分段编码。1.2 内存带宽和缓存命中率是更隐蔽的瓶颈注意力计算不仅要算还要频繁读取 K 和 V 矩阵。每个 query 都要读取全部 key 计算点积再读取对应的 value 做加权求和。如果 K、V 矩阵在计算过程中不能放进 CPU 的 L2/L3 缓存模型就会反复从主内存搬运数据。CPU 内存带宽远小于 GPU 显存带宽并且多核共享同一内存控制器一旦多个线程同时读取大量参数和中间激活值带宽会被瞬间打满。典型现象是top显示 CPU 使用率并不高但推理时间却很长。这通常不是计算单元不够用而是内存读写速度跟不上。诊断这类问题可以对比短输入和长输入的耗时增长曲线。如果长度增加一倍而耗时增长远超一倍往往就是缓存不断失效、内存带宽被耗尽。对长上下文编码器来说控制中间张量大小、避免复制 KV 数据、尽量让输入形状固定都是减少内存带宽压力的有效手段。1.3 CPU 多核调度不是线程越多越快很多开发者拿到 32 核机器后第一件事就是让 PyTorch 把线程数设满。结果常常是推理没有变快反而出现抖动。原因有两层线程数超过物理核心数后超线程逻辑核共享同一个物理核的资源多开的线程并不能带来真实并行。多线程切换时不同核心之间的缓存同步开销会增加如果线程不断迁移大量时间耗在唤醒、上下文切换和缓存预热上。热词里提到的“cpu核心停车问题”从调度角度可以这样理解操作系统为了让部分核心进入低功耗状态可能把线程集中调度到少数核心造成某些场景下负载不均。长上下文推理是突发型计算线程频繁醒来和休眠会放大调度延迟。正确做法是用线程亲和性把工作线程绑定到固定物理核心并让线程数等于物理核心数而不是逻辑核心数。2. LFM2.5-Encoders 适合 CPU 长上下文推理的设计基础2.1 Encoder 结构一次前向就能得到整篇文本向量LFM2.5-Encoders 从命名看属于编码器模型这种结构最大的特点是输入与输出一一对应整个文本序列可以一次性编码。推理时只需要一次 forward不需要像 decoder-only 模型那样逐 token 生成。自回归生成过程中每一步都依赖上一步输出串行延迟对 CPU 非常不友好而 Encoder 前向则可以把一批 token 同时参与计算让 CPU 的多个核心尽量并行。对实际业务来说这意味着长文本分类一次 forward 拿到整段文本的语义表示。文本向量化一次 forward 后做 mean pooling 或取首尾向量。检索精排对 query 和候选文档编码后计算相似度。这类任务的单次调用延迟主要来自一次前向优化方向更集中也更适合在 CPU 上做吞吐优化。2.2 2.5 版本迭代里常见的效率折中思路没有更多资料确认 LFM2.5-Encoders 内部是否使用了稀疏注意力、线性注意力或局部窗口但从“2.5”这类带小数点的版本迭代规律看通常会在容量和推理速度之间做明显折中。常见的做法有三种控制层数适当扩大 hidden size让模型在总参数不变的情况下减少顺序计算深度。使用分组注意力或局部注意力把注意力矩阵限定在局部窗口内将 O(n²) 降为 O(n×w)w 是窗口大小。用可选的注意力 kernel 实现在 CPU 上通过 oneDNN 或 SDPA 等融合实现来减少中间矩阵落盘。如果 LFM2.5-Encoders 在实际发布中采用了其中某一种设计那么它的 CPU 推理特征会比同尺寸全注意力模型更友好。落地前应查看官方模型卡片中的结构说明重点确认max_position_embeddings、num_hidden_layers、attention_probs_dropout_prob等配置避免在推理阶段开启不必要的训练逻辑。2.3 为什么编码器比解码器更适合 CPU 长上下文编码器和解码器的核心差异不在参数量而在计算路径。解码器生成阶段存在严格的串行依赖每一步新的 token 都要依赖之前的 token 状态CPU 无法通过增加并行度来降低延迟。编码器则可以把所有 token 同时计算非常适合 CPU 的 batch 式并行。对比维度Encoder 模型Decoder-only 模型长文本输入一次前向编码逐 token 生成输入是前缀计算并行度高token 间无串行依赖生成阶段低受 LFM2.5 自回归依赖限制内存占用单次前向中间张量可释放需要缓存 KV长度越长缓存越大典型任务分类、向量化、精排文本生成、对话、摘要所以如果你的目标是“读完整篇长文本然后给出向量或类别”编码器模型在 CPU 上的架构优势是天然存在的。3. CPU 推理环境准备依赖、模型加载与线程控制3.1 安装 CPU 版 PyTorch 和 Transformers在 CPU 机器上不要使用默认的 PyTorch 安装命令否则会拉取包含 CUDA 依赖的版本即使不执行 GPU 代码也会增加安装体积和启动时的动态库加载时间。推荐从官方 CPU 索引安装# 创建独立虚拟环境避免污染系统 Python python -m venv lfm-cpu source lfm-cpu/bin/activate # 安装 CPU 版 PyTorch pip install torch --index-url https://download.pytorch.org/whl/cpu # 安装模型加载和推理所需的库 pip install transformers accelerate安装完成后建议确认 PyTorch 是否正确识别 CPU 模式python -c import torch; print(torch.__version__); print(torch.backends.mkl.is_available()); print(torch.get_num_threads())这里有两个检查点mkl.is_available()为True时说明内置的 MKL 数学库可用矩阵运算可以调用优化的 BLAS 实现torch.get_num_threads()默认可能是逻辑核心数后续要根据实际物理核心数调整。3.2 加载模型权重先确认模型结构与 AutoModel 兼容如果 LFM2.5-Encoders 以 Hugging Face 权重形式发布加载方式和普通 Bert 类模型基本一致from transformers import AutoTokenizer, AutoModel # 示例模型名实际仓库名以发布信息为准 model_name your-org/LFM2.5-Encoders tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModel.from_pretrained(model_name)如果只有 PyTorch 的pytorch_model.bin和config.json可以放到本地目录后使用from_pretrained(./local_model)加载。加载后先打印模型配置print(model.config)重点看model_type、hidden_size、num_hidden_layers、max_position_embeddings和vocab_size。如果max_position_embeddings过小输入超过该长度时会在网络内部报错即使 tokenizer 没有报错。3.3 线程和内存参数启动前设置不要等卡了再调CPU 推理首先要保证线程数合理。推荐在启动脚本里显式设置以下环境变量# 以物理核心数为基准示例是 8 核 export OMP_NUM_THREADS8 export MKL_NUM_THREADS8 export KMP_AFFINITYgranularityfine,compact,1,0 export OMP_WAIT_POLICYACTIVE export OMP_STACKSIZE2G环境变量作用推荐设置设置不当的表现OMP_NUM_THREADSOpenMP 并行线程数物理核心数线程过多导致切换频繁MKL_NUM_THREADSMKL 数学库线程数与 OMP 一致矩阵运算线程竞争、内存带宽打架KMP_AFFINITY线程亲和性绑定granularityfine,compact,1,0线程迁移导致缓存命中率下降OMP_WAIT_POLICY线程等待策略ACTIVE适合推理任务空闲线程占用 CPU 轮询任务端表现不稳定OMP_STACKSIZE每个 OpenMP 线程栈大小2G或更大深层网络前向时栈溢出崩溃这里要特别说明OMP_WAIT_POLICYACTIVE会让空闲线程持续自旋减少唤醒延迟但会增加空转 CPU。如果是多服务共存的机器要评估负载情况避免推理服务把整机 CPU 占满。4. 用最小示例跑通长上下文推理4.1 构造长文本并完成 tokenization先用一段文本模拟业务中的长文本输入。这里构造的是 500 个重复句子实际项目中可能是合同正文、长邮件或研究报告。为了判断是否超过模型限制需要打印 token 数量text 这是一段用于测试长上下文编码的文本。 * 500 tokens tokenizer( text, max_length2048, truncationTrue, paddingTrue, return_tensorspt, ) print(tokens.input_ids.shape) print(tokens.input_ids[0][:10])max_length要根据模型支持的最大长度设置。如果模型只支持 1024强行输入 2048 就会在模型内部报“sequence length out of range”。对于长文本任务推荐先查model.config.max_position_embeddings再决定是否需要分段。4.2 推理代码取 last_hidden_state 并做池化编码器模型的输出通常是一个三维张量形状为[batch_size, seq_len, hidden_size]。做文本向量时最简单的方法是 mean poolingimport torch model.eval() with torch.no_grad(): outputs model(**tokens, output_hidden_statesFalse) last_hidden outputs.last_hidden_state # 忽略 padding 位置的均值池化 attention_mask tokens[attention_mask].unsqueeze(-1) sentence_vec (last_hidden * attention_mask).sum(dim1) / attention_mask.sum(dim1) print(sentence_vec.shape)output_hidden_statesFalse是关键。如果保持默认或设置为 True模型会把每一层隐藏状态都返回CPU 上内存占用会成倍增长。对于只取最后一层向量的分类或检索场景关闭这个选项能省下大量内存和复制耗时。4.3 预热与耗时统计不要直接测第一次推理CPU 上第一次调用模型会触发算子初始化、内存池创建和权重加载直接计时会得到非常大的假延迟。正确方式是先跑几次预热再进入平均耗时统计import time # 预热 3 次 for _ in range(3): with torch.no_grad(): _ model(**tokens) # 统计 10 次耗时 start time.perf_counter() for _ in range(10): with torch.no_grad(): _ model(**tokens) avg_ms (time.perf_counter() - start) / 10 * 1000 print(faverage latency: {avg_ms:.2f} ms)要同时观察内存占用可以在 Linux 下用/usr/bin/time启动脚本/usr/bin/time -v python inference.py 21 | grep Maximum residentMaximum resident set size是进程运行期间峰值内存能在不侵入代码的情况下确认是否需要降低 batch_size 或改用量化。5. 性能优化从进程级到算子级5.1 固定输入形状减少动态分支抖动CPU 算子对动态形状的容忍度低于 GPU。同一个 batch 里输入长度不断变化会导致PyTorch 重新分配中间张量。MKL 无法复用最优执行计划。缓存命中率波动明显。对于长文本任务常见的做法是让 tokenizer 按固定长度分桶。比如设置max_length1024短文本统一 padding 到 1024超长文本截断或分段。这样虽然会损失少量计算但延迟和吞吐会更稳定。tokens tokenizer( text, max_length1024, truncationTrue, paddingmax_length, return_tensorspt, )paddingmax_length会带来额外计算但好处是每一轮推理的输入形状相同。这对 CPU 场景下的批量服务特别重要。5.2 动态量化把 Linear 层降到 INT8Encoder 模型里的 Linear 层数量多、计算占比大适合做动态量化。动态量化不改变激活的精度只把权重从 FP32 转为 INT8推理时再动态量化激活。对于 CPU 上的长文本推理这是一种低成本的内存和带宽优化方式import torch model_int8 torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, dtypetorch.qint8, )量化后模型文件变小内存占用通常会下降 20% 到 40%。但要注意动态量化对 CPU 指令集有要求旧 CPU 可能没有 INT8 加速指令。实际收益要拿真实数据测试不要只看模型体积变小。5.3 使用注意力算子实现选项新版 Transformers 支持通过attn_implementation选择不同的注意力实现。在 CPU 环境下可以尝试显式开启 SDPAScaled Dot-Product Attentionmodel AutoModel.from_pretrained( your-org/LFM2.5-Encoders, attn_implementationsdpa, )sdpa偏向使用 PyTorch 内部的 fused kernel。如果模型结构不兼容加载时会直接报错此时可以回退到默认实现。另一个思路是使用 Intel Extension for PyTorchIPEXpip install intel-extension-for-pytorchimport intel_extension_for_pytorch as ipex model ipex.optimize(model, dtypetorch.bfloat16)ipex.optimize会尝试算子融合和内存复用对 CPU 推理通常有明显提升。但不同版本和 CPU 型号的兼容性不同需要把这条路径当作“可选项”而不是“必选项”。5.4 超长文本分段编码如果业务文本长度超过模型上限直接截断会丢失大量信息。更稳妥的做法是滑动窗口分段编码再把每段向量汇总成整篇文本的向量表示def encode_long_text(text, model, tokenizer, chunk_size512, stride128): model.eval() tokens tokenizer(text, return_tensorspt, add_special_tokensFalse) input_ids tokens[input_ids][0] seq_len input_ids.size(0) chunk_vecs [] start 0 with torch.no_grad(): while start seq_len: end min(start chunk_size, seq_len) chunk input_ids[start:end].unsqueeze(0) output model(chunk).last_hidden_state # 对没有 padding 的分段做简单 mean pooling chunk_vecs.append(output.mean(dim1)) if end seq_len: break start end - stride if not chunk_vecs: return None return torch.cat(chunk_vecs, dim1).mean(dim1)stride是相邻分段的重叠长度用来保留跨段语义。这里的实现忽略了特殊 token 和 attention_mask实际项目需要按业务调整。分段方式的优点是内存可控缺点是总计算量会大于一次前向属于长文本在 CPU 上的兜底方案。5.5 多进程推理比多线程更可控当一个 CPU 服务需要同时处理多个请求时不要在一个进程里无限增加线程。长文本推理中的矩阵运算已经占满 BLAS 线程如果再开几十个 Python 线程内存分配器的竞争会让整体吞吐下降。推荐架构是主进程负责接收请求和 tokenization。worker 进程各自加载一份模型副本。每个 worker 固定 4 或 8 个物理核心。进程间通过队列或共享内存传递输入输出。这样做的缺点是内存占用会按进程数翻倍但换来的好处是延迟可控某个 worker 的单次长输入不会拖垮其他请求。对于内存紧张的机器可以退回到单进程多线程模式但要接受尾部延迟变高。6. 参数调优速查表下面的表格总结了 CPU 长上下文推理中最常用的调优项。实际配置需要结合机器规格、模型大小和真实流量做基准测试不能机械照搬。配置项推荐值作用调大影响调小影响OMP_NUM_THREADS物理核心数控制 OpenMP 并行度线程切换增多可能变慢并行度不足矩阵算子无法利用多核MKL_NUM_THREADS与 OMP 一致控制 MKL 线程数与其他线程争抢带宽矩阵计算退化到单线程batch_size按内存测算通常 1 到 8吞吐和延迟平衡吞吐提升但内存和延迟上升单请求延迟低但利用率不足max_length模型上限的 1/2 或 3/4控制单次输入长度信息更完整但计算量增大容易截断关键信息chunk_size256 到 1024长文本分段宽度语义更完整但内存增加分段过多跨段信息丢失stride64 到 256分段重叠程度重叠多计算量增大分段衔接处语义断裂量化类型动态 INT8 / bfloat16降低带宽和内存开销精度可能下降较多提速不明显attn_implementationsdpa或默认选择合适的注意力 kernel需要验证模型兼容性使用更保守的实现性能可能偏低对于调优关键原则是每次只改一个变量。先固定输入长度评估线程数再固定线程数评估量化最后再测 batch_size 和分段参数。这样才能定位到真正影响性能的配置。7. 常见问题与排查路径7.1 CPU 使用率很高但推理耗时没有下降现象top中进程 CPU 使用率接近 800%但延迟和 200% 时差不多甚至更慢。常见原因线程数超过物理核心数大量线程在等待锁或上下文切换。内存带宽打满多线程都在等待同一内存控制器。每个请求都重新执行 tokenization预处理成为隐藏热点。模型中存在单线程瓶颈比如LayerNorm或某些逐元素算子。排查步骤# 查看进程内线程数 top -H -p pid # 查看线程级 CPU 占用 ps -L -p pid -o pid,tid,psr,pcpu,comm # 查看热点算子 python -m torch.utils.bottleneck inference.py处理建议将线程数降到物理核心数。用KMP_AFFINITY绑定线程到固定核心。把 tokenizer 提前 batch 化不要在推理循环里反复调用。如果热点集中在某个算子考虑用ipex.optimize做算子级优化。7.2 推理时内存不足进程被 kill现象脚本运行到长文本输入后触发Killed或dmesg中出现Out of memory。常见原因输入长度超过模型最大位置编码导致中间张量爆炸。output_hidden_statesTrue保留所有层输出。batch_size 过大CPU 算子临时分配内存超出物理内存。分段编码时把所有 chunk 的向量都保留在列表中没有及时释放。处理建议先用output_hidden_statesFalse跑一遍确认内存下降。降低max_length或batch_size。在循环里对 chunk 向量做累加而不是全部存下来再汇总。使用/usr/bin/time -v python script.py观察峰值内存确认哪个步骤增长最快。7.3 输入超长时报 “sequence length out of range”现象tokenizer 正常完成但把 token 送入模型后抛错提示 exceeds maximum position embeddings。原因model.config.max_position_embeddings小于输入长度。tokenizer 的参数max_length只控制 tokenizer 侧不保证模型侧一定可以处理。排查方法print(model.config.max_position_embeddings) print(tokens.input_ids.shape[-1])如果模型上限不足要么选择更长建模版本的模型要么使用 5.4 节的分段编码。对于纯向量化任务分段编码通常足够如果是多层 Transformer 依赖全局位置信息的任务需要谨慎评估信息损失。7.4 容器或虚拟机中 CPU 资源显示正常但推理很慢现象nproc显示 16但实际可用的 CPU 配额远低于 16。K8s 中 Pod 的 CPU 使用量持续接近 limit被 cgroup 限流。常见原因K8s 设置了cpulimit例如cpu: 4但nproc仍返回物理机或宿主机核心数。虚拟机中开启嵌套虚拟化后CPU 指令集和频率感知出现异常。虚拟机启动时出现与 CPU 配置相关的错误提示比如“客户机操作系统已禁用 CPU请关闭或重置虚拟机”等说明 CPU 热插拔、虚拟化扩展或电源管理配置没有对齐。排查命令# 查看实际 CPU 配额 cat /sys/fs/cgroup/cpu.max # 查看当前进程可使用的 CPU 集合 nproc taskset -pc $$ # 查看 CPU 型号和频率 lscpu处理建议在容器中不要依赖os.cpu_count()设置线程数改为读取 cgroup 配额并减半。给推理 Pod 设置整数的cpu请求和限制避免 float 核心数导致调度抖动。在虚拟机层面关闭不必要的 CPU 电源管理或使用专用性能模式。如果运行在多租户容器环境性能测试结果只代表当前配额不代表宿主机完整性能。对应排查表问题现象常见原因检查方式处理建议CPU 使用率 800% 但仍慢线程数超过物理核心top -Hps -L设置线程数等于物理核心数长文本输入 OOMmax_length过大或加载了所有层输出/usr/bin/time -v固定输入长度关闭 hidden_states超长输入报错模型最大位置编码不足打印max_position_embeddings分段编码或模型长度适配K8s 限流导致推理慢CPU limit 配额小于请求cat /sys/fs/cgroup/cpu.max调整资源配额或减少线程数虚拟机 CPU 配置异常虚拟化 CPU 模型或热插拔未对齐lscpu查看虚拟机告警重建 VM CPU 配置关闭热插拔8. 最佳实践与扩展方向8.1 学习环境与生产环境的 CPU 推理差异学习环境中单机直接跑满所有核心是正常的因为目标是验证结果。生产环境要做的是隔离和稳定推理进程固定线程数不要动态跟随cpu_count()变化。容器场景里设置内存 limit避免长文本输入导致整机 OOM。对每条长文本输入先统计 token 长度再决定走单次前向还是分段编码而不是把所有输入都塞进一个 batch。预留健康检查接口返回最近 N 次推理的平均耗时和内存占用便于监控告警。8.2 发布前检查清单在实际部署之前可以从这份清单逐项确认Python 环境中torch为 CPU 版本torch.version.cuda为None或不包含 CUDA 依赖。torch.get_num_threads()已设置为物理核心数。预热完成后的平均延迟和 P99 延迟已记录且有明确阈值。使用两倍正常长度的输入测试过峰值内存确认不会 OOM。模型推理阶段关闭了梯度、dropout 和 hidden_states 输出。容器环境确认 cgroup 的 CPU 和 memory 配额没有无限拉高线程数。量化模型与原始模型的输出差异在业务可接受范围内。长文本输入采用分段编码时chunk size 和 stride 已经用真实数据验证。8.3 扩展方向从单模型到长文本系统的组合优化CPU 上的长上下文推理不能只靠单个模型压榨性能。在业务系统里RAG、文档检索、长文档分类这类任务可以这样组合第一阶段用短编码器对长文本分块建索引粗排筛选出候选段落。第二阶段再用 LFM2.5-Encoders 这类长上下文编码器对候选段落做精读和精排。对超长文本采用分段向量加权汇总而不是单一 forward 处理数万 token。如果延迟仍然紧张可以蒸馏一个更小的单层编码器用于首轮过滤。这类“长文本分治”方案能够大幅减少单次长上下文推理的频率同时保留模型最终判断时对关键上下文的感知能力。CPU 长上下文推理的最终判断标准只有两个延迟是否可接受、内存是否可控。LFM2.5-Encoders 这类编码器模型天然适合先跑通这类场景但要真正承载线上流量还需要把线程调度、量化、定长输入和分段策略放在同一个工程体系里统一考虑。对还没有接触过长上下文 CPU 推理的团队建议从小模型、短一点的真实业务文本开始先建立基线再做逐项优化不要一开始就追求“完整无损地编码十万字”。在 CPU 上工程化地取舍上下文长度往往比堆模型参数更有效。