一个应用先让模型把报告分成若干章节，再并行调用模型概括各章，最后调用一次模型合并这些摘要。在普通的补全服务眼中，这段程序会呈现为一列互不相关的提示词。服务每次只能看见一条渲染完成的文本请求陆续抵达，至于哪项输出会流入哪项输入、哪些调用可以同时运行，以及用户究竟在等待哪个最终答案，这些关系都隐没在请求之外。

Parrot 从信息丢失带来的代价出发。上海交通大学与微软研究院的研究人员共同开发了这一系统，并用语义变量（Semantic Variables）扩展编程接口和服务接口。语义变量是有名称的提示词字段；当应用越过模型服务的分界线时，它仍能保留生产者与消费者之间的关系。服务由此可以把相连的调用合在一个应用内优化，取代逐条孤立处理。[2][4]

这段 13 分钟的 OSDI 2024 演讲值得观看，因为它把一笔交换清楚地摆在了台面上。Parrot 向服务层提供足够的信息，使其能够调度存在依赖的调用、传递最终输出目标，并发现重复的提示词前缀。相应地，应用需要通过 Parrot API 描述模板与依赖关系。以下时间点用于观看导航，不作逐字转写。[1][3]

0:32–2:54 — 服务商看见的是流量，开发者看见的是程序

开场迅速掠过几种 LLM 应用形态：摘要链、map-reduce 模式、聊天与搜索，以及多角色编程工作流。这里应把视线越过“智能体”这个标签，落到用户最终看到的结果及其背后多次模型调用上。这些调用彼此关系各异，有的串行，有的并行，还有一些会重复使用一段很长的共同提示词。[1][3]

到 2:25，视角发生翻转。开发者手中的工作流一越过服务商的分界线，便收拢成 OpenAI 风格的单条请求流。名称被文本替代，原本表达“A 步骤的输出成为 B 步骤的输入”的占位符，此时只剩 B 提示词中的一段字符串。补全 API 携带的信息仍足以生成下一个答案，却丢掉了另一类信息：它们原可帮助应用更早交付最终答案。

这个问题超出了负载均衡器对单条请求大小估计不准的范畴。Parrot 的主张是，服务缺少的是请求之间的关系。客户端需要等待中间响应，经网络收取结果，拼出下一条提示词，然后重新进入队列。与此同时，服务器无法识别几次 map 调用互为同级任务，也看不出生成答案的 reduce 调用正是延迟最敏感的汇聚点。论文将其称为以请求为中心的服务方式与应用级性能之间的错配。[2]

2:55–5:50 — 一次信息丢失同时挡住三类优化

问题陈述的中段把这种盲区与三项成本连在一起。第一，中间值需要绕经远端客户端，依赖链上随之多出网络传输和排队时间。第二，如果每次调用都按同一个局部指标优化，最终结果反而会受损。一组并行 map 调用适合偏重吞吐量的批处理，而负责生成答案的 reduce 调用更值得享有低延迟优先级。第三，完全渲染后的提示词遮住了模板边界，共同前缀也因此更难被发现并复用。[1][3]

留意 5:20 前后那份克制。粘性路由、依赖感知调度和共享前缀缓存早已有迹可循，演讲没有把它们包装成前所未有的发明。重点在于，多租户服务如果看不见应用身份、依赖关系与提示词模板的组织方式，便无法稳妥判断这些方法该用在何处。由此理解 Parrot，它的重心在于补上各类优化共同缺少的输入；若只把它看成若干互不相连的优化技巧，便会错过项目要解决的问题。

这一区分会影响我们如何评估这个项目。面对不透明的提示词文本，再聪明的调度器也只能靠猜测重建应用意图。Parrot 选择改写双方的约定：应用把选定的语义信息明确交给服务，服务再据此采取行动。优化空间随之扩大，代价则是额外的集成工作，以及延伸得更广的信任边界。

5:51–8:10 — 占位符成为语义变量

关键观察出现在 6:19。生成提示词的代码原本就在使用占位符：任务描述放进一个字段，生成的代码填入另一个字段，测试输出还会流向修复提示词。Parrot 把这些字段提升为语义变量。语义函数会声明自己读取和生成哪些变量，因此模板提交之后，这些关系依然得到保留。[1][3][4]

假设 code 是生成函数的输出变量，同时也是审查函数的输入变量。应用可以直接提交这条连接，服务在任何展平操作发生之前便能识别它。Parrot 会即时建立依赖图，以异步方式提交已经就绪的任务，并在程序真正需要时返回所请求的输出。应用原有的逻辑仍可留在客户端，模型调用之间的关系则会传到服务端。[2]

“语义”二字听来很重，实际做法相当具体。字段内容的真伪与工作流的正确性，仍在这套做法的覆盖范围之外；这些变量保存的是操作层面的事实，包括提示词片段从哪里分开、值从何处产生、将被何处使用，以及哪项请求输出会结束整条路径。这些信息刚好足以显露并行关系和重复上下文，同时免去服务系统逆向解析任意源代码的负担。

演讲在 7:54 展示的服务视图，是整个讲解中最具决定性的一幅图。原先堆叠在一起的提示词变成附有提示词分段信息的依赖图。应用图本就由开发者设计；Parrot 所做的，是让调用抵达基础设施之后，这张图仍然清晰可读。

8:11–10:47 — 从真正重要的答案反向安排调度

