Local AI: allow setup on busy GPUs and handle model-load OOM at use time

Problem

A supported GPU that is temporarily occupied by another application can block Local AI installation before downloads begin. Setup tells the user to close GPU applications and retry setup. Download and installation should depend on hardware capabilities and total usable GPU capacity; temporary memory pressure should be handled when the user actually runs Local AI.

Release context: requested ahead of the upcoming RTX Spark drop.

Confirmed code path

Reviewed commit: 621f4100f8b40ac84e844bcc39b01fe03a2238bb. The reporter's exact app version and a live reproduction of their machine are not established.

1. LocalInferenceSelector already selects the model/profile using total GPU capacity and CUDA compatibility. Its memory estimate includes weights, main/draft KV caches, and runtime workspace. Free memory does not downgrade the recommendation.
2. LocalInferenceEligibility explicitly allows EligibleButBusy through CanInstall.
3. CapabilitiesPage instead requires strictly Eligible, disables Continue with Local AI enabled, and displays "Close GPU applications and retry setup." The wizard caches the hardware snapshot; its Recheck control is only shown for unknown hardware, so freeing VRAM does not automatically unblock this page.
4. PreflightLocalAiHardwareStep takes a fresh reading and independently returns a terminal failure for EligibleButBusy, before runtime/model downloads.
5. SetupPipeline later starts the empty router, captures a GPU baseline, forces a test inference/model load, and verifies GPU placement. Removing only the two early gates would still allow temporary memory pressure to fail setup after downloads.

Current post-setup failure UX

• Normal inference loads the model on demand. The Companion has no dedicated load-time OOM recovery UX.
• A gateway lifecycle error becomes a generic red Chat status message using the upstream summary/message, or "Agent error". The turn ends and Send becomes available, but the error has no Retry action. See mapping and rendering.
• If the router survives and reports the model as unloaded, the Local AI page can still show Running / Downloaded and verified. Router health does not describe the failed model load.
• Router process crashes have bounded automatic router restart; this does not replay the failed inference. The detailed OOM log capture/reset currently discussed in setup belongs to setup's verification path.
• Exact gateway OOM wording and successful subsequent model reload have not been verified end to end.

Expected behavior and acceptance criteria

• Supported hardware with low free VRAM retains the same recommended model/profile and can select Local AI, continue, download, and finish setup.
• Remove the free-VRAM rejection from setup UI/preflight. Keep total-capacity, CUDA/runtime compatibility, required hardware facts, download integrity, and configuration checks.
• Setup completes without requesting model inference or requiring successful GPU model loading. Remove CaptureLocalAiGpuBaselineStep, VerifyLocalAiInferenceStep, and VerifyLocalAiGpuLoadStep from the mandatory installation path. Preserve their useful coverage as explicit diagnostics/developer or release validation.
• Keep empty-router health, registered model/path checks, WSL reachability, gateway configuration, and ownership checks. Completion copy accurately describes installation/router readiness rather than claiming successful inference.
• On actual use, a confirmed GPU OOM produces clear guidance such as "Not enough GPU memory is available to load this model. Close other GPU applications and try again." Keep installed artifacts and the selected model/profile intact; no setup restart or redownload is required.
• Provide an explicit recovery action for the failed load/request. It must target the correct session/model, avoid duplicate submissions, and avoid automatically replaying completed agent/tool work. Validate the gateway retry contract before choosing direct retry versus restoring the failed prompt for user-controlled resubmission.
• Track recoverable model-load failure separately from router health so a healthy empty router cannot erase the failure. Clear it on an appropriate successful load/recovery.
• Classify OOM only from evidence belonging to the current managed model/load attempt. Stale logs, generic HTTP 500 responses, host-RAM allocation failures, and unrelated CUDA/driver faults must not be mislabeled as GPU OOM. Preserve an actionable generic failure when evidence is inconclusive.
• Freeing GPU memory allows successful inference with the same installed model and profile. Memory becoming constrained after setup also follows this recovery path.

Validation and proof plan

Current evidence: the existing filtered LocalInferenceQualificationTests suite passed, 51 tests, 0 failures, 0 skips. No implementation changes, full build, or live OOM/UI reproduction were performed during this review.

For implementation, add focused regression tests alongside each change for busy/idle selection parity, UI/preflight admission, setup finishing with an unloaded model, retained integrity checks, load-error classification, stale-error isolation, and retry behavior. Run the required full build plus Shared and Tray tests, and affected SetupEngine and Connection tests. Run the required MXC setup/connect validation when exercising the changed gateway setup/connect E2E path.

Collect current-head isolated UI and real Gateway-to-local-model proof: install while GPU memory is occupied; finish with the model unloaded; trigger a reviewed load failure; show recovery guidance; free memory; successfully retry without reinstalling. A fake error proves presentation/classification only, not actual CUDA OOM recovery. Include rubber-duck review before PR publication.

Applicable proof pools: windows-wsl-dgx-blackwell, windows-winui-interactive, and windows-wsl-gateway-e2e; include windows-11-arm64 for native RTX Spark ARM64 release proof, and windows-wsl-mxc for the required setup/connect MXC E2E path. Record unavailable hardware/dependencies as Not verified / blocked.

Related

• #1242 tracks an intermittent Spark CUDA warm-up crash and distinguishes GPU OOM, host-memory allocation failure, and driver/runtime faults. This issue changes installation policy and recovery UX; it does not establish a fix for those underlying faults.
• #1276 records the earlier problem of failed setup verification leaving confusing installed/runtime state. Preserve the distinction between downloaded-and-verified artifacts, router health, and successful model loading.

Start with the existing filtered LocalInferenceQualificationTests, then trace CapabilitiesPage.xaml.cs, LocalAiSetupSteps.cs, SetupPipeline.cs, ChatEventMapper.cs, and ReactorChatTimeline.cs. Confirm which setup checks remain required and how gateway load failures are reported. Done means busy GPUs can finish installation without model loading, verified OOM recovery is actionable without redownloading, and focused tests cover admission, classification, stale errors, and retry behavior.