将可能性编码到类型系统中：Rust 的 Result 和 Option 类型允许在编译时捕获错误和空值，避免运行时的「空指针」调用。

在很多语言中，null 的存在带来了大量的运行时错误（比如著名的 NullPointerException）。函数返回一个特殊值（如 -1）来表示错误，也常常导致开发者忘记检查从而引发 bug。

Rust 通过 Option 和 Result<T, E> 在编译时就解决了这些问题。它们将「可能不存在的值」和「可能失败的操作」这两种情况明确地编码到类型里，强迫开发者在编译阶段就处理这些可能性，从而极大地提升了代码的健壮性。

• Option<T> 代表一个值可能存在，也可能不存在。

• Result<T, E> 代表一个操作可能成功，也可能失败。

Option

Option<T> 是一个枚举（Enum），它有两个变体：

• Some(T): 表示值存在，T 就是那个具体的值。

• None: 表示值不存在。

Result

Result<T, E> 也是一个枚举，它有两个变体：

• Ok(T): 操作成功，T 是成功的值。

• Err(E): 操作失败，E 是错误信息。

链式调用

这里把 Result 和 Option 放到一起说，因为大多数链式调用从语义上是相同的，一起说更容易理解。至于有一些 Option 或 Result 独有的方法则单独拎出来说。

下面把 None 和 Err 统称为「无值「，Some 和 Ok 统称为「有值」，Result 和 Option 统称为容器类型，原值类型为 T，新值类型为 U。下面会根据我认为的语义来把链式调用分为几个类：

无值则 Panic!

此类方法在无值时会直接 panic，通常用于调试或开发者确认某个值一定存在的场景。

转换 - Mapping

此类方法用于将值从一个类型 T 转换成另外一个类型 U。不同之处仅在于当无值时的处理方式。

链式调用

此类方法类似于 if 条件分支，可以针对有值或无值的情况继续写逻辑从而避免大量的类似 if Some(T) = F() { ... } 这样的条件判断。

Option Result 互转

有时我们需要将 Option 和 Result 互相转换，这些方法可以帮助我们完成这种转换。

总结

传统的错误处理（如 if err != nil）是一种「控制流」思想。你需要在代码的 Happy Path（成功路径）中穿插各种错误检查的分支。

Rust 的 Option 和 Result 及其组合子（combinators, 如 map, and_then）鼓励你用「数据流」的思维来编程。你可以想象数据在一个管道里流动，这个管道有两个轨道：Some/Ok 轨道和 None/Err 轨道。

map, and_then 等操作是在 Some/Ok 轨道上对数据进行加工。

一旦任何一个环节出错，数据就会切换到 None/Err 轨道，并一直走到终点。

or_else 像是提供了一个从 None/Err 轨道切换回 Some/Ok 轨道的机会。

这种模型（有时被称为「铁路导向编程」）让你的主逻辑非常清晰，错误处理被优雅地链接在一起，而不是打断主逻辑。

最近在写一个反向代理的时候，有类似以下的逻辑：

// req: &Request 表示用户发来的请求
for upstream in upstreams {
  let upstream_req = req.clone().into_parts();
  // modify uri of upstream_req and make request
  // if success then break, else try next upstream
}

乍一看，这应该是个「反向代理」都应该具备的功能：遍历所有的 upstream 尝试请求，如果成功就 break，否则就继续下一个 upstream。

不过这个代码编译不过，报错 req 没办法被 Clone，这是因为 Request 里面有一个 Body，而 Body 是没有实现 Clone。

我的第一反应仍是「解决这个编译问题」，也就是让这个 req 被成功的 Clone 下来，因为逻辑看上去是合理的，就是拿到一个请求之后，尝试所有的 upstream，如果有一个成功就 break。

多次尝试无果，之后又在 Rust 社区里看到一个类似的需求：https://users.rust-lang.org/t/how-to-copy-http-request/43690。最后的实现逻辑，大概是在内存中分配一块空间来存储 Body 的数据，到这里我才开始思考为什么 Rust 不允许 Body 被 Clone。

对于传统的反向代理，例如 nginx，用户如果上传大的文件，nginx 是先读取全部数据到他自己的内存，然后再向上游服务器发起请求（这就是万恶的 client_max_body_size 的来源，因为如果不做限制，nginx 服务器的内存很容易被打满）。而对于现代的 HTTP Server 来说，「流式」处理上下游显然是更好的选择。Body 不能被 Clone 是有道理的，就像 std::fs::File 不能被 Clone 一样，因为这些都是「一种资源」。更上层的理解，如果要 Clone Body，那么就意味着要在内存中存储多份数据，这显然是不合理的，除非我们自己强行这么干，想社区提到的那个方案一样。

Clone 这个 req 在应用逻辑存在问题，考虑当用户的请求携带一个较大的 HTTP Body，代理服务器流式地将用户数据上传到上游服务器中，Clone 这个 Body 会面临以下这些问题：

1. 首先这个流本身是没办法 Clone 的，因为如果要 Clone 则需要拿到全部数据，这就不是「流式处理」了。
2. 如果考虑不 Clone 流本身，而是把 Body 当作一个引用来 Clone 也是不行的，因为服务器无法多次读同一个流。不能说如果一个 Upstream 上传失败了，重新读这个流再上传到其他 Upstream，因为这个流的另一端是用户的浏览器，我们不能要求代理服务器在一个 Upstream 上传失败后，用户浏览器又重新上传数据。

如何改进

首先从场景上思考，在大文件上传的时候，上游服务器几乎都是单个文件服务器，这里似乎根本就不存在多个 Upstream 的问题。因此可以从 Content-Length 的大小来判断是否需要 Clone 这个 Body，如果 Content-Length 较小，那么可以像 nginx 一样获先读取 Body 的数据到内存，然后再将请求发送给上游服务器。如果一个请求的 Body 很大，则仅尝试一个 Upstream 也是合理的。

同时存在多个 Upstream，并且也希望「流式」处理的场景也是存在的，在上传第一个 Upstream 时，可以考虑用临时文件同时保存 Body 的数据，这样如果第一个 Upstream 上传失败，我们可以不响应 50X，而是立即开始上传第二个 Upstream，先读取缓存文件的数据，然后再读取剩余的 Body 中的数据，当然这个涉及到更多的细节处理了。

太多人问了，专门写一篇吧

太长不看版

1. 切到新建的那个 Conda 环境下：conda activate xxxxxx
2. 安装 Python 包 ipykernel：pip install ipykernel
3. 创建 Jupyter Kernel：python -m ipykernel install --user --name=xxxxxx
4. 刷新页面，JupyterLab 或者 Jupyter Notebook 就会正常看到新的 Kernel 了

了解一下原理

首先一台电脑上可以有多个 Python 环境，比如有 Python 3.7 和 Python 3.8，这很常见。

那如果使用 Python 3.7 安装了 JupyterLab，那么现在打开 JupyterLab 后，只会看到一个 Kernel，这个 Kernel 就是 Python 3.7 的 Kernel。

现在的需求是：我们还希望在这个 JupyterLab 上使用 Python 3.8 的 Kernel，应该怎么做？

如果在本地，那么很多人是直接在终端中切换到 Python 3.8 的环境下，然后再安装 JupyterLab，这样就可以看到 Python 3.8 的 Kernel 了（但是又可能看不到 3.7 的 Kernel）。

但这么做其实不是特别方便，特别在类似 Featurize 这样的云端服务器上，就不得不在本身自带的 JupyterLab 上添加一个 Kernel了。

