Skip to content

[Compute Gap] Implement real GPU backends and hardware parity under bounded VRAM #171

Description

@seonghobae

Buyer problem

TEPP requires high-performance Rust arithmetic with CPU and GPU execution, but current work only provides a bounded VRAM policy/type slice in #51. Protected main does not execute a production topic/psychometric kernel on real accelerator hardware, prove CPU/GPU numerical parity, or demonstrate safe behavior across the declared VRAM profiles.

Product outcome

Implement a backend-neutral compute plane with:

  • CPU f64 numerical reference;
  • bounded fixed-pool multithreading with no oversubscription;
  • NVIDIA CUDA as the primary production accelerator where materially beneficial;
  • a portable WGPU/CubeCL or equivalent path only where verified and maintainable;
  • streamed sparse batches and sufficient-statistic accumulation;
  • explicit VRAM budgeting, bounded OOM retry, and safe CPU fallback;
  • immutable compute profile and telemetry artifacts.

Existing related work

Acceptance criteria

  • compute_backend exposes a small versioned trait/API used by the real estimator and psychometric kernels.
  • CPU f64 results are the reference; every accelerator result records precision, device/backend, driver/runtime, kernel version, and comparison tolerances.
  • Fixed worker pools, thread-local sufficient statistics, deterministic reduction mode, and BLAS/thread-pool oversubscription prevention are tested on CPU.
  • Responsibilities or document×topic state are streamed by bounded batch and never retained for the full corpus on device.
  • The VRAM controller measures capacity/availability, reserves a safety margin, predicts peak allocation, autotunes micro-batches, records peak/transfer/kernel metrics, and releases temporary buffers promptly.
  • OOM causes bounded batch reduction; repeated inability to fit produces an explicit CPU fallback or typed terminal failure without dropping observations, shrinking the declared model, or moving the knowledge cutoff.
  • Real hardware CI or scheduled evidence executes the production kernel on declared accelerator backends. A skipped, emulated, or software-only lane cannot satisfy a hardware-support claim.
  • 4/6/8/12/24-GiB profiles are exercised on real hardware where available or through a documented capacity-constrained harness whose limitations are explicit; at least one low-VRAM and one higher-VRAM real device must run before release.
  • CPU/GPU parity covers objective/ELBO, posterior coordinates, fitted parameters, sufficient statistics, gradients/updates where used, convergence decisions, and final scientific metrics.
  • Mixed precision keeps accumulation/convergence-critical calculations at justified precision; numerical drift and nondeterminism have predeclared acceptance bounds.
  • GPU/CPU fallback preserves run identity, provenance, and reproducibility manifest; the backend change is visible to the buyer/auditor.
  • Browser/LLM and estimator GPU residency is phase-scheduled on small devices; local model weights and estimator tensors cannot cause uncontrolled contention.
  • Benchmarks report throughput, wall time, CPU/GPU utilization, peak RSS/VRAM, transfer bytes, energy/cost where measurable, and scaling against corpus/topic/nonzero dimensions.
  • Production statement/branch coverage and public docs remain 100%; property tests, fault injection, allocator pressure, device-loss, timeout, and parity regressions are included.

Merge and release boundary

Do not merge a backend that only allocates tensors, runs a synthetic add kernel, silently skips unavailable hardware, or diverges from the CPU scientific result. GPU speed is subordinate to correctness, bounded memory, and recoverability.

Authority

Use ADR 0001, ADR 0006, PRD §13, TRD §8, and the research/standards register. Record exact backend versions/commits and hardware evidence in doctoring and release provenance.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions