(가능한지는 잘 모르겠는데) GPU 연동 방안 찾아보기

[seonghobae]

[seonghobae]

Execution checklist

• Profile end-to-end hotspots in aefa/engineAEFA
• Compare candidate GPU paths (torch, OpenCL/gpuR, Rcpp/CUDA)
• Define opt-in GPU backend + safe CPU fallback
• Set go/no-go thresholds (speedup, numeric tolerance, install burden)
• Publish feasibility memo with recommendation

Acceptance criteria

• Baseline CPU profile documented
• At least two GPU approaches compared with constraints/trade-offs
• Explicit go/no-go threshold defined before implementation
• Default user path remains CPU/remote unchanged

[seonghobae]

Fleet quality handoff — GPU is now a Rust-backend parity requirement, not an optional R-package experiment

Fresh 2026-09-02 evidence changes this issue's older acceptance criteria.

Current kaefa production architecture still places numerical estimation in the R/mirt engine (aefa() / engineAEFA()), while active recovery PRs #79 (1c5d9f0491fc178be3f7f307dac521fbcbba6978) and #80 (1f05996780cf24ab32c747696764fee096747d64) explicitly exclude a Rust/GPU numerical core. By contrast, released sibling ContextualWisdomLab/fast-mlsirm v0.9.1 already demonstrates the ecosystem target boundary: Python/R-like host surfaces validate and marshal while production psychometric arithmetic is Rust-owned; its multilevel person-effect kernel supports deterministic CPU workers plus a wgpu score-reduction path with f64 CPU fallback. It also explicitly documents where GPU parity or full multilevel variance estimation is not yet complete.

Accordingly, do not implement this issue as torch, gpuR/OpenCL, or Rcpp/CUDA calculations inside kaefa merely to obtain a speedup. Those would create a second production numerical authority and violate the current Rust-first psychometrics boundary.

Updated owner-path acceptance

1. Profile the current aefa() / engineAEFA() computation graph only to identify numerical kernels and orchestration cost; profiling does not authorize retaining those kernels in R.
2. Produce an estimator-family ownership matrix: reuse a released/versioned fast-mlsirm Rust primitive where semantics match exactly; otherwise route the missing reusable kernel to the correct Rust owner and consume it through a narrow kaefa adapter/ACL. Keep UI, formula parsing, orchestration and presentation in kaefa.
3. Define one Rust device contract (cpu, supported GPU backend(s), auto) rather than separate algorithm implementations. CPU and GPU must execute the same scientific estimand and convergence contract. A GPU-unavailable path may fail closed or fall back only when the API contract explicitly permits it and the receipt records the selected device.
4. Acceptance is correctness/parity first, not a heuristic speedup threshold: exact same data/seed/configuration must preserve model identity, parameterization, termination/convergence semantics and missingness. Validate parameter/likelihood differences against prespecified numerical tolerances justified by floating-point/device precision, plus true-parameter recovery evidence. Report device, precision, kernel/version, hardware and fallback in provenance.
5. Exercise CPU multithreading and GPU parity under realistic item/person sizes, multilevel structures, missingness, non-convergence, singular/ill-conditioned inputs, cancellation/resource limits and deterministic repeated execution. Never silently downcast a model requiring f64 scientific accuracy merely because a GPU kernel is f32.
6. Keep reference mirt/mixedmirt fits as validation oracles where useful, not as the production arithmetic path. For feat(recovery): nested mixedmirt random-effect RMSE evidence #80 specifically, fast-mlsirm's current crossed/multiple-membership MAP kernel does not estimate variance-component ML; tau00 therefore remains a real missing Rust capability rather than a drop-in GPU target.
7. Record the resulting bounded-context/ACL decision, device contract, scientific recovery design, unsupported estimands and operability limits in ADR/research traceability and docs/product-technical-gap-baseline.md; the latter is currently absent on live develop and must become code-current before claiming commercialization closure.

The older issue comment's “choose torch/OpenCL/Rcpp-CUDA and set a go/no-go speedup threshold” is therefore superseded by this Rust-owner + CPU/GPU parity contract. Performance still matters, but it is measured after scientific equivalence and production ownership are established.