Share ORT sessions across pipeline handles - #28
Conversation
…, one engine's VRAM ONNX Runtime's C-API Run is thread-safe and weights load once per session, but ort 2.0.0-rc.12 exposes run(&mut self) — and DiarizationPipeline borrows both models &mut for its whole lifetime, so concurrent jobs previously serialized per engine. Wrapping each model in its own mutex does NOT fix this: the lock would still be held for the whole job. The split has to separate weights from per-request scratch. Change: every ORT session becomes SharedSession (Arc<Mutex<Session>>), locked for exactly one run() per inference call; the model structs themselves become the per-request scratch. SegmentationModel::clone_shared() / EmbeddingModel::clone_shared() return cheap handles sharing all sessions (weights + arenas — the VRAM) while re-allocating the staging buffers (~130 MB host RAM) and a fresh primary_batch_run_options (its preallocated output tensor must stay per-handle). No method signatures change; pipeline code is untouched. Handles run concurrently; same-session calls serialize per batch on the session mutex. Validated (RTX 3080 Ti / A6000): full test suite passes; single-job output byte-identical to before (AMI test-16 full 13.101% / exclusive 17.813%, Karpathy 8.219%, 3-run byte determinism); 4 concurrent jobs produce outputs identical to the same jobs run serially (verified across 3 independent runs); GPU memory flat at ~one warm engine during 4 concurrent jobs; two concurrent jobs no longer double each other's wall time (1.3x inflation vs 2.0x before).
Caught by review on this PR - a full backup of the former embedding module was accidentally included alongside the real changes.
|
Warning Review limit reachedNext included review available in 1 minute. View limit detailsLimit details: You’ve used all 2 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (12)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
237800a to
89b6ce0
Compare
Greptile SummaryThis PR enables non-CoreML pipeline handles to share loaded ONNX Runtime sessions while retaining private mutable inference state.
Confidence Score: 5/5The PR appears safe to merge; no actionable correctness, security, or repository-rule violations were identified. Shared mutable state is limited to mutex-serialized ORT sessions, while all scratch buffers, preallocated output state, execution-plan metadata, and pipeline-level data retain appropriate independent ownership. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
P[OwnedDiarizationPipeline] --> C[clone_shared]
C --> H1[Original handle]
C --> H2[Cloned handle]
H1 --> B1[Private segmentation and embedding buffers]
H2 --> B2[Private segmentation and embedding buffers]
H1 --> S1[Shared segmentation sessions]
H2 --> S1
H1 --> S2[Shared embedding sessions]
H2 --> S2
S1 --> M1[Arc Mutex Session]
S2 --> M2[Arc Mutex Session]
H1 --> D1[Deep-cloned PLDA, powerset, and config]
H2 --> D2[Deep-cloned PLDA, powerset, and config]
Reviews (1): Last reviewed commit: 237800a | Re-trigger Greptile |
Ports #10 onto the current typed execution plan and lazy CoreML session layout.
Changes
OwnedDiarizationPipeline::clone_sharedfor non-CoreML buildsNative CoreML sessions keep their current lazy ownership and are not exposed through
clone_shared.Verification
cargo fmt --all -- --checkcargo test --test end_to_end shared_pipeline_handles_match_when_run_concurrentlyspeakrsintegration tests passed, with one existing ignored online testcargo clippy --workspace --all-targets --features "cuda migraphx load-dynamic _metrics" -- -D warningscargo check --all-targets --features "cuda migraphx load-dynamic _metrics"Two unchanged
xtaskdataset-copy tests fail locally on a missing temporary source file, including when one failing test runs alone.Closes #10.