Add Windows AI developer setup workloads - #98

Summary

• replace AI winget configure acquisition with PR Add a resumable PowerShell setup flow for Windows developer machines #93-style resumable PowerShell check → apply → verify flows
• keep independent cuda, rocm, intel-ai, foundry, pytorch, llama.cpp, and ollama entry points
• make PyTorch self-contained for CPU, NVIDIA CUDA, AMD ROCm, and Intel XPU, with deterministic mixed-GPU selection and vendor-appropriate Triton
• resolve official backend-specific llama.cpp releases for NVIDIA CUDA, AMD ROCm, Intel SYCL/OpenVINO, Qualcomm Adreno OpenCL, Vulkan, and CPU instead of representing all x64 systems with the WinGet Vulkan package
• require llama.cpp's official backends JSON field plus actual offloaded X/Y layers diagnostics; requested -ngl is not accepted as hardware proof
• add non-mutating plans, structured JSON reports, centralized provider/promotion metadata, and portable partner validation commands

Dependency

Depends on #93 and intentionally targets user/amelbawa/dev-config-2, not main.

Acquisition and vendor layers

AI workloads no longer contain configuration.winget files. Their PowerShell entry points reuse the Windows Dev Config WinGet, retry, PATH, elevation, and bounded-process contracts through src/Workloads/_common/direct-setup.ps1.

CPU architecture and GPU vendor are independent axes. ARM64 is not a GPU vendor: the validated N1X host is Windows ARM64 with NVIDIA RTX Spark. AMD ROCm and Intel XPU/oneAPI currently publish native Windows x64 artifacts only.

Every flow inventories the host, resolves a supported provider, supports -PlanOnly, checks current state, installs/upgrades only the selected stack, executes a real workload, and writes a report conforming to src/docs/ai-workload-report.schema.json.

GPU drivers are validated prerequisites and are not installed or replaced by these flows.

Quick installation mechanics

Hardware matrix

PyTorch -Backend Auto priority is supported NVIDIA CUDA → supported AMD ROCm → supported Intel XPU → CPU. llama.cpp -Backend Auto priority is supported NVIDIA CUDA → supported AMD ROCm → supported Intel SYCL → Qualcomm Adreno OpenCL → x64 Vulkan → CPU. Explicit selections target secondary adapters and fail actionably when incompatible.

Known vendor gaps and boundaries

Auto priority is deterministic and an explicit backend can select a supported secondary vendor. Same-vendor targeting is exposed through CUDA/ROCm and explicit-backend PyTorch -DeviceIndex, llama.cpp -Device, OpenVINO -OpenVinoDeviceId, and oneAPI -SyclDeviceSelector. PyTorch Auto intentionally requires index 0. Foundry and Ollama are source-managed and report actual device/allocation rather than claiming a selector. GPU drivers are reportable preconditions; flows fail with remediation but do not replace them.

Code path readiness before hardware testing

ai-catalog.psd1::CapabilityMatrix is executable: the shared test invokes every implemented/source-managed resolver fixture and checks acquisition metadata, probe existence, report contract, and partner command. Upstream-unavailable cells are the only non-implemented cells and return cataloged actionable blockers.

Current → stable acquisition and promotion report

Metadata is centralized in src/Workloads/_common/ai-catalog.psd1; moving a qualified preview/rolling provider to a normal channel is a resolver/data change.

Real-hardware acceptance

Validated on Windows 11 ARM64 build 28120, NVIDIA RTX Spark N1X, driver 616.62, CUDA UMD 13.4, compute capability 12.1:

CUDA and PyTorch ARM64 remain developer previews; this qualifies the tested N1X configuration and is not a production-support claim. The current llama resolver preserves the same official b10883 CUDA 13.4 pair and acceptance logic, adds explicit -ngl 999, cache/digest metadata, and atomic installation; no expensive N1X model rerun was performed for this resolver-only update.

Lightweight acceptance was rerun after adding explicit adapter selection: the
indexed CUDA kernel executed on device 0
NVIDIA RTX Spark N1X (5120-core Blackwell RTX GPU), the indexed PyTorch CUDA
tensor reported torch 2.15.0.dev20260904+cu134 / CUDA 13.4 / NumPy 2.5.2,
and indexed Triton vector-add JIT executed on the same device. The reusable
llama probe reran inference plus verbose benchmark validation, read the official
backends=CUDA and gpu_info fields, and parsed offloaded 29/29 layers to GPU. The final elevated ARM64 Ollama acceptance launched runtime 0.34.0 on
resolver-owned http://127.0.0.1:65364, verified the qwen3:0.6b digest,
completed real inference, and reported 100% GPU through /api/ps. A live
Foundry report probe selected CPUExecutionProvider, marked truthful CPU
fallback, and retained WebGPU/NvTensorRT/CUDA providers only as observed
registration attempts. The final Ollama report and console log were retained
as n1x-final-ollama.json and n1x-final-ollama.log.

Partner commands and remaining hardware gaps

Checkout the qualified PR head:

gh pr checkout 98 --repo microsoft/WindowsDeveloperConfig
$ExpectedHead = gh pr view 98 --repo microsoft/WindowsDeveloperConfig `
  --json headRefOid --jq .headRefOid
if ((git rev-parse HEAD).Trim() -ne $ExpectedHead) {
  throw "PR #98 checkout does not match published head $ExpectedHead."
}

The workload implementation was qualified at ec7fc5e; later commits may be
documentation-only. Always use the live PR head selected above.

Git-only fallback:

git fetch https://github.com/Kixantrix/WindowsDeveloperConfig.git `
  mihippel-microsoft-windows-ai-setup-workloads:pr-98
