1. 从一次“离谱”的需求说起：为什么要在浏览器里训练神经网络

前阵子有个做在线教育工具的朋友找我，说他们想做一个“手写数字识别”的互动教学页面，学生用鼠标在画布上写个数字，页面立刻告诉他是几。听起来简单，但他们的约束条件很苛刻：不能有后端推理服务，不能依赖云端API，所有计算必须在用户打开网页的那一瞬间就准备好，而且还得支持“现场教学微调”——也就是学生可以自己补充几个样本，让模型当场学一下，识别效果立刻变好。

这个需求翻译成技术语言就是：在浏览器端完成神经网络的训练和推理。注意，是训练，不只是推理。推理在浏览器里跑早就不新鲜了，用ONNX Runtime Web或者TensorFlow.js加载一个预训练模型，前向传播一下，这事很多年前就能做。但训练意味着反向传播、梯度计算、参数更新，计算量比推理大得多，而且要在用户设备上跑，不能把浏览器卡死。

我当时的第一个反应是：用CPU跑JavaScript？别闹了。一个两层全连接网络在MNIST上训练，纯JS循环跑一轮epoch可能要几十秒，用户体验直接崩掉。第二个反应是：WebAssembly？能快一些，但WASM本身不直接支持SIMD并行矩阵运算，除非你自己手写SIMD指令，开发成本极高。第三个反应，也是最终落地的方案：WebGL。

WebGL的本质是什么？很多人第一反应是“画3D图形的”。没错，但更底层地看，WebGL是一套在GPU上执行并行计算的接口。它把数据组织成纹理，把计算逻辑写成着色器程序，然后让GPU的几千个核心同时跑。神经网络的训练，核心就是大规模矩阵乘法和逐元素运算，这恰好是GPU最擅长的事情。所以，用WebGL来加速浏览器端神经网络训练，不是“能不能”的问题，而是“怎么把神经网络的计算图映射到WebGL的渲染管线上”的问题。

这篇文章，我就把这条路径完整拆开讲一遍。从GPU为什么适合做这件事，到怎么把矩阵乘法写成着色器，到反向传播怎么在WebGL里落地，再到实际跑起来会踩哪些坑。如果你正在考虑把模型训练搬到浏览器端，或者单纯好奇“网页里怎么跑神经网络”，这篇内容应该能给你一套可复现的思路。

2. GPU的并行逻辑：为什么矩阵乘法在WebGL里能快几十倍

2.1 从CPU的“串行思维”切换到GPU的“并行思维”

先建立一个直觉。假设你要计算两个矩阵相乘：A是1000×1000，B也是1000×1000，结果C是1000×1000。用CPU做，你会写三层循环，外层遍历C的行，中层遍历C的列，内层做点积。总共要算10亿次乘加运算。现代CPU大概有8到16个核心，每个核心同一时刻只能处理一个乘加（不考虑指令级并行），所以理论上要跑几亿个时钟周期。

GPU不一样。一块普通的集成显卡也有几百个着色器核心，独立显卡更是几千个。这些核心可以同时执行相同的指令，只是处理不同的数据。矩阵乘法里，C的每一个元素都是独立的，互不依赖。这意味着你可以把C的100万个元素分配给GPU的几千个核心，每个核心算几百个元素，并行度直接拉满。

但这里有个关键限制：GPU的并行是SIMD式的，同一批核心在同一时刻必须执行相同的指令。你不能让核心A去做乘法，核心B去做加法，核心C去读内存。所以写WebGL着色器时，你的思维要变成：“我要对每一个像素（或每一个数据元素）执行同一套操作，只是输入数据不同。”

2.2 WebGL的渲染管线如何变成计算管线

WebGL的标准用法是：你提供顶点数据，顶点着色器处理每个顶点，然后光栅化，片段着色器处理每个像素，最后写入帧缓冲。这套流程里，片段着色器是最适合做通用计算的阶段，因为它对每个像素独立执行，天然并行。

