企业官网建设流程全解析

训练图像分类模型的人，多半都经历过这种场面：显卡利用率曲线在 30% 上下反复抖动，风扇转得挺热闹，训练一个 epoch 却要四十多分钟；你把num_workers从 4 调到 16，把pin_memory打开，把 batch size 往上顶，情况好转一点，但没根治。挂上 profiler 看一眼就明白了，时间大头既不在前向也不在反向，而是卡在数据加载进程里，CPU 时间有一半以上消耗在 JPEG 解码上。这个瓶颈我碰上过好几次，后来换了个思路：JPEG 文件里本来就存着 8×8 块的 DCT 系数，解码的目的无非是把这些系数还原成像素，而 CNN 的第一层又要从像素里重新学出边缘、纹理、方向性响应。既然两头都在做类似的事，中间那一段还原为什么不能省掉？

这就是“用 DCT 训练 CNN”的出发点——跳过 IDCT、跳过色度上采样、跳过 YCbCr 到 RGB 的转换，直接把量化后的 DCT 系数组织成张量喂进网络。本文围绕这个思路，把 JPEG 压缩管线的结构、DCT 张量该怎么排布、模型第一层要改哪里、增强操作在频域里哪些还站得住脚，以及精度和吞吐的真实权衡，一条条拆开讲。适合已经能跑通常规训练脚本、想进一步压榨数据管线吞吐的读者，也适合对频域特征感兴趣、想搞清楚“为什么这么改能work”的人。

1. 训练卡在数据加载上，问题往往不在模型

1.1 一次典型的 GPU 空转现场

现象很有辨识度：nvidia-smi里显存占用正常，GPU-Util 却在 20% 到 60% 之间锯齿状跳动，而不是稳定贴着 90% 以上跑。同时top里能看到若干个子进程 CPU 占用接近 100%，这些就是 DataLoader 的 worker。把 worker 数量从 4 提到 8，吞吐涨了一截；再提到 16，几乎不涨了，说明瓶颈已经转移到单核解码速度或者磁盘带宽上。

我第一次遇到这个问题时，第一反应是模型太小、算得太快，于是加深网络，结果训练变慢但吞吐没改善，白白浪费了一晚上。正确的定位顺序应该是：先用torch.profiler或者简单的计时打点，把“取一个 batch 数据”和“跑一次 forward+backward”分开计时。如果前者占比超过 40%，那就别再折腾模型结构了，问题在管线上。

一个粗略的经验值：在普通服务器 CPU 上，用 libjpeg 系解码器解一张 224×224 的彩色 JPEG，单核耗时大约 0.15 到 0.4 毫秒，具体取决于图像内容复杂度和是否开启了 SIMD 加速。看起来不多，但一个 batch 256 张就是 40 到 100 毫秒，而且要乘以 worker 的分摊。相比之下，一个 18 层残差网络在单张中端卡上跑 256 张的前向加反向，可能只要 30 到 60 毫秒。解码成本直接盖过了计算成本，这就是 GPU 空转的根源。

1.2 把解码成本摊开算一遍

不妨把一张 JPEG 从磁盘到变成网络输入张量的全过程拆成几段，逐段估算。第一段是读文件，一张 224×224 的图压缩后在 15KB 到 40KB 之间，走页缓存的话几乎不耗时，冷读也就几十微秒。第二段是熵解码，把 Huffman 码流还原成量化后的 DCT 系数，这一段是纯串行的位操作，很难并行，通常是解码器里最慢的部分之一。第三段是反量化加 IDCT，把 64 个系数还原成 64 个像素值。第四段是色度上采样和色彩空间转换，输出三通道的 RGB 缓冲区。第五段才是 Python 侧的数组拷贝、归一化、拼 batch。

其中第二段和第三段是大头。你可能觉得 IDCT 有快速算法，确实，libjpeg 用的 AAN 算法把 8×8 的二维 IDCT 优化到大约一百多次乘加，但它是按块逐个处理的，一张 224×224 的图有 784 个亮度块加上 196 个色度块，总数接近一千个块，累加起来就是实打实的 CPU 周期。

