zeros、ones、eye 三件套：全零、全一、单位矩阵一行命令生成

一、三件套的数学本质：为什么是这三个

要理解 zeros、ones、eye 为什么会被放在一起，得先回到线性代数的两个基本对象：加法单位元与乘法单位元。在实数域上，0 是加法单位元，1 是乘法单位元；推广到矩阵空间，全零矩阵 O 满足 A + O = A，单位矩阵 I 满足 A·I = I·A = A。全一矩阵 J 则没有这么"干净"的代数身份，它更像一个秩为 1 的构造块，但在统计学、图论和神经网络里出场率极高。

换句话说，三件套对应的是三种最基础的"填充语义"：零填充（占位、掩码、初始化）、一填充（全连接、均值、注意力掩码的补集）、对角填充（恒等、正则、残差连接）。本文评述：把这三个函数当作"语法糖"是低估了它们——它们是张量世界里最接近"公理"的构造器，几乎所有更复杂的矩阵（Toeplitz、Hankel、Vandermonde）都可以由它们通过索引赋值组合出来。

1.1 全零矩阵：不只是"什么都没有"

全零矩阵的秩为 0，零空间是整个空间，特征值全为 0。这些性质听起来"平凡"，但在工程里恰恰是它的价值所在：它是最安全的初始状态。累加器从零开始、掩码默认全零、梯度缓冲区清零，都是同一套逻辑。值得注意的是，零矩阵在浮点意义下并不总是"精确的零"——IEEE 754 存在 +0.0 与 -0.0，虽然比较时相等，但在某些符号敏感的运算（如 1/x）中会分叉。

1.2 全一矩阵：秩 1 的万能积木

J = 11ᵀ，秩恒为 1。它的特征值是一个 n 和 n-1 个 0（n 为阶数）。在统计学里，J/n 是"取均值"的投影算子；在图论里，全一向量常用来做 PageRank 的初始分布；在 Transformer 里，因果掩码的补集就是上三角的全一矩阵。笔者认为，全一矩阵最容易被误用的地方是把它当成"中性元素"——它既不中性也不无害，J 参与矩阵乘法会把所有行"拉平"成同一个方向，信息坍缩得非常快。

1.3 单位矩阵：恒等映射的离散化身

I 是对角线为 1、其余为 0 的方阵，满足 Ix = x。它的行列式为 1，条件数为 1（在 2-范数下），是数值上最"良态"的矩阵。工程上 I 的三大用途：正则化（岭回归里加 λI 改善条件数）、残差连接（y = x + F(x) 可写成 (I + F)x 的近似）、初始化（循环权重初始化为 I 以缓解梯度消失）。本文评述：I 的"良态"是双刃剑——它太稳定了，以至于在深度网络里直接用 I 初始化循环权重，反而会让网络在早期缺乏非线性表达能力。

二、内存布局与缓存：一行命令背后的代价

调用 np.zeros((10000, 10000)) 只需要一行，但背后发生的事情远比"填零"复杂：操作系统要分配 800 MB（float64）的连续虚拟内存，NumPy 要决定是 C 顺序还是 Fortran 顺序，CPU 要按页触碰内存才能真正提交物理页。理解这些，才能解释为什么有时候"生成"比"计算"还慢。

2.1 C 顺序 vs Fortran 顺序

NumPy 默认使用 C 顺序（行优先），即最后一维变化最快。对于 zeros((m, n))，内存里先排第 0 行的 n 个元素，再排第 1 行。Fortran 顺序（列优先）则相反，MATLAB 和 BLAS/LAPACK 传统上偏好它。选择哪种顺序，直接影响后续矩阵乘法的缓存命中率。

本文评述：很多性能问题并非算法问题，而是布局问题。一个在 C 顺序下按列求和的循环，缓存未命中率可能高达 90% 以上；改成按行求和，速度差可以到 5～10 倍。三件套生成时顺手指定 order，是成本最低的优化之一。

2.2 惰性分配与写时复制

Linux 的 malloc 对大块内存使用 mmap，返回的是"未触碰"的虚拟页。只有真正写入时，内核才通过缺页中断分配物理页。这意味着 np.zeros 在 Linux 上可能比 np.ones 快得多——因为 zeros 可以依赖内核的零页（zero page）机制，而 ones 必须逐字节写入 1。这一点在 macOS 与 Windows 上表现不同，跨平台基准测试必须注明系统。