要把矩阵乘法映射进去，做法是这样的：

• 把矩阵A和矩阵B分别编码成纹理。纹理的每个像素存储一个浮点数（或者用RGBA四个通道存四个数）。
• 创建一个和输出矩阵C同样大小的帧缓冲，作为渲染目标。
• 写一个片段着色器，对于输出纹理上的每一个像素位置(i, j)，计算A的第i行和B的第j列的点积。
• 用一次绘制调用（drawArrays或drawElements）触发整个计算。

这里有个细节：片段着色器不能直接“读取”另一个纹理的任意位置吗？可以，用texture2D函数，传入归一化的纹理坐标。但要注意，纹理坐标是0到1的浮点数，你需要把整数索引转换成归一化坐标。比如要读A的第k列，坐标就是(k + 0.5) / width，加0.5是为了采样到像素中心。

一次绘制调用就能算出整个C矩阵。1000×1000的矩阵乘法，在GPU上就是渲染一个1000×1000的矩形，每个像素做1000次乘加。GPU的几千个核心同时跑，实际耗时可能在几毫秒到几十毫秒之间，比CPU快两个数量级。

2.3 精度问题：WebGL的浮点数够用吗

这是很多人会忽略的坑。WebGL 1.0的片段着色器默认使用mediump精度，也就是16位浮点数，范围大约±65504，精度只有10位尾数。用来做神经网络训练，梯度值很容易下溢到0，或者上溢到Infinity。训练直接崩掉。

解决方案有两个：

第一，在着色器里显式声明highp精度。precision highp float;这样可以用到32位浮点数（具体取决于GPU实现，但大多数现代设备支持）。highp的范围和精度足够覆盖神经网络训练中的数值。

第二，如果设备不支持highp（一些老旧的移动GPU），可以考虑用“分块计算”或者“缩放因子”来规避。比如把梯度乘以一个大的常数，计算完再除回来。但这会增加复杂度，实际项目中我建议直接检测设备能力，不支持highp就降级到CPU路径。

还有一个隐藏问题：WebGL的纹理格式。默认的RGBA纹理每个通道8位，只能存0到255的整数。要存浮点数，必须使用OES_texture_float扩展，把纹理内部格式设为gl.FLOAT。这个扩展在现代浏览器上支持率很高，但还是要做特性检测。

3. 把神经网络拆成WebGL能吃的“图形任务”

3.1 全连接层的前向传播：一次矩阵乘法加一次激活

假设你有一个简单的全连接层：输入向量x（维度n），权重矩阵W（维度m×n），偏置b（维度m），输出y = activation(Wx + b)。

在WebGL里，这一步可以拆成两个渲染过程：

第一个过程算z = Wx + b。把W编码成纹理，x编码成另一个纹理（或者直接作为uniform数组传入，如果n不大的话）。输出z是一个m维向量，可以渲染成一个m×1的纹理。片段着色器里，对于输出纹理的第i个像素，计算W的第i行和x的点积，再加上b[i]。

第二个过程算y = activation(z)。这是一个逐元素操作，直接把z纹理作为输入，渲染到y纹理。着色器里对每个像素应用激活函数，比如ReLU就是max(0, z)，Sigmoid就是1/(1+exp(-z))。

这里有个优化点：如果网络有多层，可以把中间结果一直保留在纹理里，不需要读回CPU。每一层的输出纹理直接作为下一层的输入纹理。这样整个前向传播就是一系列绘制调用，数据始终在GPU显存里流转，避免了PCIe总线的来回拷贝。

3.2 反向传播的链式法则在着色器里怎么表达

反向传播是训练的核心，也是最难映射到WebGL的部分。核心公式是：对于每一层，先算输出的梯度dL/dz，然后算权重的梯度dL/dW = dL/dz * x^T，输入的梯度dL/dx = W^T * dL/dz。