关键洞察在这里：第一段的输出——量化后的 DCT 系数——本身就是一份信息量相当完整的表示。JPEG 之所以要往下走第二、三、四段，是为了让人眼能直接看；而神经网络并不需要“给人看”的格式，它需要的是一份数值稳定、结构规整、能反映局部频率分布的输入。从信息论的角度讲，后续那几段做的全是可逆或者近可逆的变换，它们不增加信息量，只是换了个坐标系。

注意：说“不增加信息量”是指理想情况下。实际实现里，色度上采样和整数 IDCT 都会引入微小的舍入误差，所以从系数重建像素再变换回去，和原始系数并不完全相等。这一点在做精度对齐测试时会暴露出来。

2. JPEG 里本来就有 DCT 系数，没必要先还原成像素

2.1 编码管线的五步走

要理解 DCT 输入怎么组织，得先清楚编码器到底做了什么。第一步，把 RGB 转成 YCbCr，然后对 Cb、Cr 两个色度通道做下采样，常见的是水平垂直各减半，也就是 4:2:0 采样，这样一个 16×16 的宏块里包含 4 个亮度块和 2 个色度块。第二步，把每个通道切成互不重叠的 8×8 小块，每个像素值减去 128 做电平偏移，让数据以 0 为中心。第三步，对每个块做二维 DCT-II，得到一个 8×8 的系数矩阵，左上角是直流分量，往右下走频率越来越高。第四步，用一张量化表逐元素相除并四舍五入，这是整个流程里唯一有损的一步，也是压缩率的主要来源。第五步，按之字形顺序扫描、游程编码、Huffman 熵编码，写进文件。

解码就是反过来走一遍。我们要做的“截胡”，位置在第四步和第五步之间——拿到量化后的系数矩阵，只做反量化，不做 IDCT。

2.2 量化表决定了哪些系数值得信任

量化表是理解 DCT 输入特性的钥匙。标准表里，低频位置的量化步长通常是个位数（比如亮度表左上角是 16，往右是 11、10、16、24……），高频位置可能到 99 甚至更大。这意味着低频系数保留了较精细的精度，高频系数被量化得很粗糙，很多直接变成 0。

这带来两个直接影响。第一，直接把系数当特征时，不同位置的数值尺度差异极大，DC 系数可能到几百上千，而高频系数大量在 -2 到 2 之间徘徊，不做归一化直接喂网络，第一层的梯度会被 DC 系数主导，训练很难收敛。第二，量化噪声在高频段是系统性的，不是随机的，这种“确定性的信息损失”在某些任务上是灾难（比如需要精细纹理的细粒度识别），在另一些任务上反而起到了正则化作用。

我在一次实验中做过对比：把同一批图的 DCT 系数按两种方式归一化，一种全局除以 255，一种按位置除以对应的量化步长，后者的收敛速度快了将近一倍，最终精度也高一些。原因不复杂，按量化步长归一化相当于把每个系数换算成“以量化单位为量纲”的值，也就是反量化，这样各位置的数值分布被拉平了。

2.3 直接拿系数当输入，省掉的是哪几段计算

从工程角度看，走 DCT 输入这条路，省掉的是 IDCT、色度上采样、色彩空间转换、以及中间那块 RGB 缓冲区的分配和拷贝。省不掉的是文件读取、熵解码、反量化。所以理论上限就是这三段的耗时占比，实测下来通常在 50% 到 70% 之间。

还有一个隐性收益：内存带宽。一张 224×224 的 RGB 图在 float32 下是 602112 字节，而同样一张图的 DCT 系数，在 4:2:0 采样下只有 784×64 + 196×64 + 196×64 = 75264 个整数值，转成 float32 是 301056 字节，只有原来的一半。如果只保留亮度通道，更是只有原来的四分之一。数据在 CPU 内存和页缓存之间搬运的压力随之下降，这在多 worker 并发时体现得尤其明显。

不过也别高兴太早，这里有个容易被忽略的反向成本：如果骨干网第一层的输入通道数从 3 变成 64，那第一层的参数量和计算量都会暴涨。这个坑我在后面单独讲。

