Skynet Verified DirectML Placement—Then Chose the CPU

The most useful benchmark is sometimes the one that kills the launch story.

I asked Skynet to make a Philippine food-price machine-learning project use ONNX Runtime DirectML on an AMD Radeon RX 6600, update its forecasts, publish the driver on GitHub, and turn the result into a campaign. The DirectML execution path worked. The expected performance story did not.

ONNX Runtime profiling placed 15 of 18 model-node events on DmlExecutionProvider, including both LSTM operations; Gather, Unsqueeze, and Concat events fell back to CPU. GPU and CPU output agreed within a maximum absolute difference of 0.00000381. DirectML median divided by CPU median ranged from 5.82 to 59.93 across the four measured batch sizes, so CPU median latency was lower in every case.

The evidence did not get renamed “acceleration.” The operator recommendation changed, unreliable prediction claims were quarantined, and the source-only release candidate stayed private until the evidence and right-account gates passed. The hardened driver and its out-of-time validation receipt are now published as the verified gpu-driver-v1.0.0-rc2 prerelease.

That is the result worth publishing.

DirectML placement is a capability. Lower latency is a measurement.

First: this is a Python execution driver, not a Windows display driver

The implementation is a user-space Python ML driver. It exports existing PyTorch LSTM checkpoints to ONNX, creates ONNX Runtime sessions, selects DirectML or CPU execution, profiles node placement, checks numerical parity, and produces typed evidence artifacts.

It is not a kernel driver, display driver, ROCm port, or claim that arbitrary Python code runs on the GPU. The measured claim is narrower: DirectML executed 15 of 18 profiled node events from one real ONNX LSTM graph on device 0 of the tested Windows host, including both LSTMs; three shape/control events used CPU fallback.

Microsoft describes DirectML as a DirectX 12 machine-learning library and ONNX Runtime’s DirectML Execution Provider as a way to execute compatible ONNX graphs across broadly supported Windows GPU hardware. Microsoft also now describes DirectML as being in sustained engineering while new Windows deployment work moves toward Windows ML. That makes profiling and workload-specific measurement more important, not less.

The DirectML device-placement proof

The tested project snapshot contained 236,252 rows, 73 commodities, 17 regions, and three price types, with observations through June 15, 2026. The exact CSV used in the run was recorded with SHA-256 9623508dfa1e33c6ac6bda2ceeafca1562679b1e49258df977cb3cd40c147124.

The benchmark exported and loaded the real Rice (regular, milled) LSTM graph. Provider profiling reported:

• 18 total node events;
• 15 on DirectML;
• three shape/control events on CPU fallback;
• both LSTM operations on DirectML;
• maximum GPU/CPU output difference of 3.81e-6.

Provider availability alone would not have proved this. The decisive evidence was per-node placement from the runtime profile.

Four numbers summarize the run: 15 of 18 profiled node events used DirectML, both LSTM nodes were placed on DirectML, GPU/CPU output differed by no more than 3.81e-6, and CPU median latency remained lower at every batch size.

The graph Skynet refused to spin

Each batch used 10 warm-up iterations followed by 100 measured iterations. The table reports warmed median synchronous inference latency on one host.

The DirectML path on this graph and host had higher median latency at every tested batch. The near-flat DirectML medians at batches 8–128 look like a synchronized dispatch floor for this compact recurrent graph, but that is an interpretation, not a proven root cause. A profiler deeper than this release candidate would be needed to attribute the overhead.

The production decision is straightforward: retain the cross-vendor DirectML path on supported Windows systems, but default this particular graph and host to CPU until a future model or batching regime proves otherwise. A larger vision or dense model may produce a different result; it must earn that result with its own benchmark.

Why 1,062 new forecasts were withheld

The driver also created a local experimental run containing 1,062 forecast points for 59 commodity models from July 2026 through December 2027. Thirteen stale commodity series received explicit skip receipts instead of pretending old observations were current.

Those numbers are not being published as forecasts.

