零、前言
📌本文为稀土掘金技术社区首发签约文章，30天内禁止转载，30天后未获授权禁止转载，侵权必究！
📕欢迎访问：
Bilibili：space.bilibili.com/57089326
（另外，其实个人博客和知乎都需要打理一下了，不过因为笔者太懒了还没去）
注意，本文不涉及太多复杂的公式与数学推导，初学者或者像笔者一样数学不好的读者可以放心阅读！
一、一图看懂论文主要内容
文字版：SoT旨在减少大型语言模型的生成延迟。通过引入思维骨架的概念，先生成答案的框架，然后并行处理每个框架点的内容，可以显著提高生成速度，并且在答案质量方面可能具有多样性和相关性的改进。这是一项以数据为中心的优化工作，展示了推动语言模型更像人类思考以提高答案质量的潜力。
只想简单看一看或者赶时间的读者到这里就可以退出了~
二、更进一步
大家现在都知道，LLM在NLP方面表现出色，并让聊天机器人这一概念从传统的人工智障变成了现在功能强大的ChatBot。
然而，这些先进的LLM的推理过程较慢，阻碍了它们的交互使用。对于一些不太着急的人来说可能还好，但是对于赶时间或者需要实时性的任务来说就不那么友好了，比如将来可能会出现的嵌入LLM的机器人，如果你让他帮你取个外卖，还要反应两分钟的话，那就要饿肚子了。
推理速度慢的主要原因包括：
- LLM的规模需要大量的内存、内存访问和计算、核心注意力操作，受到I/O速度限制；
- 在序列长度上具有二次的内存和计算复杂度；
- 推理中的顺序解码方法逐个生成令牌导致的延迟。
此前，一些研究工作改善了这些问题，包括对模型的压缩或是重新设计，以及重新设计服务系统和硬件。
本文的研究提出了一种解决第三个问题的方法，即对现成的LLM进行并行解码，而无需对模型、系统或硬件进行任何更改。
这种方法类似于人类回答问题的思考过程，先得出骨架，然后逐步添加证据和细节。通过引入思维骨架SoT，LLM可以并行完成每个观点，从而加速推理。作者在测试这种新方法的时候，发现它不仅提供了相当大的加速，还能提高答案的多样性和相关性，这真是意外之喜，不过想想也能说得通，毕竟人类也是如此，倘若直接一股脑地去想问题的话会容易想不全，如果分治的去做的话会从很多细节发现更多有趣的东西。
SoT提出了一些问题，包括是否应该将LLM的思考和写作过程组织成MindMap，将效率和整体理解与逻辑推理和即兴思考的优势结合起来等等。另外，随着机器学习领域从以模型为中心转向以数据为中心，SoT是对以数据为中心的效率优化的首次尝试，因为它引导LLM在推理过程中组织输出内容以提高效率。对于这个方向有着很大的机会和潜力。
如上图是思维骨架SoT方法的示意图。与传统的顺序生成答案的方法（左）相比，SoT（右）通过并行生成答案的不同部分来加速生成过程。具体而言，给定问题，SoT首先提示LLM生成骨架，然后进行批量解码或并行API调用以同时扩展多个观点，最后将输出聚合在一起得到最终答案。
三、原理简述
1 SoT的三个阶段
-
骨架阶段：SoT使用骨架提示模板将
用户问题转化为一个骨架请求，并从LLM的响应中提取关键要点。简单说一下什么是从LLM的响应中提取关键要点，就是说，本来LLM会生成一坨回答，但是并不是所有的内容我们都要展示出来，那样可能会显得很乱，就像是中学时我们答文科的题目，老师都是按点给分的，其实提取关键要点这个过程就类似按点给分，我们基于这些关键点，再去放到骨架里面去扩展，也就是到了第2个步骤了。
-
要点扩展阶段：基于骨架，SoT并行地扩展每个要点，使用要点扩展提示模板指导LLM生成详细的答案。
-
并行处理：对于专有模型，多个API调用可以并行处理；对于开源模型，可以批处理要点扩展请求。
2 SoT能减少解码延迟的原因
看上去很神奇，其实很简单，当使用SoT进行解码时，可以显著减少解码延迟，从而提高端到端响应的速度。这是因为SoT采用了两种策略：
- 对于基于API的模型：SoT并行发送多个API请求以获取答案的不同部分，从而减少了API请求的延迟；
- 对于开源模型：SoT通过批量处理多个要点扩展请求和答案，增加了GPU计算利用率，从而加速解码过程。
具体地，通过将答案切分成多个段并批量解码，可以获得比顺序解码更快的解码速度。此外，SoT在批量解码过程中的峰值内存开销增长较慢，因此不需要额外的内存优化技术。这些策略的综合效果使得SoT在减少解码延迟和提高效率方面更加优越。
四、横向对比
SoT与其他方法的不同之处在于，它采用了“内容协同组织以提高效率”的范式，而不是传统的模型协同设计范式。
随着从以模型为中心的时代过渡到以数据为中心的时代，而且人工智能能够很好地理解和生成越来越长的序列，通过内容的协同组织来提高LLM的效率可能成为高效LLM工具箱中的重要工具。
在系统级别的优化方面，已经提出了各种模型并行和分布式技术，以最大化LLM训练和批量推断的吞吐量。这些技术通过优化计算、存储和通信的划分、分配和调度，改善了系统的整体性能。
然而这些技术主要用于训练和批量推断等吞吐量导向的场景，并不能有效地优化推断过程中的端到端解码延迟。不过，SoT可以利用这些吞吐量导向的技术，通过并行解码多个片段并在之后进行聚合，提高批量解码的吞吐量。
另外，针对延迟敏感的场景，端到端解码阶段是整个推理过程的瓶颈，因为每个标记必须逐个生成。为了改善给定LLM的端到端解码延迟，已经提出了一些猜测解码方法，通过使用较小的辅助模型顺序解码生成一个短的候选标记序列，然后使用LLM并行验证候选标记，并保留与LLM验证结果匹配的前缀序列。
这些方法通过并行验证多个标记来加速解码过程，与仅生成一个标记相比，验证多个标记的延迟是可比的。而SoT则通过引导LLM重新组织内容，实现不同片段中多个标记的并行生成。
除此之外，与SoT并列的方法，如Prompt、预训练、预测等更多的是用于：
- 通过指导调优过程中遇到的多样的自然语言描述来推广到新任务；
- 在上下文中使用少量示范进行学习，而无需调整权重。
基于这些能力，研究领域一直在手动设计、自动搜索或持续调优提示，以揭示LLM在下游任务上的能力。例如，Chain-of-Thought提示通过提供“让我们逐步思考”的指示或几个示范来大大提高需要逻辑思考和推理的任务的性能（还记得前段时间我们讲的LLM使用小黄鸭调试法吗）。HuggingGPT设计了提示来引导LLM生成结构化的JSON，用于协调多模型执行以完成复杂任务，诸如此类的方法，等等。
这些方法旨在揭示LLM的不同能力，并提高在不同下游任务上的答案质量。相比之下，SoT则利用提示的力量来提高效率，主打一个天下武功，唯快不破。
五、思考与展望
1 不足的方面
- 答案质量评估有限：由于提示集合的限制、LLM评判者的偏见以及评估LLM生成的困难，对答案质量的评估还不完善。
- 需要扩展评估方法：扩展提示集合并引入人工评估是更可靠的质量评估的重要步骤。
2 未来工作
-
设计问题类型和描述的流水线：为了更好地使用SoT，应设计一个流水线，仅对适合SoT的问题类型和描述触发SoT模式。
这里可能不太好理解，我们简单扩展说明一下：
设计问题类型和描述的流水线是指在处理问题时，根据问题类型和描述的不同，采取不同的处理方式和模式。它可以被看作是一个根据输入的问题类型和描述，自动选择合适的处理模式或模型的过程。
例如，如果问题描述明确要求简洁明了的答案，或者问题类型更适合通过即兴思考或推理来回答而不是通过结构化的骨架生成，那么SoT模式可能不是最佳选择。在这种情况下，流水线可以选择其他生成模式，如传统的顺序解码模式或其他适合的模型。
-
改进SoT能力：通过对LLM进行微调，改进其对骨架和扩展指令的理解，使其能够为更广泛的问题类别生成更流畅自然的答案。
-
结合其他优化技术：将SoT与现有的面向吞吐量优化技术、推理引擎和服务系统进行整合，以揭示SoT在提高吞吐量和延迟方面的全部潜力。
开放性问题：
- 动态思维结构：将观点组织成“动态思维图”，以更好地处理观点之间的顺序依赖关系，并允许思维结构的动态调整，从而结合骨架思维和逻辑推理或即兴思考的优势。
- 数据中心工程的潜力：探索数据中心工程在提高效率方面的潜力，为现有的“模型-软件-硬件协同设计以提高效率”的技术栈添加一个新的数据层面。
FIN
