NumPy矩阵乘法（如@、np.dot、np.matmul）会突然吃光内存，因其直接按输出形状预分配内存，例如(10000,500)×(500,10000)结果需800MB；若输入非C-contiguous、隐式广播或dtype未降级（如float64未转float32），峰值内存可能翻倍。
为什么 np.dot 或 @ 会突然吃光内存
NumPy 的矩阵乘法（np.dot、@、np.matmul）在遇到高维或大尺寸数组时，不会“渐进式”分配内存，而是直接按输出形状预分配——比如两个 (10000, 500) 和 (500, 10000) 的 float64 矩阵相乘，结果是 (10000, 10000)，需约 800MB 内存。若中间还隐式广播或触发副本（如输入不是 C-contiguous），实际峰值可能翻倍。
常见诱因包括：
- 输入含
np.float64但业务只需np.float32 - 用
np.matrix（已弃用）或错误 reshape 导致维度混乱，触发广播而非点乘 - 在循环中反复拼接结果，如用
np.vstack累积乘积
用 np.einsum 控制计算路径和中间存储
np.einsum 不仅能替代 dot，还能显式指定求和轴顺序，避免生成完整中间张量。对大矩阵乘法，它可启用优化路径（optimize=True），自动选择分块或缓存友好的计算顺序。
例如：np.einsum('ik,kj->ij', A, B, optimize=True) 比 A @ B 在某些尺寸组合下内存峰值低 30%~60%，尤其当 A.shape[1]（即 k 维）远大于另两维时。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 始终加
optimize='greedy'或optimize=True，默认False不启用优化 - 避免写成
np.einsum('ij,jk', A, B)（缺箭头），这会返回未求和的四维张量，直接爆炸 - 若报错
ValueError: too many operands，说明传入了非数组对象（如 list），先转np.asarray()
分块乘法：手动控制内存上限
当矩阵大到无法一次性加载时，唯一可靠方式是分块。不要自己写嵌套 for 循环——Python 解释器开销太大。改用 numpy.memmap 或沿行/列切片后调用 np.dot。
示例：对 A (m, k) × B (k, n)，按 k 维分块（最省内存）：
chunk_size = 256
C = np.zeros((A.shape[0], B.shape[1]), dtype=A.dtype)
for i in range(0, A.shape[1], chunk_size):
end = min(i + chunk_size, A.shape[1])
C += A[:, i:end] @ B[i:end, :]
关键点：
- 分块维度必须是内积维度（即
A的列、B的行），否则无法累加 -
chunk_size需权衡：太小则循环开销大；太大则单次@内存仍超限。从 128 开始试，观察psutil.Process().memory_info().rss - 确保
A和B是 C-contiguous（用A.flags.c_contiguous检查），否则切片会触发副本
检查并降级数据类型与布局
内存暴涨常源于没意识到默认是 float64。很多机器学习场景用 float32 完全够用，直接减半内存。
操作步骤：
- 创建时指定
dtype=np.float32，而非事后.astype(np.float32)（后者产生副本） - 用
np.ascontiguousarray(A, dtype=np.float32)一步完成转类型+保证内存连续 - 对稀疏场景，别硬用 dense 矩阵——改用
scipy.sparse.csr_matrix，.dot()会自动跳过零值
容易被忽略的是：即使你写了 dtype=np.float32，如果输入源（如 pandas DataFrame）本身是 object 类型，NumPy 仍会升为 float64。务必在源头做 .astype(np.float32) 并验证 A.dtype。
