端侧 AI · 运行时
LiteRT-LM 并发请求怎么处理
先定义串行、排队、取消和会话所有权，再开放并行入口。
主查询：LiteRT-LM 并发请求 · 核验：2026-09-16 · 事实卡：LITERTLM-01, BENCHMARK-01
先给结论
LiteRT-LM 处理并发请求时，其语义边界首先由串行、排队、取消与会话所有权这四个概念界定，超出这些定义之外的行为不应被外推推断。换言之，LiteRT-LM 仅在满足上述前置定义并明确开放并行入口之后，才允许在同一进程内对模型调用进行并行调度，离开此范围的内容均不在本次确认之列。
需要先收集的证据
至少把下面三项与同一个 artifact、运行时和任务绑定：
- 并发契约
- 重叠请求 fixture
- 取消后下一请求结果
若缺一项，就把它写成未知，不要用模型参数、芯片宣传或网上截图代替。
实施流程
落实上述契约需要有可验证的证据支撑，应将并发契约、重叠请求 fixture 以及取消后下一请求结果逐条记录并相互对比。重叠请求 fixture 用来观测同一会话内的并行表现，并发契约规定串行、排队与取消三者之间的衔接，而取消后下一请求结果则反映取消语义是否被前后请求正确遵守，三者共同构成判定并发行为是否合规的依据。
- 选择运行时生态
- 确认支持的模型格式
- 封装应用接口
- 验证实际执行后端
- 测试取消与释放
- 保留回滚路径
最容易写错的地方
- 共享可变 session
- 无限启动 native 调用
在已记录的失败模式中，共享可变 session 与无限启动 native 调用是必须明确规避的两类错误。共享可变 session 会破坏会话所有权的串行前提，无限启动 native 调用则绕过排队与取消限制，这两类做法均与现有并发契约不符。因此，关于 LiteRT-LM 并发支持的发布结论只能限定在本次已记录（LITERTLM-01、BENCHMARK-01）的范围内，不得据此延伸出未经验证的性能或兼容性推断。
最小复现记录
| 层 | 必须记录 |
|---|---|
| 设备 | 型号、芯片、系统、RAM 档位 |
| 软件 | App 版本与 git commit |
| 模型 | 家族、变种、revision、格式、长度、hash、量化 |
| 运行时 | 版本、请求后端、实际后端证据 |
| 任务 | fixture、输入 hash、prompt hash、输出规则 |
| 结果 | 完成、失败、取消、回退与恢复 |
发布检查单
- 目标查询已在开头直接回答。
- 所有数字都能回到事实卡或原始记录。
- artifact、runtime、设备与任务没有混淆。
- 失败、取消、清理与回退都被测试。
- 隐私和网络边界单独说明。
- 结论只适用于记录中的配置。