# 观察惰性分配：zeros 通常快于 ones（Linux, 模拟数据）
import numpy as np, time

for fn, name in [(np.zeros, 'zeros'), (np.ones, 'ones')]:
    t = time.perf_counter()
    a = fn((8000, 8000), dtype=np.float64)
    dt = time.perf_counter() - t
    print(f"{name}: {dt*1000:.2f} ms, nbytes={a.nbytes/1e6:.0f} MB")

2.3 对齐与 SIMD

现代 CPU 的 AVX-512 要求 64 字节对齐才能发挥全部带宽。NumPy 从 1.22 起在部分路径上使用对齐分配，但用户自定义的 np.empty + 手动填充不一定对齐。若追求极致性能，可考虑 numpy.empty 配合 numpy.fill，或直接使用 Intel MKL 的 mkl_malloc。相关对齐细节可参考 NumPy 官方文档与 Intel oneAPI 文档。

三、NumPy 生成 API 全解与参数陷阱

NumPy 提供了 zeros、zeros_like、ones、ones_like、eye、identity、full、empty 一整套构造器。它们共享一套参数约定，但细节差异足以让人踩坑。

3.1 核心签名对照

np.zeros(shape, dtype=float, order='C', *, like=None)
np.ones(shape, dtype=float, order='C', *, like=None)
np.eye(N, M=None, k=0, dtype=float, order='C', *, like=None)
np.identity(n, dtype=float, *, like=None)
np.full(shape, fill_value, dtype=None, order='C', *, like=None)

注意 eye 的 k 参数：k=0 是主对角线，k>0 是上移，k<0 是下移。这个参数在做差分算子、卷积核、Toeplitz 构造时非常有用。identity 则是 eye 的方阵特例，没有 k 参数。

3.2 dtype 的默认陷阱

三件套默认 dtype 是 float64。在深度学习里这往往不是最优——float32 省一半内存，bfloat16 再省一半。更隐蔽的坑是整数索引：np.eye(3, dtype=int) 没问题，但 np.zeros(3, dtype=int) 在后续做除法时会被截断。本文评述：显式声明 dtype 是良好习惯，尤其在跨框架（NumPy ↔ PyTorch ↔ JAX）传递时，隐式转换带来的性能损失和精度问题远比多打几个字符昂贵。

3.3 like 参数与数组 API 标准

NumPy 1.20 引入 like= 参数，允许通过传入一个数组来"借用"其命名空间。例如 np.zeros(3, like=torch_tensor) 会返回 PyTorch 张量（前提是实现了 __array_function__ 协议）。这是 Python 数组 API 标准（Array API Standard）的一部分，目的是让下游库代码与具体框架解耦。相关规范见 NumPy NEP 18 与 Array API 标准文档。

3.4 形状参数的正确姿势

一个高频错误是 np.zeros(3, 4)——这会报 TypeError，因为第二个位置参数是 dtype。正确写法是 np.zeros((3, 4))。另外，np.zeros(5) 生成的是一维数组而非 1×5 矩阵，做矩阵乘法前需要 reshape 或 atleast_2d。

四、从稠密到稀疏：eye 的另一种打开方式

当矩阵规模上到 10⁶ × 10⁶，稠密 eye 会瞬间吃光内存（8 TB，float64）。此时必须转向稀疏表示。SciPy 的 scipy.sparse.eye 只存对角线上的 n 个元素，内存从 O(n²) 降到 O(n)。

import numpy as np
from scipy import sparse

n = 1_000_000
# 稠密：约 8 TB，直接 MemoryError
# dense = np.eye(n)

# 稀疏：约 8 MB（data + indices + indptr）
sp = sparse.eye(n, format='csr', dtype=np.float64)
print(sp.data.nbytes / 1e6, "MB")  # 模拟数据：约 8 MB

本文评述：稀疏 eye 的价值不止省内存，更在于它把"恒等"从"显式存储"变成"隐式算子"。很多迭代求解器（如共轭梯度）只需要知道"乘以 I 等于不变"，根本不需要真的构造 I。这种"算子视角"是稀疏计算的核心思想，也是 JAX 的 LinearOperator 抽象的理论基础。