JupyterLab 实际上是支持通过多环境配置的，在终端中使用 jupyter kernelspec list 就能查看到当前 JupyterLab 支持的 Kernel 列表。（注意：这个命令的执行需要在安装 jupyterlab 那个环境下），其他的环境可能连 jupyter 命令都没有）。因此我们只需要添加一个 kernel 的配置，然后配置置顶到我们新创建的环境即可。

ipykernel 这个工具，就是帮助我们添加 Kernel 配置文件的工具，所以我们需要安装这个工具，当然也可以手动添加配置文件，就不多赘述这种方式了。

是时候总结一下了。

🎯 狩猎背景

公司领导决定结束长达 5 年的远程工作，开始坐班，然后租了一间离我家不远的写字楼，办公室总共大概有个 150 平的样子。因为平常主要是我来办公室上班，因此办公室的大部分办公用品（包括办公桌椅等）的采购都是我一手操办的。我一切从成本的角度考虑：电器几乎选了小米，家具几乎找的闲鱼。我用了不到 5000 块的价格搞定了 8 个 L 型工位，却没想到等待我的是一场漫长的甲醛狩猎之旅…

下面是办公室的平面图，平常总经理室一般是关闭的，所以整个办公区的通风都靠一个可怜的下悬窗，图上我还画大了，其实更小一点：

💡 甲醛传感器

甲醛传感器是在我测试完净化器之后才开始做实验进行一些验证的，但我觉得先谈这个更合理一些，因为这样后面净化器实验结果才更加可靠。

加上净化器本身的传感器，我总共使用了 10 个传感器，下表是我使用的传感器的列表以及他们的使用情况：

上面的 10 种净化器，一些过于离谱的就直接不用看了，下面着重讨论表现比较好的三款传感器（绿字）：小米、测小菲、希望树。

💡 希望树 & 测小菲

实际上是都是英国 Dart Sensor 公司生产的传感器

这两款传感器的外观一摸一样，买到后就让我感觉是同一家厂商生产的，然后一次偶然的售后让我得知了一些内幕：

因为测小菲 400 元的传感器支持蓝牙接入米家，因此我购买了小米网关，但是死活儿连不上（最后发现其实是小爱音响的设置里默认把网关功能禁用了）。我立即联系了测小菲的客服，但由于是技术原因，客服给我转到了工程师，而工程师是工厂的人，并不是测小菲的员工。

当得知该工程师是工厂的员工之后，我直接询问了测小菲和希望树是否是都是他们家制作的，工程师很果断地回答是的；然后我又深挖了一下，问道为什么希望树的传感器总是比测小菲的传感器数值高那么一些，工程师的回答是「希望树他们也做净化器得嘛，你自己想想」…

另外，工程师还直接跟我说他们用的都是英国的 Dart 传感器，在网上搜索很容易找到其官网：https://www.dart-sensors.com；从官网包括其他的一些资讯来看，这虽然是一家历史悠久的公司，但不是一家大型公司，从其 Linkedin 页面来看，公司员工规模是 10 到 50 人，估计就十多个人左右。

这篇论文《Evaluation of low-cost formaldehyde sensors calibration》从各个方面详细得测试了 Dart 传感器的表现，其结论跟我的观测几乎一致：*Dart 传感器可以给出甲醛浓度变化的趋势，但无法准确给出甲醛的浓度值。

这个其实挺容易判断，比如两天的相同时间段，温湿度大致相同，办公室完全封闭且关闭净化器，这款传感器在这两个时段的数值可能并不是一致的，但是如果是这时候开启净化器，那么这款传感器是的数值会降低，但是降低的趋势仍然是不同的。

💡 小米传感器

由瑞士的 Sensirion 公司生产的 SFA30 甲醛传感器

小米 5S 由于是最早购买的，并且能直接联入米家，因此其采集到的数据是最多的，我的使用感受也最深刻。小米所使用的 SFA30 传感器不仅能够像 Dart 传感器一样，对环境变化作出灵敏的反应，更难能可贵的是，这款传感器数值每次随环境变化的趋势几乎是一致的，因为环境相同、温度几乎每天都相同，那么甲醛浓度的上升下降的过程，每天都应该相同才对。例如第一天下班后关闭净化器，甲醛浓度在一小时内从 0.03mg/m³ 上升到 0.09mg/m³，那么第二天应该也是大致相同的过程，但 Dart 净化器则做不到这一点，这也是我为什么一直比较相信小米读数的原因，各方面都比较符合直觉。

下图是小米 8 月 6 号至 8 月 8 号的甲醛变化情况，这两天成都都是汗蒸模式，甲醛数值高且变化幅度大，从图中可以看出小米传感器的数值在两天的变化趋势几乎是一致的：

另外，从 Sensirion 公司官网也能看出，这是一家规模很大的公司。并且其 SFA30 传感器的产品页面也有很多内容，包括一些产品相关的手册、开发文档等等。在这之后我单独购买了 SFA30 传感器和一个单片机做过一些开发，因此对这方面比较了解。

💡 理研 FP31

日本理研 FP31 是我通过闲鱼租用的；另外我购买了 3 片药片，分别在三个时刻做了 3 次检测，下面是对照表：

注意：理研的分辨率是 0.005ppm，而小米的分辨率是 0.001mg/m³，因此在数值上理研的数值要比小米的数值要低一些。

💡 总结

从分辨率、灵敏度和随环境的趋势上，小米的传感器（或者说 Sensirion 的 SFA30）遥遥领先于其他产品。并且理研 FP31 的测试结果也跟小米传感器的结果一致。

接下来的净化器的使用过程的记录，我都会以小米 5S 的传感器的数值作为基础来进行。

🫧 除醛净化器

为了给办公室除醛，我开始采购的净化器，作为一个小白，我不会傲慢地认为净化器除醛都是智商税，我认为是不是智商税，必须我亲眼所见才好下判断（反正又不是我自己掏钱🤣）。

为了之后大家能看得比较明白，先提前普及一些基础知识：

CADR

Clean Air Delivery Rate ，清洁空气传递率，是指空气净化器在单位时间内净化空气的能力，单位是 m³/h。CADR 值越大，说明空气净化器在单位时间内净化能力越强。所有除醛产品都会标注这个数值。

需要注意的是，除醛净化器一般会标注固态颗粒污染物的 CADR 和甲醛的 CADR，这两个数值是不同的，我们需要关注的是甲醛 CADR 数值，以下 CADR 都是指甲醛 CADR。

一般来说 CADR 越大的净化器出风量就越大，但出风量大并不意味着 CADR 高，因为净化器吹出来的空气并不一定是「洁净的空气」，例如可能一份空气被吸进净化器之前的甲醛是 0.1mg/m³，然后被吹出来的时候可能是 0.07mg/m³，同一个屋子下的空气需要被净化器多次净化才会有效。CADR 的数值和净化器本身的风机以及滤芯都有关系。

购买净化器的时候首先一定要根据房间大小看 CADR 的值，CADR 的单位是 m³/h。可以简单地直接对 CADR 的值除以 10 或 15，就是空气净化器满功率运行能覆盖的面积。

CCM

Cumulative Clean Mass，累积净化量。可理解为滤芯的耐造程度，CCM 越大则说明滤芯的寿命越长。另外，CCM 也会影响 CADR 的值，CADR 值一般来说都会随着使用的过程不断下降，这是因为滤芯中累积了污染物。较大的 CCM 也会让这个性能下降的过程变得缓慢。

🫧 小米 5S

