纯Rust高性能线性代数库faer：矩阵分解与跨平台分发实践

在把一个 Rust 写的推理服务打包成多平台产物时，我遇到过一件很别扭的事：代码本身是纯 Rust 的，编译产物干净利落，但只要链接上外部的数值计算后端，构建链路上就会多出一堆需要单独适配的东西——不同架构要预编译不同的二进制、交叉编译要额外准备工具链、容器镜像里还得把动态库一起塞进去。线性代数这一层看起来只是几个矩阵乘法，却往往是整条分发链路里最难对齐的部分。这也是我后来认真去看Rust 高性能线性代数库 faer的原因：一个纯 Rust 实现的计算引擎，不依赖外部数值后端，把矩阵分解、线性方程组求解、特征值、奇异值这些东西全部用 Rust 写出来，还能把性能做到和主流实现处在同一档。这篇内容适合两类人：一类是被外部数值依赖折腾过、想看看纯 Rust 方案到底能做到什么程度的工程师；另一类是刚接触 faer，想知道它的数据模型、性能来源和实际踩坑点的开发者。下面我按自己这几个月的使用顺序来讲，从它为什么存在，到具体怎么用对。

1. 为什么纯 Rust 实现这件事值得单独讨论

1.1 外部数值库依赖在分发链路上的真实成本

很多人对线性代数库的期待是“能算就行”，直到需要交付。我在一个跨平台的图像处理 Demo 里踩过这个坑：本地开发机上一切正常，打包到另一套环境下就报找不到动态库，换成静态链接又因为编译选项不匹配出一堆符号冲突。问题的本质不是数值库不好用，而是它把一个平台相关的二进制依赖塞进了原本纯 Rust 的构建图里。

这种依赖带来的成本是分散的：交叉编译要为每个目标平台准备对应的预编译产物；CI 上要维护多套工具链；发布体积会因为静态链接整个数值后端而膨胀；某些受限环境里还得考虑能不能带动态库进去。每一项单独看都不致命，叠在一起就变成了长期维护负担。

faer 选择的是另一条路——把这些东西全部用 Rust 重写，让它成为普通的一个 crate。这意味着cargo build --target aarch64-unknown-linux-gnu就能得到你要的产物，不需要额外的链接步骤，也不需要为目标平台单独准备二进制。对一个需要多平台分发的项目来说，这个差异是实打实的。

1.2 faer 的设计取舍：把性能点放回语言内部

纯 Rust 重写不等于放弃性能，但也确实不是把公式照抄一遍就能快。faer 的核心思路是把传统数值库里那些手工优化的技巧，用 Rust 的表达方式重新实现一遍：矩阵乘法走分块加微内核，SIMD 通过运行时分派挑指令集，多线程用线程池按矩阵规模决定要不要并行。这几件事做下来，它在不少方阵乘法和分解基准上已经能和成熟实现掰手腕。

这里要说清楚一点：“能对标”不等于“全面领先”。我在自己的机器上测过几组尺寸，小矩阵（几十阶）上 faer 有额外的调度开销，反而不如手写的朴素循环；中等规模（几百到一两千阶）开始追平；更大的规模上它的分块和并行优势才明显体现出来。所以别看到基准图就无脑替换，先搞清楚你的矩阵形状分布。

另一个值得说的取舍是 API 风格。faer 没有把自己包装成“傻瓜式”接口，它把视图、借用、分块这些概念暴露给了使用者。初看会觉得啰嗦，但用久了会发现这是必要的——数值计算里拷贝一次大矩阵的代价，往往比多写两行借用代码高几个数量级。

2. 数据模型：Mat、MatRef、MatMut 这套借用关系怎么用

2.1 列主序与 stride：跨库传数据前必须对齐的东西

faer 的稠密矩阵默认按列主序存储，这一点和传统数值库的约定一致，但和很多 Rust 生态里默认行主序的容器不同。这个差异在你跨库传数据时会立刻变成 bug 温床：同一块内存，你按行主序解读和按列主序解读，得到的是转置之后的结果，而转置后的矩阵在求解里往往是完全不同的数学问题。

矩阵的物理布局由 stride 描述。MatRef上可以拿到行方向和列方向的步长，这两个数值决定了“下一行”和“下一列”在内存里各跳多远。对列主序来说，行方向步长是 1，列方向步长等于行数。理解这一点之后，submatrix、transpose这类操作为什么能零拷贝就有了解释——它们只是改了 stride 和起始指针，没有搬动任何数据。

从别的库迁移数据时的安全做法是：不要假设，直接显式构造。把裸指针、切片包装成MatRef时，明确写出行数、列数和两个 stride，然后用一个小规模已知答案的用例验证一遍，比如一个 2×3 的矩阵转置后和手算结果对比。这一步花五分钟，能省掉后面调半天的痛苦。

