01 · 更快执行同一请求，与改变请求的工作量
一个问答任务可能先检索很多文档，再拼长上下文，调用大模型，生成很长答案。应用策略可以选择更相关的上下文、适合任务的模型和合理输出预算，从源头减少模型工作量。它们位于模型调用前后，改变了实际输入、模型或输出合同。
这些策略能与FlashAttention、量化和连续批处理组合，但应独立归因：同一请求的kernel提速，与缩短请求或换模型不是同一个实验。业务质量、完整率和总重试成本要一同评估。
02 · 完整任务依赖：每个环节都有新增开销
业务问题 + 权限/时效/输出要求
↓
检索 → 相关性筛选/去重 → 必要内容保留/压缩
↓
模型路由（任务特征、能力、预算、负载）
↓
构造消息与生成配置 → Prefill → Decode/工具执行
↓
检查完成与业务质量
├─ 满足 → 返回
└─ 不满足 → 回退模型/补上下文/继续或重试重排器、压缩器、路由器与校验器也要运行。小模型先答、失败再用大模型，会执行两次前向；不能把第一次便宜就算整个任务便宜。工具调用、外部等待与检索也可能成为关键路径。
03 · 上下文：选择、压缩和截断不是一回事
| 方法 | 怎样减少输入 | 容易漏什么 |
|---|---|---|
| 检索与重排 | 先找候选，再保留相关证据 | 关键证据没召回；文档范围与权限错误。 |
| 去重/历史裁剪 | 删除重复片段或不再需要的对话 | 重复不等于无用；较早约束仍可能影响当前任务。 |
| 摘要/提示压缩 | 用更短表示或选择重要token | 数值、否定、实体、条件与引用边界可能丢失。 |
| 硬截断 | 在容量或预算边界直接移除部分输入 | 最便宜但通常缺乏语义判断，可能切断证据或结构。 |
LLMLingua研究展示预算控制和逐token压缩的实现方向；这里不把论文特定数据集结果推广到任意业务。检索和压缩减少的是输入内容，不能当作与原上下文Attention输出相同的内核优化。
例如“支持A，但不支持B；版本v2除外”，若删掉“不”或“除外”，token减少却把答案条件改坏。保留结构化标识、必要数字与引用信息，仍须用任务评测验证。压缩后的前缀若改变，旧KV不能继续按原前缀身份复用。
04 · 输入减少与输出减少，影响不同阶段
Prefill处理整个输入，dense Attention的交互数量随序列长度平方增长，同时线性层等仍有线性项。Decode逐token执行，每步还读取不断增长的历史。缩短输入通常同时减少Prefill与后续历史读取；少生成token则减少Decode次数及未来KV增长。
用一个自设成本模型：任务时间=策略准备C + 0.05×N + 0.0001×N² + 2×G，单位ms；N为输入token，G为实际生成token，系数只为教学。它忽略Decode随历史变化、排队、网络与模型差别，不能当作真实性能预测。
少读、少生成，能抵消准备开销吗？
自设时间C+0.05N+0.0001N²+2G，单位ms；基线N=1000、G=200、C=0。G为实际执行长度，并非上限；忽略排队、历史增长、质量与重试，不预测设备表现。N=1000、G=200时为550 ms。压缩至N=500、增加准备30 ms，保持G=200，则480 ms；把输出改为G=100则280 ms。相反，准备150 ms、仍生成200时是600 ms，已经比基线慢。
05 · 模型路由：选择模型，与分配副本不同
模型路由决定用哪一种能力/规模的模型；M029的服务调度更多决定请求去哪个副本、何时执行。路由信号可以是任务类型、上下文长度、明确规则或学习出的难度/偏好预测，不等同于只按prompt长度。
RouteLLM提供强弱模型之间学习路由的研究实例。阈值控制质量和成本的取舍，但不是请求级正确性保证；要用目标业务数据校准，并验证域外任务和模型版本变化。
自设小模型每请求成本1、大模型5，路由成本0.1，70%走小、30%走大，预计成本0.1+0.7×1+0.3×5=2.3，相比全部大模型5更低。若先全部小模型，再有40%回退大模型，则成本0.1+1+0.4×5=3.1；再加校验和重试时会更高。这是算术假设，不是质量或耗时实测。
06 · 生成停止要保留完整任务的定义
生成可以因EOS、stop字符串、长度上限、取消或时间预算而结束；结束原因不能都标作正常完成。长度上限截断的JSON、代码、工具参数或推理过程可能不可用，需报告终止状态并按业务合同处理。
Transformers把max_new_tokens定义为不含输入的新增token上限，stop_strings可指定文本终止条件；具体后端实现和版本需核对。不能把所有early_stopping选项泛化成任何生成模式的智能早停。
依据：Transformers · 生成长度、终止与配置合同 ↗
选择任务允许的最大输出预算
每步生成后检查EOS / stop / 预算 / 取消
记录finish_reason和实际token数
若到上限但任务未完成：按合同继续/回退/报不完整
清理不再需要的KV和资源
# 不把截断内容标为完整答案；不对有副作用的工具盲目重试。并行多候选、长推理预算或多轮反思也属于任务工作量。增加它们可能提高质量而增加成本；限制它们是否合理取决于任务效果，不能只看单个候选tokens/s。
07 · CPU算例核对预算、停止与回退
下载脚本检查预算模型、路由成本和回退概率，模拟EOS早于上限与长度截断的不同终止状态。上下文例子用带关键词的证据选择和硬截断，展示删掉否定条件的错误；它不实现检索模型、真实语义压缩或学习路由器。
保持业务任务集、权限与质量标准固定
分别比较上下文、模型、输出预算三项
记录准备与校验耗时、输入/实际输出token
计回退、重试、工具执行与所有模型调用
观察完成率、任务质量、总成本和尾延迟
再与底层kernel/调度优化做组合实验依据：RouteLLM · 强弱模型学习路由原始论文 ↗ · Transformers · 生成长度、终止与配置合同 ↗
08 · 验收看有效完成，而非只看少算了多少
- 上下文：证据覆盖、否定/数值/实体、引用与必要历史约束。
- 路由：强弱模型使用比例、误路由、模型/阈值版本和域外任务。
- 输出：实际长度、结束原因、结构合法性、任务完整率。
- 成本：策略准备、全部模型调用、回退、校验与重试。
- 延迟：端到端和P95/P99，包括路由、检索和排队。
这些策略发生在应用层的系统流程中，模型选择/压缩又改变算法合同。标签可以跨维度：位置记录它发生在哪里，类型解释它改变的是工作量还是执行效率。GPU/NPU都能承接这些请求，具体收益仍由后端、负载和质量决定。
- 为什么缩短prompt的比例不等于完整请求提速比例？
- 同一个max_new_tokens，两条请求实际执行步数为何不同？
- 模型路由与缓存感知副本路由，分别决定什么？
流程位置与关联方法
这个方法可能出现在多个位置；计算线包含模型计算与算子实现，执行线包含运行时、内存和通信。
资料与核查范围
原理依据以原始论文和官方文档为主；算例与时间线是教学推导。文档核查日期：2026-10-10。引用 main / latest 文档时，实际接口以安装版本为准。
代码为接入片段或教学伪代码；本页没有声称完成 NVIDIA / 昇腾硬件实测。