本文以一个典型的三层多层感知机（MLP）为例，梳理神经网络前向传播与反向传播的数学基础，并在此基础上，从系统视角剖析单次训练迭代中的 GPU 显存占用情况及相应的显存优化策略。

一、 数学基础：基于链式法则的反向传播

一个三层 MLP 模型，其参数矩阵分布为 W_1, W_2, W_3，输入为 x，真实标签为 y。

1. 前向传播 (Forward Propagation)

前向传播的核心是计算每一层的中间激活值（Activations）以及最终的预测值 \hat{y}。为保持表达严谨且简洁，省略偏置项并合并激活函数，各层计算过程可表示为：

• 第一层： h_1 = f_1(W_1, x)
• 第二层： h_2 = f_2(W_2, h_1)
• 第三层： \hat{y} = f_3(W_3, h_2)

从全局视角来看，整个前向传播是一个深度的嵌套复合函数，其最终的损失函数（Loss）计算如下：

$L = \text{Loss}(f_3(W_3, f_2(W_2, f_1(W_1, x))))$

2. 反向传播 (Backpropagation)

训练的核心目标是最小化误差 L。我们需要求解损失 L 对各层参数 W 的偏导数（梯度），即量化参数微小变化对最终误差的边际影响。该过程严格依赖微积分中的链式法则（Chain Rule）。

• 第三层梯度： 误差直接对 W_3 求导，等于总误差对预测值的偏导乘以预测值对 W_3 的偏导。

  $ \frac{\partial L}{\partial W_3} = \frac{\partial L}{\partial \hat{y}} \cdot \frac{\partial \hat{y}}{\partial W_3} $

• 第二层梯度： 误差需先传导至第二层的输出 h_2，再对 W_2 求导。

  $ \frac{\partial L}{\partial W_2} = \underbrace{\frac{\partial L}{\partial \hat{y}} \cdot \frac{\partial \hat{y}}{\partial h_2}}_{\text{传导至 } h_2 \text{ 的误差}} \cdot \frac{\partial h_2}{\partial W_2} $

• 第一层梯度： 同理，误差依次反向传播至第一层。

  $ \frac{\partial L}{\partial W_1} = \frac{\partial L}{\partial \hat{y}} \cdot \frac{\partial \hat{y}}{\partial h_2} \cdot \frac{\partial h_2}{\partial h_1} \cdot \frac{\partial h_1}{\partial W_1} $

3. 参数更新 (Weight Update)

获取各层梯度后，通过梯度下降（Gradient Descent）算法，结合学习率 \eta 对模型参数进行迭代更新：

• W_3 \leftarrow W_3 - \eta \cdot \frac{\partial L}{\partial W_3}
• W_2 \leftarrow W_2 - \eta \cdot \frac{\partial L}{\partial W_2}
• W_1 \leftarrow W_1 - \eta \cdot \frac{\partial L}{\partial W_1}

二、 系统视角：单次迭代的 GPU 显存剖析

在上述数学过程转化为工程代码并在 GPU 上执行时，显存（VRAM）的占用是制约模型规模的核心瓶颈。在一次 Forward + Backward 循环中，GPU 显存主要被以下两类数据占据：

1. 静态与输入数据

• 模型参数 (Model Parameters): 即上述的 W_1, W_2, W_3。
• 输入与标签 (Inputs & Labels): 维度通常为 Batch_Size \times 数据维度的大小。

2. 动态生成数据（训练时激增的开销）

• 中间激活值 (Activations, H): 在计算链式法则时，反向传播需要用到前向传播的中间结果（如 h_1, h_2）。因此这些状态必须驻留在显存中 (直到计算出 n-1 层才会释放内存)，其占用大小与 Batch_Size 输入序列长度 呈严格的线性正相关关系。
• 参数梯度 (Gradients, \nabla W): 大小与模型参数 W 完全一致。
• 优化器状态 (Optimizer States): 如果使用 Adam 等具有动量机制的优化器，需要额外记录每个参数的过去一阶动量（Momentum）和二阶方差（Variance）。并为了保证精度使用 32位，这将消耗 4 \times 模型参数大小的额外显存。

