Frontier teachers propose · Blackwell proves · deterministic evaluation rewards
Verified Triton intelligence for faster AI.
SPARKDISTILL turns pinned frontier-model trajectories into GPU-validated training data, teaches compact students to develop, debug, and optimize Triton kernels, and rewards only measured improvements over the current frontier.
One verifiable improvement loop
The goal is a latest-Triton specialist stack—Triton 3.7.1 on NVIDIA Blackwell today—that gets better through open competition rather than uncheckable claims. SN74 on Gittensor rewards verified dataset contributions and verified model-quality gains inside the existing subnet.
Frontier models propose
Only the pinned teacher basket—Claude Fable 5 and GPT-5.6 Sol at xhigh reasoning—may generate production trajectories. Arbitrary or cheaper substitute models are rejected by policy.
Blackwell executes
Generated Triton kernels are compiled, executed, numerically checked, screened for cheating and eval leakage, then proved on an NVIDIA RTX PRO 6000 Blackwell confidential-computing node.
Students learn verified work
Accepted engineering rationale and final kernels become reasoning-format SFT records. Axolotl recipes train compact students whose job is Triton translation, correctness, debugging, profiling, and optimization.
The frontier moves only on proof
The validator compares the candidate and current frontier on the same held-out benchmark basket. SN74 rewards only the verified marginal gain; the winning public recipe and dataset become the next starting point.
How SparkProof works
SparkProof is the data-provenance layer. It does not trust a teacher's plausible-looking code or a miner's CSV. It keeps a row only after the code survives independent validation and the complete run is bound to confidential-computing evidence.
- Build diverse training tasks. Seeded, stratified sampling draws from official Triton API documentation, semantics and tutorials, deterministic kernel mutations, PyTorch-to-Triton translation tasks, self-evolution, and failure mining. TritonBench remains evaluation-only.
- Call only pinned frontier teachers. Requests go through an approved gateway—OpenRouter or yunwu—to
claude-fable-5andgpt-5.6-solwithreasoning.effort=xhigh. The exact request body is fingerprinted. - Validate outside the model. The compiler, PyTorch oracle, anti-cheating checks, numerical tests, and Blackwell GPU—not the teacher—decide whether a kernel is correct. Bad candidates may be repaired; failures are preserved separately.
- Prove on confidential hardware. Production runs execute on an NVIDIA RTX PRO 6000 Blackwell CC node. NVIDIA attestation evidence is nonce-bound to the raw trajectory archive so it cannot be reused for a different dataset.
- Seal the verified subset. SparkProof writes a
sparkproof-2manifest, Merkle root, validation report, raw and verified trajectories, release-gate report, dataset hash, andgpu_attestation.json. - Publish data and proof together. Hugging Face receives the SFT-ready rows plus the complete
proof/directory, allowing validators to replay the checks without access to the miner's machine.
Teacher outputs are hypotheses, not ground truth. Production accepts only the pinned frontier-model basket, but correctness comes from compile-and-execute validation, independent numerical tests, decontamination, and the attested Blackwell GPU.
Cheap verification by anyone
Proving requires the Blackwell RTX PRO 6000 CC node. Verifying does not. GitHub Actions, a laptop, or any CPU host can download the published proof/ directory and independently check policy, hashes, Merkle consistency, raw-to-verified filtering, and attestation binding.
| Verifier check | What it establishes |
|---|---|
| Pinned teacher policy | Every row names an allowed frontier teacher and approved gateway model slug; substitute slugs fail production verification. |
request_sha256 | The stored prompt, model slug, generation settings, and xhigh reasoning request match the committed request fingerprint. |
| Validation reports | Only rows that passed Triton syntax, compile/execute, numerical correctness, and production policy are included in the verified dataset. |
| Raw → verified consistency | The miner cannot replace accepted rows after validation or hide where the verified subset came from. |
| Merkle root + dataset SHA-256 | Any post-proof edit changes the committed bundle root or the registry-pinned trajectory hash. |
| GPU CC nonce binding | The NVIDIA attestation evidence is tied to the raw trajectory archive used in that proof. |
| Online NVIDIA verification | sparkproof-verify --online additionally verifies the NRAS JWT signature against NVIDIA JWKS. |
Exact trust boundary: SparkProof proves the recorded request, validation process, hardware evidence, and post-proof integrity. Commercial APIs do not provide provider-signed inference receipts, so offline verification cannot cryptographically prove what OpenAI or Anthropic executed internally. OpenRouter generation IDs can be re-queried with the creating key; yunwu currently has no equivalent external ledger.
From miner bundles to one canonical dataset
A miner publishes its verified bundle to Hugging Face and opens a text-only PR adding the URL and pinned trajectories_sha256 to datasets/registry.jsonl. The registry workflow runs before merge:
- Download the miner's complete
proof/directory from Hugging Face. - Re-run production SparkProof verification against the pinned generator and teacher policy.
- Confirm Blackwell CC evidence, release-gate success, row count, and the exact SHA-256 claimed by the PR.
- Require at least 25 verified rows for
dataset:xs; larger contributions earns,m,l, orxl. - Deduplicate and aggregate all accepted registry entries into
gittensor-model-hub/sparkproof-miningwith a provenance manifest. - Merge only after the canonical mining dataset publishes successfully. Rejected proofs are labeled
dataset:REJECTand closed.
Evaluation controls the frontier
Dataset verification answers “is this training data authentic and GPU-validated?” Frontier evaluation answers “did this public dataset and recipe make the student measurably better?” They are separate gates.
Only public inputs count
The training submission is the public recipe plus a registry-backed dataset—not a secret checkpoint. Anyone can fork the current leader and try the next improvement.
Validator-owned evaluation
Miners cannot submit the benchmark used to reward themselves. Frozen held-out prompts and protected TritonBench material remain isolated from training generation and decontamination fails closed if the corpus is unavailable.
Same run, same basket
The candidate and current frontier are evaluated under the same deterministic harness. Reward is based on marginal quality delta, not a miner's claimed score or checkpoint rank.
Verified wins become shared
Passing improvements receive eval:XS through eval:XL, are appended to the public run ledger, and become the new frontier every miner can build on.
Proof of training: a weights-free claim bundle — evaluation scores, training time, GPU claim, and a per-file hash manifest of the checkpoint — cryptographically bound twice via its claim_sha256: into the NRAS-signed RTX PRO 6000 CC attestation nonce (the GPU), and into an Intel TDX quote's REPORTDATA whose MRTD measures the guest VM itself (the software environment). The validator verifies the proof from the published artifacts alone — attestations, nonce bindings, hashes, training budget — with no retraining. Trained weights never leave the miner's machine, and the public recipe + dataset keep every merged win reproducible by anyone. Unattested submissions fall back to retraining from source.
Train, share the recipe, move the frontier
Dataset miners feed the canonical mining mix; training miners turn that verified data into better students. The submission is never a secret checkpoint — it is the public Axolotl recipe plus the registry-backed dataset behind it. That design keeps improvement continuous, competitive, and fast.
- Start from the current leader. Fork the frontier recipe under
recipes/and point it at the canonical mining dataset or your own verified registry entry. Every merged win is public, so the next miner never starts from zero. - Train and score locally. Run
scripts/install_train.sh,scripts/prepare_mining_sft.sh, thenscripts/train.sh recipes/qwen3.5-4b-phase1/sft-mining.yamlandscripts/eval.shagainst the held-out frontier basket. You are competing on marginal quality delta — not a self-reported leaderboard. - Open a narrow PR with the recipe and dataset. Commit the changed
sft.yaml(or add a new recipe file) and cite the dataset URL or registry line. Small, focused recipe changes with a clear eval gain are easier to review and merge. - Let the validator verify your proof. The validator checks your published claim bundle — GPU CC attestation,
claim_sha256nonce binding, checkpoint hash manifest, and the 5-hour training budget — viaeval.verify. The PR merges only if the proof verifies — not because you shipped weights, and no retraining is required for attested submissions. - Winning recipes become shared infrastructure. Accepted runs receive
eval:XSthrougheval:XL, enter the public run ledger, and become the next frontier every miner can fork. Copy the leader and add one optimization is expected — not cheating.
Continuous improvement
Verified datasets aggregate into sparkproof-mining; verified recipes stack into a public frontier. Each accepted PR raises the bar the whole subnet trains against.
Open competition
No private moats: whoever holds the frontier must have a fully public recipe and dataset behind it. Anyone can fork, experiment, and submit the next measurable win.
Move fast
Reward tiers (eval:XS–XL) pay for verified marginal gains, not maintainer opinion. Tight recipe PRs, fast local eval loops, and the proof-of-training fast path keep the improvement cycle short.
The loop closes in public: SparkProof miners grow verified Triton data → training miners distill better students from shared recipes → evaluation moves the frontier only on proof → the new leader's recipe and dataset become everyone's next starting point. That is how a latest-Triton specialist stack keeps improving without slowing down for trust.
Mine the dataset track
A production miner needs a Blackwell RTX PRO 6000 confidential-computing VM, a pinned SparkProof checkout, teacher-gateway credentials, and a Hugging Face token. Verification and registry review happen automatically after publication.
# On a Blackwell RTX PRO 6000 CC VM
git clone https://github.com/gittensor-model-hub/SparkProof.git
git clone https://github.com/gittensor-model-hub/SparkDistill.git
cd SparkProof
cp .env.example .env
scripts/install.sh
# Generate → best-of-N/repair → compile/execute → attest → release gate → publish
scripts/run_triton_pipeline.sh \
--run-id my-triton-run \
--limit 25 \
--release-gate \
--publish your-hf-user/sparkproof-triton-v1
# Build the text-only registry line for your PR
cd ../SparkDistill
scripts/registry_line.sh \
--bundle ../SparkProof/bundles/my-triton-run \
--miner your-github-handle \
--repo-id your-hf-user/sparkproof-triton-v1Production dataset PRs must contain exactly one append to datasets/registry.jsonl. The first merge/reward tier is 25 verified rows. See the complete miner guide for policies, labels, failure modes, and the training track.
Build toward the specialist stack
Dense Triton specialist
Close the full SparkProof → canonical dataset → Axolotl SFT → held-out evaluation loop on Qwen3.5-4B, with every accepted training row and frontier improvement independently verifiable.
MoE kernel expert
Extend the verified data and recipe loop to Qwen3.6-35B-A3B, aligned with sparkinfer's MoE serving focus while preserving the same public provenance and evaluation gates.
Continuous verified improvement
Feed every verified frontier back into generation, training, evaluation, and sparkinfer serving so kernel intelligence and edge inference performance improve together.
Build the frontier in public
Contribute verified datasets, better public recipes, or measurable evaluation improvements through SN74. Every accepted win becomes reusable infrastructure for the next miner—not a private moat.