Direct answer
Define serialization, queueing, cancellation, and conversation ownership before accepting parallel work. Treat those four terms as the prerequisite vocabulary for any concurrent-request scenario in LiteRT-LM, and refuse to read additional behavior into them beyond what is stated here.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Concurrency contract
- Overlapping-request fixtures
- Cancellation and next-request result
A runtime comparison is publishable only when artifact identity, build configuration, selected backend, task fixture, and failures are recorded.
Implementation workflow
Record and compare the concurrency contract, overlapping-request fixtures, and the cancellation and next-request result. Treat those three evidence items as the recorded set to keep aligned when documenting concurrent-request behavior, rather than as sources of inferred mechanisms or unstated outcomes.
- Freeze the product task and minimum device tier.
- Choose the runtime and supported artifact format.
- Pin artifact and runtime revisions.
- Wrap native state behind an application-owned interface.
- Test load, representative work, cancellation, close, and fallback.
- Publish only the behavior reproduced by the recorded configuration.
Failure patterns to prevent
- Sharing mutable session state
- Launching unbounded native calls
Sharing mutable session state and launching unbounded native calls are pitfalls to rephrase when describing concurrent requests. Release wording is limited to what the recorded evidence shows, so avoid extending the description beyond those two pitfalls and the evidence attached to them.
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 端侧专题.