• 京东价格 1499
• 甲醛产品标注 CADR 225m³/h
• 实际除醛效果：约等于 0，一个 10 平方不到的财务室都无法控制甲醛浓度
• 产品使用感受：甲醛传感器准确，但除醛效果差

这是购买的第一款净化器，当时完全是小白状态，无脑入的小米净化器。但这实际上是我的问题，这么小的 CADR 最多只能覆盖个 20 来平米的空间，官方也标注了适用面积，最大只有 62 平米，而我们的办公区有 80 平米。

不过值得注意的是，在小米 5S 的产品页面中，对这款净化器的定位是「除醛净化器」，并且京东的产品图文介绍中首先大篇幅地展示了这款净化器的除醛效果，但是在除醛的部分没有标注「适用面积」，而是在颗粒物 CADR 的部分标注的。因为颗粒物的 CADR 比甲醛的 CADR 大得多，因此其能够适用的面积也就大得多，如下所示：

这款净化器的表现自然不用我多说，因为从 CADR 数值上就远达不到要求，因此除醛效果也是非常的差，几乎等于毫无用处，但好在小米 5S 的甲醛传感器是比较准的，在这个时候我还没有购买其他的传感器，是小米5S净化器主动告知我他没什么用的。如果传感器本身不诚实，那可能接下来的故事就是大家每天吸着甲醛干活儿了，因此我现在也庆幸第一次就买到了带有可靠传感器的净化器。现在这台小米 5S 依旧在服役，作为甲醛传感器使用。

小米 5S 的除醛效果：单独放在独立的 10 平米不到的财务室，都无法控制甲醛浓度数值，甲醛只升不降，可以说在除醛上毫无用处。

🫧 小米 Ultra

• 京东价格 4599
• 甲醛 CADR 400m³/h
• 实际除醛效果：会议室可以将甲醛浓度控制在 0.05mg/m³ 左右，办公区约等于没用
• 产品使用感受：小房间有一定效果，但大空间没用，另外传感器有作弊嫌疑

在使用过 5S 之后，发现浓度无法降低，感觉是办公室的面积太大了导致的，所以又向公司申请购买更高级的净化器；为了方便连接米家，还是选购了小米品牌的 Ultra 净化器，Ultra 净化器产品页面也直接说明了适用于 70 平的办公场所。

这款产品几乎也是专门针对除醛的，采用了除醛的黑科技「醛能解」，催化分解甲醛的滤芯更是完全无需更换。产品到货之后，光搬出来都花了不少力气，因为这滤芯的总质量太大了，我内心认为这下肯定稳了，这滤芯也太扎实了。

但可笑的是这款净化器在办公区的表现也几乎等于没用。这对我的压力也挺大的，毕竟花了那么多钱，结果买了一堆没用的东西。从这时开始我就打算好好做一些空气净化器的功课和实验，难道空气净化器除醛真的是智商税吗？难道我们只能在办公室里吸甲醛吗？

🧪 实验

在20平不到的会议室中，先将小米 5S 放进去，以最低功率运行；然后再将小米 Ultra 放进去，以做满功率运行。

试验的结果：

我也在小红书上发了第一个视频来谈论这个实验的结果，当时的我认为 20 平米仅能将甲醛控制在 0.05mg/m³ 左右是完全不达标的结果，因为京东的产品页面上吹的天花乱坠，并且说甲醛浓度可以降低至 0.01mg/m³，超过国标 8 倍，然而如果一个 20 平的会议室都仅能控制在 0.05mg/m³ 左右，那么显然是远低于我当时预期的。

下面是我在社交平台上分享的第一个关于甲醛的内容，就是这一次实验的讨论。

xiaomi-ultra-test

因为当时使用过的净化器还是太少，而且对小米 Ultra 的期望很高，毕竟从来没买过如此昂贵的净化器。如果放在现在来看，如果小米 Ultra 能够长时间（指在我们办公区至少半年）都还能有这个表现的话，那相对来说也不算差了。可惜我没有长期使用小米 Ultra，在没达到预期之后就果断选择了退货，而小米也是二话不说全额退款，考虑到滤芯毕竟是耗材，这点感觉小米还是很良心的。

最后，放一个小米 Ultra 拙劣的作弊实锤，5S 还靠谱一些，不整这些幺蛾子：

🫧 IAM M8 Pro

• 京东价格 5199
• 甲醛 CADR 614m³/h
• 实际除醛效果：使用的前几天除醛效果拔群，最大的办公区可将甲醛浓度稳定在 0.03mg/m³ 左右，但之后效果逐渐下降非常明显，大概十天后变得没有用处
• 产品使用感受：除醛效果真的好，但是并不持久，滤芯堆料上不像 Ultra，不知道这是不是他不持久的原因之一。另外传感器表现一般，低浓度下（<0.06时）数值上跟小米差不多，但是在高浓度下就上不去，感觉也有作弊的嫌疑。另外，智能需要绑定的一个叫「心动智家」的平台，似乎是 IAM 自己做的，因为里面只有他们自己的产品，涂鸦或者米家都不支持，差评。

踩过小米两次坑之后，这次我打算购买其他品牌的旗舰除醛净化器了，呼声最高的就是这款 IAM M8 Pro，到货之后我立即拉到财务室和办公区进行了测试。

🧪 实验

办公区先全封闭闷到浓度稳定，然后开启小米 Ultra 运行 1 小时，关闭 Ultra 后再闷一个小时，然后再开启 IAM M8 Pro，看最后的总的甲醛浓度变化。

整个曲线见下图：

紫色区域有一段下降是因为断电将净化器从财务室搬到办公区导致的，小米是算的 10 分钟均值。当时在小红书上发的视频链接：

iam-pro

这效果真的立竿见影，本以为终于可以安心工作了，但是好景不长…

刚来的3、4天，效果确实非常好，甲醛浓度在办公区都能稳定在 0.04mg/³ 以内（感谢小米，我已经将我的预期从 0.01mg/³ 升到 0.04mg/³ 了）。但是过了 10 天之后，就全程在 0.06mg/m³ 左右，见下图：

这性能都不能说下降了，简直就是俯冲。官方宣传的超大 CCM 也是完全没感觉出来。然后我在 B 站的置顶评论中说了一下这个事（毕竟在第一周使用的时候还在几个常用的平台上还吹了一波，这倒好，马上打我脸是吧），之后就去找售后了，结果售后让我删除评论然后全额退款，我当然是不愿意的，最后是交了 280 的折旧费用（没发票无法报销，自付了），然后直接退货了。

🫧 宫菱

• 京东价格 2799
• 甲醛 CADR 716m³/h
• 实际除醛效果：前一周表现依然亮眼，跟 IAM Pro 几乎一致。之后除醛的性能也有所下降，但总体上说相比 IAM Pro 好得多，20 天的使用情况总体来说还能接受
• 产品使用感受：20天整体表现来看，除醛效果不错，价格亲民，风量很大。传感器完全是一坨💩。除了除醛以外，其他功能相比起小米来说就差得不止一点儿了。

宫菱到货的时候，正赶上成都最闷热的那几天，从半夜的甲醛浓度的峰值就能看出，甲醛浓度随温湿度的影响非常大，之前的半夜甲醛浓度峰值最多也就 0.11mg/m³，而现阶段的半夜峰值直逼 0.16mg/m³，可以说一来就赶上了地狱模式。

下面是宫菱前 20 天的运行情况，其开启的区间大致是：凌晨 3:00 至 凌晨 5:00，早上 8:00 至 下班（偶尔下班会忘记关）。凌晨基本上都是全封闭无新风空调的状态，这个时间段主要用来看恶劣环境下净化器的表现。

