NPU Training: VKORE-46M-NPU Explained
A 46M-parameter model was pretrained on inference-only NPUs. See what the GPU comparison proves, what it does not, and why the result matters for AI.
Can an Inference-Only NPU Train a Language Model? VKORE-46M Puts It to the Test
For years, inference-only neural processing units have had a pretty clear job: run a model that's already been trained, efficiently. Training - backpropagation, optimizer updates, and all the coordination that comes with multiple chips - usually lives in a GPU-focused workflow. That split has real consequences. If you want to adapt or train a model, you typically still need expensive GPU infrastructure, even if you already have NPUs around for inference.
South Korean company Vidraft says it's shown a different path. It reports that VKORE-46M-NPU, a 46-million-parameter language model, was pretrained from scratch on a 32-chip, inference-oriented NPU system - without NVIDIA GPUs. Vidraft also claims its NPU training loss trajectory correlated at 0.99 with a GPU run using the same model and training conditions.
This is an interesting engineering result, but it's worth reading it with the right level of skepticism. The model is small, the training method isn't public, and a matching loss curve is evidence that a training loop can run - it's not proof that NPU systems can substitute for GPUs across every kind of workload. Below is what the demonstration supports, what's still unknown, and what teams should do before betting production timelines on it.
Why training on an inference NPU is unusual
An inference chip is generally built to execute a model that's already been trained. The forward pass takes inputs, runs through the network, and produces outputs. Training adds extra steps: you compute how far the output is from the target, propagate that error backward through the network, and update model weights with an optimizer.
Those extra steps change what the system needs. Training often requires keeping or recreating intermediate values, computing gradients, managing optimizer state, and coordinating updates across devices. When a model is split across chips, the system also has to exchange information between them. An inference-oriented software stack may not expose those features - or make them work efficiently.
That's why the common assumption in the industry has been that inference-focused NPUs aren't a great fit for training, especially pretraining from random initialization. But that's not a law of physics. A chip optimized for inference can still run operations that show up in training; the real question is whether the full set of required operations can be implemented correctly and efficiently in the hardware and software environment you actually have.
What Vidraft says it demonstrated
Vidraft says it ran backpropagation directly on an inference-only NPU system and pretrained VKORE-46M-NPU from scratch. In other words, it wasn't adapting a pretrained checkpoint and just doing light finetuning on the NPU. The company says it used 32 first-generation NPU chips released in 2025, rather than a newer accelerator.
This matters because "fine-tuning" and "from-scratch pretraining" aren't the same kind of proof. Fine-tuning starts with weights that already encode useful patterns. A from-scratch run has to show that the whole training loop - forward computation, gradient calculation, optimizer updates, and repeated iterations - works end to end on that platform.
Vidraft describes its software layer as VKORE, intended to support training and inference across NPU hardware. The CUDA comparison is really about what the software layer is expected to do: hardware usefulness depends not only on chips, but on the tooling that lets developers run real workloads. That said, it doesn't automatically mean VKORE has CUDA-level maturity, an equivalent ecosystem, or comparable breadth of support. The gap between those claims and the actual state of the tooling is something the current demonstration can't resolve on its own.
Why the implementation details matter
Vidraft says its main training technique is proprietary and patent-pending, with a technical paper planned later. The training code is not open source. That means outside readers can't yet inspect the implementation, reproduce the run, or independently verify specifics like numerical methods and communication strategy.
None of this makes the result worthless - it just changes how strong the conclusion should be. The public model and the comparison materials are a starting point, but reproducibility and independent review will depend on more technical detail. For teams evaluating NPU training, the difference between a promising demo and a production-ready platform usually shows up in those implementation details.
What the VKORE-46M comparison tells us
The strongest piece of evidence in the announcement is the comparison between an NPU run and a GPU reference. Vidraft says both runs used the same model, initialization, data, and training schedule. It reports a 0.99 correlation between the loss trajectories, and it says throughput converged to a similar level. The material summarized here doesn't include a specific tokens-per-second number, so the throughput claim reads more like a qualitative statement than a benchmark you can directly compare against another system.
Loss measures how far a model's predictions land from the training targets under a chosen objective. Over time, decreasing loss usually suggests the model is learning to fit the training data. Looking at the shape of loss curves can help you see whether two systems are making broadly similar progress under matched conditions.
What a 0.99 correlation means - and what it does not
A correlation of 0.99 means the reported NPU and GPU loss curves moved in a very similar way over the measured run. That's solid evidence that the NPU run wasn't just producing random updates or failing to learn. It's also more informative than a single chart showing loss falling on the NPU alone.
But correlation isn't identity. Two curves can match closely while still differing in absolute loss values, the exact parameter updates, final model quality, or evaluation performance on a held-out task. Correlation also doesn't tell you that both runs had precisely the same numerical behavior unless the underlying setup and measurements can be checked independently. What the reported result supports is that NPU training tracked the GPU reference under the stated conditions; it doesn't prove the systems produce interchangeable outcomes.
And in practice, that distinction matters. If you're evaluating a new accelerator, you want to know whether it can run the full training loop and whether the results are stable. You also need the end of the story: final task performance, wall-clock time, power draw, cost per training run, and how results scale as model size and dataset size increase. A loss-curve match answers only part of that.
The model is a proof of operation, not a quality claim
VKORE-46M-NPU has 46 million parameters, which is small by today's standards for language models. Vidraft says it was trained on public datasets and can generate short English stories. The company presents the model as evidence that its NPU training path works, not as a claim that it competes with major commercial models or open-weight systems.
That's a reasonable scope for an initial demonstration. Smaller models reduce the cost and complexity of proving an end-to-end training loop works. They also limit what you can infer about large-scale training. Scaling changes the game: memory pressure, inter-chip communication, data throughput, optimizer state, and fault recovery all become harder. A successful 46M run doesn't automatically mean those problems are solved for models with billions of parameters.
The model is available on Hugging Face. Vidraft's original announcement and technical overview lays out the company's account. Those sources are useful for examining the release, but they shouldn't be treated as a third-party reproduction.
Where the business impact could be real
The business case isn't just "NPUs might be cheaper than GPUs." A real comparison has to include hardware costs, software support, engineering time, power, cooling, utilization, and the cost of running training operations. An accelerator that's cheaper to buy can still end up costing more overall if it requires major custom engineering or if it runs workloads much more slowly.
Still, the direction is worth watching. Many organizations use GPUs for training and separate hardware for inference. If an NPU system can handle both reliably, it could simplify some deployments and make better use of hardware that might otherwise sit idle between inference tasks. And for teams with strict data-location requirements, local training could reduce the need to move sensitive data to an external service - assuming the organization can run appropriate governance and security controls.
Use cases that fit the near-term evidence
The most credible near-term opportunity isn't training a frontier model in an office environment. It's giving teams more options for smaller, bounded workloads where control, availability, or hardware cost matters. Candidates include:
- Small domain-specific models: cases where the training objective and data volume are modest, and buying a GPU allocation doesn't feel justified.
- Local or private environments: organizations that need to keep data inside a controlled environment and are willing to operate their own hardware.
- Development and evaluation: testing training pipelines, data preparation, or model behavior on an alternative accelerator before committing to larger infrastructure.
- Combined inference and limited training: systems where the same hardware could run deployed models and occasional updates, as long as capacity and scheduling meet measured requirements.
These are opportunities to test, not results already proven by the 46M model. Production teams would still need to validate that their own model architecture, dataset, sequence length, and training cadence are supported. Hardware behavior can shift a lot when the workload doesn't match the demo.
Why software can matter more than the chip
A capable chip is only part of an accelerator platform. Developers still need supported operators, stable libraries, clear documentation, monitoring and debugging tools, model conversion paths, and a plan for failures. In practice, the software layer determines whether a team can use the hardware without building a custom stack for every project.
That's where VKORE's ambition may be strategically important. Vidraft is positioning it as a common NPU software layer rather than a one-off training script. The CUDA comparison points to a real industry dynamic: hardware becomes more useful when developers can move familiar workflows across systems and when software investment accumulates over time.
That said, ecosystem claims take time to verify. The real test is whether developers can take a representative model, run it with predictable results, debug issues when they happen, and keep it working through software updates. Until independent users can repeat those workflows, it's fairer to treat VKORE as an attempt to build an NPU training platform - not as a settled alternative to mature GPU ecosystems.
What teams should verify before adopting NPU training
If you're evaluating a platform like this, start with the workload - not the hardware announcement. Decide what success means in your context: model quality, time to train, cost per run, privacy requirements, or the ability to run without a cloud dependency. Without that baseline, hardware comparisons tend to turn into contests of headline specs that don't predict your actual results.
A practical assessment can be broken into four checks:
- Reproduce the workload: run a representative model and dataset, not just a vendor sample. Document initialization, optimizer settings, batch configuration, and evaluation method.
- Measure the complete cost: track elapsed time, power, utilization, engineering effort, and any software or support costs. Tokens per second alone won't capture the cost of a successful training run.
- Validate model behavior: compare final loss and task-specific evaluation results, not only the curve shape. Run multiple trials if variability could matter for a production decision.
- Test operational fit: check deployment, monitoring, failure recovery, model export, security controls, and upgrade paths. If you can't maintain it, it isn't production-ready.
Keep the comparison fair
A useful GPU-versus-NPU benchmark keeps the workload constant and reports anything that can change outcomes: software versions, precision settings, batch size, sequence length, data pipeline details, and stopping criteria. It should share both the metric and the method used to obtain it. If a vendor doesn't publish enough detail to reproduce the comparison, treat it as a reason to test further - not as a procurement conclusion.
It also helps to separate three questions that often get bundled together:
- Can the hardware train this model? The VKORE-46M demo is evidence in favor of "yes" at least for one small model and configuration.
- Can it train efficiently? Vidraft reports comparable throughput, but you'll need a full, reproducible benchmark with numeric results to judge the workload you care about.
- Can your team operate it reliably? That depends on tooling, support, compatibility, and operational maturity - none of which can be inferred from one successful pretraining run.
Vidraft says larger models and real data expansion are next steps. Those are exactly the tests that will clarify the limits of the current result. Until then, the sensible stance isn't "dismiss inference NPUs as incapable" and it isn't "assume GPUs are obsolete." The right view is to treat the demo as a promising sign - and demand the rest.
Conclusion
VKORE-46M-NPU challenges a simple assumption: that an inference-oriented NPU can't participate in training. Vidraft reports a from-scratch pretraining run on 32 such chips and a loss trajectory closely correlated with a GPU reference. That's meaningful evidence that the training path can work for a small model.
What it doesn't prove yet is that NPUs can replace GPUs across model sizes or production workloads. The model is small, the core method isn't public, and throughput details plus independent reproductions are still needed before broader claims hold up. For businesses, the practical move is to pick a bounded workload and test it with a fair, end-to-end cost comparison.
If you want to assess the release directly, start with the VKORE-46M-NPU model on Hugging Face, then compare it against a representative workload from your own environment. The real value will come down to what teams can reproduce - and what they can operate reliably over time.