在WebGL里，dL/dz的计算通常涉及逐元素乘法（比如ReLU的导数就是z>0?1:0，和dL/dy逐元素相乘）。这个可以写成一个片段着色器，输入是dL/dy纹理和z纹理，输出是dL/dz纹理。

dL/dW的计算是一个外积：dL/dz是m维，x是n维，外积得到m×n的矩阵。这个可以映射成一次矩阵乘法，把dL/dz当作列向量，x当作行向量。输出纹理的大小是m×n，每个像素(i,j)的值是dL/dz[i] * x[j]。这个计算很简单，但要注意纹理的布局——WebGL纹理是二维的，你需要决定怎么把一维向量和二维矩阵对应起来。

dL/dx的计算是W^T乘以dL/dz，这是一个矩阵向量乘法。W^T是n×m，dL/dz是m维，结果是n维。这个可以复用前面矩阵乘法的着色器，只是把W的纹理转置一下（或者在着色器里交换索引）。

实际实现时，我建议把每一层的反向传播拆成三个独立的渲染过程：算dL/dz、算dL/dW、算dL/dx。每个过程一个着色器程序，输入输出都是纹理。这样逻辑清晰，调试也方便。

3.3 参数更新：在GPU上做还是回CPU做

参数更新是W = W - learning_rate * dL/dW。这个操作本身很简单，逐元素减法。但问题在于：更新后的W需要作为下一轮前向传播的输入。如果W一直留在GPU纹理里，那更新也可以在GPU上做，写一个片段着色器，输入W纹理和dL/dW纹理，输出新的W纹理。

但这里有个权衡。如果所有参数都在GPU上，你就没法方便地查看训练过程中的权重变化，也没法做复杂的优化器（比如Adam需要维护一阶矩和二阶矩，计算量不大但逻辑稍复杂）。我的做法是：前向和反向在GPU上跑，参数更新回CPU做。每一轮迭代结束后，把dL/dW从GPU读回CPU（用readPixels），在JavaScript里更新权重，再把新权重上传到GPU纹理。这样虽然多了两次数据传输，但灵活性大大提高，而且对于小网络来说，传输开销远小于计算开销。

读回数据时要注意：readPixels是同步操作，会阻塞渲染管线。如果每轮都读，可能会成为瓶颈。优化方法是批量读——积累几轮的梯度再一起读回，或者用WebGL 2.0的PBO（像素缓冲对象）做异步读回。但WebGL 2.0的兼容性还不如1.0，实际项目中要权衡。

4. 手写一个WebGL神经网络训练器的完整路径

4.1 环境搭建与基础工具函数

首先，你需要一个WebGL上下文。创建一个canvas，获取gl对象。然后检查必要的扩展：

const canvas = document.createElement('canvas'); const gl = canvas.getContext('webgl'); const floatExt = gl.getExtension('OES_texture_float'); if (!floatExt) { throw new Error('设备不支持浮点纹理，无法进行GPU训练'); }

接下来是几个基础工具函数，这些函数会反复用到：

创建浮点纹理：输入是一个Float32Array，输出是一个WebGL纹理对象。注意设置纹理参数为NEAREST采样，避免插值导致数值错误。

function createFloatTexture(gl, data, width, height) { const texture = gl.createTexture(); gl.bindTexture(gl.TEXTURE_2D, texture); gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, width, height, 0, gl.RGBA, gl.FLOAT, data); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.NEAREST); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.NEAREST); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_S, gl.CLAMP_TO_EDGE); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_T, gl.CLAMP_TO_EDGE); return texture; }

创建帧缓冲：帧缓冲是渲染目标，你把片段着色器的输出写进去。每个帧缓冲绑定一个纹理作为颜色附件。

function createFramebuffer(gl, texture) { const fb = gl.createFramebuffer(); gl.bindFramebuffer(gl.FRAMEBUFFER, fb); gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0, gl.TEXTURE_2D, texture, 0); return fb; }