use faer::Mat; // 用闭包按 (行, 列) 索引生成，不依赖任何存储顺序假设 let a = Mat::<f64>::from_fn(3, 2, |i, j| (i * 10 + j) as f64); // 小规模矩阵字面量，写测试用例时很省事 let b = faer::mat![[1.0, 2.0], [3.0, 4.0]];

2.2 视图借用省掉的是哪部分拷贝

Mat拥有数据，MatRef是只读借用视图，MatMut是可写借用视图。三者之间的关系和 Rust 里Vec、&[T]、&mut [T]的关系是同构的。这个设计在数值代码里价值极大，因为典型的计算流程是：一个大矩阵先做分解，分解结果反复用于求解不同的右端项。如果每次求解都要把分解结果复制一份，内存和带宽都会爆炸。

我习惯的做法是：数据落在Mat里，往下的所有计算接口一律传as_ref()得到的视图。分解对象内部持有对原始数据的引用（通过生命周期约束），后续求解直接复用。这样整条链路上只在最初分配一次，中间没有任何隐含拷贝。

视图还有个隐藏好处：子矩阵操作是零成本的。做分块算法时，把大矩阵切成若干块分别处理，在 faer 里就是submatrix调用，不需要先把块拷出来。这个特性在手写迭代算法时特别顺手。

2.3 可变视图与别名规则

MatMut的可写借用遵循标准 Rust 借用规则——同一时刻只能有一个可变借用，且不能同时存在不可变借用。这在数值计算里会带来一点摩擦，比如“原地更新矩阵的一半，同时读另一半”这种操作，编译器会拦下来。

绕开的方式有两种：一是把读写区域显式切成互不相交的子块，分别拿可变视图，编译器能接受（因为借用区域不重叠）；二是先拷贝到临时缓冲区，算完再写回，代价是多一次内存往返。我一般优先选第一种，实在切不开才用第二种。

需要提醒的是，faer 出于性能考虑，内部有些路径会用 unsafe 绕过一部分检查。这不代表你在外部就可以随意违反借用规则——一旦你把同一块内存同时以可变和不可变身份传进两个接口，行为就是未定义的。这类 bug 表现为“数值莫名其妙算错”，极难排查，所以宁可多写点代码也别赌。

3. 分块、微内核与线程：性能到底是拿什么换来的

3.1 分块策略解决的是缓存命中率而不是算力

矩阵乘法是 O(n³) 的计算量配 O(n²) 的数据量，听起来计算密集，实际上现代 CPU 上它首先是个内存访问问题。朴素三重循环在大矩阵上慢，不是因为乘加指令慢，而是因为每次访问 B 的元素都要从内存（甚至主存）里捞，缓存反复被冲刷。

分块的做法是把大矩阵切成能塞进各级缓存的小块，让一个块在被换出之前被尽可能多次使用。faer 在实现里对分块尺寸做了针对性的选取，目标是让 L1、L2、L3 三层缓存各司其职。这个过程说起来简单，实际调参非常细碎：块太小，循环开销和边界处理占比上升；块太大，缓存装不下退化成朴素循环。

对使用者的启示是：如果你的矩阵尺寸刚好卡在某些不友好的数值上，性能可能不如预期。这不是库的问题，是分块边界效应。测性能的时候别只测 1024 这种漂亮数字，也测测 997、1009 这类质数尺寸，看看波动范围能不能接受。

3.2 pulp 的运行时 SIMD 分派带来什么

不同 CPU 支持的 SIMD 指令集不一样，编译期写死一种，产物换台机器就可能跑不起来或者跑不出性能。faer 借助一个向量抽象层做运行时分派：程序启动后探测当前处理器支持什么，然后选择对应的实现路径。

这个设计带来两个直接后果。第一，编译产物是通用的，不用为不同指令集分别构建。第二，性能上限能吃到硬件的最好水平，但下限取决于你用的硬件——在老机器上跑，向量宽度窄，加速比自然低。

我自己测下来，f64 类型的矩阵乘法在支持宽向量指令的机器上提升最明显，到了小尺寸矩阵反而因为分派和初始化的额外开销显得不划算。faer 内部对尺寸有阈值判断，但你在业务层做批量小矩阵运算时，可能合并成批处理更划算——把小矩阵拼成块对角，一次性调用大矩阵接口，往往比循环调用小接口快。

3.3 并行阈值与线程数不是越大越好

多线程那一块是通过可选的 feature 引入的。开启之后，大矩阵运算会自动切分任务到线程池。这里的关键是阈值：矩阵小到一定程度，切分和合并的开销超过并行带来的收益，反而变慢。

