[DISCUSSION] Apache Mahout Roadmap: Q3–Q4 2026

[rich7420]

Context

QuMat and QDP have evolved significantly over the last several releases.

QDP now includes work around:

• CUDA and AMD ROCm execution;
• multiple quantum data encodings;
• DLPack / GPU-pointer paths;
• batching and asynchronous prefetch;
• memory management;
• preprocessing and validation;
• realistic QML benchmarks;
• CPU / PyTorch reference implementations.

There are also several recent issues around runtime and performance engineering, for example:

• [Roadmap] Strengthen CUDA kernel implementation #1227 — compute-kernel performance and comparison with torch.compile()
• [Feature] [qdp] A end-to-end profiling system for qdp #1410 — end-to-end QDP profiling
• [Feature] Add estimate_memory() for pipeline GPU footprint #1429 — pipeline memory estimation
• [Feature] Fail fast when estimated memory exceeds VRAM #1430 — fail-fast VRAM validation
• [Feature] PyO3 bindings for Preprocessor #1431 — Python bindings for preprocessing

Taken together, I think there is an interesting question about how we want QDP to evolve, but I do not think we need to answer that question completely in this roadmap issue.

Areas I am personally interested in

Below are areas I think may be worth discussing for Q3–Q4 2026. These are not commitments or an ordered project roadmap.

QDP correctness and benchmark quality

Possible work includes:

• CUDA / ROCm semantic and numerical conformance;
• clearer benchmark definitions;
• reproducible benchmark metadata;
• separating kernel, data-to-state, pipeline, and end-to-end benchmarks;
• ensuring cross-framework comparisons perform equivalent operations.

Given that performance is an important part of QDP, I think benchmark reproducibility and correctness are especially valuable.

Runtime observability and memory planning

There is already ongoing / proposed work around:

• end-to-end profiling ([Feature] [qdp] A end-to-end profiling system for qdp #1410);
• memory estimation ([Feature] Add estimate_memory() for pipeline GPU footprint #1429);
• fail-fast VRAM checks ([Feature] Fail fast when estimated memory exceeds VRAM #1430);
• preprocessing ([Feature] PyO3 bindings for Preprocessor #1431).

It may be useful to coordinate these as a broader runtime / observability effort.

QDP interoperability

Today QuMat is an important consumer of QDP.

I think it is worth exploring whether QDP should also become easier to use independently from QuMat, for example from existing PennyLane or Qiskit workflows.

A small external-framework prototype could help us understand whether this is actually useful before introducing larger abstractions.

Quantum preparation runtime / planning

One possible longer-term direction is to think of QDP as the preparation layer between classical data and quantum computation.

That might eventually include concepts such as:

• preparation semantics;
• backend capabilities;
• implementation/provider selection;
• memory and copy planning;
• preparation profiling.

I have opened / plan to open a separate proposal issue for this idea so that the architectural discussion does not make this roadmap issue too large.

QPU preparation research

QDP's current direct-state preparation is primarily useful for simulator workflows.

A physical QPU requires a different preparation path, typically an executable circuit rather than direct state-vector handoff.

It may be interesting longer term to investigate whether simulator preparation and QPU circuit preparation can share some common high-level encoding semantics.

I would consider this a research topic rather than a near-term roadmap commitment.

What I do not think this roadmap needs to decide

I do not think we need to decide in this issue whether Mahout should become:

• a complete replacement for PennyLane or Qiskit;
• a generic GPU data engine;
• a general device runtime or compiler;
• a fixed sequence of 0.x / 1.0 feature milestones.

Those are larger questions and should be discussed separately if contributors want to pursue them.

Community request

Please comment below with any of the following:

1. What do you plan to work on during Q3–Q4 2026?
2. What features or capabilities would you most like to see?
3. Which areas are you willing to help implement, review, benchmark, or document?
4. Are any of the areas above better handled outside Mahout core?
5. Are there existing issues that should be grouped into a larger tracking issue / EPIC?
6. If you are a maintainer and willing to help coordinate a larger effort, please say so.

I am especially interested in hearing from users of QuMat/QDP about where the current bottlenecks are in real workflows.

The intent here is to make it easier for contributors with overlapping interests to find each other and to help the individual issues we work on add up to a coherent direction.

[rich7420]

cc @ryankert01 , @guan404ming , @viiccwen , @400Ping , @0lai0