编译着色器程序：这是标准流程，编译顶点着色器和片段着色器，链接成程序。顶点着色器通常很简单，就是传递一个覆盖整个画布的矩形。

function createProgram(gl, vertexSource, fragmentSource) { const vs = gl.createShader(gl.VERTEX_SHADER); gl.shaderSource(vs, vertexSource); gl.compileShader(vs); const fs = gl.createShader(gl.FRAGMENT_SHADER); gl.shaderSource(fs, fragmentSource); gl.compileShader(fs); const program = gl.createProgram(); gl.attachShader(program, vs); gl.attachShader(program, fs); gl.linkProgram(program); return program; }

这些工具函数看起来简单，但每个都有坑。比如纹理的宽高必须是2的幂吗？在WebGL 1.0里，如果使用NEAREST采样和CLAMP_TO_EDGE，可以不是2的幂。但有些驱动会强制要求，所以最安全的做法是padding到2的幂。我一般会把矩阵维度补齐到最近的2的幂，比如1000×1000的矩阵，实际分配1024×1024的纹理，多出来的部分填0。

4.2 矩阵乘法着色器的逐行拆解

矩阵乘法是整个训练流程里最核心的计算。假设我们要算C = A × B，A是M×K，B是K×N，C是M×N。

顶点着色器很简单，就是画一个覆盖整个输出纹理的矩形：

attribute vec2 a_position; void main() { gl_Position = vec4(a_position, 0.0, 1.0); }

片段着色器是重点：

precision highp float; uniform sampler2D u_A; uniform sampler2D u_B; uniform vec2 u_A_size; // (M, K) uniform vec2 u_B_size; // (K, N) uniform vec2 u_C_size; // (M, N) void main() { vec2 c_pos = gl_FragCoord.xy; // 当前像素在C中的位置 float sum = 0.0; for (int k = 0; k < int(u_A_size.y); k++) { // 读A的第c_pos.x行，第k列 vec2 a_uv = vec2((c_pos.x + 0.5) / u_A_size.x, (float(k) + 0.5) / u_A_size.y); float a_val = texture2D(u_A, a_uv).r; // 读B的第k行，第c_pos.y列 vec2 b_uv = vec2((float(k) + 0.5) / u_B_size.x, (c_pos.y + 0.5) / u_B_size.y); float b_val = texture2D(u_B, b_uv).r; sum += a_val * b_val; } gl_FragColor = vec4(sum, 0.0, 0.0, 1.0); }

这段代码有几个关键点：

第一，gl_FragCoord.xy给出的是像素中心坐标，比如第一个像素是(0.5, 0.5)。所以计算纹理坐标时要加0.5再除以尺寸。

第二，循环次数必须是常量或者可以用uniform控制。WebGL 1.0的GLSL不允许非常量循环边界，但可以用一个足够大的常量循环，然后在循环体内用if判断是否超出范围。不过现代浏览器对动态循环的支持已经不错了，实际测试中大多数设备都能跑。

第三，每次循环要读两次纹理。纹理读取是GPU计算中最慢的操作之一，因为要访问显存。优化方法是把A和B的纹理绑定到不同的纹理单元，并且尽量让循环内的访问模式有局部性。但矩阵乘法的访问模式天然是跳跃的，所以这个优化空间有限。

一个实用的优化技巧：分块计算。把大矩阵切成小块，比如32×32的块，每个块的计算可以更好地利用GPU的缓存。但这会增加着色器的复杂度，实际项目中如果矩阵不大（比如全连接层通常几百维），直接算就够了。

4.3 激活函数与损失函数的GPU实现

激活函数是逐元素操作，实现起来简单。以ReLU为例：

precision highp float; uniform sampler2D u_input; void main() { vec2 uv = gl_FragCoord.xy / vec2(textureSize(u_input, 0)); float val = texture2D(u_input, uv).r; gl_FragColor = vec4(max(0.0, val), 0.0, 0.0, 1.0); }

Sigmoid稍微复杂一点，因为要算exp：

