无GPU训练大模型：推理专用NPU跑通反向传播

把一块只擅长“推理”的芯片拿来训练模型，听起来像让短跑运动员去跑马拉松——硬件设计根本不支持。但VIDRAFT最近发布的VKORE-46M-NPU证明，这条路在工程上是走得通的。

事件核心：46M参数模型在推理NPU上完成预训练

VIDRAFT公开了一个名为VKORE-46M-NPU的小型语言模型，参数量4600万，完全从随机权重开始预训练，训练过程没有使用任何GPU。硬件平台是一块第一代推理专用NPU——按照传统机器学习工程的认知，这类芯片只适合跑前向推理，不适合做训练。

模型使用公开数据集训练，能够生成简短的英文故事。权重、模型卡以及NPU与GPU训练的对比分析材料都已发布在Hugging Face上。

这个发布的意义不在模型本身的能力，而在于它是一份可验证的工程证明：推理专用芯片上可以跑通反向传播。VIDRAFT正在构建的VKORE软件层，目标是成为“NPU领域的CUDA”，覆盖推理加速、完整预训练和LoRA微调三项能力，这次发布的是预训练里程碑的公开验证产物。

工程难点：推理NPU为什么不能直接训练

推理NPU的架构针对前向传播做了大量优化，但反向传播需要的能力它基本不具备。梯度计算和权重更新要求灵活的访存模式、高精度中间缓冲区、原地张量修改等特性，这些在GPU训练中是默认配置，在推理NPU上往往缺失或受限。

VIDRAFT的做法是在NPU之上自建软件抽象层。由于推理专用芯片通常没有厂商提供的训练栈，他们通过VKORE层自行实现反向传播，让NPU表现为可训练的计算基底。

训练从随机初始化开始，没有使用任何预训练检查点。这一点很关键——它排除了“实际上是微调却包装成预训练”的可能性。为了验证正确性，VIDRAFT还在高性能GPU上跑了完全相同的训练任务，在匹配条件下对比两者的损失轨迹。

具体实现细节（算子融合策略、内存管理、梯度累积机制）尚未公开，将在后续论文中描述。

反向传播对硬件的核心需求

反向传播的硬件瓶颈不在算力，而在访存和精度。前向传播中，每层激活值用完即可丢弃；反向传播则必须保留每层激活值直到梯度回传完成，显存占用与网络深度成正比。同时，权重更新需要将梯度以高精度累积到参数上，通常要求 FP32 精度的梯度累积缓冲区，而推理 NPU 的片上 SRAM 往往按 INT8/FP16 前向推理优化，FP32 缓冲区可能根本无处安放。此外，梯度下降涉及“读取权重—计算梯度—原地更新权重”三步串行操作，对原地修改（in-place update）和灵活随机访存的依赖很强，而推理 NPU 的 DMA 引擎和调度器通常假设数据流是单向的、不可变的。这些架构假设在训练场景下全部失效，因此才需要在芯片之上重建一套反向传播抽象。

关键指标：损失轨迹相关系数0.99意味着什么

NPU训练和GPU训练之间，损失轨迹相关系数达到0.99。这个数字需要正确理解。

它衡量的是训练动态的相似度，不是吞吐量对等。VIDRAFT明确说明，这不代表NPU训练速度能追上GPU——推理NPU做训练通常更慢。0.99的含义是：NPU上的训练过程沿着与GPU基线统计上几乎相同的路径收敛，梯度计算在数值上是一致的，不是近似或发散的。

另外，VIDRAFT验证了通用公开模型可以在同一块NPU上做推理和量化模型执行，说明VKORE层同时覆盖了训练和部署两端。

损失轨迹相关系数的统计含义

损失轨迹相关系数通常指 Pearson 相关系数，衡量两条损失曲线在训练步数维度上的线性相关程度。0.99 意味着两条曲线几乎完全同向变动——NPU 每一步的损失下降幅度与 GPU 基线的比例关系高度稳定。但相关系数不反映绝对差异：即使两条曲线始终相差一个固定偏移量，相关系数仍可接近 1。因此 VIDRAFT 的对比更可能采用了逐步骤对齐的损失值序列，以检验梯度计算的数值一致性，而非泛化性能的最终对齐。真正要排除的是梯度发散、梯度消失或梯度方差过大等训练失败模式，0.99 说明这些风险在数值层面被排除。

怎么获取与使用

模型权重、模型卡和对比分析材料已在Hugging Face公开：

pip install huggingface_hub
huggingface-cli download vidraft/VKORE-46M-NPU

需要注意仓库slug以VIDRAFT的Hugging Face页面为准。核心训练代码未公开，出于知识产权保护考虑暂不发布，技术论文计划在后续发布。目前没有提到这个模型的公开API端点。

几个需要厘清的问题

这是真正的反向传播吗？ VIDRAFT在新闻稿中明确表示在NPU上实现了反向传播（역전파），描述为标准反向模式梯度计算，不是无梯度替代方案。技术机制未公开。

0.99的相关系数是否意味着NPU训练和GPU一样快？ 不是。这个系数衡量的是损失曲线随步数演化的相似性，与墙钟吞吐量或样本效率无关。结果的意义在于正确性验证，不是速度基准测试。

什么时候支持LoRA微调和更广泛的模型预训练？ LoRA微调是VKORE软件层的路线图项目，与推理加速和预训练并列。目前没有公开的时间表。

能在自己的NPU硬件上训练吗？ 暂时不行。训练栈是内部的，公开的只有训练好的模型权重和分析材料。需要关注后续技术论文和VKORE SDK的发布。

这件事的行业意义

对ML工程师来说，这个案例提供的价值在于：当你被迫考虑非GPU的加速器方案时，推理专用NPU至少不再是完全不可行的训练平台。0.99的损失相关系数说明数值正确性可以保证，尽管速度不占优势。

当然，局限同样明显。模型只有46M参数，训练数据是公开数据集，训练代码不开源，速度指标未披露。从46M到更大规模模型之间还有多少工程障碍，目前无法判断。VKORE软件层能否像CUDA那样形成生态，也取决于后续的LoRA支持和SDK开放程度。

VIDRAFT的发布更像一个起点而非终局。它的价值不在于证明“NPU可以训练大模型”，而在于证明“推理NPU上的反向传播在数值上是可信的”——这是后续一切工作的前提条件。

NPU 训练栈与 CUDA 生态的类比边界

把 VKORE 比作“NPU 领域的 CUDA”，关键差异在于 CUDA 的成功建立在硬件指令集、编译器、运行时库和框架适配四层协同之上，且 NVIDIA 对硬件有完全控制权。第三方软件层要跨多种 NPU 硬件实现训练抽象，必须面对每家芯片的算子集、内存布局和驱动接口互不兼容的问题。VIDRAFT 目前在一款第一代推理 NPU 上跑通预训练，证明了单点可行性，但距离 CUDA 式生态还有硬件覆盖广度、算子库完整度和框架集成深度三个维度的差距。后续论文能否披露算子融合与内存管理策略，将决定这套方案是定制工程还是可复用的通用方案。