我在 8 核机器上的经验是：单次运算规模在几百阶以下，单线程往往更快；上千阶之后并行收益才开始显现。但这不是绝对规律，取决于内存带宽——如果运算本身受限于内存带宽而不是算力，加线程也没用，甚至因为争抢带宽更慢。

线程数也不是拉到核数就完事。在容器环境或者共享服务器上，可用核数和物理核数往往对不上，盲目按物理核数配置线程池会导致严重超订。比较稳妥的做法是让线程池规模跟随容器配额，或者干脆在应用层显式控制并发任务数，避免多个线程池互相打架。

4. 分解与求解：把 API 选对，比调参收益大得多

4.1 按矩阵结构选分解：一张对照表

线性代数这块最容易犯的错，不是 API 写错，而是选错了分解方法。选错的后果不是报错，而是算出一个精度很差甚至完全错误的结果，你还以为是对的。下面这张表是我自己整理的选择依据，按“你已知的矩阵性质”查就行。

这张表的核心逻辑是：利用矩阵已知的结构信息换取速度和精度。你多知道一条性质（对称、正定、稀疏），就多一条优化路径。反过来，如果你不确定矩阵是否正定，就别用 Cholesky，老老实实上 LU 或者 QR。

4.2 复用分解结果，别在循环里重复分解

这是我见过最多的性能问题。典型写法是在一个循环里，每次迭代都重新对同一个矩阵做分解，然后只解一个不同的右端项。分解的复杂度是 O(n³)，求解只有 O(n²)，重复分解等于把 99% 的时间浪费在重复劳动上。

正确做法是把分解对象提到循环外，里面只调求解。

use faer::linalg::solvers::{DenseSolveCore, Solve}; // 分解一次，后续反复使用 let lu = a.as_ref().partial_piv_lu(); for rhs in right_hand_sides { // 每次只做 O(n^2) 的代入求解 let x = lu.solve(rhs.as_ref()); // ... 使用 x }

不同小版本之间，solvers模块的路径和 trait 名称有过调整，有个别版本把分解类型挪到了专门的子模块里。我的习惯是锁定版本后先翻一遍solvers模块的文档，把要用的 trait 一次性use进来，别靠记忆写。编译器报“找不到方法”的时候，八成是 trait 没导入，而不是方法不存在。

还有一个细节：求解接口的右端项既可以是单列向量，也可以是多列矩阵。如果你的场景是批量求解多个右端项，把它们拼成一个矩阵一次调用，比循环调用快得多——底层可以把这些列当作一批处理，内存访问模式友好很多。

4.3 稀疏矩阵那条支线什么时候该走

稠密矩阵的存储是 O(n²)，当矩阵里绝大多数元素是零时，这个开销就完全浪费了。faer 里有独立的稀疏矩阵类型，用三元组（行、列、值）构造，内部按压缩列格式存储。

判断要不要走稀疏路线有个粗略标准：非零元素占比低于百分之几，稀疏存储的收益才明显。占比在中间地带（比如 20%~50%）时，稀疏格式的索引开销可能反而拖慢速度，这时候稠密存储配合合适的算法更划算。

稀疏分解的接口和稠密的不一样，需要先做符号分解（确定非零结构），再做数值分解。这个两步走的模式对重复求解同一个稀疏结构特别友好——结构不变时，符号分解可以复用。我处理过一批结构相同、只有数值不同的稀疏系统，把符号分解提出来后整体耗时降了一大截。

// 稀疏矩阵从三元组构造，注意索引类型要显式指定 use faer::sparse::{SparseColMat, Triplet}; let triplets = vec![ Triplet::new(0usize, 0usize, 4.0_f64), Triplet::new(1, 1, 3.0), Triplet::new(0, 1, 1.0), ]; let sparse = SparseColMat::<usize, f64>::try_new_from_triplets(2, 2, &triplets)?;

构造时最容易出错的是重复索引的处理。同一个 (行, 列) 位置出现多次时，不同接口的行为可能不同——有的累加，有的报错。做有限元组装这类天然会产生重复项的场景，务必先查清楚你用的构造函数是累加语义还是严格去重语义，否则会得到一个静默错误的结果。

5. 真跑起来之后才会遇到的那些问题

5.1 feature 组合与编译时间的取舍

faer 把不少能力做成了可选 feature：多线程支持、SIMD 路径、稀疏矩阵、序列化、以及一个只保留核心功能的精简模式。默认配置开得比较全，代价是编译时间明显拉长。

我第一次引入的时候没注意，全量 feature 编了挺久，增量编译也慢。后来按需裁剪：只做稠密计算的项目关掉稀疏支持；单线程场景关掉并行支持；不需要序列化的场景关掉序列化。裁剪之后编译时间降下来了，产物体积也小了。

