ParallelPrompt: Extracting Parallelism from Large Language Model Queries¶

会议: NeurIPS 2025
arXiv: 2506.18728
代码: 有（开源benchmark + C++执行框架）
领域: LLM效率
关键词: 查询内并行, Prompt分解, LLM推理加速, Benchmark, 语义保真度

一句话总结¶

构建了首个查询内并行（intra-query parallelism）基准数据集ParallelPrompt，包含37000+条真实用户提示的结构化分解标注，证明约10%的用户查询包含可并行的潜在结构，并行执行可实现最高5.7×的延迟加速且质量损失有限。

研究背景与动机¶

领域现状：LLM推理优化主要集中在两个层面——token级别（推测解码、KV缓存等）和请求级别（批处理、调度等）。但一个被忽略的维度是单个查询内部的并行性：很多用户提示本身包含多个可以独立执行的子任务。
现有痛点：现有的任务分解方法（如Skeleton-of-Thought、Tree-of-Problems）针对的是合成场景或预定义模式，对真实用户查询中多样化的并行模式泛化能力差。更重要的是，目前没有标准化的基准数据集来量化查询内并行的潜力。
核心矛盾：用户经常写出包含多个可独立处理子任务的查询（如"翻译以下10个句子"、"分析这5本书的优缺点"），但LLM serving系统将它们作为整体串行处理。这种"单体查询"假设浪费了大量可利用的并行机会。
本文要解决什么？
构建第一个真实用户查询的句内并行基准
量化并行的实际收益（延迟和质量的trade-off）
评估现有分解方法在真实场景下的表现
切入角度：从100万+真实LLM对话日志中，用多阶段pipeline筛选出包含可分解结构的查询，提取结构化schema（模板+共享上下文+迭代数据），然后用并行vs串行执行来量化收益。
核心idea一句话：约10%的真实用户查询具有可利用的查询内并行结构，简单的schema-based分解就能带来显著的延迟改善。

方法详解¶

整体框架¶

ParallelPrompt包含三个组件：(1) 数据筛选管道：从LMSYS-Chat-1M和WildChat-1M中用Claude 3.5进行多阶段分类和schema提取，再用规则验证（支持多语言）；(2) 结构化标注：每个查询标注为5-field schema（任务模板、共享上下文、数据列表/生成数量等）；(3) 执行评估套件：C++高性能后端，对比串行和并行执行的延迟、结构一致性和语义保真度。

关键设计¶

多阶段筛选管道：
做什么：从200万+原始查询中筛选出可并行的37000+条
核心流程：Claude 3.5分类→schema提取→三层验证（高置信62%有显式结构标记、中置信38%依赖语义线索、失败38.6%的候选被拒）
设计动机：精确率优先于召回率——宁可漏掉一些可并行查询，也要确保被标注的确实可以安全并行执行
发现：10.3%的用户查询具有可分解结构，这个比例出人意料地高
分类体系：
做什么：将并行模式分为7个canonical类别 + 400+新兴类别
7个主类：重复生成（25%）、阅读理解（30%）、命名实体识别（30%）、关键词提取（7%）、翻译（9%）、语言校正（6%）、情感分析（3%）
400+新兴类别按6个元类别组织：比较型、生成型、分析型、变换型、组织型、计算型
多语言覆盖：11+种语言，中文5.6%、俄文6.3%，但非西方语言验证成功率较低（28-34% vs 55-63%）
执行与评估框架：
做什么：用C++后端实现精确的延迟测量，用schema-based分解替代特定任务的分解逻辑
评估维度：延迟（raw speedup和normalized speedup）、语义保真度（GPT-4o judge）、结构一致性
Normalized speedup的设计：LLM处理多任务时倾向于"长度预算"导致截断（要10个故事则每个只写50字），并行执行每个子任务都获得完整上下文，所以需要调整token长度差异

实验关键数据¶

主实验（schema提取用Claude 3.5，执行用GPT-4-1106-preview）¶

任务类别	并行均时(s)	串行均时(s)	Normalized加速	Raw加速
关键词提取	2.38	3.23	2.54×	1.36×
阅读理解	3.49	10.27	5.72×	2.94×
重复生成	3.79	9.51	4.39×	2.50×
重复生成(E2E含提取)	4.88	9.51	3.41×	1.70×

质量保持分析¶

任务类别	质量保持率	影响程度
阅读理解	92%	低（独立问答保持语义准确性）
关键词/实体抽取	82-85%	中等（一致性和冗余处理有损失）
创意生成	76%	高（叙事连贯性和风格一致性受损）

关键发现¶

串行执行时间随输出数量 \(n\) 线性增长，并行基本保持恒定——\(n\) 越大加速越明显
SoT和ToP在真实查询上大量失败：SoT的两阶段outline-expand假设不适用于抽取任务，ToP的递归分解对扁平独立任务产生不必要开销
包含schema提取开销的E2E加速仍达3.41×，说明提取成本被并行收益覆盖
非西方语言的schema提取质量明显更低，东亚语言验证成功率仅28-34%

亮点与洞察¶

"10%的查询可并行"这个统计发现本身就很有价值：对于日处理数十亿查询的生产系统，这意味着数亿次优化机会，且与现有优化（推测解码、KV缓存）完全互补
Schema-based分解的通用性比task-specific方法好得多：只需模板+上下文+数据列表三个字段就能处理各种并行模式，而SoT/ToP只适用于特定类型
Quality-Speedup的task-dependent trade-off图（Figure 7）提供了清晰的决策指南：结构化抽取任务是并行的甜区，创意生成需要谨慎

局限性 / 可改进方向¶

Schema提取依赖Claude 3.5（闭源），且对非西方语言效果差——需要探索开源替代和多语言优化
只测试了"可完全分解"的查询——现实中很多查询有部分依赖（如"先总结再对比"），需要支持DAG式的半并行执行
执行端用GPT-4 API，受API rate limit影响；在本地部署场景下（如vLLM），并行收益的经济性分析未做
Benchmark偏向信息抽取类任务（NER 30% + 阅读理解 30%），创意生成类的代表性不足
未讨论并行执行后结果的重组和排序问题——对某些任务（如有序列表），结果合并可能引入额外复杂性

评分¶

新颖性: ⭐⭐⭐⭐ 查询内并行是一个新颖且重要的研究方向，首个标准基准
实验充分度: ⭐⭐⭐⭐ 37000+查询、多任务类别、质量分析详尽，但模型覆盖有限
写作质量: ⭐⭐⭐⭐ 结构清晰，可视化丰富，但某些部分重复冗长
价值: ⭐⭐⭐⭐⭐ 对LLM serving有直接的工程价值，基准数据集将推动该方向研究