QuantEM.GPU Remote#
QuantEM.GPU Remote exposes the existing CUDA implementation to another process while keeping raw 4D-STEM data and full-volume computation on a Linux CUDA host. It is a deployment and communication layer, not another kernel runtime or numerical implementation.
The product name is QuantEM.GPU Remote. Its reproducible Conda environment
is quantem-gpu-remote, and its command remains quantem-gpu serve.
Choose the page you need#
Goal |
Page |
|---|---|
Create and verify the service environment |
|
Connect from the same host or another machine |
|
Implement a client or evolve the wire contract |
|
Understand GPU selection, memory fit, and eviction |
|
Change CUDA kernels used by the service |
Component boundary#
client process
│ versioned requests and typed image payloads
▼
QuantEM.GPU Remote src/quantem/gpu/remote/
│ public QuantEM.GPU calls (io.load, detector.prepare, dpc.integrate)
▼
CUDA implementation src/quantem/gpu/{io,detector,dpc}/
│
▼
encoded resident acquisitions and their products
The service owns catalog discovery, source readiness, CUDA admission, resident acquisition reuse, and response provenance. A client owns presentation, interaction, and user-visible policy. The service does not import a client UI framework.
Scientific invariants#
Every response preserves scan and detector shape, output dtype, half-open
regions, scan and detector bins, and implementation revision. Each acquisition
is loaded once into the lossless encoded form io.load returns; every detector
bin, scan bin, and scan crop is computed from that resident by adding exact
integer counts. A cropped or binned result is never represented as native
resolution.
Raw detector data stays on the CUDA host unless a requested endpoint explicitly returns a selected diffraction payload. Missing capacity or unsupported work returns a typed failure; it never causes an implicit CPU fallback, crop, bin, or precision change.