然后这种恶劣的环境下，宫菱的 20 天表现尚可，但是性能依然有所下降，从半夜凌晨 3 点到 5 点的表现就可以作出大致的判断。刚来的时候，即使峰值浓度 0.12mg/m³，但是凌晨 3 点的浓度也能控制在 0.05mg/m³ 左右，但是从 8 月 4 号开始，性能就开始明显下降，但好在他至少在降低，而且白天大楼有新风之后，白天甲醛浓度还算可以接受。

为什么8月9号之后性能又恢复了？

可以看到 8 月 9 号开始，除醛性能一下子就变得非常好了。凌晨都能控制在 0.04mg/m³ 左右，但是也能看到峰值明显变低了：只有 0.08mg/m³，我本来以为是写字楼新风的规则城半夜也开放了，因为不会无缘无故变化这么大。但是询问过大楼的新风师傅后他们说并没有更改过运行规则，那这个原因多半就是天气变化了，查一下历史天气：

8 月 9 号直接降低了 5 到 7 度，从这儿就能看出甲醛的变化确实受温湿度的影响很大。那前面的「性能折损」，也有可能是因为温湿度升高导致甲醛释放速率过快，净化器的抗不过来导致的。但这个现象又引发了我另一个思考：到底当前办公室的甲醛释放速率有多大，对一个净化器做评价时，应该需要引入这个因素才行，否则可能会造成一些「误判」。从目前的现象来看，我认为在温湿度很高的情况下，我们办公室的甲醛浓度释放速率相对应该也是非常高的了，8 月 5 号峰值都已经达到了 0.16mg/m³，这个数值已经高出标准一倍了，而且是在关闭净化器后短时间就能达到这个浓度。

20天之后的表现

可以看到夜晚时间段，宫菱也仅能将甲醛浓度压在 0.08mg/m³，一方面是成都这几天又热了起来，另一方面也能明显看出宫菱的性能折损也是很严重的。

🫧 总结和思考

在比较过上述 4 款除醛净化器之后，我斗胆作出以下结论（» 表示远大于，～ 表示约等于）：

• 传感器 小米 5S > 小米 Ultra > IAM M8 Pro » 宫菱
• 短期除醛效果 宫菱 ～ IAM M8 Pro » 小米 Ultra » 小米 5S

对比宫菱和 IAM M8 Pro

实际上一个月的测试之后，宫菱和 IAM M8 Pro 的表现我认为是接近的，因为 IAM M8 Pro 是 24 小时无间断的运行，一周之后就嘎了；宫菱除了半夜有 2 个小时的运行时间外，其他时间都是人在的时候运行，一天大概运行 10 个小时，而白天大部分时间是有新风的。

再次吹一波小米的传感器

我很庆幸第一次就购买到了传感器表现最好的净化器小米 5S，不然我可能不会意识到我天天吸着甲醛工作。

关于小米 Ultra 的表现

小米 Ultra 因为 CADR 太低的原因，在我们的办公区几乎是零作用；但在会议室其实是有一些作用的，可以将甲醛稳定在 0.05mg/m³；然后最近我又看到了小米出了一台

办公室的的甲醛挥发量并没有纳入考虑

一个疑问是，我并不知道办公室的甲醛浓度释放的速率到底是多少，我在想一个极端环境：一个到处都是福尔马林并且温度很高的房间里，如果把这些净化器去净化这个房间，他们能坚持多久，会不会一天就变得完全没用了？但是市面上这些净化器，只说明了他们的「适用面积」，并没有说这个面积下的甲醛释放速率是多少，因此我的实验可能并不适用于别人，只能看出这些净化器在我们办公室里的表现。其他人可能购买了环保等级更高的家具，那么这些净化器可能又是另外一种表现。

宫菱和 IAM M8 Pro 几乎都是用活性炭除醛（虽然官方宣称有催化剂分解，但从这个耐造程度来看催化剂在我们的办公区并没有太大作用），而活性炭在运行一段时间后都会逐渐达到饱和，那这个时间长短几乎就完全取决于室内的甲醛挥发量了。下面说一下家具的情况：

• 办公区的家具只有一种：L 型办公位；从海鲜市场购买的全新的，一套大约 600 元，总共购买了 8 套，老板声称环保等级为 E1。
• 每个工位上有一个开孔，另外在走弱电的时候，我们还自己开了孔。
• 工位的挡板用的是透明塑料的材质（具体是什么我不清楚），其封边特别不牢固，用手压一下经常都能掰烂，里面应该是胶水。

总得来说这套家具的甲醛总释放率应该不低，这些净化器不耐造的原因可能并不是他本身不行，而是我们办公区本身就是地狱级别。

🛠️ 自制甲醛传感器

小米 5S 的甲醛传感器确实表现非常好，经过一些搜索之后也知道了他用的是瑞士的 Sensiron 的 SFA30 传感器，这个传感器的价格在 160 元左右，加上一个带 WiFi 模块的单片机价格大概在 180 元左右。都到这一步了，那肯定是要自己制作一个传感器才行，目前已经做好并且采集了 5 天的数据了，下面是这个传感器和小米 5S 的对比：

两者在办公区摆放的位置不同，并且单位也不同（小米 5S 做了转换），但即便如此两者的表现还是很接近的。

关于这个自制的传感器的采集数据、可视化代码、板子的代码以及其他更多的信息都放在了下面这个 Repo 里面，感兴趣的同学也可以自行制作一个：

diy

网友评论

留存一些有用的信息。

这个 B 站网友做了比较好的实验，并且还请了 cma 机构测试，加以佐证小米的传感器确实没问题；另外就我的经验来看，我认为他的实验数据是没问题的，那么说明小米对于普通家用其实是可以的，另外就还是需要看长期表现，我已经在催了。

这个 B 买了小米 Ultra，另外自己有一个霍尼韦尔的独立传感器，然后他说 12 平米小米 Ultra 降低到 0.03 了，但是霍尼韦尔的不动，因此他认为 Ultra 不行。根据我的实验来看，其实直接关注 Ultra 的结果就行了，再次说明小米的净化器在家用小空间下是管用的。

Changelog

8 月 19 号

• 添加宫菱 20 天后的表现内容
• 「总结与思考」章节，添加更多内容
• 添加「网友评论」章节