4.1 稀疏格式选择

4.2 带状矩阵与差分算子

用 eye 的 k 参数可以快速构造差分矩阵。一阶前向差分算子 D 满足 (Dx)ᵢ = xᵢ₊₁ - xᵢ，可写成 eye(n, k=1) - eye(n)。这类算子在数值 PDE、信号处理、图拉普拉斯构造中反复出现。

import numpy as np

n = 5
D = np.eye(n, k=1) - np.eye(n)   # 前向差分
# [[-1, 1, 0, 0, 0],
#  [ 0,-1, 1, 0, 0],
#  [ 0, 0,-1, 1, 0],
#  [ 0, 0, 0,-1, 1],
#  [ 0, 0, 0, 0,-1]]

L = D.T @ D   # 一维拉普拉斯（近似）

本文评述：把 eye 当作"差分积木"，是数值线性代数里非常优雅的一招。它把"构造稀疏算子"从手写循环变成了矩阵表达式，既简洁又利于向量化。相关技巧在 LeVeque 的《Finite Difference Methods for ODEs and PDEs》中有系统讨论。

五、深度学习中的初始化：zeros/ones 的边界

在神经网络里，三件套的角色从"数学构造"变成"初始化策略"。这里有一条铁律：不要把权重全部初始化为零。原因是对称性——如果同一层的所有神经元权重相同，它们在反向传播中会收到相同的梯度，永远无法分化，网络退化成单个神经元。这一结论在 Goodfellow 等人的《Deep Learning》第 8 章有清晰论述。

5.1 偏置可以为零，权重不行

实践中，偏置 b 初始化为 zeros 是标准做法，因为对称性破坏由权重完成。权重则使用 Xavier/Glorot 或 He 初始化，它们本质上是"带缩放的随机数"，而不是三件套。本文评述：三件套在初始化里的正确位置是"缓冲区"——优化器状态（Adam 的 m、v）、梯度累加器、掩码，而不是可学习参数本身。

5.2 残差连接与单位矩阵初始化

残差网络的核心是 y = x + F(x)。如果把 F 的最后一层权重初始化为零，整个残差块在训练初期就是恒等映射，梯度可以无损回传。这一思路在 Goyal 等人 2017 年的论文 "Accurate, Large Minibatch SGD" 中被用于训练 ImageNet，也被后续的 Fixup、ReZero 等工作继承。ReZero 更进一步，把残差分支乘以一个可学习的零初始化标量 α，让网络从恒等映射平滑地"生长"出非线性。

5.3 循环网络与正交初始化

RNN 的循环权重若用随机初始化，梯度容易爆炸或消失。Saxe 等人 2013 年的工作指出，正交初始化（orthogonal init）能保持梯度范数稳定。而单位矩阵初始化是正交初始化的一个特例，在 IRNN（Identity RNN）中被证明可以让网络学到长程依赖。本文评述：I 初始化在 RNN 上的成功，本质是因为它让循环雅可比矩阵的特征值落在单位圆上，避免了谱半径的指数衰减。

5.4 注意力掩码：ones 与 eye 的协奏

Transformer 的因果掩码是一个下三角全一矩阵，通常写成 np.tril(np.ones((L, L)))。而 padding 掩码则常用 eye 的变体来构造。这些掩码在训练时被加到注意力分数上（加 -∞ 或 -1e9），从而屏蔽未来位置。相关实现可参考 Hugging Face Transformers 的 modeling 源码。

import numpy as np

L = 4
causal = np.tril(np.ones((L, L), dtype=bool))
# [[ True, False, False, False],
#  [ True,  True, False, False],
#  [ True,  True,  True, False],
#  [ True,  True,  True,  True]]

# 转成加性掩码
mask = np.where(causal, 0.0, -np.inf)

六、GPU 与张量框架：PyTorch / JAX / CuPy 对照

三件套在 GPU 框架里的语义基本一致，但设备、内存格式、自动微分行为各有差异。下表给出对照。

6.1 PyTorch 的 requires_grad 与叶子张量