3. 输入张量怎么排：三种布局的取舍

3.1 块内系数展开成通道

最自然的排法是把每个 8×8 块的 64 个系数当成 64 个通道，空间维度上每个块对应一个“像素”。一张 H×W 的图，DCT 张量的形状就是(64, H/8, W/8)；如果是 4:2:0 彩色，再拼上色度通道（需要先把 Cb、Cr 的块数补到和 Y 一致，或者分别对待），通道数变成 192，空间维度是(H/8, W/8)。

这种布局的好处是保住了局部性：同一个空间位置上，64 个通道描述的是同一块区域的频率构成，卷积核在空间上滑动时，感受野是相邻的块，语义上是连贯的。坏处是空间分辨率直接掉了 8 倍，224×224 的图变成 28×28，这对分类任务勉强够用，对检测、分割这类需要精细定位的任务就不太友好了。

通道数怎么处理，我有两个实践建议。一是如果显存吃紧，先只用亮度通道，64 通道输入，色度信息对大多数分类任务贡献有限，砍掉之后精度通常只掉零点几个点，但显存和计算量省下三分之二。二是如果坚持用三通道，记得把 4:2:0 的色度块做 2× 上采样（在块级别复制，不是在像素级别插值），让它和亮度的块网格对齐。

3.2 只保留低频的裁剪方案

之字形扫描顺序本身就是按频率从低到高排的，所以取前 N 个系数就是取最低频的 N 个。因为量化之后绝大多数高频系数是 0，保留它们只是在喂噪声。

一张典型的质量因子 75 的图，之字形前 10 个系数承载了绝大部分能量，前 16 个基本能覆盖 95% 以上的非零系数。所以用 N=10 或 N=16，通道数从 64 降到 10 或 16，第一层的计算量直接降一个数量级，而精度损失往往在 0.3 个点以内。

我做过一组粗略的对照，在同一个分类任务上：

数字只能当趋势看，不同数据集、不同质量因子下差异很大。但拐点很明显：从 16 往下降，收益递减而精度掉得越来越快。

提示：取前 N 个系数时，一定要按标准之字形顺序取，而不是按矩阵的行优先顺序取。行优先取到的是“第一行加第二行前几个”，频率覆盖不均匀，效果会差一截。

3.3 用 1×1 卷积做可学习的通道压缩

如果不想手工定 N，可以保留全部 64 通道，但在网络最前面插一个 1×1 卷积把它压到 16 或 32 通道，让网络自己学该怎么组合这些频率分量。这个 1×1 卷积的参数量只有 64×16=1024 个，几乎可以忽略，但它把“选哪些频率”这个决策从人工变成了可学习。

这个做法还有一个额外好处：1×1 卷积本质上是在做频带组合，学出来的权重矩阵可以直接拿来看——哪一行权重大，说明网络认为哪个频率分量重要。我在一次实验中把它可视化出来，发现训练好的权重确实偏向低频的几行，但中间频段（比如第 9 到 20 个系数）的权重也不小，说明纯手工砍到前 10 个会丢掉一部分有用信息。

还有一种混合思路：低频用独立通道，高频做分组求和或者取绝对值后合并成少量通道。这个方案我没深入验证过，但从信号处理的角度看是合理的——高频的符号本身意义不大，能量更有意义。

4. 手写一遍：从 JPEG 文件到可训练的 batch

4.1 取系数的库选择和踩雷点

Python 生态里能直接读到 DCT 系数的路径不多，主流是调用 libjpeg 的jpeg_read_coefficients接口，常见的有几个第三方绑定库。选型时注意几个硬指标：是否支持渐进式 JPEG（progressive），是否支持算术编码，是否暴露了量化表，返回的系数是按什么顺序排的。

渐进式这个坑我踩过。早期版本的某些绑定只支持基线模式，遇到渐进式文件直接抛异常或者返回全零，而很多网络图片恰恰是渐进式的。上线前统计一下数据集里渐进式文件的占比，别等训练到一半才发现一半样本是垃圾。

