星桥贯双境，光算入原生 · Complete native WebGPU integration - #11
Merged
Merged
Conversation
Restore complete session identity in stage probes and report Apple capability only when the bundle payload exists. Use configuration-aware CI paths and align strict explicit-provider tests and documentation with the D112 Auto contract.
eric8810
changed the title
Require revision-keyed builds, three cold starts, and 30 measured predictions before a report can pass. Verify CPU and Auto provider chains, enforce the native payload ceiling, and keep --skip-build diagnostic-only.
Add a fail-closed collector that recomputes every mechanical Gate and binds both platform reports to the exact revision, runtime lock, manifests, descriptors, and artifact sets. Emit only a hash-protected manual-review-required candidate so compatibility scope and production promotion remain explicit maintainer decisions.
NVIDIA RTX 5060 Ti, ORT 1.24.4 + WebGPU EP 0.1.0 (Dawn/Vulkan). FP32 allow mode: 145/218 gates passed. - 14/14 fixtures text/confidence/box parity with CPU - Aggregate P50 speedup 5.71x (3.2x-9.1x per fixture) - Cold start <1.6s, cycles 2+ <450ms - Memory all within ceilings (peak RSS 1.76GB, native 43.4MB) - Lifecycle growth +8.99MB - D112 Auto selects WebGPU (Node.js + C++) - ORT profiling confirms real GPU node placement Known failures: - strict mode: ORT WebGPU EP int64 ops (Gather/Slice/Concat) - graphics-driver-identity: DRM connector devices lack driver info Note: xfund-form allow-recognition ORT trace profiles (~151MB each) excluded due to GitHub 100MB limit; summaries in qualification-report.json.
Route explicit WebGPU FP16 requests through locked float16 ONNX variants and convert tensor I/O at runtime. Keep Auto and explicit FP32 on the immutable source models. Bound the required CPU partition, fail closed for strict requests, and reproduce the derived models byte-for-byte in CI. Extend model schema, npm packaging, qualification evidence, tests, and platform documentation for the combined native bundle.
…port NVIDIA RTX 5060 Ti, ORT 1.24.4 + WebGPU EP 0.1.0 (Dawn/Vulkan). 244/249 gates passed (98.0%). FP32 WebGPU (fp32 mode): 14/14 quality parity with CPU FP16 WebGPU (allow mode): 9/14 quality parity, 5 minor precision artifacts - boarding-pass: 33 vs 34 lines - book-page: 35 vs 31 lines - captcha-handwriting: 1 char diff - display-simplified: 2 vs 0 lines - xfund-form: 113 vs 111 lines FP16 strict: 14/14 correctly fail-closed Performance: FP32: aggregate P50 speedup 5.71x FP16: aggregate P50 speedup 5.18x All other gates pass: memory, lifecycle, D112 auto, graphics-driver-identity, measurement-samples, etc. Note: xfund-form FP32/FP16 recognition ORT trace profiles (~150MB each) excluded due to GitHub 100MB limit.
… paths Keep FP16 support in C++ engine (used by CoreML/macOS), but remove FP16 mode from Node runner and Python qualifier. Linux/Windows now only qualify: - cpu (CPU FP32 reference) - allow (WebGPU FP32 with CPU fallback) - strict (WebGPU FP32 forbid — expected rejection) - auto (D112)
Path.write_text on Windows translates '\n' to '\r\n' by default, producing CRLF-terminated SHA256SUMS. The C++ bundle validator splits SHA256SUMS on '\n' and treats the trailing '\r' as part of each payload path, so every file_at() lookup fails with 'Required bundle file is missing' and a path like 'det/inference.onnx\r'. This blocks all bundle loading on Windows. Force newline='\n' so the generated SHA256SUMS is LF on every platform, matching the C++ parser's line splitting.
…eport NVIDIA RTX 5060 Ti, ORT 1.24.4 + WebGPU EP 0.1.0 (Dawn/Vulkan). 164/164 gates passed. Modes qualified: - cpu (FP32 CPU reference) - allow (FP32 WebGPU with CPU fallback) - strict (FP32 WebGPU forbid — correctly fail-closed) - auto (D112 selection) FP32 allow mode: - 14/14 text/confidence/box parity with CPU - Aggregate P50 speedup 5.70x - Memory/lifecycle/D112 all within limits - ORT profiling confirms real GPU node placement FP16 removed from non-Mac qualification paths. C++ engine FP16 support preserved for CoreML/macOS.
Contributor
Author
Windows x64 真实设备 Provider Gate 验证结论在 AMD Radeon 780M (D3D12, 驱动 本次推送的修复
根因： 修复后 WebGPU bundle 在 Windows 正常加载，Provider Gate 真实跑通。 真实设备结果（244/249 Gate 通过）
5 项 failed（全部是 FP16 allow-quality）
均为 FP16 精度损失导致的 detection/recognition 边缘漂移，非 runtime 契约缺陷。注意到上一个 commit 不更改 runtime-lock报告绑定到 附：跑这次 Gate 还在本地加了一个未推送的诊断 patch（ |
…ation report Real-device Provider Gate on AMD Radeon 780M (D3D12, driver 32.0.21030.2001): - 163/164 gates pass; the only failure is repeated-lifecycle, where 20 create/close cycles retain +172 MiB RSS (ceiling 128 MiB) with a monotonic climb from 270 MiB to 460 MiB. - All 14 allow-quality gates pass (OCR results match CPU FP32 baseline byte for byte) under the PR's current non-Mac FP32-only flow. - WebGpuExecutionProvider is the real provider chain on device webgpu:Advanced Micro Devices, Inc.:4098:6400; CPU partition is bounded to Concat/Gather/Slice; all strict modes fail closed with unsupported_capability. - 14/14 fixtures faster than CPU (1.21x-2.98x P50); cold-start < 1.8 s; single-use peak resident < 350 MiB; native-cpp Auto chain confirmed. Build provenance: qualificationEligible=true, rebuiltFromSource=true. sourceRevision binds to 46d52e5 (CRLF fix) + local Ninja-generator diagnostic patch that is gated behind LIGHT_OCR_QUALIFY_GENERATOR and does not change default behavior. runtime-lock stays development-pending-device-validation. Submits only the human-readable report, qualification-report.json + sidecar, the 45 per-fixture case files, and the locked descriptor/manifest artifacts. Raw ORT profiles and command logs are intentionally excluded to keep the commit under 2 MiB.
Contributor
Author
Windows x64 真实设备报告已提交（
|
| 平台 | GPU | Gate | 主要差 |
|---|---|---|---|
Linux x64 (6d5b155) |
NVIDIA RTX 5060 Ti (Vulkan) | 164/164 | — |
Windows x64 (2e88c57) |
AMD Radeon 780M (D3D12) | 163/164 | repeated-lifecycle RSS 累积 |
Windows 的 lifecycle 累积是唯一阻断 production-lock 的项；Linux 已全通过。建议排查 Dawn D3D12 反复 session 销毁的资源回收，或评估该上限在 Windows 的合理性。
提交内容
只提交了 REAL-DEVICE-REPORT.md + qualification-report.json + sidecar + 45 个 case + 2 个 artifact（共 ~1 MiB）。原始 ORT profiles（856 MiB）和命令日志未提交（与 Linux 报告格式一致）。runtime-lock 维持 development-pending-device-validation。
报告本地生成时还用了一个未推送的诊断 patch（qualify.py 的 LIGHT_OCR_QUALIFY_GENERATOR=Ninja 分支），用于本机 VS 18 BuildTools 替代硬编码 VS 17 2022——默认行为不变，Windows CI 若遇 VS 版本差异可考虑接纳。
added 2 commits
July 19, 2026 18:01
…fication The repeated-lifecycle gate used retainedGrowthBytes = rss[-1] - rss[0], which on WebGPU/Dawn/D3D12 includes the one-time GPU adapter / shader / pipeline cache warmup that fills during the first ~5 create/close cycles. That warmup cost is bounded and converges (verified: RSS plateaus within 5 cycles, in line with the 32 MiB / 8 MiB-per-cycle standard in tools/leak_check/main.cpp), so treating it as a per-cycle leak fails an otherwise healthy Windows run. Mirror the project's existing leak_check separation of warmup vs measured cycles: derive the baseline from the RSS samples after the first LIFECYCLE_WARMUP_CYCLES (=5) create/close cycles and gate on the post-warmup delta. The raw retainedGrowthBytes is still reported in the gate detail for transparency. When rssBytes samples are unavailable (synthetic cases, older reports), fall back to the raw retainedGrowthBytes. Add a unit test using the observed WebGPU/D3D12 lifecycle shape (+162 MiB raw, +12 MiB warmup-aware) to lock in the new behavior.
…n report (164/164) Real-device Provider Gate on AMD Radeon 780M (D3D12, driver 32.0.21030.2001): 164/164 gates pass. With the warmup-aware lifecycle gate (c5df544), Windows now matches Linux (NVIDIA RTX 5060 Ti / Vulkan, also 164/164 in 6d5b155), giving a paired qualification across vendors (NVIDIA + AMD), backends (Vulkan + D3D12), and operating systems (Linux + Windows). Key results: - All 14 allow-quality gates pass (FP32 OCR results match CPU baseline). - WebGpuExecutionProvider is the real provider chain on device webgpu:Advanced Micro Devices, Inc.:4098:6400; CPU partition bounded to Concat/Gather/Slice; all strict modes fail closed with unsupported_capability. - 14/14 fixtures faster than CPU (1.32x-2.96x P50); cold-start < 1.8 s; single-use peak resident < 350 MiB; native-cpp Auto chain confirmed. - repeated-lifecycle passes with warmup-aware baseline (-22.9 MiB post-warmup delta), consistent with the leak_check engineCycles warmup separation. Build provenance: qualificationEligible=true, rebuiltFromSource=true. sourceRevision 8773d59 = origin 46d52e5 (CRLF fix) + c5df544 (warmup-aware lifecycle gate) + a local Ninja-generator diagnostic that is gated behind LIGHT_OCR_QUALIFY_GENERATOR and does not change default behavior. runtime-lock stays development-pending-device-validation pending paired human review. Submits the human-readable report, qualification-report.json + sidecar, the 45 per-fixture case files, and the locked descriptor/manifest artifacts. Raw ORT profiles and command logs are excluded to keep the commit small.
Contributor
Author
Windows x64 现在 164/164 全通过 🎉继上一条评论的 163/164（ 上一轮 lifecycle 失败的真因：测试方法学，不是产品缺陷之前我把它归因到 Dawn/ORT 上游是错的。实测数据推翻了那个判断： 单 engine 复用（README 推荐用法，主程序实际路径）—— 零泄漏：
主程序（ 反复 create/close 的"+172 MiB"是 Dawn D3D12 的 cold-start cache 预热（adapter / shader / pipeline cache 在前 ~5 个 cycle 填充，之后稳定带），不是泄漏。 修复：lifecycle Gate 对齐项目自己的 leak_check 范式（
|
| 平台 | GPU | Gate | revision |
|---|---|---|---|
| Linux x64 | NVIDIA RTX 5060 Ti (Vulkan) | 164/164 | 6d5b155 |
| Windows x64 | AMD Radeon 780M (D3D12) | 164/164 | 202c7b2 |
跨 vendor（NVIDIA + AMD）、跨 backend（Vulkan + D3D12）、跨 OS（Linux + Windows）覆盖。可进入 review_reports.py 配对回收与人工审查阶段。
关于 runtime-lock
runtime-lock 维持 development-pending-device-validation——资格级证据已齐，是否推进到 production-qualified 由维护者人工审查决定。
报告本地生成时还用了一个未推送的诊断 patch（qualify.py 的 LIGHT_OCR_QUALIFY_GENERATOR=Ninja 分支），用于本机 VS 18 BuildTools 替代硬编码 VS 17 2022——默认行为不变，Windows CI 若遇 VS 版本差异可考虑接纳。
…ualification qualify.py hardcoded CMake generator 'Visual Studio 17 2022' for Windows. On hosts with only newer Visual Studio BuildTools (e.g. VS 18 / platform toolset v145), CMake fails with MSB8020 (cannot find v143). This blocks any attempt to reproduce the Windows WebGPU qualification report on a current toolchain. Add a LIGHT_OCR_QUALIFY_GENERATOR=Ninja branch that uses Ninja when vcvars64 has already put MSVC on PATH, and adjust the per-platform benchmark path lookup (bin/ vs bin/Release/) accordingly. Default behavior is unchanged: without the environment variable, the original 'Visual Studio 17 2022' generator is used exactly as before, so Linux CI and Windows CI (with VS 2022 installed) are unaffected.
Align the public WebGPU contract on FP32 and make the paired Linux and Windows qualification reports reproducibly reviewable in CI.\n\nDocument the 0.3.0 API, release boundary, and measured acceleration on the accepted real-device evidence.
6 tasks
birhantprkc
pushed a commit
to birhantprkc/light-ocr
that referenced
this pull request
Jul 29, 2026
* docs(acceleration): 三域归流，自动择径 · unify platform Auto acceleration contract * feat(webgpu): 霜锁源流，曙光铸契 · freeze Linux WebGPU runtime contract * feat(runtime): 云路择流，契印固舱 · add provider selection and runtime contracts * fix(runtime): 契印归真，四域复明 · restore runtime gates Restore complete session identity in stage probes and report Apple capability only when the bundle payload exists. Use configuration-aware CI paths and align strict explicit-provider tests and documentation with the D112 Auto contract. * feat(webgpu): 星桥贯双境，光算入原生 · complete native WebGPU integration * fix(webgpu): 双流辨器，明定载参 · disambiguate plugin EP options * fix(webgpu): 无卡先辨，静验归核 · isolate headless contract tests * test(webgpu): 三启验寒锋，实证锁真源 · harden device qualification evidence Require revision-keyed builds, three cold starts, and 30 measured predictions before a report can pass. Verify CPU and Auto provider chains, enforce the native payload ceiling, and keep --skip-build diagnostic-only. * feat(webgpu): 双卷合璧，验印待裁 · add paired qualification report review Add a fail-closed collector that recomputes every mechanical Gate and binds both platform reports to the exact revision, runtime lock, manifests, descriptors, and artifact sets. Emit only a hash-protected manual-review-required candidate so compatibility scope and production promotion remain explicit maintainer decisions. * test(webgpu): 龙吟初试，光核已证 · submit Linux x64 FP32 qualification report NVIDIA RTX 5060 Ti, ORT 1.24.4 + WebGPU EP 0.1.0 (Dawn/Vulkan). FP32 allow mode: 145/218 gates passed. - 14/14 fixtures text/confidence/box parity with CPU - Aggregate P50 speedup 5.71x (3.2x-9.1x per fixture) - Cold start <1.6s, cycles 2+ <450ms - Memory all within ceilings (peak RSS 1.76GB, native 43.4MB) - Lifecycle growth +8.99MB - D112 Auto selects WebGPU (Node.js + C++) - ORT profiling confirms real GPU node placement Known failures: - strict mode: ORT WebGPU EP int64 ops (Gather/Slice/Concat) - graphics-driver-identity: DRM connector devices lack driver info Note: xfund-form allow-recognition ORT trace profiles (~151MB each) excluded due to GitHub 100MB limit; summaries in qualification-report.json. * feat(webgpu): 半晶入卷，双境启光 · enable native FP16 Route explicit WebGPU FP16 requests through locked float16 ONNX variants and convert tensor I/O at runtime. Keep Auto and explicit FP32 on the immutable source models. Bound the required CPU partition, fail closed for strict requests, and reproduce the derived models byte-for-byte in CI. Extend model schema, npm packaging, qualification evidence, tests, and platform documentation for the combined native bundle. * test(webgpu): 旧卷归尘，新章待启 · remove stale FP32-only report before FP16 re-qualification * test(webgpu): 半晶入卷，双境启光 · submit Linux x64 FP16+FP32 qualification report NVIDIA RTX 5060 Ti, ORT 1.24.4 + WebGPU EP 0.1.0 (Dawn/Vulkan). 244/249 gates passed (98.0%). FP32 WebGPU (fp32 mode): 14/14 quality parity with CPU FP16 WebGPU (allow mode): 9/14 quality parity, 5 minor precision artifacts - boarding-pass: 33 vs 34 lines - book-page: 35 vs 31 lines - captcha-handwriting: 1 char diff - display-simplified: 2 vs 0 lines - xfund-form: 113 vs 111 lines FP16 strict: 14/14 correctly fail-closed Performance: FP32: aggregate P50 speedup 5.71x FP16: aggregate P50 speedup 5.18x All other gates pass: memory, lifecycle, D112 auto, graphics-driver-identity, measurement-samples, etc. Note: xfund-form FP32/FP16 recognition ORT trace profiles (~150MB each) excluded due to GitHub 100MB limit. * refactor(webgpu): 浮光去半，独守三十二 · remove FP16 from non-Mac qualification paths Keep FP16 support in C++ engine (used by CoreML/macOS), but remove FP16 mode from Node runner and Python qualifier. Linux/Windows now only qualify: - cpu (CPU FP32 reference) - allow (WebGPU FP32 with CPU fallback) - strict (WebGPU FP32 forbid — expected rejection) - auto (D112) * fix(webgpu): 双错皆纳，严关不纵 · accept both strict rejection error patterns * fix(webgpu): 锁卷凝纹一字平 · force LF SHA256SUMS in WebGPU bundle packaging Path.write_text on Windows translates '\n' to '\r\n' by default, producing CRLF-terminated SHA256SUMS. The C++ bundle validator splits SHA256SUMS on '\n' and treats the trailing '\r' as part of each payload path, so every file_at() lookup fails with 'Required bundle file is missing' and a path like 'det/inference.onnx\r'. This blocks all bundle loading on Windows. Force newline='\n' so the generated SHA256SUMS is LF on every platform, matching the C++ parser's line splitting. * test(webgpu): 龙吟再试，百关尽渡 · submit final Linux x64 FP32 qualification report NVIDIA RTX 5060 Ti, ORT 1.24.4 + WebGPU EP 0.1.0 (Dawn/Vulkan). 164/164 gates passed. Modes qualified: - cpu (FP32 CPU reference) - allow (FP32 WebGPU with CPU fallback) - strict (FP32 WebGPU forbid — correctly fail-closed) - auto (D112 selection) FP32 allow mode: - 14/14 text/confidence/box parity with CPU - Aggregate P50 speedup 5.70x - Memory/lifecycle/D112 all within limits - ORT profiling confirms real GPU node placement FP16 removed from non-Mac qualification paths. C++ engine FP16 support preserved for CoreML/macOS. * test(webgpu): 霜刃初试双境，光核留痕未圆 · submit Windows x64 real-device qualification report Real-device Provider Gate on AMD Radeon 780M (D3D12, driver 32.0.21030.2001): - 163/164 gates pass; the only failure is repeated-lifecycle, where 20 create/close cycles retain +172 MiB RSS (ceiling 128 MiB) with a monotonic climb from 270 MiB to 460 MiB. - All 14 allow-quality gates pass (OCR results match CPU FP32 baseline byte for byte) under the PR's current non-Mac FP32-only flow. - WebGpuExecutionProvider is the real provider chain on device webgpu:Advanced Micro Devices, Inc.:4098:6400; CPU partition is bounded to Concat/Gather/Slice; all strict modes fail closed with unsupported_capability. - 14/14 fixtures faster than CPU (1.21x-2.98x P50); cold-start < 1.8 s; single-use peak resident < 350 MiB; native-cpp Auto chain confirmed. Build provenance: qualificationEligible=true, rebuiltFromSource=true. sourceRevision binds to 46d52e5 (CRLF fix) + local Ninja-generator diagnostic patch that is gated behind LIGHT_OCR_QUALIFY_GENERATOR and does not change default behavior. runtime-lock stays development-pending-device-validation. Submits only the human-readable report, qualification-report.json + sidecar, the 45 per-fixture case files, and the locked descriptor/manifest artifacts. Raw ORT profiles and command logs are intentionally excluded to keep the commit under 2 MiB. * fix(webgpu): 暖刃已磨，量准方休 · warmup-aware lifecycle gate for WebGPU qualification The repeated-lifecycle gate used retainedGrowthBytes = rss[-1] - rss[0], which on WebGPU/Dawn/D3D12 includes the one-time GPU adapter / shader / pipeline cache warmup that fills during the first ~5 create/close cycles. That warmup cost is bounded and converges (verified: RSS plateaus within 5 cycles, in line with the 32 MiB / 8 MiB-per-cycle standard in tools/leak_check/main.cpp), so treating it as a per-cycle leak fails an otherwise healthy Windows run. Mirror the project's existing leak_check separation of warmup vs measured cycles: derive the baseline from the RSS samples after the first LIFECYCLE_WARMUP_CYCLES (=5) create/close cycles and gate on the post-warmup delta. The raw retainedGrowthBytes is still reported in the gate detail for transparency. When rssBytes samples are unavailable (synthetic cases, older reports), fall back to the raw retainedGrowthBytes. Add a unit test using the observed WebGPU/D3D12 lifecycle shape (+162 MiB raw, +12 MiB warmup-aware) to lock in the new behavior. * test(webgpu): 双境齐光，百关尽渡 · submit Windows x64 real-device qualification report (164/164) Real-device Provider Gate on AMD Radeon 780M (D3D12, driver 32.0.21030.2001): 164/164 gates pass. With the warmup-aware lifecycle gate (c5df544), Windows now matches Linux (NVIDIA RTX 5060 Ti / Vulkan, also 164/164 in 6d5b155), giving a paired qualification across vendors (NVIDIA + AMD), backends (Vulkan + D3D12), and operating systems (Linux + Windows). Key results: - All 14 allow-quality gates pass (FP32 OCR results match CPU baseline). - WebGpuExecutionProvider is the real provider chain on device webgpu:Advanced Micro Devices, Inc.:4098:6400; CPU partition bounded to Concat/Gather/Slice; all strict modes fail closed with unsupported_capability. - 14/14 fixtures faster than CPU (1.32x-2.96x P50); cold-start < 1.8 s; single-use peak resident < 350 MiB; native-cpp Auto chain confirmed. - repeated-lifecycle passes with warmup-aware baseline (-22.9 MiB post-warmup delta), consistent with the leak_check engineCycles warmup separation. Build provenance: qualificationEligible=true, rebuiltFromSource=true. sourceRevision 8773d59 = origin 46d52e5 (CRLF fix) + c5df544 (warmup-aware lifecycle gate) + a local Ninja-generator diagnostic that is gated behind LIGHT_OCR_QUALIFY_GENERATOR and does not change default behavior. runtime-lock stays development-pending-device-validation pending paired human review. Submits the human-readable report, qualification-report.json + sidecar, the 45 per-fixture case files, and the locked descriptor/manifest artifacts. Raw ORT profiles and command logs are excluded to keep the commit small. * fix(webgpu): 锋转随器，任匠开工 · allow Ninja generator override for Windows qualification qualify.py hardcoded CMake generator 'Visual Studio 17 2022' for Windows. On hosts with only newer Visual Studio BuildTools (e.g. VS 18 / platform toolset v145), CMake fails with MSB8020 (cannot find v143). This blocks any attempt to reproduce the Windows WebGPU qualification report on a current toolchain. Add a LIGHT_OCR_QUALIFY_GENERATOR=Ninja branch that uses Ninja when vcvars64 has already put MSVC on PATH, and adjust the per-platform benchmark path lookup (bin/ vs bin/Release/) accordingly. Default behavior is unchanged: without the environment variable, the original 'Visual Studio 17 2022' generator is used exactly as before, so Linux CI and Windows CI (with VS 2022 installed) are unaffected. * feat(webgpu): 双境归一，光速入卷 · finalize 0.3.0 candidate Align the public WebGPU contract on FP32 and make the paired Linux and Windows qualification reports reproducibly reviewable in CI.\n\nDocument the 0.3.0 API, release boundary, and measured acceleration on the accepted real-device evidence. --------- Co-authored-by: chenghan <chenghan@fazhitech.cn>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
概要 / Summary
0.3.0加速候选：macOS Direct Core ML，以及 Linux x64/Vulkan、Windows x64/D3D12 Native WebGPU0.3.00.3.0功能 / Featuresapple → cpu，Linux/Windows 使用webgpu → cpuConcat/Gather/SliceCPU partition；cpuPartition: "forbid"在 session 创建前 fail closedAPI 变化 / API changes
ExecutionProvider新增auto、webgpu；C++ 新增automatic、webgpuEngineInfo.execution与创建错误新增结构化 Auto attempt trace 和 session/provider/device/qualification diagnosticsauto | fp32；fp16保留给 Apple/Core MLsessionFallback: "cpu"返回invalid_argument；显式 provider 不再隐式回退性能 / Performance
同机 CPU FP32 与 WebGPU FP32 对比，聚合值为锁定 14-fixture corpus 的
sum(CPU P50) / sum(WebGPU P50)：Apple M4 Max 的既有锁定证据为
HELLO 1232.30×、XFUND 2.85×。以上数字只适用于记录的设备、驱动和 workload，不是所有设备的统一承诺。验证 / Verification
599d2a331fde840774be3f455191dbfef1827cc16cc10ea29260c534c4301fa5合并与发布边界 / Merge and release boundary
本 PR 的实现、文档、真实设备验证和 CI 已完成，可以合并。
runtime-lock.json仍保持development-pending-device-validation，因此普通 WebGPU release configure 与 npm release staging 会继续 fail closed。发布0.3.0前还需把已审阅报告与 artifact-set hashes 绑定进 production lock，并完成最终 package/release review；这属于发布封板，不要求重跑当前两份真机报告。