Align the repository with the new collaboration workflow by separating meeting records from project framework materials, so discussion outputs and formal research assets can evolve independently.
3.1 KiB
3.1 KiB
推理运行域
1. 主题定位
推理运行域用于解释人工智能目标负载本身的时间行为、资源行为和优化空间。框架2强调,大模型与智能算法的实时问题不能完全归因到 RTOS 身上,原因就在于推理运行域本身已经带有很强的结构性时间特征。
2. 推理运行域包含什么
这一层主要包括:
- 模型结构与参数规模;
- 量化方式与数值精度;
- Prefill / Decode 两阶段时间特征;
- KV Cache 生命周期与内存组织;
- 推理框架队列、批处理与上下文管理;
- 算子实现、驱动路径和设备执行接口。
这一层回答的是:
人工智能目标负载本身具有什么样的时间行为、内存行为和资源竞争特征。
3. 为什么这一层不能被省略
如果把所有实时性问题都写成 RTOS 问题,就会忽略以下事实:
- 不同模型大小对内存和时延的影响完全不同;
- 量化方式会显著改变推理峰值、稳定性和能效;
- 同一硬件上,不同框架和不同算子组合会带来巨大差异;
- Decode 阶段与 Prefill 阶段的时间结构并不相同;
- 推理框架内部队列策略会直接影响首响应时间与尾延迟。
因此,推理运行域必须被单独分析。
4. 核心研究问题
4.1 模型时间行为如何进入系统分析
后续研究需要回答:
- 不同模型在 Prefill 与 Decode 阶段分别造成什么样的时间分布;
- 哪些阶段是延迟敏感的;
- 哪些阶段可以延后、限流或降级;
- 哪些阶段会对关键保障负载形成直接冲击。
4.2 内存与缓存如何形成主瓶颈
对于设备端 SoC 和边缘节点,KV Cache、统一内存与 DMA 搬运常常比算力本身更早成为主瓶颈。
因此,这一层需要重点分析:
- 权重、KV Cache、工作区和运行时缓冲的占用边界;
- 模型切换、上下文增长和并发请求如何改变内存行为;
- 哪些内存组织方式更适合和关键保障负载并存。
4.3 量化与算子如何影响实时边界
量化和算子优化不仅影响吞吐,还影响:
- 首响应时延;
- 长稳阶段的功耗与热状态;
- 设备端资源占用;
- 能否在受限部署条件下持续运行。
5. 评价重点
这一层的核心指标包括:
TTFTTPOT- 端到端响应时间
- 功能有效性与任务完成率
- 峰值内存、工作区与长稳退化
- 单位任务能耗与热漂移
这些指标构成 AI 目标负载本身的主证据。
6. 与其他层的关系
- 与
RTOS 直接控制域的关系:推理运行域描述 AI 目标负载自身行为,RTOS 控制域负责保护关键任务不被这些行为拖垮; - 与
系统协同域的关系:推理运行域给出负载输入,系统协同域回答这些负载如何与 Linux、Hypervisor 和异构资源共同形成整体边界。
7. 当前结论
框架2保留 RTOS 的重要性,但明确要求把推理运行域单独提出,是因为:
只有先把人工智能目标负载本身的时间结构说清楚,后续系统边界分析才不会落回单因果叙事。