float sigmoid(float x) { return 1.0 / (1.0 + exp(-x)); }

但要注意，exp函数在highp下可能会有精度问题，特别是当x很大或很小时。一个稳定的实现是：

float stable_sigmoid(float x) { if (x >= 0.0) { return 1.0 / (1.0 + exp(-x)); } else { float e = exp(x); return e / (1.0 + e); } }

损失函数通常用交叉熵。对于分类问题，交叉熵的梯度是softmax输出减去真实标签。这个计算可以放在CPU做，因为只涉及输出层，计算量小。但如果想全GPU化，也可以写一个着色器，输入是预测概率和真实标签，输出是每个样本的损失值。

4.4 反向传播的着色器实现细节

反向传播里最复杂的是dL/dW的计算。假设当前层的输入是x（n维），输出梯度是dL/dz（m维），那么dL/dW是一个m×n的矩阵，每个元素是dL/dz[i] * x[j]。

这个计算可以写成一个着色器，输出纹理大小是m×n：

precision highp float; uniform sampler2D u_dz; // m维向量，存成m×1纹理 uniform sampler2D u_x; // n维向量，存成n×1纹理 uniform vec2 u_dz_size; uniform vec2 u_x_size; void main() { vec2 pos = gl_FragCoord.xy; // pos.x是行索引i，pos.y是列索引j vec2 dz_uv = vec2(0.5 / u_dz_size.x, (pos.x + 0.5) / u_dz_size.y); vec2 x_uv = vec2(0.5 / u_x_size.x, (pos.y + 0.5) / u_x_size.y); float dz_val = texture2D(u_dz, dz_uv).r; float x_val = texture2D(u_x, x_uv).r; gl_FragColor = vec4(dz_val * x_val, 0.0, 0.0, 1.0); }

注意这里纹理坐标的写法。因为dz和x都是一维向量，我习惯把它们存成宽度为1、高度为维度的纹理。这样读取时，x坐标固定为0.5/width（即像素中心），y坐标根据索引变化。

dL/dx的计算是W^T × dL/dz。W是m×n，W^T是n×m，dL/dz是m维，结果是n维。这个可以复用矩阵乘法的着色器，只需要把W的纹理坐标交换一下。或者写一个专门的着色器：

precision highp float; uniform sampler2D u_W; // m×n uniform sampler2D u_dz; // m维 uniform vec2 u_W_size; uniform vec2 u_dz_size; void main() { float i = gl_FragCoord.y; // 输出向量的索引 float sum = 0.0; for (int j = 0; j < int(u_W_size.x); j++) { vec2 w_uv = vec2((float(j) + 0.5) / u_W_size.x, (i + 0.5) / u_W_size.y); float w_val = texture2D(u_W, w_uv).r; vec2 dz_uv = vec2(0.5 / u_dz_size.x, (float(j) + 0.5) / u_dz_size.y); float dz_val = texture2D(u_dz, dz_uv).r; sum += w_val * dz_val; } gl_FragColor = vec4(sum, 0.0, 0.0, 1.0); }

这里W的读取是W[j][i]，因为我们要算W^T的第i行，也就是W的第i列。所以w_uv的x坐标是j（行索引），y坐标是i（列索引）。这个索引交换很容易搞混，写的时候要特别小心。

5. 实测中那些文档不会告诉你的坑

5.1 纹理尺寸限制与矩阵分块策略

WebGL有一个硬性限制：MAX_TEXTURE_SIZE。这个值在不同设备上不一样，低端手机可能只有2048，高端显卡能到16384。如果你的权重矩阵超过这个尺寸，就必须分块。

分块矩阵乘法的思路是：把A切成若干行块，B切成若干列块，然后逐块计算。每个块的计算结果写到一个临时纹理，最后拼起来。但这样会增加绘制调用次数和纹理切换开销。

