Research models that only run in notebooks do not ship. The gap between a working QML experiment and a deployed service that a colleague or client can actually use is mostly plumbing — authentication, model serialization, training orchestration, API scaffolding — but it is enough plumbing to kill most research-to-production pipelines. QML Explorer is the web application we built to close that gap for our quantum machine learning work.
The Problem
Across the qml_model_02 and qml_model_03 research efforts, the team developed quantum machine learning models for waveform classification, time-series prediction, and tabular data embeddings. Each model worked in a local Python environment with its own dependencies, training scripts, and evaluation notebooks. Getting any of them in front of a stakeholder meant either sharing a notebook (fragile, environment-dependent) or spending days wiring up a bespoke API (not scalable when you have a dozen model variants).
We needed a single platform where a researcher could upload a model definition, trigger training, inspect results, and expose the trained model as an API — all without writing deployment code.
Architecture
QML Explorer has three layers:
Frontend — a React/TypeScript single-page application. It handles model browsing, training job management, result visualization, and inference testing. Authentication supports Google and Kakao login via OAuth, covering the team's primary identity providers.
Backend — a Python service (FastAPI) that manages the model registry, training job queue, and inference API. Each model is registered with its circuit definition, hyperparameters, and dataset reference. Training jobs are dispatched to workers that run the Romulus runtime.
Romulus Runtime — our internal model-building framework that wraps Omega Functions circuit execution with classical optimization loops, data loading, and checkpointing. Romulus handles the mechanics of variational training: parameter initialization, gradient computation (via Omega Functions' adjoint differentiation), optimizer stepping, and convergence monitoring.
One-Click Training
The training workflow is deliberately simple. A researcher selects a registered model and dataset, optionally adjusts hyperparameters, and clicks train. The backend creates a training job, assigns it to a worker, and streams progress (loss curves, validation metrics) back to the frontend via WebSocket. When training completes, the trained parameters are stored in the model registry and the model becomes available for inference.
This sounds straightforward, but making it reliable required careful handling of failure modes: worker crashes mid-training, GPU memory exhaustion, non-convergent runs that need early stopping. The job queue supports resumption from checkpoints, and the frontend surfaces enough diagnostic information (gradient norms, parameter distributions, loss landscape samples) for a researcher to diagnose problems without SSH-ing into a worker node.
REST API for Inference
Every trained model is automatically exposed as a REST endpoint. The API accepts input data in JSON, runs the quantum circuit with the trained parameters on the Omega Functions statevector backend, and returns predictions. For latency-sensitive use cases, we also support a WASM deployment path where the circuit runs client-side in the browser — the same Omega Functions WASM build described in our earlier post.
Model Coverage
The current model library includes waveform classification (distinguishing signal types in noisy time-domain data), time-series prediction (short-horizon forecasting using quantum reservoir features), and tabular embeddings (using parameterized quantum circuits to learn feature representations for classical downstream tasks). These span the qml_model_02 and qml_model_03 research lines and cover the use cases where we have found quantum circuits to offer a genuine advantage over purely classical baselines.
What We Learned
The biggest lesson was that deployment infrastructure for QML is not meaningfully different from classical ML infrastructure. The quantum-specific parts — circuit compilation, backend selection, gradient computation — are all encapsulated in the runtime. Everything above that layer is standard web engineering: job queues, model registries, API gateways, auth flows. Treating QML deployment as a special problem would have led us to build something unnecessarily exotic.