这是个非常有意思的问题，核心原因在于CPU缓存机制和底层线性代数库（比如OpenBLAS、MKL）的高度优化，咱们一步步拆解：

1. 缓存复用：数据只加载一次，反复利用 #

你代码里的x是一个1×p的行向量，当计算x @ coef（coef是p×k的矩阵）时，x的p个元素只需要从内存加载到CPU缓存一次。之后和coef的每一列做内积时，都可以直接从缓存读取x的元素，完全不需要再从内存重新加载。

但如果是k次单独计算x @ b_i（每个b_i是coef的一列），情况就不一样了：虽然小k时x可能还留在缓存里，但随着k增大，缓存很可能被其他数据挤出去，导致每次计算都要重新加载x；更关键的是，coef的每一列在内存中如果是非连续存储（numpy默认是行优先的C顺序，列元素是间隔k的），单独访问每一列的缓存命中率会很低，每次都要从内存读取零散的数据，耗时剧增。

2. BLAS库的批量运算优化 #

numpy的矩阵乘法底层依赖BLAS（Basic Linear Algebra Subprograms）库，这类库针对批量运算做了极致优化：

• 循环分块（Loop Tiling）：把大矩阵拆成适配CPU缓存大小的小块，让计算过程中数据尽可能留在缓存里，避免频繁的内存-缓存交换；
• 向量化指令：利用AVX、AVX2等CPU指令集，一次可以计算多个元素的乘积和，大幅提升并行计算效率；
• 多线程并行：自动利用多个CPU核心，把k列的计算任务分配到不同核心上同时执行。

而k次单独的向量乘运算，每次只能调用BLAS的gemv（矩阵-向量乘）函数，无法充分利用这些批量优化的特性，效率自然差很多。

3. 函数调用开销的分摊 #

每次单独执行x @ b_i，都要触发numpy的调度逻辑、BLAS函数的调用，这部分是固定的开销。而一次执行x @ coef只需要一次调度和函数调用，把k列的计算都打包处理，相当于把这部分固定开销分摊到了k次计算上，进一步拉低了平均耗时。

结合你的测试场景 #

你设置的p=100，当k从1增长到4000时，time_k的增长速度远慢于k*time_1，完全符合上面的逻辑：随着k增大，缓存复用和批量优化的收益越来越明显，抵消了计算量的线性增长。

内容的提问来源于stack exchange，提问作者user8648470