git switch pr-98

Open elevated PowerShell in the repository root:

$ErrorActionPreference = 'Stop'
$ReportRoot = Join-Path $env:TEMP "devconfig-ai-$env:COMPUTERNAME"
New-Item -ItemType Directory -Path $ReportRoot -Force | Out-Null

.\src\tools\collect-ai-hardware.ps1 `
  -OutputPath "$ReportRoot\hardware.json" *>&1 |
  Tee-Object "$ReportRoot\hardware.console.log"

function Invoke-PartnerFlow {
  param(
    [Parameter(Mandatory)] [string] $Name,
    [Parameter(Mandatory)] [string] $Script,
    [string[]] $Arguments = @()
  )
  $planPath = Join-Path $ReportRoot "$Name-plan.json"
  $finalPath = Join-Path $ReportRoot "$Name-final.json"
  & $Script @Arguments -PlanOnly -ReportPath $planPath *>&1 |
    Tee-Object (Join-Path $ReportRoot "$Name-plan.console.log")
  $plan = Get-Content $planPath -Raw | ConvertFrom-Json
  if ($plan.result.blockers.Count) {
    throw "$Name blocked: $($plan.result.blockers -join '; ')"
  }
  & $Script @Arguments -ReportPath $finalPath *>&1 |
    Tee-Object (Join-Path $ReportRoot "$Name-final.console.log")
  $final = Get-Content $finalPath -Raw | ConvertFrom-Json
  if (-not $final.result.ready) {
    throw "$Name did not produce result.ready=true."
  }
}

# NVIDIA Windows x64
Invoke-PartnerFlow nvidia-cuda .\src\Workloads\cuda\install.ps1
Invoke-PartnerFlow nvidia-pytorch .\src\Workloads\pytorch\install.ps1 `
  @('-Backend', 'CUDA', '-RequireTriton')
Invoke-PartnerFlow nvidia-llama .\src\Workloads\llama.cpp\install.ps1 `
  @('-Backend', 'CUDA')

# AMD Windows x64
Invoke-PartnerFlow amd-pytorch .\src\Workloads\pytorch\install.ps1 `
  @('-Backend', 'ROCm')
Invoke-PartnerFlow amd-hip .\src\Workloads\rocm\install.ps1
Invoke-PartnerFlow amd-llama .\src\Workloads\llama.cpp\install.ps1 `
  @('-Backend', 'ROCm')

# Intel Windows x64 GPU
Invoke-PartnerFlow intel-pytorch-xpu .\src\Workloads\pytorch\install.ps1 `
  @('-Backend', 'XPU', '-RequireTriton')
Invoke-PartnerFlow intel-openvino-gpu .\src\Workloads\intel-ai\install.ps1 `
  @('-Device', 'GPU', '-Profile', 'OpenVINO')
Invoke-PartnerFlow intel-full-gpu .\src\Workloads\intel-ai\install.ps1 `
  @('-Device', 'GPU', '-Profile', 'Full')
Invoke-PartnerFlow intel-llama-sycl .\src\Workloads\llama.cpp\install.ps1 `
  @('-Backend', 'SYCL')
Invoke-PartnerFlow intel-llama-openvino .\src\Workloads\llama.cpp\install.ps1 `
  @('-Backend', 'OpenVINO')

# Intel Windows x64 NPU (not XPU/SYCL)
Invoke-PartnerFlow intel-openvino-npu .\src\Workloads\intel-ai\install.ps1 `
  @('-Device', 'NPU', '-Profile', 'OpenVINO')

# Qualcomm/Adreno Windows ARM64
Invoke-PartnerFlow qualcomm-llama .\src\Workloads\llama.cpp\install.ps1 `
  @('-Backend', 'OpenCL')
Invoke-PartnerFlow qualcomm-foundry .\src\Workloads\foundry\install.ps1

Foundry is source-managed: Qualcomm validation records the actual EP/fallback
and does not require accelerator selection. Return the entire $ReportRoot
directory plus reboot requested/performed status.

Success is not INSTALL_OK. Each final report must have
result.ready=true, no blockers, and acceptance evidence for the intended
device/backend.

Remaining live gaps are AMD x64 PyTorch ROCm + native HIP + llama ROCm, Intel x64 PyTorch XPU/compile + OpenVINO/SYCL + llama SYCL/OpenVINO, NVIDIA x64 llama CUDA 13.3/12.4, and Qualcomm ARM64 llama OpenCL/Adreno.

Validation

• 1,314 hardware-independent assertions pass across shared/CUDA/ROCm/Intel/Foundry/PyTorch/llama/Ollama suites
• the executable capability matrix covers 30 implemented/source-managed cells and 9 explicit upstream-unavailable boundaries
• all source PowerShell parses; all Python smoke scripts compile
• all seven -PlanOnly flows complete and reports validate against the checked-in JSON schema
• all ten llama b10883 Windows backend asset patterns match exactly one official asset with a GitHub SHA-256 digest
• PyTorch tests cover exact ROCm/XPU tuples, self-contained toolkit separation, mixed-adapter priority/fallback, ARM64 rejection, smoke record parsing, and disabled Triton semantics
• llama tests cover every backend/architecture, CUDA runtime choice and paired-asset completeness, mixed-GPU priority/explicit selection, unsupported requests, digest cache/idempotence, and backend/device/GPU-layer evidence
• git diff --check passes

Hardware-dependent flows remain manual_test in hosted CI.