SSLError: HTTPSConnectionPool(host='staging_some_service.proxy.featurize.cn', port=443):
Max retries exceeded with url: /
(Caused by SSLError(SSLCertVerificationError(1, "[SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: Hostname mismatch,
certificate is not valid for 'staging_some_service.proxy.featurize.cn'. (_ssl.c:1006)")))

服务器证书问题？

这个错误看起来很明显，就是证书验证失败，因为域名不匹配。但是这个域名 https://staging_some_service.proxy.featurize.cn 我一直都会使用 Chrome 浏览器访问，从来没有报过证书问题，证书是 Let’s Encrypt 签发的，定期更新，签发后的第一时间我们就用浏览器测试过，是没有问题的。因此应该可以排除是服务器的证书配置有问题。

Staging 机器系统证书的问题？

在 Staging 机器上使用 curl 发出请求，也可以正常返回结果，仅仅是使用 Python 的 requests 发出请求才会报错。因此我这里大概也能有一定程度的把握排除掉是 Staging 机器本身的证书配置问题。

Python 本身的问题？

这时开始怀疑是 Python 的问题，可能 Python 用了和系统不同的证书文件。

通过 curl 加 -v 参数可以看到使用的证书文件：

➜ curl -v https://staging_some_service.proxy.featurize.cn                                            
* Host example.com:443 was resolved.
* IPv6: (none)
* IPv4: 93.184.215.14
*   Trying 93.184.215.14:443...
* Connected to example.com (93.184.215.14) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):

然后，使用 Python 的 certifi 模块查看 Python 使用的证书文件：

➜ python3.11 -c "import certifi; print(certifi.where())"
/opt/homebrew/lib/python3.11/site-packages/certifi/cacert.pem

确实不同，那么强制让 Python 使用于 curl 相同的证书文件 /etc/ssl/cert.pem 再试：

import requests
requests.get(
  "https://staging_some_service.proxy.featurize.cn",
  verify="/etc/ssl/cert.pem"
)

结果还是报同样的错误，现在只觉得问题一定出在 Python 上，但具体不知道到底是什么问题。

一通胡乱的尝试

在 SO 上一通搜索，几乎尝遍了所有的方法，都没用。正当我准备放弃 SSL，直接 verify=False 时，我突然想到了一个问题…

现在的现象是：浏览器访问正常，本机 curl 访问正常，但是 Python requests 访问不正常。但在生产环境，我们是没有这个问题的，生成环境也会访问 *.proxy.featurize.cn 这样的域名，也是使用 requests 发出请求。因为我们使用的是通配符证书，所以 *.proxy.featurize.cn 是可以匹配的。

然后我尝试在 staging 上访问了一个生产环境中的一个域名 abc.proxy.featurize.cn，发现不报错了！现在问题已经浮出水面，是域名格式的问题，staging_some_service.proxy.featurize.cn 这个域名中有下划线，而生产环境中的域名都是没有下划线的。

然后直接 Google 搜索 is underscores allowed in domain names，答案显而易见的是：NO。在 RFC 中 2.3.1 节说明了域名（hostname）格式只能包含大小写和横杠，并且以字母开头，以字母或数字结束，https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1：

The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.

但是，似乎很多浏览器和 DNS 服务器并不完全严格遵守这个规范，所以在浏览器中访问 staging_some_service.proxy.featurize.cn 是没有问题的，而 Python 严格的执行了这一规范，现在看来是错怪了 Python。

🤔 思考

首先这个问题的根源是我对规范不了解导致的，就是这么简单。

其次，这也说明规范是需要严格遵循的，在使用 Chrome 或 cURL 的时候，都没有报错，甚至连个 Warning 都没有。在域名管理的解析的面板上，几乎没有一家对此进行说明，我也能成功添加下划线的域名。

上面是 Cloudflare 域名解析的面板，我添加了一个 1_b_.chenglu.me 的域名，可以看到我几乎违反了全部规范（使用了下划线，开头没有用字母，结尾没有用数字或字母），但还是成功添加了。

我的这个博客也是托管到 Cloudflare 上的，在博客域名 Hostname 的绑定上，会比域名解析要严格一些，但我依然可以添加违反规则的域名，例如可以使用 2333.chenglu.me（已取消解析） 访问本博客，这个域名违反了开头必须是字母的规则。

因为 Cloudflare 博客域名的绑定规则更加苛刻，因此如果访问 1b.chenglu.me(已取消解析) 会显示一个 Cloudflare 定制的错误页面，HTTP 状态码是 522。但这是成功返回了的，能拿到 HTTP 的完整响应。但是，如果用 requests 去请求这个域名，则会得到跟上面一样的报错：

➜ python3.11 -c 'import requests; requests.get("https://1_b_.chenglu.me")'
urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: Hostname mismatch,
certificate is not valid for '1_b_.chenglu.me'. (_ssl.c:1006)

我自己都不敢相信 2024 年了我还在为这个问题发愁…

笔者从 16 年就开始使用 TensorFlow 了，在大概 17 年的时候转投 PyTorch。TensorFlow 以前一直以安装困难，使用麻烦而饱受诟病。然而都 2024 年了，他还是熟悉的味道，不是用户需要，我是真不想咽下这一口的。不过硬吞还是吞了，不能白吃，顺便记录一下这一坨是如何被咽下去的。

PS 下面的安装过程全都在 Conda 虚拟环境中执行的。

记一次失败的经历

安装一个软件，第一反应是什么？当然是按照官方文档的流程来呀。我信心满满地按照中文官方文档直接使用 pip install tensorflow，然后使用文档中提供的测试命令来测试：

python -c "import tensorflow as tf;print(tf.reduce_sum(tf.random.normal([1000, 1000])))"

诶诶不对呀，这测试的代码咋没有测 GPU 呢？然后网上搜索一番，找到了正确测试 GPU 的代码：

python3 -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))"

结果当然是调用 GPU 失败了。遇到问题当然是优先思考是不是我自己有问题，毕竟对方是谷歌。而且在 TF 的旧版本中我已经知道，安装 TensorFlow，除了安装其本身的包之外，还需要自己单独安装 CUDA、cuDNN 等其他的依赖，但都 2024 了，就不能学学 PyTorch，把依赖都放在 Python Package 内吗？

然后我开始像以前一样使用 apt 从英伟达提供的官方软件源中安装 CUDA 和 cuDNN，安装完毕，确认动态链接库的配置正确后，我尝试再次运行测试代码，然而还是失败了，并且会发出一个警告日志：

Cannot dlopen some GPU libraries. Please make sure the missing libraries mentioned above are installed properly if you would like to use GPU

大意就是「上面列出的这些动态链接库找不到，请安装这些东西后再试」。但奇葩就在于，他根本没给咱列出来，到底是哪些个依赖找不到，我尝试打开 TensorFlow 的 Debug 级别的日志，再跑测试代码，依然没给我显示到底是哪些库没有，就一直在那儿逼逼「上面列出的东西找不到了」。此刻他就像是一个领导，一直重复着「关键的问题在于找到问题的关键」，但就是不给你说问题是什么。官方论坛上的这个哥们儿跟我一样，也是这个问题的受害者。

在瞎猫抓耗子似的一通搜索之后，我偶然有幸、冥冥注定般般地打开了官方英文文档，然后我发现英文文档的测试的代码多出了针对 GPU的测试，但我明明记得中文的文档中是没有的。然后我详细看了英文文档，发现安装方式尽然跟官方中文文档的不一样！我只是通过右上角的语言切换按钮切换了语言而已啊，尽然连内容都变了。稍微认真分析就可知道，中文文档是一个旧版本（具体不知道是哪一版的），只有语言切换为英文看的才是最新的文档，此刻我的内心万马（那个马）奔腾，作为简中用户的我又一次感受到了不公。平复好心情后，继续阅读文档，发现正确的安装方式为：

pip install tensorflow[and-cuda]

虽然被官方中文过期文档坑让我有点愤怒，但现在更多的是喜悦：「啊哈！这肯定是一键安装的命令，看看这 [and-cuda]，多么与时俱进的安装方式」。

我又信心满满地创建了一个新的虚拟环境，然后执行了这个命令，从不断滚动的日志中发现明显安装了更多来自 nvidia 的东西。「这下肯定对了」，然后当我测试的时候，他就像 4 月的阿森纳，在掉链子这件事情上从来不掉链子：还是报同样的错！此刻的我已经有点蚌埠住了，甚至一度想放弃：什么掏粪男孩，见鬼去吧！作为一名资深的 AI 环境搭建从业者，我什么时候受到过这种委屈？

冷静下来之后，我开始回朔整个事件，分析到底是哪出错了：