我的经验是：对于全连接层，权重矩阵通常不会超过4096×4096（那已经是1600万参数了），所以大多数设备都能直接放下。但如果做卷积层，特征图可能很大，就需要分块。实际项目中，我建议先检测MAX_TEXTURE_SIZE，如果矩阵维度超过限制，就自动降级到CPU计算，或者用分块策略。

还有一个隐藏限制：MAX_RENDERBUFFER_SIZE和MAX_VIEWPORT_DIMS。这些通常和纹理尺寸限制一致，但有些设备上帧缓冲的尺寸限制更严格。创建帧缓冲后，一定要检查checkFramebufferStatus，确保返回FRAMEBUFFER_COMPLETE。

5.2 浮点纹理的读写精度陷阱

前面提到要用OES_texture_float扩展。但即使扩展存在，不同设备对浮点纹理的支持程度也不一样。有些设备只能渲染到浮点纹理但不能读取，有些设备读取时会有精度损失。

一个实用的检测方法是：创建一个浮点纹理，写入一个已知值（比如0.123456789），然后读回来，看精度是否满足要求。如果误差超过1e-6，就说明这个设备的浮点纹理不可靠，需要降级。

另外，readPixels读回浮点数据时，返回的是Float32Array。但有些设备会返回Uint8Array，即使你请求的是浮点格式。所以读回后要检查数据类型，必要时做转换。

还有一个坑：WebGL的texImage2D在传入Float32Array时，如果数据长度和width×height×4不匹配，会静默失败或者产生未定义行为。一定要确保数据长度正确。我习惯在创建纹理前先算好：width * height * 4，然后检查数组长度。

5.3 训练不收敛的排查链路

GPU训练最让人头疼的问题是：训练不收敛，但你看不到中间过程。CPU训练时你可以打印每一层的梯度、权重，但GPU上数据都在纹理里，读回来很麻烦。

我总结了一套排查链路：

第一步，检查前向传播。用一个已知的输入，手动算一遍CPU版本的前向结果，然后和GPU版本对比。如果前向就不对，那反向肯定不对。对比时要注意精度，GPU的浮点运算和CPU可能有微小差异，但应该在1e-5以内。

第二步，检查梯度。用数值梯度法验证：对于某个权重w，计算Loss(w+ε)和Loss(w-ε)，然后(Loss(w+ε)-Loss(w-ε))/(2ε)就是数值梯度。和GPU算出的梯度对比，如果差异大，说明反向传播有问题。

第三步，检查参数更新。如果梯度对了但Loss不下降，可能是学习率太大或太小。GPU训练时，梯度值可能因为精度问题被截断，导致实际学习率和设定值不符。可以先把学习率调小10倍试试。

第四步，检查数据。有时候问题不在GPU，而在输入数据。比如标签编码错了，或者输入没有归一化。GPU训练对输入尺度很敏感，因为浮点数的动态范围有限。

5.4 性能调优：从每秒几轮到每秒几百轮

最初的实现可能每秒只能跑几轮迭代，慢得让人怀疑人生。优化方向有几个：

减少绘制调用。每次绘制都有固定开销，包括状态切换、着色器绑定、纹理绑定。如果能把多个操作合并到一个着色器里，就能减少调用次数。比如把矩阵乘法和偏置加法合并，把激活函数和损失函数合并。

使用顶点缓冲对象（VBO）。画矩形时，不要每次都用gl.vertexAttribPointer重新指定顶点数据。创建一个VBO，把矩形的四个顶点存进去，每次绘制时直接绑定。

避免不必要的纹理切换。纹理切换是昂贵的操作。如果多个着色器使用相同的输入纹理，尽量把它们安排在连续的绘制调用里。

使用WebGL 2.0。WebGL 2.0支持更多纹理格式、多重渲染目标（MRT）、以及更灵活的循环控制。如果目标用户设备支持，优先用WebGL 2.0。但要注意兼容性，做好降级方案。

批处理。如果训练数据是小样本，可以把多个样本打包成一个批次，一次前向传播算完。这样GPU的利用率更高，因为每个着色器调用处理的数据量更大。