客户端请求最终语义变量时，可以同时附上端到端性能指标。Parrot 沿变量依赖关系向后传递这一目标，再按各项工作的角色分组。在 map-reduce 摘要任务中，彼此独立的 map 调用可以组成批次来提高吞吐量，下游的 reduce 调用则可以按低延迟要求调度。系统要优化的是所请求输出的完成时间，单个中间调用的局部最优退居其次。[2][4]

9:07 开始的混合应用示例让这一思路更加清楚。交互式聊天机器人和分析任务可以共享同一组模型资源，但它们看重的性能表现并不相同。Parrot 从各自的应用级目标推导请求级优先级，省去了用一条无差别规则处理两者的做法。全局最优调度仍在其承诺范围之外；它提供的是调度策略所需的依赖信息和目标信息。

到 10:48，提示词的组织方式又打开了另一类优化空间。借助明确的语义分段，Parrot 可以识别共享前缀，省去逐个 token 比较每条提示词的工作。亲和性调度把拥有可复用上下文的请求聚在一起，定制的 attention 路径则结合与 FlashAttention、PagedAttention 相关的思路，高效使用共享前缀。[2][3] 应用采用带有明确分段的模板后，优化会自动执行；原样使用补全 API 的客户端仍处在优化范围之外。

两套做法彼此相扣。依赖图说明任务何时就绪，以及哪项输出决定用户要等多久；模板说明调用之间哪些输入区域会重复出现。Parrot 的贡献，是把这两类信息一同保留在服务抽象中。

8:38–11:48 — 把加速数字放回测试环境中阅读

评估幻灯片与上述工作原理的讲解在时间上有所重叠，第二遍观看时值得在这里暂停。论文的单 GPU 实验使用一块显存 80 GB 的 NVIDIA A100，多 GPU 实验使用四块显存各为 48 GB 的 NVIDIA A6000。服务引擎运行 LLaMA-7B 或 LLaMA-13B 模型。工作负载包括链式和 map-reduce 式 arXiv 摘要、搜索形态的请求、GPT 风格应用，以及 MetaGPT 风格的编程工作流。[2]

最大的数字需要连同完整参照系一起读。在多智能体工作流中，与偏重延迟的 vLLM 基线相比，Parrot 报告的完成延迟最高降低 11.7×；与刻意偏重吞吐量的基线相比，最高降低 2.45×。这些是特定工作流与测试配置下的最大值，不能当作智能体软件普遍适用的倍率。四 GPU 共享提示词实验还报告了最高 12× 的请求速率优势，比较对象是无法复用这些前缀的基线；关闭 Parrot 的亲和性调度后，该项比较所显示的优势会缩小。[2]

其他限制条件同样值得留意。随着生成输出变长，链式摘要的收益会收窄，因为 token 生成逐渐主导总耗时，避开的协调延迟所占比重随之下降。搜索形态的评估采用合成数据：作者无法取得生产搜索应用未公开的中间工作流，因此依照请求特征建模。硬件、模型、流量模式与注入的网络条件共同描述的是一套研究测试环境，与今天的前沿模型集群不能等同。[2]

把这些限制条件交代清楚，结论依然有分量。在受控工作负载中，保留应用信息后，系统便能利用那些基线系统因看不见应用关系而错过的优化机会。论文展示的是这份信息约定的价值；实际部署仍须测量自身依赖图的形态、前缀重复程度与客户端延迟，再判断这份约定是否值得采用。

原型之外留下了什么

Parrot 的代码仓库明确说明，公开代码属于研究原型，目前没有积极维护。[5] 它的接入范围也相当可观：其中包括 Python 前端、服务运行时和定制内核，远超在现有不透明 API 上打开一个即插即用开关。动态分支与普通的客户端函数还会增加服务器完整观察应用的难度；论文把公平性、故障和异构集群等更广泛的问题留给后续研究。[2][5]

因此，可以直接照搬的部分有限，值得吸收的经验依旧清楚。评估这一思路的团队，应当先追踪一个应用从输入抵达最终输出的全过程：辨认模型调用之间的依赖关系，找出重复前缀，标记用户等待的输出，并测量客户端往返和重新入队的耗时。完成这些工作后，团队才能判断公开这些关系所带来的批处理、调度或缓存复用收益，能否抵偿新 API 的成本。

长久留下的是一条关于接口的启示。补全 API 把一次调用简化为送入提示词、得到文本，模型访问也因此变得格外简单。复合应用中的这种简洁会抹去上下文，而推理服务恰恰需要这些上下文来优化整体。Parrot 恢复了其中一小部分。语义变量的价值与名称听起来多么智能无关；它让基础设施能够识别，眼前的下一条请求属于一项规模更大的计算。

来源

1. USENIX，“OSDI '24 — Parrot：借助语义变量高效服务基于 LLM 的应用”，Chaofan Lin 演讲，2024 年。
2. Chaofan Lin 等，《Parrot：借助语义变量高效服务基于 LLM 的应用》，第 18 届 USENIX 操作系统设计与实现研讨会，2024 年。
3. Chaofan Lin 等，OSDI '24 官方演讲幻灯片，2024 年。
4. 微软亚洲研究院，《大语言模型应用如何实现端到端优化？》，Parrot 第一手技术解析，2024 年 7 月 25 日。
5. Microsoft，ParrotServe 研究原型代码仓库与实现文档。
6. 微软亚洲研究院，上海系统与工程组简介及实验室官方照片。