Research pathway
Governed Conversion & Adaptive Serving Research
Test whether a supported model keeps useful behaviour after conversion, then check whether fewer active experts preserve that quality.
Your starting point
Would this help?
This is a fit when
- A model owner with one supported donor and a material conversion decision
- A partner prepared to reject sparse rungs that fail quality before discussing performance
When another approach is a better fit
- A request to reduce inference cost before matched quality and systems evidence
- Multiple donor families, production serving, expert marketplaces, or broad portability claims
What we’re planning
Proposed outcomes.
- 01Donor, licence, tokenizer, weight, and configuration identity manifest
- 02Conversion contract and exact/full-expert anchor receipt
- 03K32/K24/K16/K8/adaptive quality and divergence ladder
- 04Matched latency, throughput, memory, and resource measurements only for qualified candidates
- 05Failure/fallback evidence, independent review, and promote/remediate/stop decision
Where this stands
What is known. What needs testing.
Run only through a qualified NF-C protocol with supported donor rights, exact anchor, protected splits, quality threshold, matched hardware method, fail-closed fallback, and independent review.
Existing basis
- A governed dense-model conversion and validation toolchain
- A pinned real-model 28-layer, 32-expert-per-layer conversion
- Five exact complete-expert engineering cases and a complete 112-unit protected trace
- Content-bound fail-closed sparse-runtime authorization machinery
Evidence still needed
- Broader all-step and long-context dense-anchor evaluation
- Complete aligned checkpoint and material K24/K16/K8/adaptive quality
- Replicated matched latency, throughput, memory, and calibrated energy evidence
Working together / 8–16 weeks
How we’ll work together.
Start with a supported original model and an agreed quality test. Check the conversion first, then try fewer active experts. Keep the original reference when a candidate fails.
The project steps in detail
- 01Qualify donor, rights, workload, hardware, and decision through NF-C.
- 02Freeze the anchor, split, alignment, K ladder, fallback, and analysis protocol.
- 03Verify conversion integrity before sparse quality testing.
- 04Measure systems behavior only for quality-qualified candidates.
- 05Promote one exact bounded result—or redesign/stop without losing the dense anchor.
What we need before work starts
Before starting
- One supported, lawfully usable donor and approved workload
- Frozen donor baseline, quality threshold, splits, and target hardware
- Permission to preserve negative rungs, failures, and holdout access
- Independent method and result review
Scope and handover
What we agree before starting.
We agree the work in a signed statement of work before starting. This page explains the offer; the signed agreement sets the commitment.
How you accept the handover
- The donor, rights, conversion identities, and exact/full-expert anchor are frozen and verified.
- Every planned sparse rung is evaluated or rejected against the quality-first protocol.
- Systems measurements occur only for quality-qualified candidates under matched conditions.
- Fallback, failures, review, and promote/redesign/stop decisions remain visible.
What this work covers
Sponsored quality-first research, normally delivered through a qualified Research & Benchmark Partnership.
One supported donor/version, hardware profile, frozen evaluation, dense anchor, K ladder, and quality-first promotion rule. No savings or production promise.
Toolchain and K32 anchor existence do not establish material sparse quality, speed, memory, energy, cost savings, broad portability, or production readiness.
Offer source and review record
Talk to us
What are you trying to find out?
Tell us the question, what you’ve tried and how you’d use the answer. We’ll see whether we can help investigate it.