实测下来，一个两层全连接网络（784-128-10）在MNIST上训练，优化前每秒约5轮，优化后能到每秒200轮以上。这个速度已经足够做交互式教学了——学生写一个数字，模型在几百毫秒内就能完成一轮微调。

6. 浏览器端训练的边界与适用场景

6.1 什么规模的模型适合放在浏览器里训

不是所有模型都适合浏览器端训练。我的经验是：参数量在10万到100万之间的模型，WebGL训练是可行的。超过这个规模，纹理尺寸和显存会成为瓶颈，而且训练时间会变得不可接受。

具体来说，全连接层每层几百到几千维，层数不超过5层，这样的网络在浏览器里训练很流畅。卷积层也可以做，但需要把卷积展开成矩阵乘法（im2col），这会增加内存占用。如果卷积核不大（比如3×3），通道数不多（比如32或64），也是可以跑的。

不适合的场景包括：大型语言模型、高分辨率图像生成模型、需要大量迭代才能收敛的模型。这些还是交给专业训练环境。

6.2 隐私保护与离线可用性的真实价值

浏览器端训练最大的卖点不是性能，而是数据不出本地。用户的输入数据、标注数据、甚至模型本身，都可以完全留在浏览器里。这对于隐私敏感的应用场景很有价值，比如医疗健康类的个人数据训练、教育类的学生行为数据建模。

另一个价值是离线可用。一旦页面加载完成，后续的训练和推理都不需要网络连接。这对于网络不稳定的环境，或者需要完全离线部署的场景，是很实用的特性。

还有一个容易被忽略的价值：即时反馈。用户补充几个样本，模型立刻更新，识别效果当场变好。这种交互体验是云端训练做不到的，因为云端训练有网络延迟和排队等待。

6.3 和TensorFlow.js的GPU后端有什么不同

TensorFlow.js也支持WebGL后端，而且封装得很好，几行代码就能定义模型并训练。那为什么还要自己写WebGL着色器？

区别在于控制粒度。TensorFlow.js的WebGL后端是一个通用框架，它会把各种操作映射到着色器，但中间有很多抽象层。对于标准操作（比如全连接、卷积、常见的激活函数），它的性能已经很好。但如果你需要自定义操作，或者想针对特定硬件做极致优化，自己写着色器更灵活。

另外，TensorFlow.js的WebGL后端在某些设备上会有兼容性问题，而且它的内存管理是自动的，有时候会导致纹理泄漏或者频繁的垃圾回收。自己管理纹理和帧缓冲，虽然代码量大，但行为完全可控。

我的建议是：如果标准模型能满足需求，直接用TensorFlow.js，省时省力。如果需要自定义训练逻辑，或者对性能有极致要求，再考虑手写WebGL。

7. 从原型到产品：工程化落地的几个关键决策

7.1 如何设计降级方案保证兼容性

不是所有浏览器都支持WebGL，也不是所有支持WebGL的设备都支持浮点纹理。产品化时必须设计降级方案。

我的做法是三级降级：

第一级，WebGL 2.0 + 浮点纹理。这是最优路径，性能最好。

第二级，WebGL 1.0 + 浮点纹理扩展。性能稍差，但兼容性更广。

第三级，纯CPU JavaScript。用TypedArray做矩阵运算，虽然慢，但保证能用。对于小模型（参数量小于1万），CPU版本也能在可接受的时间内完成训练。

降级检测在页面加载时做一次，把结果缓存起来。用户不需要知道底层用的是哪条路径，只需要看到训练能跑起来。

7.2 训练过程的进度反馈与中断处理

GPU训练是异步的，你发出绘制调用后，GPU在后台跑，JavaScript继续执行。如果训练循环写成一个大的for循环，页面会卡死，用户看不到任何进度。