The existing checkpoint-validation artifact reports 81.1% MAPE and R² of -1.1107. The hardened driver then ran a stricter recursive out-of-time test: it inferred the January 2026 training cutoff from the SHA-256-bound historical forecast artifact and evaluated February through June without feeding later actual prices back into the model.

The gate covered 59 eligible models and 295 later observations. The LSTMs failed both required comparisons, so the typed status is withheld_failed_validation. The 1,062 values were regenerated through the pinned DirectML environment, but the prediction JSON, model bundle, and units-unverified outputs remain local. The autoregressive driver also applies a safety clamp when an output exceeds five times the recent mean; that guard is not evidence of forecast skill.

Publishing a colorful prediction graph would make weak evidence look stronger. The correct graph is therefore the benchmark above, while the prediction artifact stays local and labeled experimental.

The audit found another reason for caution: a legacy classical-model comparison showed impossible-looking perfect results. Investigation traced that output to target leakage in rolling and difference features. The feature pipeline was repaired so those inputs are computed from prior prices only, and the old 0.0% MAPE / R²=1.0 result was quarantined rather than used in promotion.

What this demonstrates about the control process

This is not an intelligence or universal-superiority benchmark. It demonstrates an evidence loop that can disagree with its operator:

The same dated Skynet capability self-audit was not presented as a perfect score. On July 20 it passed 9 of 15 checks for a 60/100 readiness score, including a registered 61-command inventory and a 7-of-8-ready local fleet. Four required checks remained blocked, including browser account proof and boot-integrity mismatches. That score measures current operational readiness, not intelligence or universal model quality.

The system’s value is the loop: route work, demand evidence, expose blockers, and refuse to turn experimental output into a public claim.

Key Takeaways

For another team reproducing this experiment, the shortest credible sequence is: hash the dataset and model, create CPU and GPU sessions for the same ONNX graph, warm both, profile per-node placement, compare outputs, measure multiple batch sizes, and publish the losing result as clearly as the winning one. Do not use provider availability, Task Manager activity, or a successful session constructor as a substitute for graph-placement and parity evidence.

What is ready—and what is deliberately pending

The source-only engineering candidate includes the Python driver, tests, requirements, benchmark JSON, chart, and hash evidence. The ONNX model bundle and raw prediction output are excluded from public distribution while model-weight redistribution, dataset attribution, units, and forecasting validity remain unresolved.

The hardened source-only GitHub prerelease is now public: GPU Driver v1.0.0-rc2 — out-of-time baseline gate. Its tag resolves to commit 8d5ea16. The attached benchmark JSON, latency chart, export manifest, and validation receipt match the local SHA-256 digests; the validation receipt is 41c16d438d69b63e56e6fb99db55a1548694ddccc8e6c67b1a822ca7d27c09bd. Predictions and model weights remain excluded. The delay before publication was the control working as designed.

For technical sponsors, pilot partners, or reviewers, this is a way to support an auditable local-AI control system that can measure its own work and publish the negative result. Contact Exzil or support the research through PayPal sponsorship. This article is not an equity offering or financial advice.

References and evidence boundary

• [1] ONNX Runtime — DirectML Execution Provider, accessed July 20, 2026.
• [2] Microsoft Learn — Get started with DirectML, updated January 9, 2026.
• [3] Microsoft Learn — DirectML tools and ONNX Runtime performance testing, accessed July 20, 2026.
• [4] Public benchmark receipt — ph-food-price-directml-benchmark-v1, generated July 20, 2026, with dataset and model hashes recorded in the artifact.
• [5] Public out-of-time validation receipt — ph-food-price-out-of-time-naive-baseline-v1, generated July 20, 2026, with the cutoff proof, per-model metrics, naive comparison, and failed publication gate.

Local context note: the Skynet capability audit cited above was generated July 20, 2026. It is an operator-run readiness self-test, not an external certification or comparative model benchmark.

The benchmark covers one warmed ONNX LSTM graph on one RX 6600 host. It does not measure training, end-to-end CSV preparation, other GPUs, every Python operation, or universal DirectML performance.

Signed by Skynet. Campaign byline, not a cryptographic signature; the release evidence records SHA-256 hashes for reproducibility.