关于返回格式，不同库差别很大。有的是把系数按块铺开成和原图同尺寸的二维数组（每个 8×8 块里的 64 个值按某种顺序放在对应的块区域内），有的是给一个(块数, 64)的矩阵，还有的块内按之字形排、有的按行优先排。拿到之后第一件事不是急着训练，而是打印形状、打印前几个值，和已知识别度高的区域对比验证。

一个可靠的验证方法是自检：取一张图，用同一个库读出系数，手动做反量化加 IDCT，看能不能重建出接近原图的像素。再用常规解码器解一遍，两个结果做差，平均绝对误差应该在 1 到 2 个灰度级以内，超出这个范围说明系数顺序或者量化表用错了。

import numpy as np # (row, col) -> zigzag 序号的标准映射表 ZIGZAG = np.array([ [ 0, 1, 5, 6, 14, 15, 27, 28], [ 2, 4, 7, 13, 16, 26, 29, 42], [ 3, 8, 12, 17, 25, 30, 41, 43], [ 9, 11, 18, 24, 31, 40, 44, 53], [10, 19, 23, 32, 39, 45, 52, 54], [20, 22, 33, 38, 46, 51, 55, 60], [21, 34, 37, 47, 50, 56, 59, 61], [35, 36, 48, 49, 57, 58, 62, 63], ]) # 把块内按行优先排的 64 维向量转成按 zigzag 排 def row_major_to_zigzag(block64): return block64[ZIGZAG.ravel()] # 反过来 def zigzag_to_row_major(zig64): out = np.empty(64, dtype=zig64.dtype) out[ZIGZAG.ravel()] = zig64 return out

这段代码看着不起眼，但它是整个流程的地基。系数顺序错了，后面所有调试都是白费。

4.2 反量化与归一化

拿到量化后的整型系数coef（形状(num_blocks, 64)，已转成之字形顺序）和量化表qtable（同样是 64 维，按之字形顺序或在取用时重排），反量化就是逐元素相乘：

coef_dq = coef * qtable # 还原到 DCT 域的真实幅值 coef_dq[:, 0] /= 8.0 # DC 分量按 DCT-II 归一化系数缩放 coef_dq /= 128.0 # 大致对齐到 [-1, 1] 量级

关于 DC 那一行：标准二维 DCT-II 的直流分量等于块内像素均值乘以 8（因为 8×8 变换的归一化因子是 1/8 在正变换里、1/8 在反变换里，而 JPEG 的实现约定把一部分因子放进了反量化）。具体数值取决于实现，不必纠结公式，直接拿一张纯色图测一下：均匀灰度 128 的块，反量化后 DC 应该是 0（因为做了电平偏移），均匀灰度 200 的块，DC 反量化后应该接近(200-128)*8=576。用这个性质标定一下就能确认缩放系数。

归一化这一步我还想强调一点：如果你打算用预训练权重，那 DCT 输入和原模型的 RGB 输入分布完全不同，权重迁移基本没戏，必须从头训或者至少重新训前几层。有人试过把 DCT 系数用固定的线性组合近似成 RGB 再做微调，理论上是可行的（DCT 到 RGB 是线性变换，可以写成卷积），但实践中收益不明显，反而把省下来的计算又加回去了。

4.3 Dataset 和 collate 的写法

数据集的骨架和普通图像分类几乎一样，区别在于__getitem__里不调Image.open()，而是调底层解码接口拿系数。

import torch from torch.utils.data import Dataset, DataLoader import numpy as np class DCTDataset(Dataset): def __init__(self, paths, labels, keep_coef=16, transform=None): self.paths = paths self.labels = labels self.keep = keep_coef self.transform = transform def __len__(self): return len(self.paths) def __getitem__(self, idx): path = self.paths[idx] # read_dct 返回 (num_blocks_h, num_blocks_w, 64) 的亮度系数、 # 以及按行优先排好的量化表 coef, qtable = read_dct(path, channel="y") coef = coef.astype(np.float32) * qtable.astype(np.float32) coef[..., 0] /= 8.0 coef /= 128.0 # 取低频的 keep 个系数，放到通道维 x = np.transpose(coef[..., :self.keep], (2, 0, 1)) # (C, H/8, W/8) x = torch.from_numpy(np.ascontiguousarray(x)) if self.transform is not None: x = self.transform(x) return x, self.labels[idx]

