// SparseFlow V2 · Apple-device research
From GPU execution
to on-device evaluation.
Our independent Apple-ecosystem research compares dense, channel-pruned, and physically compact vision models through Core ML on iPhone. This research track is separate from the NVIDIA results on this page.
Read the research overviewCompaction → export → device
Source-model validation, Core ML export, and real-device short-run measurements.
Current status: mixed latency results
No general iPhone speedup claim. Sustained performance and energy savings are not yet established.
Independent Maple Silicon research; no Apple partnership or endorsement is implied.
What teams should
see immediately
SparseFlow is positioned around one buying question: can it reduce GPU cost while improving throughput on real inference workloads?
The current work centers on correctness validation, reproducible benchmarking, and fast comparisons against dense baselines.
- 1.4× average speedup across validated production shapes
- Up to 1.6-1.7× on FFN-heavy inference paths
- Up to 40% inference cost reduction on FFN-heavy workloads
- A100 validated; RTX 4090 benchmarking in progress
- No model changes required to start evaluating
- Results shared in 24-48 hours for the right benchmark setup
More GPUs should not be
the default answer
Inference teams are asked to improve latency and throughput while controlling GPU spend. In practice, that usually means buying more hardware because efficient sparse execution is hard to operationalize.
Modern hardware supports structured sparsity, but adoption remains fragmented across frameworks, compilers, and runtimes.
That leaves many structurally sparse workloads running like dense ones, with potential savings left on the table.
Built to prove savings,
not just describe them
SparseFlow approaches sparsity as a systems problem, not a collection of isolated optimizations.
By integrating compiler transformations, runtime execution, and performance validation into one path, it gives teams a cleaner way to test whether sparse execution produces real savings on their workloads.
Benchmark-first
engineering
SparseFlow treats structured sparsity as a first-class compiler concern, but the product decision still comes down to benchmark evidence. The platform is designed around four core principles:
Structured N:M sparsity patterns are represented explicitly in the compiler IR, making sparsity intent visible throughout the compilation pipeline.
All required constraints are verified before any sparse transformation, ensuring optimizations are only applied when safety can be guaranteed.
Dense operations are rewritten to sparse equivalents only when verification passes, maintaining correctness as the primary goal throughout.
A fallback path to dense execution is always available when verification fails, ensuring no correctness compromises under any conditions.
Current evaluation
scope
The current technical scope is oriented around reproducible evaluation, validation, and targeted inference acceleration:
- MLIR-based compiler infrastructure for sparsity propagation and verification
- Structured N:M sparsity support starting with 2:4
- CPU and GPU validation paths with reproducible correctness testing
- Deterministic test cases and dense-baseline comparisons
- A100 validated; RTX 4090 benchmarking in progress
SparseFlow is still a focused systems effort. At this stage, the following areas remain under development:
- Full production deployment at scale
- Performance guarantees across every workload shape
- Complete framework integration across all stacks
- Full GPU backend coverage across all operators
These areas are being approached incrementally, following correctness validation and reproducible benchmarking.
Answers before the
first call
No. SparseFlow is positioned as an inference optimization path. The current evaluation flow is designed to benchmark against your existing inference workload without requiring retraining to assess potential value.
The current benchmark path is oriented around existing PyTorch and Hugging Face style inference flows, so teams can compare SparseFlow against a practical dense baseline instead of a synthetic integration target.
A100 is currently validated. RTX 4090 benchmarking is in progress. SparseFlow is aimed at supported NVIDIA hardware where structured sparsity can translate into real throughput and cost gains.
SparseFlow is presented as infrastructure for customer workloads rather than a hosted consumer service. The current commercial path is a founder-led evaluation and pilot, with validation performed against the customer’s target environment.
Easy to evaluate with
your existing stack
We aim to keep the first evaluation simple: use your current model path, compare against the dense baseline, and return a concrete answer quickly.
No integration project required to start the benchmark conversation
Works with existing PyTorch and Hugging Face style inference paths
Dense baseline versus SparseFlow comparison stays explicit
Results are intended to come back in 24-48 hours for the right setup
Decision-making stays grounded in speedup, latency, and cost deltas
Maple Silicon Inc. is a Canadian technology company building two systems: SparseFlow for AI inference acceleration and Maple Shield for passive drone detection and airspace awareness.
SparseFlow™ is the company's compute product for teams exploring whether sparse execution can improve inference economics on supported NVIDIA hardware.
We are open to pilot evaluations with teams that want to benchmark SparseFlow against an existing inference path and identify where savings are real. The free benchmark review is a lightweight screening step; the paid pilot is the hands-on evaluation inside your stack.