Direct answer
Offer recoverable actions when a measured task cannot safely continue, so the experience acknowledges the stoppage and provides an explicit, restorable path forward rather than an implicit or silent failure. The wording must remain tied to this stated focus, and any interpretation beyond it must not be inferred or introduced.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Failure classification
- User action mapping
- Retry after cleanup
A device badge must come from an exact device, OS, artifact, runtime, backend, and workload record, not parameter-count intuition.
Implementation workflow
Record and compare Failure classification alongside User action mapping alongside Retry after cleanup, using these evidence items together so that each instance of a stopped measured task is documented in the same form and reviewed across occurrences. The connected reading must not extend past what these recorded items already cover.
- Record the exact artifact and format.
- Measure the app before model load.
- Measure after model initialization.
- Run a representative product task.
- Repeat the fixed workload without restarting.
- Store failures, fallback, and cleanup behavior.
Failure patterns to prevent
- Guessing a universal RAM cutoff
- Crashing after a generic spinner
Avoid Guessing a universal RAM cutoff and avoid Crashing after a generic spinner, since both pitfalls fall outside the recorded evidence and would rely on assumptions not supported by the documented Failure classification, User action mapping, and Retry after cleanup. Any release-facing wording is limited strictly to what those recorded items establish, with no added claims about thresholds, behavior, or technical causes.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.