几个细节值得说。np.ascontiguousarray不能省，transpose之后内存不连续，直接from_numpy再送进 DataLoader 会在后面某个环节触发一次隐式拷贝，不如显式做掉。read_dct每张图都要打开一次文件句柄，在多 worker 场景下最好在每个 worker 内部复用或者干脆每次新建，不要跨进程共享句柄，后者在某些平台上会导致莫名其妙的读错位。

还有一点：如果keep很小（比如 10），张量本身很小，单个样本的拷贝开销占比就高了，这时候可以考虑在 worker 里就把整个 batch 拼好（用自定义collate_fn），减少 Python 层的调用次数。

4.4 第一层卷积的改造

这是最容易出问题的地方。原来的网络第一层是Conv2d(3, 64, kernel_size=7, stride=2, padding=3)，输入 224×224，输出 112×112。现在输入变成 28×28，如果 stride 还是 2，输出就只有 14×14，整个骨干网的降采样次数没变，最终特征图会小到没法看。

处理方式有三种，各有取舍：

第一种是把第一层的 stride 改成 1，输出 28×28，后续层的降采样次数相应减少一到两次。这样整体感受野和原设计接近，但需要重新规划层结构，工作量较大。

第二种是在第一层前面插一个反卷积或者Upsample把 28×28 放大回 112×112，然后照搬原网络。这样做丢失了“省计算”的意义，但保住了结构兼容性，适合做对照实验。

第三种是干脆接受小分辨率，用更浅或者更窄的骨干。分类任务上我试过把输入当 28×28 处理，配一个轻量的卷积主干，在中小规模数据集上精度并没有明显下降，反而因为参数少了、过拟合风险降低，泛化还稍微好一点。

第一层的参数量变化也值得算一下：3→64 的 7×7 卷积是 9408 个参数，64→64 的 3×3 卷积是 36864 个，涨了将近四倍。如果你保留了 192 通道输入，那就是 192×64×3×3=110592，涨了一个数量级。这部分参数在总参数量里占比不大，但它是梯度回传的必经之路，学习率调度要相应调整——我一般会把第一层的学习率设成主干的一半，避免训练初期震荡。

5. 增强操作的物理边界：DCT 域里哪些还成立

5.1 翻转：符号翻转的推导

水平翻转是最常用也最容易实现的一种增强，在 DCT 域里它有一个非常干净的等价形式。

一维 DCT-II 的定义是 $X_k = \sum_{n} x_n \cos\left(\frac{\pi}{N}(n+\tfrac{1}{2})k\right)$。把序列翻转，令 $m = N-1-n$，代入后余弦项变成 $\cos\left(\pi k - \frac{\pi}{N}(m+\tfrac{1}{2})k\right) = (-1)^k \cos\left(\frac{\pi}{N}(m+\tfrac{1}{2})k\right)$。也就是说，翻转后第 $k$ 个系数等于原来的第 $k$ 个系数乘以 $(-1)^k$。

推广到二维，水平翻转对应每个系数的列索引 $u$ 带来的符号 $(-1)^u$，垂直翻转对应 $(-1)^v$。实现起来就是给一个 8×8 的符号模板做逐元素相乘，同时把块的列顺序（或行顺序）整体反过来。

# 水平翻转用的符号模板：sign[v][u] = (-1)**u sign_h = np.array([[(-1) ** u for u in range(8)] for _ in range(8)], dtype=np.float32) def flip_horizontal(coef): # coef: (H/8, W/8, 64) 行优先排 blocks = coef.reshape(coef.shape[0], coef.shape[1], 8, 8) blocks = blocks[:, ::-1, :, :] * sign_h[None, None, :, :] return blocks.reshape(coef.shape[0], coef.shape[1], 64)

这个操作只涉及一次乘法和一次切片，比在像素域翻转再重新做 DCT 便宜得多。而且它是精确等价的，不引入任何额外误差。

5.2 裁剪：只能站在块边界上