1. 我确定 pip install tensorflow[and-cuda] 已经安装了所有的依赖，因为从日志中明显已经安装了很多来自 nvidia 的 CUDA。
2. 我确定报错的原因是找不到某些动态链接库，虽然他并没有给出具体的库名，但我有 9 成把握是 CUDA 相关的。
3. 安装了又找不到？安装了但找不到…Hmmm….
4. 所以还是动态链接库搜索路径问题？

我具体看了 pip 的安装日志，找到其中一个 nvidia 开头的包名（比如 nvidia-cudnn-cu11），然后使用 pip show nvidia-cudnn-cu11 找到安装路径，然后发现所有 CUDA 相关的依赖都被安装在了 site-packages/nvidia 目录下：

# in site-packages/nvidia
tree -L 1  
.
├── __init__.py
├── __pycache__
├── cublas
├── cuda_cupti
├── cuda_nvrtc
├── cuda_runtime
├── cudnn
├── cufft
├── curand
├── cusolver
├── cusparse
├── nccl
├── nvjitlink
└── nvtx

除了我所熟悉的 cuda_runtime，cudnn 等，还有很多其他的东西，而这些目录下都有动态链接库文件。一不做二不休，直接把所有的目录全部加到 LD_LIBRARY_PATH 中，然后再次测试，终于成功了！

export LD_LIBRARY_PATH=`find {CONDA_ENV_PATH}/envs/py311/lib/python3.11/site-packages/nvidia -name "lib" | tr '\n' ':'`

python3 -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))"

但现在算安装成功了吗？并没有。首先，我需要配置 LD_LIBRARY_PATH，或是修改 /etc/ld.so.conf 才能正常使用，这多少有点别扭。其次这种安装方式有一个问题，如果想在同一个环境中同时安装 PyTorch 和 TensorFlow，是会出问题的，因为他们依赖不同版本的 cuda 包，比如现在装好 TensorFlow 后，再去安装 PyTorch，这些 cuda 相关的软件包会根据 PyTorch 的依赖配置被重新安装且覆盖原来的版本，这可能会导致使用 TensorFlow 时候出现问题。但好在问题的 Root Cause 算是已经找到了。

为什么这么晚才意识到这个问题

我安装过很多不同时期，不同版本的 PyTorch，早期的 PyTorch 不会安装英伟达发布的 Python 依赖（因为那个时候英伟达还没发布过基于 Python Package 的 CUDA），因此 PyTorch 是把所有 CUDA 依赖自行编译成了几个动态链接库（.so）文件中，然后随着 PyTorch 的 Python 的包一起安装。因此安装 PyTorch 是不需要单独安装 CUDA 的。而现在英伟达发布了 CUDA 的 Python 包，所以现在安装 PyTorch 的时候，会直接安装英伟达的 Python CUDA 包了，这种方式跟当前 tensorflow[and-cuda] 的安装方式是一样的。然而，使用 PyTorch 是不需要自己去修改 LD_LIBRARY_PATH 的，这大概率是因为使用 PyTorch 的时候，他会自动把这些动态链接库加到环境变量中，但怎么也没想到 TensorFlow 不会这么做。

稍微好一些的安装方式

对于不需要同时安装 TensorFlow 和 PyTorch 的环境的场景，可以就使用上面的方法，通过修改 LD_LIBRARY_PATH 来解决问题。因为 Featurize 上的环境需要同时安装 PyTorch 和 TensorFlow，因此还需要找到另外的办法。

我的打算是保证 PyTorch 的 CUDA 依赖，然后 TensorFlow 使用旧的手动安装 CUDA 的方法来安装，这样的好处是：

1. PyTorch 的 CUDA 会从 Python 的包中获取，然后 TensorFlow 的 CUDA 会从系统环境 /usr/loca/cuda 中获取，这样就不会冲突了。
2. 系统本身就需要安装一个 CUDA 环境。

而 TensorFlow 需要的 CUDA 相关的依赖也比较清晰了，从 sites-packages/nvidia 目录下就可以找到所有依赖，或者从官方源码的 setup.py 中也能找到 [and-cuda] 所需要的依赖。整个安装过程如下：

# 首先跟着 nvidia 官方文档添加官方 apt 源，否则找不到 cuda-12-3 和 libcudnn8
pip install tensorflow # 这里主要不要加 [and-gpu]
sudo apt-get install cuda-12-3 libcudnn8

对，就是这么简单的两行，就可以愉快地使用 TensorFlow 了。之所以之前搞了很久，就是因为安装了错误的 CUDA 和 cuDNN 版本。对照着官方源码中的 setup.py安装对应的版本就成功解决这个问题了。

最近工作中涉及到实时的数字人渲染，因此梳理了一下近些年的工作，对于作者来说，几乎全是新鲜事物：），从平常搜索的过程中发现这个方向热度非常高，主要原因是非常适合商业的落地（就是很能赚钱）。本文主要是对这个方向的一些工作进行梳理，以及对 NeRF 的浅薄理解。

近些年的工作梳理

时下 2D 图像技术盛行，人脸重建最容易想到的就是极致得使用 2D 图像相关的技术来实现，例如通过音频、文字甚至文字的感情来产生关键点或图像，然后再通过图像的方式渲染人脸。这种方法主要的问题是需要在渲染速度和质量上做很大的取舍。一般来说，直接替换人的嘴部区域会导致图像非常割裂，需要再用到的一些面部修复技术来二次精修，这样导致整个渲染过程非常慢。代表的工作有基于 GAN 的 LibGan: Towards Automatic Face-to-Face Translation，使用 lipsync 监督的 Wav2Lip: A Lip Sync Expert Is All You Need for Speech to Lip Generation In The Wild，基于 Diffusion 的 Diff2Lip: Audio Conditioned Diffusion Models for Lip-Synchronization。

而最近更流行的方向，是基于神经辐射场（Neural Radiance Fields, NeRF）的方法（NeRF YYDS！）。NeRF 通过体积渲染（Volume Rendering）的方式，可以使整个脸部细节保留得更完整，并且可以像 3D 游戏中创建人物时的捏脸的方式一样去捏 2D 图像，代表性的工作是：Dynamic NeRF: Dynamic Neural Radiance Fields。既然可以捏 2D 的头像，那么通过文字或语音驱动嘴形也就顺理成章了，例如AD-NeRF: Audio Driven Neural Radiance Fields for Talking Head Synthesis。ADNeRF 可以通过音频或文字渲染出高质量的人脸说话视频，但其本身的训练和推理过程都非常耗时（因为 NeRF 本身的原因），但好在有一系列的工作来加速 NeRF 的训练和推理过程，这使得实时渲染高质量的数字人成为可能。现在，终于可以重磅请出 RAD-NeRF: Real-time Neural Talking Portrait Synthesis，该工作可以实现实时的高质量人物渲染，这对于游戏、电影、直播等领域都有着非常大的应用前景。后续还有一些其他工作，几乎都是基于 RAD-NeRF 的改进，例如 GeneFace: Generalized and High-Fidelity Audio-Driven 3D Talking Face Synthesis。

NeRF 的工作原理

NeRF 主要用于 3D 重建。给定一个物体，通过从不同方向上对该问题进行拍摄来获取一组图片，然后使用这组图片数据来对该物体进行 3D 建模，而该模型不同于传统的 3D 模型（例如 Blender 中的模型），而是一个神经网络（由 MLP 组成，大小一般在 100MB 以内）。

先说推理

NeRF 由两个部分组成：

1. 3D 模型隐式表达（神经网络）
2. 体渲染（Volume Rendering）

神经网络

NeRF 使用一个神经网络来「存储」一个 3D 模型，这个神经网络的作用是，给定一个视角（摄像机的位置和方向等）和空间点的位置（空间的某一个点），NeRF 可以推理出该点的信息（颜色和密度）。

