[performance] Add execution profiles and observable accelerator fallback

[eric8810]

Why

Performance tuning has two different product objectives:

1. Minimize wall-clock latency for batch/background work.
2. Preserve CPU capacity for the foreground application while OCR runs.

A single thread-count default cannot express both. Accelerator selection also cannot be considered successful merely because a provider was registered: ONNX Runtime may partition unsupported regions to CPU, and CoreML may place accepted operations on MLCPU rather than GPU/ANE.

The current engine reports CPUExecutionProvider and exposes thread counts, but it does not yet expose a qualified execution policy or enough evidence to distinguish actual hardware execution from fallback.

Evidence

On the 15-page reference PDF, pre-rendered at 200 DPI:

• Current CPU 1-thread / recognition batch 1: ~70.55 s OCR-only.
• CPU 12 intra-op threads / batch 1: ~15.35 s OCR-only.
• Increasing ORT inter-op threads above 1 regressed a page-level test (~0.64 s at intra=12/inter=1 versus ~1.02 s at inter=2 or 4).
• CoreML with the current dynamic models appeared available but compute-plan profiling showed that nearly all work remained on MLCPU.
• Static CoreML GPU probes materially reduced process CPU seconds, which is the relevant metric for the interactive product profile.

These results show why provider name, page time, and thread count must be reported together with CPU consumption, shape policy, cold start, memory, and fallback.

Goal

Define explicit, testable execution profiles and make provider placement/fallback observable per model.

Suggested profile semantics (names are provisional):

• cpu-low-impact: tightly bounded CPU use for foreground coexistence.
• cpu-fast: tuned CPU latency, keeping ORT inter-op at 1 unless benchmarks prove otherwise.
• coreml-gpu: Apple Silicon offload, enabled only after hardware-placement and quality gates pass.
• cpu-throughput: opt-in bounded recognition concurrency for offline/bulk processing.

The library should expose capabilities and accept an explicit policy; the host application remains responsible for choosing an interactive or batch profile.

Acceptance criteria

• Document profile goals, supported platforms, and whether each is stable/experimental.
• Report requested provider and actual session providers separately for detection and recognition.
• Report effective intra/inter-op thread counts, recognition concurrency/batch policy, precision, shape policy, and model-cache status.
• Accelerator modes expose graph partition/compute-plan evidence in diagnostics or a qualification command; silent CPU/MLCPU fallback emits a structured warning or error according to policy.
• Benchmark output includes wall time, process CPU seconds/core-equivalent, peak RSS, cold initialization, warm inference, and detection/preprocess/recognition/postprocess stage timings.
• Profile defaults are selected from reproducible corpus benchmarks, not a hard-coded machine-specific thread count.
• Existing callers retain a documented compatibility path.
• Automated tests cover unavailable providers, partial fallback, invalid profile/provider combinations, and diagnostics stability.

Non-goals

• Treating maximum CPU utilization as the universal optimum.
• Promising GPU/ANE execution based only on GetProviders()/provider registration.
• Selecting one cross-platform backend for every device.
• Enabling lossy precision or shape bucketing without OCR quality gates.

References

• ONNX Runtime execution-provider partitioning model: https://onnxruntime.ai/docs/execution-providers/
• CoreML EP options and profiling: https://onnxruntime.ai/docs/execution-providers/CoreML-ExecutionProvider.html
• PaddleOCR benchmark guidance (module and end-to-end timing): https://github.com/PaddlePaddle/PaddleOCR/blob/main/docs/version3.x/pipeline_usage/instructions/benchmark.en.md

[eric8810]

已由 #11 的 0.3.0 execution contract 完成。当前实现包含 descriptor-driven Auto、显式 provider 严格语义、detector/recognizer 分会话 requested/actual provider 与设备/精度/模型诊断、结构化 creation trace，以及冷启动、CPU-time、RSS、placement、质量和 lifecycle 资格证据。