1. 浏览器端机器学习训练到底在做什么
1.1 从“打开网页就能训练模型”说起
浏览器端机器学习训练，说白了就是把原本跑在服务器或者本地Python环境里的神经网络训练过程，整个搬到网页里完成。你打开一个页面，不用装CUDA、不用配环境、不用连远程服务器，浏览器自己就能拿着你的数据跑前向传播、反向传播、梯度更新这一整套流程。这件事在几年前听起来像是天方夜谭，因为JavaScript当年连个像样的矩阵乘法都跑不利索，更别提训练一个几层深的卷积网络了。
但事情在WebGL 2.0普及之后发生了质变。WebGL本质上是一个JavaScript能调用的GPU接口，它最初是为3D图形渲染设计的，但GPU这东西有个特点：它天生就是干大规模并行计算的料。神经网络的训练过程，拆开来看就是海量的矩阵乘加运算，这跟图形渲染里顶点变换、像素着色的计算模式高度相似。于是有人就想，既然GPU能同时算几百万个像素的颜色，那为什么不能同时算几百万个神经元的激活值呢？
这个思路一旦打通，浏览器端训练就从“不可能”变成了“可行但需要技巧”。我最早接触这块是在一个图像分类的Demo项目里，当时的需求很简单：用户上传几张图片，浏览器里直接训练一个小型分类器，不传数据到服务器。听起来简单，但真正动手才发现，从数据预处理到梯度计算，每一步都有坑。
1.2 为什么要在浏览器里训练而不是服务器
你可能会问，服务器上GPU集群训练得好好的，为什么非要折腾浏览器？这个问题我一开始也问过自己。后来在实际项目中摸爬滚打久了，才慢慢理解其中的价值。
首先是数据隐私。很多场景下用户不愿意把原始数据上传到服务器，比如医疗影像、个人照片、键盘输入习惯等。浏览器端训练意味着数据从头到尾不离开用户的设备，训练完模型直接本地推理，数据不出域。这在合规层面省掉了大量麻烦。
其次是零安装成本。你想让一个非技术用户用上机器学习能力，让他装Python、配环境、下依赖，基本等于劝退。但让他打开一个网页，点个按钮，等几十秒看到结果，这个体验门槛几乎为零。我做过一个对比测试，同样的图像分类任务，服务器方案的用户完成率不到四成，浏览器方案能到八成以上，差距就在安装这一步。
第三是边缘计算的天然优势。浏览器就在用户手边，推理延迟极低，不需要网络往返。训练虽然比服务器慢，但对于小模型、小数据量的场景，比如个性化推荐、输入法预测、简单手势识别，浏览器端训练完全够用，而且响应更快。
当然，浏览器端训练不是没有代价。GPU内存有限、JavaScript没有原生指针、WebGL的调试工具远不如CUDA成熟，这些都是实打实的限制。但正是这些限制，逼着你去思考哪些计算是真正必要的，哪些精度是可以牺牲的，哪些层是可以砍掉的。这种约束下的工程优化，反而让我对神经网络的理解更深了一层。
1.3 适合哪些人深入这个方向
如果你是一个前端工程师，想往AI方向靠但不想彻底转后端，浏览器端机器学习是一个非常好的切入点。你已有的JavaScript功底、对浏览器API的熟悉、对性能优化的直觉，在这里都能直接复用。你不需要从头学Python生态，只需要理解神经网络的基本原理，剩下的就是用你擅长的方式去实现它。
如果你是一个机器学习工程师，想把自己的模型部署到更轻量的环境，这个方向也值得投入。你会发现很多在Python里理所当然的操作，在WebGL里需要重新设计。比如Python里一个np.dot就搞定的矩阵乘法，在WebGL里你要考虑纹理布局、着色器写法、数据精度、内存对齐，这些细节会反过来加深你对计算本质的理解。
如果你只是一个对技术好奇的开发者，想看看浏览器到底能跑多复杂的计算，那这个方向也能给你足够的探索空间。从最简单的全连接网络开始，一步步加上卷积、池化、批归一化，每加一层你都会遇到新的挑战，每解决一个挑战你都会对GPU计算有新的认识。
2. WebGL凭什么能跑神经网络
2.1 GPU的并行结构与神经网络的天然匹配
要理解WebGL为什么能跑神经网络，得先理解GPU和CPU的根本区别。CPU像是一个博士，什么都会，但一次只能专心做一两件事。GPU像是一万个中学生，每个人只会做简单的加减乘除，但一万个人同时做，总吞吐量就上去了。
神经网络的计算模式恰好是“简单操作的大量重复”。一个全连接层，输出每个神经元的值，就是输入向量和权重向量的点积加上偏置。如果有1024个输入和1024个输出，那就是一百多万次乘加运算。这些运算之间没有依赖关系，可以完全并行。GPU的流处理器就是为这种场景设计的，每个流处理器负责一小块计算，所有流处理器同时开工，效率极高。
WebGL暴露给JavaScript的，正是GPU的这种并行能力。你通过编写着色器程序，告诉GPU每个“像素”应该怎么计算。在图形渲染里，像素的颜色由光照、纹理、法线决定；在神经网络里，像素的值可以代表神经元的激活值、权重、梯度。这种映射一旦建立，GPU就变成了一个通用的并行计算引擎。
我刚开始做这块的时候，最大的思维转变就是：不要想着“计算一个矩阵”，而要想着“计算一张图片”。矩阵的每个元素对应图片的一个像素，矩阵乘法对应的是像素之间的加权求和。这个思维转换过来之后，很多WebGL的限制就不再是障碍，而是设计约束。
2.2 纹理即内存：数据在GPU上的组织方式
WebGL里没有通用的内存分配接口，你不能像CUDA那样cudaMalloc一块显存然后随便读写。WebGL能操作的数据载体只有两种：纹理和缓冲区。缓冲区主要用于顶点数据，纹理才是真正用来存矩阵的。
纹理本质上是一个二维数组，每个元素有RGBA四个通道，每个通道可以是8位、16位或32位浮点数。这就意味着，一个纹理像素最多可以存四个浮点数。如果你要存一个1024x1024的权重矩阵，你可以把它铺成1024x1024的纹理，每个像素存一个权重值，另外三个通道空着或者存别的参数。
但这里有个关键问题：WebGL 1.0的纹理默认是8位归一化的，也就是说每个通道只能存0到1之间的小数，精度极低。训练神经网络需要的是32位浮点数，8位根本不够用。所以真正能用于训练的，必须是WebGL 2.0，它支持32位浮点纹理，精度问题才得到解决。
即使有了32位浮点纹理，数据布局仍然需要精心设计。比如一个卷积层的权重是四维张量[输出通道, 输入通道, 核高, 核宽]，你不能直接把它塞进一个二维纹理。常见的做法是把四维张量展平成二维矩阵，或者用多个纹理分别存储不同维度的数据。我试过几种布局方案，最后发现把输出通道和输入通道展平，核高核宽保持二维的方式在着色器里索引最方便，计算效率也最高。
还有一个坑是纹理的尺寸限制。不同设备支持的最大纹理尺寸不一样，常见的是4096x4096或8192x8192。如果你的矩阵太大，一个纹理装不下，就得拆成多个纹理，计算时还要处理跨纹理的边界。这个在实现全连接层时特别容易遇到，因为全连接层的权重矩阵往往很大。
2.3 着色器：在GPU上写“核函数”的正确姿势
着色器是WebGL的计算入口。你可以把它理解成CUDA里的核函数，只不过语法是GLSL，运行在GPU的每个像素上。一个典型的计算着色器长这样：它接收几个输入纹理，对当前像素坐标对应的数据做运算，然后输出到目标纹理。
写着色器有几个必须遵守的规则。第一，不能有循环依赖。每个像素的计算必须独立，不能读取其他像素刚刚写入的结果。这意味着你不能在着色器里做迭代更新，只能做一次性的映射。对于神经网络训练，这意味着前向传播的每一层、反向传播的每一步，都需要单独的着色器调用。
第二，分支要尽量避免。GPU的流处理器是成组执行的，如果一组里的像素走了不同的分支，两组分支都会被执行，效率直接减半。所以在着色器里写if-else要特别小心，能用量化计算代替分支就尽量代替。比如ReLU激活函数，用max(0.0, x)就比if (x > 0.0) return x; else return 0.0;高效得多。
第三，精度声明不能省。GLSL里浮点数的精度默认是mediump，也就是16位左右，对于训练来说完全不够。每个浮点变量都必须显式声明为highp，纹理采样也要用highp。我一开始没注意这个，训练出来的模型loss死活不下降，排查了半天才发现是精度截断导致梯度消失。
第四，纹理采样有开销。每次texture2D调用都是一次内存访问，虽然GPU有缓存，但频繁采样仍然会拖慢速度。优化的时候要尽量把多次采样合并成一次，比如把权重和偏置打包到同一个纹理的相邻像素里，一次采样就能拿到两个值。
2.4 从图形管线到计算管线的思维转换
用WebGL做计算，最别扭的地方在于你始终在跟图形管线的概念打交道。你得创建一个“画布”，虽然你根本不画任何东西；你得设置“视口”，虽然你只是在定义计算范围；你得绑定“帧缓冲区”，虽然你只是在切换输出目标。
我刚开始的时候特别不适应，总觉得这些概念是多余的。但后来想通了：WebGL就是一个伪装成图形API的计算API。它之所以设计成这样，是因为它要兼容现有的图形硬件和驱动。你只要把“画布”理解成“计算网格”，“像素”理解成“计算单元”，“颜色”理解成“输出数据”，整个流程就顺了。
具体来说，一次计算调用的流程是这样的：创建一个帧缓冲区对象，绑定一个纹理作为颜色附件，这个纹理就是输出目标。然后设置视口大小为输出纹理的尺寸，编译并链接着色器程序，绑定输入纹理到纹理单元，最后调用drawArrays绘制一个覆盖整个视口的矩形。GPU会对视口内的每个像素执行一次片段着色器，把结果写入输出纹理。
这个流程里，drawArrays的调用次数就是你的计算步骤数。前向传播一层调用一次，反向传播一层调用一次，参数更新再调用一次。一个简单的三层网络，一次训练迭代可能要调用十几次。每次调用都有固定的开销，所以减少调用次数是优化的关键方向之一。我后来把一些可以合并的操作合并到同一个着色器里，比如把矩阵乘法和偏置加法合并，把激活函数和下一层的输入准备合并，调用次数直接减半，训练速度提升了将近一倍。
3. 神经网络在浏览器里的完整训练流程
3.1 数据准备：从JavaScript数组到GPU纹理
训练的第一步是把数据搬到GPU上。你的原始数据可能是JavaScript里的一个二维数组，每个样本是一个向量。你需要把它转换成一个纹理，每个像素存一个或几个数值。
这里有个关键决策：数据精度。JavaScript的Number是64位双精度，但WebGL 2.0的浮点纹理通常是32位单精度。从64位转到32位会有精度损失，但对于神经网络训练来说，32位精度完全够用，甚至16位在某些场景下也能工作。我一般直接用Float32Array来存数据，然后通过texImage2D上传到纹理。
数据布局方面，我习惯把样本按行排列，特征按列排列。比如有1000个样本，每个样本784个特征（28x28的图像），我就创建一个1000x784的纹理，每个像素存一个特征值。如果特征数不是4的倍数，我会补齐到4的倍数，因为纹理的宽度最好是4的倍数，这样内存对齐更好，采样效率更高。
标签数据单独存一个纹理，每个样本的标签占一个像素。如果是分类任务，标签可以存成one-hot向量的形式，也可以存成类别索引，在着色器里再转成one-hot。我倾向于存类别索引，因为省内存，而且转换的计算量很小。
还有一个容易被忽略的点：数据归一化。原始像素值通常是0到255的整数，直接拿去训练会导致梯度爆炸。我一般会在上传到GPU之前，在JavaScript里做一次归一化，把像素值缩放到0到1之间，或者减去均值除以标准差。这个操作在CPU上做一次就行，不需要放到GPU上每次迭代都做。
3.2 前向传播：矩阵乘法在着色器里的实现
前向传播的核心是矩阵乘法。假设输入是X（形状[batch, in_features]），权重是W（形状[in_features, out_features]），输出是Y = X * W + b。在WebGL里，这个计算可以这样实现：
输出纹理的尺寸是[batch, out_features]，每个像素(i, j)对应输出矩阵的第i行第j列。着色器对每个像素执行：遍历in_features维度，累加X[i, k] * W[k, j]，最后加上偏置b[j]。
这个遍历在着色器里是一个循环。GLSL支持for循环，但循环次数必须是编译时常量，或者至少是uniform变量。对于in_features这种可能变化的维度，我一般把它作为uniform传入，然后在着色器里写for (int k = 0; k < in_features; k++)。实测下来，只要循环次数不超过几百，性能是可以接受的。
但这里有个大坑：纹理采样次数。每次循环里要采样两次纹理（一次X，一次W），如果in_features是784，那就是1568次采样。虽然GPU有纹理缓存，但这么频繁的采样仍然会成为瓶颈。我的优化方法是把X和W的采样合并，比如把W的四个连续值打包到一个像素的RGBA四个通道里，一次采样就能拿到四个权重值，循环次数直接除以4。
另一个优化是利用共享内存。WebGL没有显式的共享内存，但你可以通过把数据预加载到着色器的局部变量里来减少重复采样。比如在循环开始前，把当前像素对应的X行数据一次性读进来，存到一个局部数组里，循环里只采样W。这个技巧在in_features较大时效果明显，我试过784维输入，优化后速度提升了将近三倍。
3.3 反向传播：梯度计算的着色器设计
反向传播比前向传播复杂得多，因为要计算每一层的梯度，并且要沿着网络反向传递。对于一个全连接层，假设损失函数对输出的梯度是dY，那么权重的梯度是dW = X^T * dY，输入的梯度是dX = dY * W^T，偏置的梯度是db = sum(dY, axis=0)。
在WebGL里，这三个计算需要三个不同的着色器。dW的计算是矩阵乘法，输出纹理尺寸是[in_features, out_features]，每个像素(k, j)累加X[i, k] * dY[i, j]对i的求和。dX的计算类似，输出纹理尺寸是[batch, in_features]，每个像素(i, k)累加dY[i, j] * W[k, j]对j的求和。db的计算是沿着batch维度求和，输出是一个向量，可以存成一个宽度为out_features、高度为1的纹理。
这里的关键难点是梯度累加。在CPU上，你可以直接写dW += ...，但在GPU上，你不能在着色器里做累加，因为每个像素是独立计算的。解决方案是：要么在着色器里一次性算完所有累加（把循环放在着色器内部），要么用多个渲染通道做归约。我一般选择前者，因为全连接层的in_features和batch通常不会太大，一次性算完是可行的。
但如果是卷积层，情况就复杂了。卷积的梯度计算涉及到im2col和col2im操作，在WebGL里实现起来非常繁琐。我试过用多个着色器分步实现，先做im2col把输入展开成矩阵，然后按全连接层的方式算梯度，最后用col2im把梯度还原成卷积核的形状。这个过程调用次数多，中间纹理也多，内存开销很大。后来我改用直接卷积的梯度算法，虽然计算量稍大，但省去了中间步骤，整体反而更快。
3.4 参数更新：优化器在GPU上的落地
参数更新这一步相对简单，就是把梯度应用到权重上。以SGD为例，W = W - learning_rate * dW。在WebGL里，你可以写一个着色器，输入权重纹理和梯度纹理，输出更新后的权重纹理。每个像素执行一次减法和乘法，计算量很小。
但如果是Adam或者Momentum这种带状态的优化器，就需要额外的纹理来存储一阶矩和二阶矩。Adam的更新公式是：m = beta1 * m + (1 - beta1) * dW，v = beta2 * v + (1 - beta2) * dW^2，W = W - learning_rate * m / (sqrt(v) + epsilon)。这需要三个输入纹理（W、dW、m、v）和两个输出纹理（新的m、新的v、新的W）。我一般把m和v打包到一个纹理里，每个像素存两个值，减少纹理数量。
这里有个细节：学习率衰减。训练过程中学习率通常需要逐渐减小，这个衰减可以在JavaScript里计算好，作为uniform传给着色器。我试过在着色器里做衰减，但发现uniform更新更简单，而且不会增加着色器的复杂度。
还有一个坑是梯度裁剪。浏览器端训练很容易遇到梯度爆炸，因为数值精度有限，累加误差会被放大。我一般会在参数更新之前，在着色器里对梯度做一次裁剪，把绝对值超过阈值的梯度截断。这个操作很简单，但效果非常明显，能显著提升训练的稳定性。
4. 性能优化与常见问题排查
4.1 纹理布局与内存对齐的实战经验
纹理布局对性能的影响远超我的预期。最开始我用的是最直观的布局：一个矩阵一个纹理，每个像素存一个值。后来发现，这种布局下纹理采样的效率很低，因为每次采样只能拿到一个值，而GPU的纹理缓存是按块读取的，一次读取可能拿到相邻的多个值，但如果你只用其中一个，剩下的就浪费了。
优化后的布局是把四个连续的值打包到一个像素的RGBA通道里。比如权重矩阵的每一行，前四个值存到第一个像素，接下来四个值存到第二个像素，以此类推。这样一次采样就能拿到四个值，采样次数直接除以4。对于矩阵乘法这种需要频繁采样的操作，性能提升非常明显。
但打包也有代价：索引计算变复杂了。原来你只需要根据行列号直接采样，现在你需要先算出打包后的像素坐标，再从RGBA通道里取出对应的值。这个计算在着色器里是额外的开销，但相比采样次数的减少，这个开销是值得的。
还有一个细节是纹理的宽度最好是2的幂次。虽然WebGL 2.0支持非2的幂次纹理，但某些GPU对2的幂次纹理有更好的优化。我一般会把纹理宽度补齐到最近的2的幂次，比如784会补齐到1024。补齐的部分填0，计算时虽然会多算一些，但整体效率更高。
4.2 着色器编译与链接的避坑指南
着色器编译是WebGL开发中最容易出问题的地方。首先，GLSL的版本声明必须放在第一行，前面不能有任何注释或空行。我一开始习惯在文件开头写版权注释，结果着色器死活编译不过，排查了半天才发现是版本声明的位置问题。
其次，精度声明必须显式指定。在片段着色器里，precision highp float;必须写在所有变量声明之前。如果忘了写，默认是mediump，精度不够会导致训练结果完全错误。这个坑我踩过不止一次，后来养成了习惯，每个片段着色器开头都先写精度声明。
第三，uniform变量如果没被使用，会被优化掉。你调用gl.getUniformLocation会返回null，然后设置uniform值时就会报错。解决方案是要么确保每个uniform都被使用，要么在获取location时做null检查。我一般会在设置uniform之前先判断location是否为null，避免不必要的报错。
第四，着色器链接错误的信息很模糊。有时候链接失败，但错误信息只说“链接失败”，不告诉你具体原因。这时候要检查：输入输出变量是否匹配、纹理单元是否冲突、uniform数量是否超过限制。我遇到过一次链接失败，最后发现是两个着色器用了同一个纹理单元编号，导致冲突。
4.3 训练不收敛的排查思路
浏览器端训练不收敛的原因很多，我整理了一个排查顺序，基本上能覆盖大部分情况。
第一步，检查数据精度。如果纹理是8位的，那训练肯定不收敛。确认使用的是gl.FLOAT类型的纹理，并且OES_texture_float扩展已经启用。WebGL 2.0原生支持浮点纹理，但WebGL 1.0需要扩展。
第二步，检查梯度计算。可以在JavaScript里用一个小矩阵手动算一遍梯度，然后跟GPU算出来的梯度对比。如果差异很大，说明着色器里的梯度公式写错了。我遇到过一次，反向传播的矩阵转置搞反了，导致梯度方向完全错误，loss越训越大。
第三步，检查学习率。浏览器端训练因为精度限制，学习率通常要比CPU训练小一个数量级。我一般从1e-4开始试，如果loss下降太慢就调大，如果震荡就调小。
第四步，检查初始化。权重初始化不能用全零，否则所有神经元的梯度都一样，网络学不到东西。我一般用Xavier初始化或者He初始化，在JavaScript里生成随机数，然后上传到GPU。
第五步，检查数值稳定性。如果loss突然变成NaN，说明有数值溢出。常见原因是除零、log(0)、exp(大数)。可以在着色器里加一些保护，比如max(x, 1e-7)防止除零，min(x, 20.0)防止exp溢出。
4.4 浏览器兼容性与性能监控
不同浏览器对WebGL 2.0的支持程度不一样，虽然现在主流浏览器都支持，但细节上仍有差异。我遇到过在某个浏览器上浮点纹理渲染正常，但在另一个浏览器上渲染出来全是黑屏，最后发现是纹理过滤参数的问题。解决方案是显式设置纹理过滤为NEAREST，避免使用默认的LINEAR过滤，因为浮点纹理的线性插值在不同GPU上的行为不一致。
性能监控方面，WebGL没有像CUDA那样详细的profiler，但你可以用performance.now()在JavaScript里打点，测量每次drawArrays调用的耗时。我一般会在训练循环里记录每个步骤的时间，找出最耗时的环节。通常来说，矩阵乘法和卷积是最耗时的，激活函数和参数更新相对较快。
还有一个监控指标是GPU内存使用。WebGL没有直接的内存查询接口，但你可以通过创建纹理的数量和尺寸来估算。如果创建了太多纹理，可能会触发浏览器的内存限制，导致上下文丢失。我一般会复用纹理，把不再需要的纹理绑定到新的输出上，而不是每次都创建新纹理。
5. 从Demo到可用系统的工程化思考
5.1 模型规模与浏览器能力的平衡
浏览器端训练最大的限制是GPU内存。一个消费级GPU通常有2到8GB显存，但浏览器能用的可能只有几百MB。这意味着你不能训练太大的模型。我做过测试，一个参数量在100万以内的模型，浏览器端训练基本没问题；超过1000万，就很容易触发内存限制。
所以模型设计上要做取舍。全连接层可以宽，但不能太深，因为每一层的激活值都要存纹理。卷积层可以深，但通道数要控制，因为卷积核的参数量是通道数的平方。我一般会把模型控制在5层以内，参数量控制在50万左右，这样训练速度和内存占用都比较平衡。
另一个策略是梯度累积。如果batch size太大导致内存不够，可以把一个大batch拆成几个小batch，分别计算梯度，然后累加。这样内存占用小了，但训练效果跟大batch差不多。我试过把batch size从256降到64，用4次累积，训练效果几乎一样，但内存占用只有原来的四分之一。
5.2 训练过程的用户交互设计
浏览器端训练跟服务器端训练最大的区别是用户能看到训练过程。这既是优势也是挑战。优势是用户可以实时看到loss下降、准确率上升，体验很好。挑战是如果训练太慢，用户会失去耐心。
我的做法是分阶段展示。第一阶段用少量数据快速训练一个粗略模型，让用户看到初步效果，通常几秒钟就能完成。第二阶段用全量数据精细训练，这时候展示进度条和实时指标，让用户知道还要等多久。第三阶段是推理阶段，用户可以用训练好的模型做预测。
还有一个细节是训练中断处理。用户可能随时关闭页面或者刷新，如果训练到一半中断了，之前的计算就白费了。我一般会定期把模型参数从GPU读回JavaScript，存到IndexedDB里。这样即使页面刷新，也能从上次的检查点继续训练。
5.3 模型导出与跨平台部署
训练完之后，模型需要能导出和使用。最简单的方式是把权重从GPU读回JavaScript，然后序列化成JSON或者二进制格式。读回的过程是：创建一个帧缓冲区，绑定权重纹理，调用readPixels把数据读到Float32Array里。
但readPixels是同步操作，会阻塞渲染管线，速度很慢。如果模型很大，读回可能要几秒钟。优化方法是分块读回，每次读一小块，中间让出主线程，避免页面卡死。我一般会把权重分成多个小块，每块读完后用setTimeout让出一下，这样页面不会冻结。
导出的模型可以用于浏览器端推理，也可以传到服务器做进一步处理。如果要在浏览器端推理，可以直接用同一套WebGL着色器，只是不需要反向传播和参数更新，速度会快很多。我试过同一个模型，训练时每次迭代要50毫秒，推理时只要5毫秒，差距主要在于反向传播的计算量。
5.4 实际项目中的取舍与经验总结
做了几个浏览器端机器学习的项目之后，我最大的体会是：不要试图在浏览器里复现服务器端的所有能力。浏览器有浏览器的优势，也有浏览器的限制。优势是低延迟、隐私保护、零安装；限制是内存小、精度低、调试难。
所以项目设计要从场景出发。如果是小数据量的个性化任务，比如用户行为预测、简单图像分类，浏览器端训练非常合适。如果是大数据量的通用任务，比如训练一个通用的语言模型，那还是老老实实上服务器。
还有一个经验是渐进增强。先做一个能跑通的最小版本，哪怕只支持全连接层、只支持SGD、只支持小批量数据。跑通之后再逐步加功能，加卷积、加Adam、加数据增强。每加一个功能都要做性能测试，确保没有引入瓶颈。我见过太多项目一开始就想做全能框架，结果做到一半发现性能撑不住，推倒重来。
最后，调试工具要提前准备。WebGL的调试不像Python那么方便，没有print大法，没有断点调试。我一般会写一些辅助函数，把GPU上的纹理读回JavaScript，然后在控制台里打印出来对比。虽然麻烦，但这是排查问题的唯一途径。提前把这些工具写好，后面能省很多时间。
这个方向还在快速演进，WebGPU的出现可能会带来新一轮的性能提升。但WebGL积累的这些经验，对理解GPU计算、理解神经网络底层原理，仍然非常有价值。我个人的建议是，如果你想深入这个方向，先从实现一个最简单的全连接网络开始，把前向传播、反向传播、参数更新这三步跑通，然后再逐步扩展。每一步都会遇到问题，但每解决一个问题，你对整个系统的理解就会深一层。