更具体一点： NeRF 的输入是一个五元组（x, y, z theta, phi），其中（x, y, z）表示真实空间 3D 坐标系中的一个点，（theta, phi）表示此刻观察该点的摄像头位置信息。输出为该点的颜色（rgb值）和体积密度（sigma）。体积密度主要在第二步的体渲染中会用到，现在可以暂时将他视作为该点的一个权重，要更直观的解释的话，可以把他看作透明度。（输入除了 5 元组，其实还有位置信息编码，但这不影响我们理解 NeRF 原理，因此不做介绍了）。

体渲染

体渲染就是将 3D 空间中的所有点渲染成一个 2D 图片。因为在第一步中，我们可以得到在某个视角下的所有空间点的 RGB 和密度信息，体渲染则是将这些信息转换成 2D 图像。体渲染的过程是一个积分过程，即同一个视线（可理解为观测点到 2D 图像上某个像素的连线，后问有详细说明）上的对每个像素点进行积分，得到该视线对应 2D 图像上某个点的颜色信息。形象的解释可以想象成把整个空间的信息沿着视线的方向去拍扁（或者说是投影），拍扁后的 2D 图片就是渲染结果。

体积密度在这里会发挥作用：在体渲染的过程中，我们需要对每个像素点进行积分，而这个积分的权重就是体积密度。体积密度越大，说明这个点越重要，因此在积分的过程中，这个点的权重就越大（其实就是加权求和）。

现在，我们已经可以通过输入某一个视角信息，就得到一个 2D 图像，完成了 3D 渲染的工作。

训练

训练就很简单了，因为在推理过程中，已经得到了一个 2D 图像，那么直接可以将这个 2D 图像和真实的 2D 图像进行对比，算 MSE 损失即可。注意第一步神经网络和第二步体渲染都是可导的，因此整个过程是可导的，可以直接端到端地训练神经网络。

关于 z 是如何选择的？ 因为输入是一个空间信息，而我们从拍摄到的图片仅能获取到 2D 的信息，那么这里 z 的输入应该是什么？

在上面的介绍中，有一个重要的信息没有提及，就是输入的 x, y, z 是如何选择的。特别是 z，因为我们的数据是图片，图片是 2D 的，只能拿到 x, y，那么 z 是如何选择的呢？这里需要引出一个概念：射线投射（Ray Casting）。

简单来说：从拍摄位置，到 2D 图像上的某个点，就可以在 3D 空间中确定一条射线，也就是上文提到的视线（起点是相机位置，理论上没有终点），而 (x, y, z) 就是我们在这条线上采样一些点（因为这条线是空间中的线，因此点的三维空间坐标也是可以确定的，也就是 z 也是确定的），只是采样的方法有很多种，例如均匀采样、随机采样等等。采样的方式也关系到模型的性能。下面是 ChatGPT 的解释：

给定一个2D图像上的像素点，可以根据相机模型反向投射出一条3D空间中的射线。这条射线从相机的中心出发，通过像素点对应的“视窗”上的点，延伸到场景中。通过改变射线上点的深度（即 z 坐标），可以在3D空间中采样不同的点。这种方法称为射线投射（ray casting）。

总结

字太多了，放个狗头吧：

为什么看源码不看论文？因为论文上的一堆公式对数学渣来说是真不想看啊。

总的来说 LoRA 的代码很好理解，核心代码就十来行，读起来是轻松，因此本文篇幅相对较短。有效的方法通常都很简单。

官方源码

LoRA 的官方源码实现了 Conv，Linear，Embedding 的 LoRA 版本，本文用 Linear 来阐述其原理。

模型结构

对于普通的 Linear，其参数仅有 weight 和 bias，而 LoRA 多了两个 lora_A 和 lora_B，对应的代码逻辑如下：

class Linear(nn.Linear, LoRALayer):
    def __init__( self, in_features: int, out_features: int, r: int = 0, alpha: int = 1):
        # ...
        self.lora_A = nn.Parameter(self.weight.new_zeros((r, in_features)))
        self.lora_B = nn.Parameter(self.weight.new_zeros((out_features, r)))
        self.scaling = alpha / r

因为本身继承自 nn.Linear，所以该模块还包含 self.weight 和 self.bias。可以看到 lora_A 和 lora_B 的维度分别是 (r, in_features) 和 (out_features, r)，其中 r 是 LoRA 的超参数。

聪明的读者们应该已经意识到，lora_B @ lora_A 的 shape 正好等于 self.weight，也就是 (in_features, out_features)，因此很容易联想到 LoRA 的实现中应该会有这样的操作：self.weight + lora_B @ lora_A，事实也正是如此。

注意到这里的还有一个超参数 alpha，他处以 r 会得到一个 self.scaling 浮点数，这个数在接下来的计算中会用到。

因此 r 在这里有两个作用：

1. 在 lora_B @ lora_A 中充当了类似 hidden dim 的作用。
2. 和 alpha 一起获得了一个 scaling 参数。

如果对于一个 1024 x 1024 的 Linear 层（不算 bias 共 1,048,576 个参数），如果 r = 64，那么增加的参数量为 1024 * 64 + 64 * 1024 = 131,072，这个参数量仅是原参数量的 1/8。

训练过程

图应该已经很清楚了，X 分别过 self.weight 和 lora_B @ lora_A，将输出相加后得到结果。不过注意 Linear 的参数是被固定的，并不参与训练优化，训练过程中仅优化 lora_A 和 lora_B。

抬出代码：

def forward(self, x: torch.Tensor):
    if training:
        x1 = F.linear(x, T(self.weight), bias=self.bias)
        x2 = dropout(x) @ T(self.lora_A) @ T(self.lora_B) * self.scaling  # 这里还有个 dropout
        x = x1 + x2
    else:
        # 推断的逻辑，稍后给出

    return x

推理过程

在推断之前，我们都会调用 model.eval() 方法，而该方法会触发 LoRA 模型的一个 merge 操作，如代码所示：

self.weight.data += T(self.lora_B @ self.lora_A) * self.scaling

也就是聪明的读者们早就猜到的加法操作，这样，相当于把 lora_B 和 lora_A 的所有信息，「融合」到了 self.weight 中。融合之后，推理过程就跟一般的 Linear 一模一样了。

Hugging Face PEFT

对于大模型 LoRA 微调，用更多是用 Hugging Face 的 PEFT 来做。下面来看看在大模型微调中 LoRA 是如何做的。先看一下官方的使用 Demo：

from transformers import AutoModelForCausalLM
from peft import get_peft_model, LoraConfig, TaskType

model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen1.5-0.5B")

peft_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    inference_mode=False,
    r=64,
    lora_alpha=32,
    lora_dropout=0.1,
    target_modules=["q_proj", "v_proj"]
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()

trainable params: 6,291,456 || all params: 470,279,168 || trainable%: 1.3378130327899194

LoraConfig 中的 r 和 lora_alpha 等参数上文都已经讲过，主要关注到 target_modules，原始大模型 QWen 中的 q_proj 和 v_proj 是 Linear 层，而 get_peft_model 会自动将其转换为 LoRA 层。

注意到 target_modules 参数，这个参数标识需要被替换为 LoRA 的模块名。

下面为 inject 前后两个模型的结构对比，左边是普通模型，右边是 LoRA 模型。

可以看出 LoRA 模型中的 q_proj 和 v_proj 都被修改为了 lora.Linear，并且增加了 lora_dropout，lora_A 和 lora_B 等参数。

QLoRA