随机裁剪就没这么幸运了。像素域里可以从任意位置切一个 224×224 的窗口出来，DCT 域里如果窗口起点不是 8 的倍数，切出来的就不是完整的块，需要做块内重采样，代价高而且会引入边界伪影。

实际可行的方案有两个。第一个是把裁剪限制在块对齐的位置上，也就是从(H-224)/8 + 1个合法起点里随机选。这样可选的裁剪位置少了，增强的多样性下降，但实现干净、无伪影。第二个是接受轻微的信息损失，对跨越边界的块做近似处理，比如只在块边界上做窗口滑动并允许少量重叠。

牺牲空间上界定了多大，可以用数字感受一下：一张 256×256 的图裁 224×224，像素域有 33×33=1089 个合法起点，块对齐之后只剩 5×5=25 个。多样性掉了两个数量级。所以如果你的任务强依赖随机裁剪（比如目标检测里的尺度抖动），DCT 输入可能不是好选择，或者要接受更弱的增强强度。

还有一个折中办法：在块内做循环移位。对每个块施加一个线性相位旋转，等效于块内平移，代价是 8×8 个复数乘法，比重新做 DCT 便宜，但块边界会不连续，视觉上就是块效应。分类任务上我试过，精度影响很小，可以接受。

5.3 量化强度扰动：天然的噪声增强

这是 DCT 域独有的增强方式。既然量化是有损的，那就可以主动改变量化强度来模拟不同的压缩质量。做法是把已经反量化的系数，用一张缩放过的量化表重新量化一遍：

def requantize(coef_dq, qtable, alpha): # alpha > 1 表示更粗糙的量化，模拟更低质量 step = qtable * alpha return np.round(coef_dq / step) * step

把alpha在 0.8 到 2.0 之间随机采样，就得到了一组从“比原图更清晰”到“明显压缩失真”的样本。这个增强在低质量数据集上提升明显，因为模型学会了忽略量化噪声。但要注意，alpha太大（比如超过 3）会把中频信息也抹掉，精度反而下降，我一般把上界卡在 2.0。

另外，这个操作和普通的加性高斯噪声增强不是一回事。量化噪声是乘性的、和信号幅度相关、在高频集中，而高斯噪声是加性的、均匀分布的。两者不冲突，可以叠加使用，但没必要，因为量化扰动已经覆盖了大部分场景。

6. 收益与代价：什么时候该上这条路

6.1 吞吐实测的拆解

我在一台 8 核机器配单张中端显卡的环境上做过一组对照，数据集是十来万张的中等规模图像分类数据，分辨率统一到 256×256，训练用同一个 18 层残差网络结构（DCT 版本按前面说的方式改了第一层和降采样规划）。

几个观察。第一，加 worker 的收益会饱和，从 8 到 16 只快了 23%，说明这时候已经撞到单核解码瓶颈或者磁盘瓶颈了。第二，DCT 输入在同样 8 worker 下比常规路径快 58%，而且这是在只保留 16 个系数的情况下，数据量本身也小了很多。第三，从 16 通道换成 64 通道，吞吐反而降了，因为第一层的计算量上来了，说明这时候瓶颈已经从数据加载转移到了计算。

最后一条很关键：DCT 输入不是万能的。如果你的模型本来就很轻，数据加载占比不高，那改完之后可能一点都不会快。判断标准很简单，先测一下常规管线的数据加载耗时占比，低于 30% 就没有必要折腾。

6.2 精度掉的点在哪

精度损失主要来自三处，理解它们有助于判断你的任务能不能接受。

第一处是量化噪声。高质量 JPEG（质量因子 90 以上）的损失很小，通常在 0.3 个点以内；质量因子 60 以下的图损失会明显放大，尤其是那些依赖细纹理的类别。如果你的数据集混了不同质量的图，建议把质量因子作为一个元信息记录下来，训练时做分层采样。

第二处是色度信息的丢失。只用亮度通道时，颜色相关的类别区分能力下降。有些任务里颜色是关键线索（比如区分不同颜色的同类物体），这种场景必须保留色度系数。