以目前最热门的模型llama、qwen等，最小规模 7B 至少 14GB，一次训练单次batch size \times 6=84GB （模型参数[1] 梯度[1] 优化器[4]），已经 超出一张A100的大小，所以如今大模型训练设计出了各种显存优化策略。

三、 显存优化：存算置换与高效训练策略

针对上述显存瓶颈，工程上常采用“以计算时间换取显存空间”或“降低数值精度”的策略。

1. 核心“存算置换”策略概览

(以下提及的存算置换策略，其底层原理与工程实现机制将在后续的专栏文章中进行详细深度解析。)

• 小批次 + 梯度累加 (Small Batch + Gradient Accumulation): 在时间维度上拆分大 Batch，通过多次小 Batch 的前向/反向传播累加梯度，绕过单次激活值过大的显存限制。（但依旧会 OOM）
• ZeRO-Offload (算时加载): 将优化器状态或梯度等暂时卸载至 CPU 内存（RAM），在需要计算时再通过 PCIe 调度至 GPU显存。
• 梯度检查点 (Gradient Checkpointing): 前向传播时主动丢弃部分中间激活值 H，在反向传播经过该层时重新计算。这是一种典型的以增加计算量（约30%）换取显著显存节省的策略。

2. 其他正交优化技术

工业实践上更为常用

• 混合精度与量化 (Mixed Precision / Quantization): 将传统的 FP32 运算降阶为 FP16/BF16，甚至 INT8/INT4，成倍削减显存占用并提升计算吞吐。
• 参数高效微调 (PEFT, 如 LoRA): 在微调阶段冻结主干网络（不保存其激活值与优化器状态），仅注入极少量的可训练参数矩阵，将训练显存开销降低至全量微调的零头。

看完了？说点什么呢

最近使用AI Agent, 框架开发web应用。然而设计数据库或前后端交互时，还需自行设计后端。当然过于跨域等老生常谈的问题不用过多赘述，因为Nginx解决了大部分。在开发过程中总结一些关于Nginx配置踩坑并额外补充的一些前端知识。

一个简单的配置

## web
    location /tb/ {
    alias D:/Projects/xxx/dist/;
    index index.html;
    try_files $uri $uri/ /tallybook/index.html;
    }
## api
    location /tbapi/ {
        proxy_pass http://127.0.0.1:8000/;
        proxy_redirect off;
    }

root 与 alias

localtion 模块中用来指定映射服务器静态资源文件的命令

• root 是追加：它把请求的 URL 拼接到 root 指定的路径后面。
• alias 是替换：它用 alias 指定的路径 替换掉 location 匹配的部分。

当浏览器访问：*http://site.com/images/cat.jpg 时*

location /images/ {
    root /var/www/html;
}

→ /var/www/html/images/cat.jpg

location /images/ {
    alias /var/www/html/;
}

→ /var/www/html/cat.jpg

注意：如果 location 后面有 /（例如 /images/），那么 alias 后面必须也要加 /。

proxy_pass 反向代理的路径透传

