From the Research Universities edition of October 28, 2026
Jülich adds JUBIS, a 656,640-core Sparxity (SpiNNaker2) system beside its exascale Jupiter Booster for sparse machine-learning workloads
Jülich Supercomputing Centre (JSC), with Sparxity (formerly SpiNNcloud) · Research computing and HPC architecture · Germany; international, limited transferability
- Publisher
- HPCwire
- Original publication
- 28 October 2026 (HPCwire)
- Source retrieved
- 2026-10-29
What happened
HPCwire reports that JSC announced it has tapped Sparxity, a Dresden and Manchester neuromorphic spinoff, to provide JUBIS, a multi-million-dollar system of 90 boards (48 SpiNNaker2 chips per board, 152 cores per chip) totalling 656,640 cores. JUBIS will sit near the Jupiter Booster, Europe's first exascale system, and run sparse machine-learning workloads such as sparse solvers and optimizers that are a poor fit for Jupiter or other JSC systems. A JSC neuroscience lab scientist said it complements JSC infrastructure and opens new research opportunities. Sparxity's CEO argued that GPUs handle sparse data poorly and that increasingly sparse mixture-of-experts models suit its architecture, and said it has dozens of systems at 30 customers including Sandia National Laboratories.
Why it matters
Shows a leading research computing center adding a non-GPU accelerator for workloads GPUs serve poorly, relevant to U.S. centers deciding whether to diversify beyond GPU clusters for sparse scientific ML and MoE inference.
Evidence and measured results
Read the full article. Hardware counts and customer claims come from Sparxity via HPCwire; no benchmarks, energy figures or JSC workload results were reported.
Limitations and uncertainty
Vendor-sourced figures relayed by trade press; no performance or efficiency data. Exact cost not disclosed. Efficiency and MoE claims are the CEO's. European context limits direct transfer.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-28; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Some scientific ML and inference workloads run inefficiently on GPU clusters, but centers lack evidence on alternatives.
- Stakeholders
- Research computing director
- HPC architects
- Faculty with sparse solver or MoE workloads
- Procurement
- Discovery questions
- What share of workloads are sparse or irregular?
- Are GPU utilization rates low for those jobs?
- Is there budget for an evaluation system?
- Value hypothesis
- A workload assessment may identify jobs where specialized hardware could improve efficiency, to be proven by benchmarks.
- Potential engagement
- A workload characterization and benchmark plan for sparse jobs across current and candidate architectures.
- Unsupported claims
- Efficiency or speed gains
- Suitability for general AI training
- Vendor customer counts as validation
Pre-sales engineering
Role takeaway
- Fit
- Fits centers with sparse solvers, optimization or MoE inference workloads alongside GPU systems.
- Architecture and integration
- Specialized event-based accelerator system placed beside GPU partitions, with scheduler routing by workload type.
- Prerequisites
- Representative sparse workloads
- Porting tools and libraries
- Scheduler integration
- Constraints
- No published benchmarks
- Small vendor ecosystem
- New programming model
- Security
- Apply standard cluster access controls and review vendor software supply chain.
- Proof of value
- Benchmark time-to-solution on sparse solvers
- Measure energy per solution against GPU nodes
- Assess porting effort per application
Delivery
Role takeaway
- Work
- Select workloads, port and benchmark, integrate with the scheduler, and train users.
- Dependencies
- Vendor support
- Application developer time
- Evaluation hardware access
- Ownership
- Research computing center.
- Skills and adoption
- Staff and users learn event-based programming models and workload triage.
- Governance checkpoints
- Vendor viability review
- Benchmark go/no-go
- Allocation policy for specialized hardware
- Acceptance criteria
- Energy per solution below GPU baseline on chosen workloads (proposal)
- Porting effort documented
- User support plan in place
- Risks
- Vendor lock-in or failure
- Low adoption due to porting effort
- Gains limited to narrow workloads
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Heterogeneous centers may place specialized sparse or event-based accelerators beside GPU systems and route workloads by data structure.
Governance
Who approves, reviews and stays accountable for outcomes?
Adding novel architectures needs workload-matching policies and evaluation before allocation to users.
Security and privacy
What data, permissions and controls need testing?
Not discussed.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
New programming models for event-based hardware require user training and support staff skills.
Procurement
What should contracts, pricing and exit terms secure?
Centers can buy specialized accelerators from small vendors for niche workloads, with vendor viability and software support as diligence items.
Operating model
Which teams own the service once it runs?
Workload triage across architectures becomes a research computing service.
Publication history
- 2026-10-28Research Universities · Issue 505 resources
Stable resource ID: julich-jubis-sparxity-sparse-ml-system-20261028