第三处是空间分辨率下降带来的定位精度损失。分类任务只要全局语义，影响有限；但如果下游有检测或者关键点回归，28×28 的特征图起步就太粗了。

我见过的最大精度跌幅出现在一个细粒度识别的场景，掉了 3 个多点，原因是该任务依赖高频纹理细节，而高频恰好被量化表砍得最狠。换回 RGB 输入立刻恢复。所以这类任务慎重。

6.3 一个判断清单

把上面的经验整理成一张决策表，遇到新项目可以对着过一遍：

最后一行容易被忽略。如果你手上有一个在超大规模数据上预训练好的骨干，微调能省下大量算力，那强行改成 DCT 输入等于放弃这份红利。这种情况下，DCT 输入更适合作为“从零训练一个新骨干”时的加速手段，而不是“微调现有模型”的手段。

7. 排查清单：跑不通时按这个顺序查

7.1 数值对不上

最常见的症状是训练 loss 一开始就是 nan 或者几十上百。按这个顺序查：系数顺序是否搞对（用第 4.1 节的重建自检）；反量化的缩放系数是否正确（用纯色块标定）；DC 系数是否漏了除以 8；归一化是否用了整型的除法（在 numpy 里整型除整型会走整除，必须显式转 float32）。

还有一个隐蔽的问题：有些库返回的系数是int16，但反量化之后可能超出int16范围，如果你没转float32就直接乘，会发生溢出回绕，数值看起来完全随机。这个 bug 我调了整整一个下午，因为它在小图上偶尔不出现。

7.2 训练不收敛但 loss 不是 nan

症状是 loss 缓慢下降到某个值就卡住，验证精度远低于 RGB 基线。先检查第一层的初始化，通道数变了之后，默认的 Kaiming 初始化是按fan_in缩放的，fan_in从 147 变成 576 甚至 1728，初始权重的尺度会小很多，可能导致梯度消失。可以试着把第一层的初始化标准差手动放大，或者给它单独配一个更大的学习率。

第二个怀疑对象是 BatchNorm。如果第一层后面紧跟 BN，而输入分布的变化很大（不同图像的 DC 系数差异可能上百倍），BN 的 running stats 会更新得很慢，前几个 epoch 表现会很难看。解决方式是把 BN 的 momentum 调小，或者干脆在第一层前加一个可学习的仿射变换做归一化。

第三个可能是数据本身有问题。统计一下系数张量的均值和方差，看看是不是有一批图全是零（渐进式文件读取失败），或者某个通道的方差远大于其他通道。

7.3 吞吐没提升

如果 profile 显示数据加载还是慢，先确认瓶颈在哪一段。用strace或者简单的计时打点，把“读文件”“熵解码”“反量化”“tensor 构造”分开测。常见情况是文件读取成了新瓶颈——因为每个 worker 都要独立打开文件，文件数一多，随机读的 IOPS 压力就上来了。这时候可以把数据集打包成几个大的二进制归档文件，按索引顺序读，能明显改善。

另一种情况是 Python 层的开销过大。如果keep很小，张量本身没多大，但每个样本都要走一遍 Python 的对象构造、类型转换、transform 链，这些开销加起来可能比解码还多。这时候考虑用torch.utils.data.IterableDataset自己管批次，或者把反量化和归一化挪到 GPU 上做（只搬原始整型系数过去，传输量小得多）。

还有一种情况是“提升了但没体现在 epoch 时长上”。这时候看 GPU 利用率，如果它上去了但 epoch 时长没变，说明瓶颈转移到了计算；如果它还是低，那可能是多 worker 之间有锁竞争，比如共享了一个写日志的文件句柄。

最后，还有一点是在实际项目里体会最深的：这条路的价值不在于“一定更快”，而在于它把数据管线的成本从一个几乎无法优化的黑盒里拿了出来。常规解码路径的耗时藏在第三方库里，你能调的只有 worker 数量和线程数；而 DCT 路径的每一步都在你的代码里，哪一段慢可以单独优化，哪一段可以缓存，哪一段可以批量化，全都是可控的。我在好几个项目里最后都不是靠它提速，而是靠它把性能瓶颈变得“可见”，然后才找到真正该动的地方。