[dependencies] # 版本号请替换成你查阅当天的最新稳定版 faer = { version = "0.20", default-features = false, features = ["std", "linalg", "rayon", "simd"] }

需要提醒的是，某些 feature 之间存在隐含依赖关系，比如并行支持可能要求标准库支持。裁剪完如果编译报错，先看错误信息里提到的 feature 组合，通常加上那个缺失的就能过。另外，逗号后面的格式在不同版本的清单里可能有差异，报错时优先怀疑清单写法本身。

还有一个容易忽略的点：feature 是加法语义。如果你的项目里有多个依赖都引入了同一个库的不同 feature 集合，最终会合并成并集。你在这个 crate 里关掉的 feature，可能被另一个依赖重新打开。检查最终产物用了哪些 feature，可以用查看依赖树的方式确认，别只看自己写的那一行。

5.2 数值精度：条件数比库本身更值得怀疑

算出来的结果不对，第一反应往往是怀疑库有 bug。我踩过几次之后总结出一条：先怀疑矩阵的条件数，再怀疑库。条件数衡量的是输入微小扰动会被放大多少倍，条件数一万的矩阵，即使算法完美，双精度也只能保住十二位左右的有效数字。

自测方法很简单：构造一个已知精确解的系统，用库求解，然后把残差和误差分开看。残差（A·x - b的范数）大，说明求解过程有问题；残差小但误差（x和精确解的距离）大，说明矩阵本身就是病态的，这时候换什么库都没用，得考虑正则化或者换更高精度。

另一类常见问题是正定性判断。Cholesky 分解要求矩阵对称正定，实践中这个条件经常只是“理论上成立”——数值误差累积之后，某个主元可能变成极小的负数，导致分解失败。处理方式是在对角线上加一个微小的修正项，但这会改变问题本身，得权衡。我一般会先记录失败时的最小主元值，如果它只是勉强为负，加个舍入级别的修正就够了；如果差得远，说明前一步的矩阵构造就有问题。

5.3 常见编译与运行时错误的排查路径

我把踩过的坑归了几类，按出现频率排。

第一类是 trait 没导入导致的“方法不存在”。faer 把很多能力拆到了 trait 上，solve、分解构造这些方法往往来自特定 trait。报错信息说某个类型没有某方法，先检查use列表。

第二类是类型不匹配。faer 对标量类型是泛型的，f32和f64的矩阵是完全不同的类型，混用会报类型错误。求解时右端项的元素类型必须和矩阵一致，跨类型要先显式转换。

第三类是生命周期约束不满足。分解对象借用了原始矩阵，如果原始矩阵在分解对象还活着的时候被移动或销毁，编译器会拦下来。解决办法是调整变量声明顺序，让矩阵先于分解对象声明，或者干脆把两者打包进一个结构体统一管理。

第四类是运行时 panic，多数来自维度不匹配或正定性检查失败。建议在关键调用外面包一层检查，把矩阵维度和对角线最小值打出来，比对着 panic 信息猜要快得多。

6. 迁移与验证：怎么判断它适不适合你的场景

换数值库这件事，最大的风险不是性能不够，是静默的数值差异。你换完之后程序不报错，跑出来的结果和原来差了百分之几，等你发现的时候已经上线了。

我的做法是建一个小型的验证套件，固定几组有代表性的输入：小尺寸的已知答案矩阵、中等尺寸的随机矩阵、以及从真实业务里采样出来的矩阵。每组都记录新旧两套实现的输出，比对相对误差。相对误差控制在某个阈值以内（双精度我一般按量级设），超过就逐项排查。

这套验证还有一个附加价值：它能暴露性能特征。跑验证的时候顺手计时，你就能看到在你的实际矩阵形状分布下，新库到底是快还是慢。我用这套方法测下来，某些形状上收益明显，某些形状上差不多，还有少数形状上略慢——这个结论比任何公开基准都有参考价值，因为它是你的数据。

迁移顺序上，我建议从最独立、耦合最少的那部分开始。先替换一个纯计算的工具函数，观察一段时间，再逐步扩大到核心路径。别一次性全换，出了问题定位成本太高。

最后一点个人体会：faer 这类纯 Rust 数值库真正的价值，不完全在性能数字上，而在于它把数值计算这一层重新纳入了 Rust 的构建体系。你不需要为它维护额外的工具链，不需要为跨平台分发做特殊处理，cargo 能做的事它都能做。对于本来就在 Rust 生态里的项目，这个工程层面的收益，往往比几个百分点的性能差距更值得考虑。如果你的场景是矩阵规模中等以上、需要多平台分发、而且能接受花点时间调 API，那它值得认真评估一遍。