PyTorch 里 torch.zeros(3, requires_grad=True) 会创建一个叶子张量，参与反向传播。但实践中很少直接对零张量求梯度——因为梯度会累加到它上面，而它本身没有上游依赖。更常见的是把 grad 缓冲区设为 requires_grad=False。

6.2 JAX 的函数式与不可变性

JAX 的数组是不可变的，jnp.zeros 返回的数组不能原地修改，必须用 .at[idx].set() 生成新数组。这与 NumPy 的原地赋值习惯差异很大，是 JAX 新手最常见的坑。本文评述：不可变性虽然牺牲了原地操作的性能，但换来了函数式变换（jit、grad、vmap）的可组合性，是 JAX 设计哲学的核心取舍。

6.3 显存与 dtype 的联动

在 GPU 上，torch.zeros((1024, 1024), dtype=torch.float32, device='cuda') 占 4 MB 显存，float64 则翻倍。混合精度训练（AMP）下，主权重用 float32、计算用 float16/bfloat16，三件套的 dtype 选择直接影响显存占用与数值稳定性。相关实践见 NVIDIA Apex 与 PyTorch AMP 文档。

七、性能基准：一次可复现的实测

下面给出一组整合自公开基准与本地模拟的对比数据，用于说明三件套在不同规模下的相对开销。所有数据标注为"模拟数据"，实际数值会因硬件、系统、NumPy 版本而异。

（模拟数据，Linux x86_64，NumPy 1.26，float64，取 5 次中位数。仅供趋势参考。）

可以看到，zeros 始终快于 ones，eye 因为要写对角线而略慢。差距在 16000×16000 时达到约 2 倍。本文评述：这个差距在单次调用里微不足道，但在需要反复生成临时缓冲区的循环里（如自定义训练循环），累积起来相当可观。能用 zeros 就不用 ones，能用 empty 就不用 zeros——前提是你能保证后续会覆盖全部元素。

7.1 与 empty 的对比

import numpy as np, time

shape = (8000, 8000)
for fn in [np.empty, np.zeros, np.ones]:
    t = time.perf_counter()
    a = fn(shape)
    print(f"{fn.__name__}: {(time.perf_counter()-t)*1000:.1f} ms")

empty 几乎瞬时返回（只分配不初始化），但内容是不确定的。若后续代码没有完整覆盖，会引入难以复现的 bug。本文评述：empty 是"性能换正确性"的典型，只在热路径且能保证全覆盖时使用。

八、工程实践清单与常见坑

8.2 三个真实踩坑案例

案例一：整数除法截断。某同学用 np.zeros(n, dtype=int) 做累加器，后续除以 n 得到全零。原因是整数除法在 NumPy 里是 floor 除法。修复：dtype=float。

案例二：ones_like 的 dtype 继承。np.ones_like(int_array) 返回整数全一，若用于 softmax 的初始温度会出问题。修复：显式 dtype=np.float32。

案例三：eye 的 k 参数方向。有人以为 k=1 是下对角线，实际是上对角线。修复：记住"正上负下"。

九、前沿预判：从三件套看张量编程的演进

三件套看似稳定，但它们所处的生态正在快速变化。笔者认为，未来三到五年有三个值得关注的方向。

9.1 数组 API 标准化

Python Array API Standard 正在推动 zeros/ones/eye 的跨框架统一。截至 2024 年，NumPy、CuPy、PyTorch、JAX、Dask 都已部分实现该标准。这意味着下游库可以写一份代码跑遍所有后端。相关进展见 data-apis.org 的官方文档。

9.2 编译式张量编程

JAX 的 jit、PyTorch 2.0 的 torch.compile、Mojo 等，都在把"生成张量"这类操作编译成融合内核。未来 zeros/ones 可能不再是独立的 kernel launch，而是被编译器内联到更大的计算图中。本文评述：这会进一步模糊"生成"与"计算"的边界，对性能调优的直觉提出新要求。

9.3 稀疏与结构化矩阵的复兴

随着大模型参数上到万亿，稠密矩阵的边际收益在下降。结构化矩阵（Toeplitz、低秩、块对角）和稀疏表示重新受到重视。eye 作为最基础的结构化矩阵，其"算子化"用法（不显式存储，只定义乘法）会成为主流。相关研究可参考 Monarch 矩阵、Butterfly 矩阵等工作。

十、参考文献与声明