解决方案是用requestAnimationFrame或者setTimeout把训练循环拆成小批次。每一帧跑几轮迭代，然后更新进度条，再请求下一帧。这样页面保持响应，用户能看到训练进度。

中断处理也很重要。用户可能中途关闭页面或者切换标签页。要在beforeunload事件里清理WebGL资源，避免内存泄漏。另外，如果用户切换标签页，requestAnimationFrame会暂停，训练也会暂停。这是符合预期的行为，但要在UI上给出提示。

7.3 模型持久化：把训练好的权重存到哪里

训练完成后，权重需要保存。GPU纹理里的数据不能直接序列化，必须先读回CPU，转成Float32Array，然后存到IndexedDB或者localStorage。

IndexedDB适合存大文件（几MB到几十MB），localStorage只适合存小数据（几KB）。对于神经网络权重，通常用IndexedDB。存储时可以把Float32Array转成Blob，或者直接存ArrayBuffer。

读取时反向操作：从IndexedDB读出ArrayBuffer，转成Float32Array，再上传到GPU纹理。整个过程要注意异步处理，因为IndexedDB的读写都是异步的。

还有一个细节：权重的版本管理。如果模型结构变了，旧权重就不能用了。我习惯在存储时带上一个版本号或者结构哈希，读取时校验，不匹配就重新初始化。

8. 我踩过的三个印象最深的坑

第一个坑是纹理坐标的0.5偏移。刚开始写着色器时，我直接用了gl_FragCoord.xy / textureSize作为纹理坐标，结果采样到的总是相邻像素的值，导致矩阵乘法结果完全错误。排查了很久才发现，gl_FragCoord给出的是像素中心坐标，而纹理坐标需要的是归一化的像素中心，所以要加0.5再除。这个细节在大多数WebGL教程里都不会强调，但做通用计算时是致命的。

第二个坑是浮点纹理的线性插值。默认情况下，纹理采样使用线性插值，会混合相邻像素的值。对于图像渲染这是好事，但对于矩阵运算这是灾难。必须把TEXTURE_MIN_FILTER和TEXTURE_MAG_FILTER都设为NEAREST。我一开始忘了设，结果梯度计算出来总是有微小的噪声，训练完全不收敛。

第三个坑是帧缓冲的完整性检查。创建帧缓冲后，我没有检查checkFramebufferStatus，直接就开始渲染。在某些设备上，帧缓冲创建失败但不会报错，渲染结果全是0。后来养成了习惯，每次创建帧缓冲后都检查状态，不完整就抛异常。这个检查在开发阶段能省下大量调试时间。

9. 后续可以继续深挖的方向

如果你已经把基础的WebGL训练跑通了，还有几个方向可以继续优化。

一是用WebGL 2.0的变换反馈（Transform Feedback）。WebGL 2.0允许把顶点着色器的输出直接写回缓冲区，不需要经过片段着色器。这对于逐元素操作（比如激活函数、参数更新）可能更高效，因为避免了纹理的创建和绑定。

二是混合精度训练。用16位浮点数做前向和反向，用32位浮点数做参数更新。这样可以减少显存占用和带宽消耗，速度可能提升一倍。但要注意数值稳定性，可能需要损失缩放（loss scaling）来防止梯度下溢。

三是多GPU协同。如果用户设备有多个GPU（比如集成显卡加独立显卡），理论上可以用多个WebGL上下文并行计算。但浏览器对多GPU的支持还很有限，实际可行性不高。

四是和WebAssembly结合。把一些不适合GPU的操作（比如数据预处理、复杂的优化器逻辑）放到WASM里做，GPU专注做矩阵运算。两者通过SharedArrayBuffer通信，实现真正的并行。

这条路我走了大半年，从最初的“这能行吗”到现在的“基本能用”，中间踩了无数坑，但也积累了不少经验。浏览器端训练不是要取代专业训练环境，而是在特定场景下提供一种轻量、隐私、即时的选择。如果你的项目恰好需要这些特性，WebGL方案值得一试。