端侧 AI 推理队列背压：有界准入、公平性与取消

直接回答

队列背压是一项准入策略：它决定哪些推理请求可以进入有界工作队列，哪些应等待，哪些可合并，哪些必须拒绝或取消。它与选择工作线程不是同一个问题。工作线程设计把昂贵原生调用移出 UI 线程；准入控制则防止应用接受超过单一运行时所有者安全处理能力的任务。如果没有上限，连续点击、页面恢复和后台触发可能让提示词、图像缓冲、结果状态或协程闭包长时间留在队列中。 先从产品语义定义规则。实时相机预览可能更需要最新帧并丢弃过期帧；用户提交的翻译也许需要 FIFO 顺序；同一请求重复点击可以在第一个仍活动时忽略；可取消摘要任务可以被用户的新编辑替换。这些策略不能通过一个通用无限队列实现。需要定义请求类别、最大运行中及排队数量、过期行为、取消所有者和队列满时的用户可见结果。还要说明公平性是 FIFO、按优先级加权，还是按功能配额。除非产品有意且可观察，否则高优先级请求不应无限期饿死更早已接受的任务。 只有输入、制品、运行时、提示和结果契约都在语义上等价时，合并请求才安全。两张图像即使来自同一屏幕也不自动是重复请求。队列可以合并重复刷新意图并保留最新输入，但必须记录哪些请求 ID 被取代，并只把结果交给最后保留的所有者。身份无法证明时，应分别排队或明确拒绝，不能静默合并用户内容。为保护隐私和内存，积压诊断不要保存原始输入；仅记录请求 ID、类别、入队时间、队龄、状态及取消/拒绝原因。 队列生命周期应显式表示：已提交、已接受、排队、开始、流式生成、完成、取消、过期、拒绝或失败。可观察队列深度、最老等待时长、运行中数量和类别等待状态，但除非在明确定义的测试中测量，否则不要把它们宣传为性能指标。取消尚未开始的排队任务时，应立即移除；取消活动原生推理时，使用运行时支持的边界，并等清理完成后才释放共享资源。UI 观察者消失并不代表排队请求或原生调用已经停止。 测试突发与竞态：连续点击、离开再返回、输入替换旧输入、排队期间取消、活动期间取消、队列满、工作者失败及运行时关闭。断言队列不超过配置容量，没有请求收到另一个请求的输出，旧任务不能更新新页面，每个已接收请求都到达一种终止状态。公平性和内存仅在固定夹具与准确设备/运行时下测量；项目没有完整基准数据。交付物是可预测的过载行为和可审计状态，而不是通用队列大小或延迟承诺。 背压策略应优先表达用户意图。对于可以被新请求替代的实时预览，最新优先可能合理；对于用户明确提交的翻译或摘要，静默丢弃旧任务可能违背预期。若队列达到上限，可显示“当前请求正在等待”“旧请求将被替换”或“请稍后重试”等清晰状态。避免含糊的加载动画让用户继续点击，从而放大积压。每条策略都要记录决定依据并通过场景测试验证。 排队任务的资源也必须有所有者。入队前保留大图像、音频、提示对象，会在推理开始之前就占用内存；可将原始媒体存放于有界临时文件，并在任务完成、取消或过期时清理。若任务包含模型会话，不应长期保持不安全的 native handle。队列需要在应用生命周期结束或模型切换时定义清空、迁移或拒绝行为。避免让 WorkManager 的持久任务语义与进程内交互队列混为一谈；两种任务的持久性、用户期望和恢复规则不同。 监控指标应是安全且足够判断状态的元数据，例如排队数量、等待时长区间、请求类别、取消原因、终止状态和资源释放结果。不要上传提示词或结果来估算积压。公平性测试可测各类别被服务的先后顺序和等待上限，但除非保存完整原始运行数据，不应发布延迟表现。所有公开结论都限制在实际队列策略、应用构建和测试负载内。

一个原生推理尚未完成，连续点击不断堆积请求

用户连续点击端侧摘要按钮，首个请求仍在运行。页面重建又创建了一个新请求，后台还有旧任务等待。应用现在为每次点击启动协程，没有显示哪些任务已接受或仍在排队。

决策

引入应用所有的有界准入协调器，按请求 ID 管理，制定顺序/合并策略、显式取消，并在队列满时向用户显示拒绝或替换。

预期结果

用户能看到当前运行与等待状态，过期工作不会无限滞留，完成结果不会交付给错误请求。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• COVE-LIFECYCLE-01：ModelManager 串行化模型加载；该事实不定义推理请求队列策略。
• MEMORY-03：Android Studio Memory Profiler 可观察应用实际内存，发布判断应基于准确制品和目标设备测量。

只有记录了模型身份、构建配置、实际后端、任务样例和失败情况，运行时比较才可复核。

实施流程

Recorded evidence items must be connected and compared to support assessment of queue behavior. Queue ownership policy, overload fixtures, and rejected and recovered outcomes are gathered together as documented evidence so they can be recorded side by side and compared against one another. The connection lies in linking who owns the queue, what overload conditions were applied via fixtures, and which requests were rejected or subsequently recovered, enabling consistent comparison rather than drawing conclusions beyond these recorded items.

1. 定义请求类别和语义价值. 将交互生成、可替换预览、用户编辑、重试与后台维护分别列出。对每类明确 FIFO、最新优先、去重或拒绝哪种策略符合产品含义；不能只因来自同一屏幕就合并输入。
2. 设定队列与运行中上限. 根据运行时所有权契约及目标测试环境的内存测量，确定活动原生调用数和等待请求上限。定义满载行为、过期请求处理及类别公平性，不能把猜测的固定数称为普遍支持上限。
3. 分配身份、所有权和取消路径. 每个已接受请求都分配 ID、制品/运行时身份、任务所有者和终止状态。开始前取消应移除排队任务；活动任务取消要经过运行时支持的边界，并在共享资源复用前等待清理。
4. 安全合并并给出准入结果. 仅当输入、制品、提示与结果契约明确等价时才合并。记录被替代的请求 ID，只把最终结果给保留任务。无法证明等价时，应分别排队或说明拒绝原因。
5. 测试过载、公平性和可观察性. 注入点击突发、页面重建、新输入替换、排队/活动取消、容量用尽、工作者失败和运行时关闭。断言容量有界、每个 ID 只有一个终止状态、服务顺序符合政策且结果不串单。积压信号不记录原始输入。

验收标准

• 队列容量、类别顺序/公平性、过期、合并条件和满载行为明确且可测试。
• 每个请求 ID 恰好进入一种终止状态，输出只交给其任务/会话所有者。
• 开始前取消的排队任务会被移除；活动取消需等待运行时支持的清理边界后才能复用资源。
• 积压观察采用脱敏元数据，不声称通用队列大小、延迟或内存上限。

决策对照表

需要避免的失败模式

• 误以为把调用移到后台线程就自动限制了请求数量。
• 不判断输入语义就合并同一界面的所有任务或静默丢弃请求。

Accepting unlimited work and hiding rejected requests are pitfalls to rephrase, with release wording limited to recorded evidence. Accepting unlimited work means taking on queued items without a stated bound, and hiding rejected requests means keeping rejected outcomes from view. The phrasing here is drawn from recorded evidence and does not extend to mechanisms, causes, or implementation behavior beyond what is stated.

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• Android Memory Profiler
• Android 线程与任务管理指南
• Kotlin Channel 缓冲通信文档

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题