QLoRA 是在 LoRA 的基础上，加上了模型量化。QLoRA 允许主模型是一个量化模型，因为主模型往往参数都非常多，加上量化后会极大得降低主模型对资源的要求。

QLoRA 论文上主要有三个贡献：

1. 4-bit NormalFloat (NF4) quantization，一种新的量化类型
2. Double Quantization（DQ），一种新的量化方法
3. Paged Optimizers，一种针对 NVIDIA 的硬件上的优化方法

QLoRA 主要的使用方法跟 LoRA 的区别并不大，仅是多了两个参数 bnb_4bit_quant_type 和 bnb_4bit_use_double_quant，这都是多了一些参数控制，下面是例子：

from transformers import BitsAndBytesConfig

nf4_config = BitsAndBytesConfig(
   bnb_4bit_quant_type="nf4",
   bnb_4bit_use_double_quant=True,
)

model_nf4 = AutoModelForCausalLM.from_pretrained(model_id, quantization_config=nf4_config)

QLoRA 的实现位于 bitsandbytes 中，核心实现都是 CUDA C++ ，这里就不展开讨论了。

总结

LoRA 使用了一个简单的加法操作，将原有的 weight 和 lora_B @ lora_A 相加，通过仅对 lora_* 做训练，来极大的减少需要优化的参数（单层降低 1/8，全部大模型的话大约能缩减到 1%，因为并不是所有层都被转为 LoRA）。

核心参数说明

1. r 参数指定了 lora_B 和 lora_A 的 hidden dim，因为添加的参数量为 in_features * r + r * out_features，因此其越大则表示所添加的训练参数越多。
2. alpha 参数是一个缩放参数，lora_B @ lora_A 的结果会乘以 alpha / r，这个参数可以用来控制 lora_B @ lora_A 对原模型的影响程度。其越大则表示对对原模型的影响越大。
3. dropout 在输入上加上的 dropout，可参考训练过程中的代码。
4. target_modules 这是 PEFT 中的一个参数，指定了需要被替换为 LoRA 的模块名。

PyG 中使用 torch_geometric.data.Dataset 来表示一个数据集，一个数据集可包含多个图，每个图由 torch_geometric.data.Data 对象表示。torch_geometric.data.Data 对象包含了图的节点、边、特征等信息，以及图的标签等信息。下面我们详细得了解其中的细节。

初始化

初始化数据集会选择性地做两件事：

• 下载数据集，将数据集的原始数据下载到本地某个目录中 self.raw_dir。
• 预处理数据集，调用 process 方法对数据集进行预处理，该方法需要用户自己实现。这里的「预处理」实际上指的是将原始数据集处理为含有 torch_geometric.data.Data （下文以 Data 代称）的一个列表，而 Data 则是 torch_geometric 中用于表达一个图的基本数据结构。关于 process 以及 Data 对象，下面将详细说明。

预处理

预处理的逻辑位于 torch_geometric.data.Dataset.process 方法中。

在 process 方法中，用户需要将原始数据集处理成图数据结构，每个图用一个 Data 对象表示。为了避免每次读取数据都要做相同的处理，我们还需要将这些 Data 对象存放到硬盘中。

所有处理好的 Data 对象应该可以被索引，因此通常需要将 Data 存储在一个列表中。如果内存不足，每个 Data 可以存储在硬盘中，文件名带有索引即可。

Data 对象

定义位于：torch_geometric.data.Data。Data 表示了一张图，有两个核心的属性：

• x -> [num_nodes, num_node_features] 所有点的特征矩阵。
• edge_index -> [2, num_edges] 表示所有的边，邻接矩阵的一种简单的表现方式。

通过上述两个属性，就可以确定一张图。在 torch_geometric 中，大多数相关的模型都需要同时传入这两个属性作为输入。因此，这两个属性通常是必不可少的。

其他可选的属性：

• edge_attr -> [num_edges, num_edge_features] 表示边特征，即边的属性，例如在社交网络中人与人的关系特征，或是节点之间的距离等。并不是所有的模型都支持处理边的特征，可以通过 model.supports_edge_attr 来确认模型是否支持边特征。因此，这应该是一个可选特征。
• pos -> [num_nodes, 3] 表示每个节点在空间中的坐标。对于一些 Graph 模型，除了需要节点的特征和关系之外，还需要节点在空间中的位置信息，例如处理点云（Point Cloud）时需要知道点的空间位置信息。当然，除了这种用法之外，还可以将节点的空间信息编码为 edge_attr 并传入一般的模型中。

获取样本 get 方法

跟 torch.utils.data.Dataloader 的 __getitem__ 类似，用户需要定一个 get 方法来获取单个样本，该方法的签名如下：

def get(self, idx: int) -> Data

数据预处理 & 增强

PyG 默认提供了一些数据变换的方法，它们位于 torch_geometric.transforms 中。可以使用这些方法来对 Data 对象进行各种变换。

在选择数据变换时，我们需要考虑该变换是「预处理」还是「随机增强」。通常将原始数据处理为 Data 的集合都是一个耗时的过程，因此 Dataset 的初始化被设计为带有缓存的逻辑。Dataset 的初始化方法提供两个参数，pre_transform 和 transform。对于「预处理」的变换，应该传入 pre_transform，而对于在线的随机增强，则传给 transform。

💡 虽然 pre_transform 和 transform 是基类 Dataset 的属性，但它们都需要用户在子类的 process 和 get 方法中手动调用才会生效。

Batching

图的批处理与图像或序列不同。在图像和序列中，通常使用 padding 或 resize 将不同尺寸、长短的样本堆叠在一起，但这种方法无法对图做类似的操作。

图有一个特性，如果节点之间没有连接，则它们不会相互传递消息。因此可以直接将几个图堆叠成一个超图（HyperGraph），而这个超图中的每个小图就像一座孤岛，彼此之间没有连接关系。因为堆叠起来的大图仍然是一张「图」，在结构上可以直接用于所有图模型，因此在模型层面也无需做任何改动。

torch_geometric.loader.DataLoader 会自动完成上述的 batching 操作。它的实现只是替换了 torch::DataLoader 的 collate 参数，因此其他的参数与 torch::DataLoader 保持一致。collate 中的逻辑也并不复杂，只需要将每个 Data 的 x 属性直接进行 cat 操作（相当于直接 cat 节点信息），而 edge_index 属性在进行 cat 操作的同时加上一个偏移即可，其偏移量就是已经被 stack 的节点数量。

下面是 batching 数据的一些打印信息：

train_dataset[0]
#=> Data(x=[2645, 2], edge_index=[2, 5198], y=[1])

train_loader = iter(DataLoader(train_dataset, batch_size=2))
next(train_loader)
#=> DataBatch(x=[3680, 2], edge_index=[2, 7162], y=[2], batch=[3680], ptr=[3])
next(train_loader)
#=> DataBatch(x=[15985, 2], edge_index=[2, 31879], y=[2], batch=[15985], ptr=[3])
next(train_loader)
#=> DataBatch(x=[3910, 2], edge_index=[2, 7624], y=[2], batch=[3910], ptr=[3])

总结

torch_geometric 的 Dataset 在 PyTorch 的基础上增加了 download 和 process 方法。这些方法的目的是让用户将原始数据集转换为 Data 对象的集合，并做缓存。

Data 对象是 torch_geometric 的一个非常核心的接口。我们用 Data 来表示一张图，其中 Data.x 表示节点信息，Data.edge_index 表示节点与节点的邻接信息。

Batching 几乎不需要用户写代码， torch_geometric 的 DataLoader 会自动完成该工作。