对于nginx设置

    location /downloader/data/ {
        proxy_pass http://127.0.0.1:8000/;

如果设置了autoindex on; location 建议以 / 结尾

注意，此时只会路由到/downloader/data 或 /

🕳 python http.server

最好的debug方式就是在 do_GET中打印地址

    def do_GET(self):
        print(self.path)
        # ...
        super().do_GET()

启用 http.server 需要注意的坑
场景：将http.server作为静态资源服务器，指定资源目录

如果希望指定目录. 则需要在python后端重写**path** ，这种方法在需要修改目录的情况下最方便。

# 将 Nginx 传来的虚拟路径替换为本地实际目录
self.path = self.path.replace('/downloader/data', f'/{DIRECTORY}')
# 指定 http.server 访问的目录
# self.path = f'/{DIRECTORY}' + self.path

try_files 单页应用（SPA）的部署策略

try_files $uri $uri/ /index.html;

为什么这样写：

现代 SPA（单页应用）

现在的前端框架（如 Vue/React），整个网站其实只有一个 HTML 文件（通常是 index.html）。页面的切换（路由）是由浏览器里的 JavaScript 控制的，而不是服务器。

问题来了：

1. 用户访问首页 http://site.com/ -> Nginx 返回 index.html -> JS 加载 -> 此时用户点击按钮跳转到 /user/profile。
   • 注意：这时候浏览器地址栏变了，但浏览器并没有向 Nginx 发送请求，是 JS 把页面内容变了。一切正常。
2. 但是！ 用户在 /user/profile 这个页面，按了一下 F5 刷新。
3. 浏览器向 Nginx 发送请求：GET /user/profile。
4. Nginx 傻眼了：我去哪里找 /user/profile 这个文件？根目录下根本没有 user 文件夹，更没有 profile 文件。
5. Nginx 默认行为：直接报 404 错误。

作用 （三步走）

先尝试访问路由文件→ 访问目录 + index/html（如果存在）→ 指定的html (兜底)

一种优雅的**“静态资源优先，应用入口兜底”** 的设计模式

看完了？说点什么呢

控制移动

基础移动

创建一个物体

进入蓝图 （蓝图关系）

蓝图设置

F7 编译蓝图

设置移动性

预览

Alt+P

非线性移动

添加时间轴

编辑时间轴

接入时间轴

Spline 移动

通过 spline 设计物体运动路线，实现复杂的运动路线

• 创建蓝图 -> 赋予 spline 组件
• 场景中编辑线条 （拖动、alt 添加节点）
• 运动物体引用 spline 位置

创建 spline 蓝图

蓝图

最右侧为 Ftransform 变量，可视为 位置、旋转、缩放 的结构体

设置路径

从内容菜单拖出对象

Alt + 🖱️ 左键端点拉出新的路径点

移动物体引用路径

创建一个新的蓝图类

打开蓝图为其添加一个 spline 蓝图的引用，（相当于一个指向该类对象的指针）

记得编译

绑定对象

编辑蓝图

预览

看完了？说点什么呢

过程

开启c++编程后，编译报错

Expecting to find a type to be declared in a module rules named 'VisualStudioTools' in 'UE5Rules, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.  This type must derive from the 'ModuleRules' type defined by UnrealBuildTool.

缺少 VisualStudioTools , 疑似新建c++项目，初始化时安装插件时选择 安装到驱动 导致。 应该选择安装到项目

解决方法

项目目录新建Plugins目录， 将 ...\UE_5.x\Engine\Plugins\VisualStudioTools 拷贝到该目录下。

其他

类似问题，同理解决方法

Expecting to find a type to be declared in a module rules named 'XXX' in 'UE5Rules

看完了？说点什么呢

突然接到任务，做一款基于UE5的项目，大概两个月时间， 这不可能完成的吧。从头开始学估计要花不少时间，虽然项目上只需要关注 C++ 侧的编程，只能先学再说了。
迅速了解了下UE5的作品。貌似可以开发VR 项目。刚好用上在角落吃灰的quest3，原本也有计划在3年内做款 VR Game，这下提前计划了。最近各种学习计划被提前 等于没提前

针对项目做计划

近期目标就是实现运动与事件交互吧 （2025.10.25）

• C++ Class 如何使用 （如何体现到blueprint）
• 实现物体移动
• 物体状态触发事件
• 物体与物体间的交互

看完了？说点什么呢

天津神户园，纪念中日的两个港口城市友好交往而建。可惜到时天时以晚，加上手机电量告急。匆匆拍上几张照片便乘车返回了。
下午到天津市区开会，刚好在水上公园边上，会议结束时便顺路散步到了神户园。 听闻这个中日蜜月期建成的园林很久了，但地方太偏了（没一条顺路的地铁线到达）

从里面拍摄，经典的日式入口

内部小道和建筑都极具日式风格⛩️ 。虽然看着挺亮，全靠手动快门救活

、

看完了？说点什么呢

记一次wsl下的环境踩坑，折腾一个多小时，发现了奇怪的解决方法

发现问题

先上环境：

import onnxruntime as ort
ort.get_available_providers()

显示可用

['TensorrtExecutionProvider', 'CUDAExecutionProvider', 'CPUExecutionProvider']

报错段，识别不到 gpu ，但环境下pytorch能使用gpu

session = ort.InferenceSession("yolov8n/best.onnx", providers=["CUDAExecutionProvider"])

*************** EP Error ***************
EP Error /onnxruntime_src/onnxruntime/core/providers/cuda/cuda_call.cc:129 std::conditional_t<THRW, void, onnxruntime::common::Status> onnxruntime::CudaCall(ERRTYPE, const char*, const char*, SUCCTYPE, const char*, const char*, int) [with ERRTYPE = cudaError; bool THRW = true; SUCCTYPE = cudaError; std::conditional_t<THRW, void, common::Status> = void] /onnxruntime_src/onnxruntime/core/providers/cuda/cuda_call.cc:121 std::conditional_t<THRW, void, onnxruntime::common::Status> onnxruntime::CudaCall(ERRTYPE, const char*, const char*, SUCCTYPE, const char*, const char*, int) [with ERRTYPE = cudaError; bool THRW = true; SUCCTYPE = cudaError; std::conditional_t<THRW, void, common::Status> = void] CUDA failure 100: no CUDA-capable device is detected ; GPU=-1 ; hostname=DESKTOP-LBBLQ7H ; file=/onnxruntime_src/onnxruntime/core/providers/cuda/cuda_execution_provider.cc ; line=282 ; expr=cudaSetDevice(info_.device_id); 

 when using ['CUDAExecutionProvider']
Falling back to ['CPUExecutionProvider'] and retrying.
****************************************

尝试 debug

查阅资料，认为的 onnxruntime 找不到 cudnn, 而 pytorch 是自带 cudnn 的。

wsl 中的 cuda toolkit 都是调用window下的，在win下安装好后一般不必在wsl重新安装

apt 安装库，修改环境变量 ... 之后便报了 not found 错误, 然而继续把缺少的安装上并修改环境变量后，在终端执行 nvidia-smi 发现无效了, 赶紧把环境变量注释掉。

意外解决

原本打算就这样算了，服务器用 CPU （i7-13700） 也足够，在中间需要数据转换时 import torch 报错 undefined symbol,一开始以为还是把环境搞崩了，但开了新的 .py 发现能正常使用。之后尝试在使用 onnx 前多加一行

import torch # add
import onnxruntime as ort
session = ort.InferenceSession("yolov8n/best.onnx", providers=["CUDAExecutionProvider"])

没想到真就通过了...

记录引起报错的代码

onnxruntime: 无法识别 GPU

import onnxruntime as ort
session = ort.InferenceSession("yolov8n/best.onnx", providers=["CUDAExecutionProvider"])

pytorch: undefined symbol 报错

import onnxruntime
import torch

看完了？说点什么呢

使用hashcat掩码模式破解文档时，一开始以为设计mask，会和正则一样，虽然复杂但使用GPT之类的工具能快速构建出规则。但可能是版本原因或其他问题，GPT、deepseek提供的方案都无效

看完了？说点什么呢

表达与清晰问题可以分为两类，信息表达不充分与表达过度，而这类问题在如今有AI辅助下，是最好解决。

信息表达不充分

获取信息不足，理解困难

• 神秘命名（Mysterious Name），不用多说，像 a b x y 等变量命名，虽说设计阶段很方便，但在维护与使用会产生时间成本。
• 注释（Comments），不是说写注释不好，而是不应该把注释当作“除臭剂”

def do_stuff(a, b):
    return a * b + 42
result = do_stuff(5, 7)

def calculate_total_price(unit_price: float, quantity: float) -> float:
    TAX = 42
    return unit_price * quantity + TAX
total = calculate_total_price(5, 7)

上面的函数 do_stuff 就算把注释加上，每次阅读代码可能都需要鼠标移到函数上靠IDE的阅读一遍注释才能理解其作用；而calculate_total_price 只看函数命名便能知道它是干嘛的。

表达过度

代码获取信息过多，信噪比低

• 冗赘的元素（Lazy Element），被设计出来但没有被使用的变量、函数、类等，也可能是维护过程遗留的东西，属于纯粹的噪音
• 夸夸其谈通用性（Speculative Generality），过早抽象、设计，不仅是噪音，还在开发阶段浪费不少时间与精力
• 循环语句（Loops） ，并不是说循环是错的，而是说在高层逻辑中显式写循环是低层次的表达。相比于使用声明式的高级抽象（如函数式操作），往往会产生更多的问题。比如map stream等高级方法能代替 for while的功能，并更清晰地表达其意图。

看完了？说点什么呢

对该书重构部分，“坏味道”的总结。随着 IDE 功能的完善与日益发展的AI，有些问题也有了更好的解决方法，后续进一步展示个人解读与思考

1. 神秘命名（Mysterious Name）  
2. 重复代码（Duplicated Code）  
3. 过长函数（Long Function）  
4. 过长参数列表（Long Parameter List）  
5. 全局数据（Global Data）  
6. 可变数据（Mutable Data）  
7. 发散式变化（Divergent Change）  
8. 霰弹式修改（Shotgun Surgery）  
9. 依恋情结（Feature Envy）  
10. 数据泥团（Data Clumps）  
11. 基本类型偏执（Primitive Obsession）  
12. 重复的 switch（Repeated Switches）  
13. 循环语句（Loops）  
14. 冗赘的元素（Lazy Element）  
15. 夸夸其谈通用性（Speculative Generality）  
16. 临时字段（Temporary Field）  
17. 过长的消息链（Message Chains）  
18. 中间人（Middle Man）  
19. 内幕交易（Insider Trading）  
20. 过大的类（Large Class）  
21. 异曲同工的类（Alternative Classes with Different Interfaces）  
22. 纯数据类（Data Class）  
23. 被拒绝的遗赠（Refused Bequest）  
24. 注释（Comments）

对24个"坏味道"进行分类

一、表达与清晰度问题

• 神秘命名（Mysterious Name）
• 注释（Comments）
• 循环语句（Loops）
• 冗赘的元素（Lazy Element）
• 夸夸其谈通用性（Speculative Generality）

二、结构与规模问题

• 过长函数（Long Function）
• 过大的类（Large Class）
• 过长参数列表（Long Parameter List）

三、重复与分散问题

• 重复代码（Duplicated Code）
• 重复的 switch（Repeated Switches）
• 异曲同工的类（Alternative Classes with Different Interfaces）
• 霰弹式修改（Shotgun Surgery）
• 发散式变化（Divergent Change）

四、耦合与依赖 （模块间）

• 全局数据（Global Data）
• 可变数据（Mutable Data）
• 依恋情结（Feature Envy）
• 过长的消息链（Message Chains）
• 中间人（Middle Man）
• 内幕交易（Insider Trading）
• 被拒绝的遗赠（Refused Bequest）

五、数据组织问题

• 数据泥团（Data Clumps）
• 基本类型偏执（Primitive Obsession）
• 纯数据类（Data Class）
• 临时字段（Temporary Field）

除去1外，其他4类可以归为设计边界上的不合理

规模问题 → “一个类/函数是不是太胖？”

重复问题 → “为什么到处都有类似的逻辑？”

耦合问题 → “为什么 A 和 B 粘在一起动不了？”

数据问题 → “为什么数据不像对象，更像裸变量？”

看完了？说点什么呢