第18篇-Speculative-Decoding-投机解码加速推理

【AIaaS 全栈架构师】第 18 篇：Speculative Decoding——投机解码如何加速推理 2-3 倍

本系列定位：面向全栈架构师的 AIaaS 系统化教程。本篇为模块三"模型推理与部署优化"的第五篇，深入投机解码这一推理加速的核心算法。技术栈以 Go 为主，Python/C++ 为辅。

---

本篇你将学到

• 理解自回归解码的串行瓶颈：为什么 Decode 阶段每步只能出一个 Token
• 掌握 Draft Model 投机解码的核心思想：小模型快速起草、大模型并行验证
• 学会分析接受率与加速比的关系，理解"为什么投机解码能做到无损"
• 深入 Medusa、EAGLE/EAGLE-2、Lookahead Decoding、N-gram 投机四大变体的原理与取舍
• 建立投机解码方案选型框架，知道在什么场景该用哪种方案

学完本篇，你将能在 vLLM、TensorRT-LLM 等引擎中正确配置投机解码参数，并理解每种方案对显存、延迟和接受率的影响。

---

一、回顾：自回归解码的串行瓶颈

1.1 自回归生成的本质

第 14 篇我们讲过，大语言模型生成文本的方式是**自回归（Autoregressive）**的：每一步根据已有的全部 Token，预测下一个 Token，再把新 Token 拼回去，循环往复。

输入：     "中国的首都是"
第 1 步：   "中国的首都是" → 预测 "北"
第 2 步：   "中国的首都是北" → 预测 "京"
第 3 步：   "中国的首都是北京" → 预测 "."
...

要生成 100 个 Token，就必须跑 100 次前向传播。这就是串行瓶颈。

1.2 Prefill 与 Decode 的不对称

第 16 篇讲 Continuous Batching 时我们引入了两个阶段：

阶段	计算特征	并行度	GPU 利用率
Prefill（预填充）	处理整个 prompt，一次算出所有 Token 的 KV Cache	高（长序列并行计算）	高（70%+）
Decode（解码）	每次只算 1 个 Token，追加到 KV Cache	极低（batch 内各请求并行，但单请求内串行）	低（常常不足 5%）

关键矛盾在 Decode 阶段：

• 每步只处理 1 个新 Token，但要把整棵 Transformer走一遍
• 计算量很小（只算 1 个 Token 的 QKV），但访存量很大（要读所有注意力权重 + 上层 MLP 权重）
• 这是典型的**访存密集型（Memory-Bound）**操作，GPU 大量算力闲置

核心洞察：Decode 阶段 GPU 算力严重过剩，瓶颈在访存带宽。如果我们能让每一步多算几个 Token，就能充分利用闲置算力。

1.3 为什么不能直接一次预测多个 Token？

你可能会问：既然 GPU 闲着，为什么不让模型一步直接输出 5 个 Token？

答案是：Transformer 的标准结构只输出每个位置的概率分布，位置 $t$ 的输出只依赖前面 $\mathrm{0..}t$ 的输入。要预测位置 $t+2$ 的 Token，必须先知道位置 $t+1$ 是什么——这又回到了串行。

投机解码的核心创意正是围绕这个矛盾展开的：用一个"草稿来源"先把后续 k 个 Token 猜出来，再让大模型一次并行验证这 k 个 Token 是否正确。

---

二、Draft Model 投机解码：核心思想

2.1 朴素想法

假设我们有两个模型：

• Target Model（目标模型）：你真正想用的大模型，比如 Llama-3-70B，质量高但慢
• Draft Model（草稿模型）：一个同家族的小模型，比如 Llama-3-8B，质量稍差但快得多

流程：

1. 让 Draft Model 自回归生成 k 个候选 Token（比如 k=4）
2. 把这 k 个 Token 一次性喂给 Target Model，让它并行验证
3. Target Model 一次前向传播就能给出这 k 个位置各自的概率分布
4. 对比 Draft 的猜测和 Target 的真实分布，接受匹配的前缀，拒绝后从第一个不匹配处重新采样

2.2 为什么能加速？

关键在于并行验证。Target Model 验证 k 个 Token 的成本，和生成 1 个 Token 几乎一样——因为它们是一次前向传播算出来的（Prefill 模式处理这 k 个候选位置）。

2.3 数学本质：无损性证明

这是投机解码最巧妙的地方——它是无损的。最终输出的分布和直接用 Target Model 生成完全一致。

原理基于拒绝采样（Rejection Sampling）：

设 Draft 在位置 $i$ 采样的 Token 是 $x_i$，Target 在该位置的真实概率分布是 $q(x)$，Draft 的分布是 $p(x)$。

对每个候选 Token $x_i$：

• 若 $q(x_i)\ge p(x_i)$：直接接受（Draft 选了个 Target 也觉得合理的 Token）
• 若 $q(x_i)<p(x_i)$：以概率 $\frac{q(x_i)}{p(x_i)}$ 接受，否则拒绝
• 一旦拒绝，从归一化分布 $\text{normalize}(\max (0,q(x)-p(x)))$ 重新采样一个 Token

可以证明（Leviathan et al., 2022），这样得到的最终分布严格等于 Target 的分布 $q(x)$。也就是说：投机解码不损失任何精度，只是可能"浪费"一些计算。

---

三、接受率与加速比分析

3.1 接受率（Acceptance Rate）

设 Draft 和 Target 在每个位置的 Token 完全一致的概率为 $\alpha$（接受率）。一次投机 $k$ 个 Token，期望接受的 Token 数为：

$$E[\text{接受数}]=\sum _{i=1}^k{\alpha }^i\cdot (1-\alpha )+k\cdot {\alpha }^k\approx \frac{\alpha (1-{\alpha }^k)}{1-\alpha }$$

举个例子，$\alpha =0.7,k=4$：

• 至少接受 1 个的概率：$1-(1-0.7{)}^1\approx 1.0$（很高）
• 接受 1 个：$0.7$
• 接受 2 个：$0.7^2=0.49$
• 接受 3 个：$0.343$
• 接受 4 个（全部）：$0.24$
• 期望接受数 ≈ $0.7\times (1-0.7^4)/(1-0.7)\approx 2.14$ 个

3.2 加速比公式

设 $c_D$ 是 Draft 单步成本，$c_T$ 是 Target 单步成本。投机 $k$ 个 Token 的总成本约为 $k\cdot c_D+c_T$（k 次 Draft 前向 + 1 次 Target 前向）。

传统方式生成 $E$ 个 Token 的成本是 $E\cdot c_T$。加速比：

$$\text{Speedup}=\frac{E\cdot c_T}{k\cdot c_D+c_T}=\frac{E}{k\cdot \frac{c_D}{c_T}+1}$$

继续上面的例子（$E=2.14,c_D/c_T=0.1$ 假设 Draft 是 Target 的 1/10 算力，$k=4$）：

$$\text{Speedup}=\frac{2.14}{4\times 0.1+1}\approx 1.53\text{ 倍}$$

如果接受率更高（$\alpha =0.85$），$E\approx 3.0$，加速比 ≈ 2.1 倍。

3.3 加速比影响因素一览

因素	影响	说明
接受率 $\alpha$	核心	Draft 与 Target 分布越接近，$\alpha$ 越高
候选长度 $k$	双刃	太小收益有限，太大浪费 Draft 计算
Draft 成本 $c_D$	重要	Draft 越小越省，但太小可能导致接受率低
批大小	重要	大 batch 下 Target 已近算力饱和，投机收益递减

经验值：在 batch=1（单用户）场景下，加速比通常在 2-3 倍；batch > 32 时收益急剧下降，因为 Continuous Batching（第 16 篇）已经让 GPU 忙起来了。

---

四、投机解码变体全景

朴素 Draft Model 方案有几个痛点：

1. 要维护两个模型：增加显存和管理复杂度
2. Draft 和 Target 必须同家族：否则接受率太低（不同模型 Token 化都可能不一样）
3. Draft 模型本身仍是串行：生成 k 个 Token 仍是 k 步

后续衍生了一系列变体来解决这些问题。

下面逐个展开。

---

五、Medusa：多头并行起草

5.1 核心思想

Medusa（Cai et al., 2024）的想法是：与其另起炉灶训一个 Draft Model，不如直接在 Target Model 上加几个"预测头"，让一个前向传播同时预测未来多个位置的 Token。

标准 Transformer 只有最后一个 Hidden State 进入 LM Head 输出下一个 Token。Medusa 在此基础上添加多个 Medusa Head：

• Head 1：预测位置 $t+1$（标准 LM Head）
• Head 2：预测位置 $t+2$（跳过一步，直接预测）
• Head 3：预测位置 $t+3$
• Head 4：预测位置 $t+4$
• …

每个 Head 是一个轻量的 MLP（输入是当前层的 Hidden State），独立预测未来第 $i$ 个位置的 Token。

5.2 工作流程

1. Target Model 跑一次前向，得到 Hidden State
2. 各 Medusa Head 同时预测 $t+1,t+2,t+3,t+4$ 的候选 Token（每个 Head 取 Top-k 候选）
3. 用 Tree Attention 构造一棵候选树，一次 Target 前向验证整棵树
4. 接受最长匹配路径

关键优势：起草过程完全并行，不需要 k 次串行前向。

5.3 Tree Attention

由于每个 Head 给出 Top-k 候选（比如 k=4），4 个 Head 共有 $4^4=256$ 种组合。Medusa 用一棵剪枝后的候选树来验证，比如典型的 Medusa 树有 64 个节点。

Tree Attention 的实现是：将候选树的所有节点排成一个序列，通过修改注意力掩码让每个节点只能看到自己的祖先路径。这样一次前向就能并行验证所有候选。

5.4 训练成本

Medusa Head 需要在目标模型上做少量微调（典型 1-2 个 epoch），冻结主干只训 Head。训练数据可以是模型自己生成的语料，成本不高。

方面	Medusa	Draft Model
额外模型	无（仅几个 MLP Head）	是（一整个小模型）
起草方式	并行（1 次前向）	串行（k 次前向）
接受率	中等（30-50%）	高（同家族时 60-80%）
训练成本	微调 Medusa Head	用现成小模型即可
显存增量	小	大（要装第二个模型）

---

六、EAGLE / EAGLE-2：自回归特征预测

6.1 动机：Token 太离散，特征更连续

Medusa 直接预测 Token 概率分布，但 Token 是离散的、跳跃的，误差大。EAGLE（Li et al., 2024）的洞察是：预测 Hidden Feature（隐藏层特征）比预测 Token 更容易、更准确。

6.2 EAGLE 架构

EAGLE 在 Target Model 之上加一个轻量的 Auto-Regressive Draft Network：

1. 输入：Target 当前位置的 Hidden State + 上一步采样的 Token Embedding
2. 用一个 1-2 层的小 Transformer（与 Target 共享 embedding）预测下一个位置的 Hidden State
3. 把预测的 Hidden State 喂入 Target 的 LM Head，得到 Token 分布
4. 自回归地重复，得到 k 个候选 Token
5. Tree Attention 并行验证

和 Medusa 的关键区别：

维度	Medusa	EAGLE
预测对象	Token（离散）	Hidden Feature（连续）
起草方式	多个并行 Head	单个自回归小网络
特征利用	只用最后层 Hidden	融合 Hidden + Token Embedding
接受率	30-50%	60-80%+

EAGLE 的接受率显著高于 Medusa，因此加速比也更高——论文报告在 LLaMA-2-70B 上达到 3x 以上的端到端加速。

6.3 EAGLE-2 的改进

EAGLE-2（Li et al., 2024）进一步引入上下文感知的动态候选树：

• EAGLE-1 用固定形状的候选树（每次都展开 64 个节点）
• EAGLE-2 根据每个位置的实际置信度动态分配候选预算：高置信位置多展开几个分支，低置信位置少展开
• 通过 Best-First Search 在 Draft 网络输出的概率树上搜索 Top-N 候选路径

EAGLE-2 的接受率进一步提到 70-85%，端到端加速可达 4-5x（在 batch=1 场景）。

6.4 vLLM 中的 EAGLE 支持

vLLM 0.5+ 原生支持 EAGLE，启动参数示例：

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Meta-Llama-3-8B-Instruct \
    --speculative-model "JeffreyBolt/Llama-3-8B-Instruct-EAGLE" \
    --use-v2-block-manager \
    --speculative-draft-tensor-parallel-size 1

关键参数：

• --speculative-model：指定 EAGLE 辅助网络（需提前训练好）
• --speculative-draft-tensor-parallel-size：辅助网络的张量并行度

---

七、Lookahead Decoding：基于 Jacobi 迭代

7.1 Jacobi 迭代回顾

前面所有方案都需要某种"草稿来源"（Draft Model / Medusa Head / EAGLE 网络）。Lookahead Decoding（Fu et al., 2024）走了一条完全不同的路：完全不需要任何额外训练。

它的理论基础是 Jacobi Iteration：解方程组 $x=F(x)$ 时，从一个初始猜测 $x^{(0)}$ 出发，反复用 $x^{(t+1)}=F(x^{(t)})$ 迭代。

应用到自回归生成：把"生成 n 个 Token"看作在求解一个 n 元方程（每个位置的最优 Token 相互依赖）。从随机初值出发，多次 Jacobi 迭代就能收敛到正确答案。

7.2 工作机制

Lookahead Decoding 维护一个 N-gram Pool（候选池），通过 Jacobi 迭代不断生成新的候选 N-gram，再用 Target 验证：

1. 保留一个固定大小的滑动窗口（window size = $W$）
2. 每一步用 Jacobi 迭代对窗口内所有位置同时更新一次
3. 把每次迭代的中间结果存入 N-gram Pool
4. Target 一次前向验证 Pool 中所有候选

7.3 优劣分析

优点：

• 零训练：不需要任何额外模型，开箱即用
• 零额外显存（除一个小的 N-gram Pool）
• 跨模型通用：换模型无需重训

缺点：

• 加速比相对有限（典型 1.5-2x，不如 EAGLE）
• 对短重复模式效果好，长逻辑推理效果一般
• Jacobi 迭代需要多步收敛，window 太大会增加延迟

7.4 适用场景

• 快速验证、原型开发（不想训 Draft 模型）
• 模型迭代频繁（每换一个模型都要重训 EAGLE 太麻烦）
• 离线批量生成（接受率不高没关系，反正要批处理）

---

八、N-gram 投机解码：零额外模型

8.1 思想

N-gram 投机是最简单粗暴的方案：用一个 N-gram 统计表作为草稿来源。

核心观察：在很多任务中，输出文本有大量重复模式——比如代码生成中的 def/return/import、SQL 中的 SELECT/FROM/WHERE、对话中的常用短语。这些重复模式可以用 N-gram 频率表捕捉。

8.2 实现

维护一个静态或动态的 N-gram 模型：

• 静态：用大量语料离线统计 N-gram 频率，存成查表
• 动态：在生成过程中实时收集已生成 Token 的 N-gram（vLLM 默认实现）

生成时，根据当前上下文的最后 N-1 个 Token，查表预测接下来最可能的 k 个 Token。

8.3 vLLM 中的使用

vLLM 自 0.5 起内置了 N-gram 投机解码，启动参数极简：

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Meta-Llama-3-8B-Instruct \
    --speculative-model "[ngram]" \
    --num-speculative-tokens 5 \
    --ngram-prompt-lookup-max 4

参数说明：

• --speculative-model "[ngram]"：使用内置 N-gram 投机
• --num-speculative-tokens：每次投机几个 Token
• --ngram-prompt-lookup-max：N-gram 的最大 N

8.4 效果评估

任务类型	接受率	加速比
代码生成（高度重复）	50-70%	1.8-2.5x
SQL 生成	60-75%	2.0-2.8x
翻译（高重复短语）	40-55%	1.5-2.0x
开放对话（低重复）	15-30%	1.1-1.4x
创意写作（最低重复）	10-20%	<1.2x（可能负收益）

N-gram 投机的特点是对任务极其敏感：高度结构化任务收益巨大，开放生成收益微弱。

---

九、方案对比与选型决策

9.1 五大方案横向对比

方案	额外训练	额外显存	接受率	典型加速比	实现复杂度	引擎支持
Draft Model	无（用现成小模型）	大	60-80%	2-3x	中	vLLM, TRT-LLM
Medusa	微调 Head	小	30-50%	2-2.5x	中	vLLM, TGI
EAGLE-2	训练辅助网络	小	70-85%	3-5x	中高	vLLM, TRT-LLM
Lookahead	无	极小	-	1.5-2x	低	vLLM
N-gram	无	极小	任务相关	1.2-2.8x	极低	vLLM

9.2 选型决策树

9.3 几个工程经验

1. 先测接受率：上投机解码前，先用一小批样本测出实际接受率。接受率低于 30% 时收益不显著，低于 20% 可能负收益（验证开销超过收益）。

2. batch 越大收益越低：单用户场景（batch=1）收益最大，高并发场景（batch > 32）GPU 已经被 Continuous Batching 喂饱，投机解码反而增加调度开销。典型适用场景是低延迟交互式应用（聊天、IDE 补全）。

3. 候选长度 k 不是越大越好：经验值 k=4~8 较合适。k 太大会让 Draft 生成成本线性增加，而接受率随位置衰减。

4. 同家族 Draft Model 接受率最高：跨家族（比如用 Qwen 当 Llama 的 Draft）接受率会断崖式下降，因为 Tokenizer 不同，Token 边界都对不齐。

5. 量化与投机解码可叠加：用 INT4 量化的 Target + INT4 量化的 Draft，能进一步压低显存和加速。但要注意 Draft 也需量化。

---

十、投机解码的工程实现要点

10.1 Tree Attention 的实现

所有变体最终都要落到"并行验证一棵候选树"。Tree Attention 的实现要点：

• 候选树展平：把树的所有节点按 BFS/DFS 顺序展平成序列
• Attention Mask 构造：每个节点 $i$ 只能看到其所有祖先 $\text{ancestor}(i)$ 及自己。掩码是一个 $L\times L$ 的下三角矩阵（L 是候选树节点数）
• 位置编码：每个节点的 position_id 等于它在原序列中的位置（$t,t+1,t+2,\dots$）
• 采样：Target 一次前向后，对每个节点得到概率分布，做拒绝采样

vLLM 内部用 torch.cuda.Stream 并发处理多棵候选树（多个请求各自的 Tree Attention 互不干扰）。

10.2 显存与调度的耦合

投机解码与 PagedAttention（第 15 篇）+ Continuous Batching（第 16 篇）的耦合是个工程难点：

• KV Cache 预分配：候选树的每个节点都需要预留 KV Cache 位置，浪费部分显存
• 拒绝后的回滚：被拒绝的候选 Token 的 KV Cache 要立即释放
• Batch 调度：每个请求的候选树大小可能不同，如何与 Continuous Batching 的迭代步调对齐

vLLM 用 V2 Block Manager 专门处理投机解码下的内存管理，比 V1 更高效但实现更复杂。

10.3 性能监控指标

生产环境上线投机解码后，关键监控指标：

指标	含义	健康阈值
spec_tokens_accept_rate	候选 Token 接受率	> 50%
spec_speedup_ratio	端到端加速比	> 1.5x
spec_draft_time_ratio	Draft 耗时 / 总耗时	< 30%
spec_wasted_compute_ratio	被拒绝的 Token 占比	< 50%

如果 spec_tokens_accept_rate 持续低于 30%，说明当前 Draft 方案与 Target 不匹配，应考虑切换方案或重训 Draft。

---

十一、与其他加速技术的叠加

投机解码不是孤立技术，它和模块三其他技术可以叠加：

11.1 与量化的叠加

• Target 模型量化：INT4/INT8 Target 模型本身已经加速 Decode，但访存仍是瓶颈，投机解码可继续叠加
• Draft 模型量化：Draft 模型量化后更快，起草阶段成本进一步降低
• 实践中：INT4 Target + FP16 Draft 是常见组合

11.2 与 Continuous Batching 的叠加

• 小 batch 下叠加收益大：batch=1 时投机解码收益 2-3x
• 大 batch 下收益消失：batch=64 时 Continuous Batching 已饱和，投机解码可能负收益
• 混合策略：根据实时 batch 大小动态开关投机解码

11.3 与 Prefix Caching 的叠加

• Prefix Caching（第 15 篇）复用 prompt 的 KV Cache，与投机解码无冲突
• 两者各自独立加速 Prefill 和 Decode 阶段，效果近似相加

11.4 叠加效果的经验数据

技术组合	单查询延迟加速	吞吐量影响
基线（FP16）	1.0x	1.0x
+ INT4 量化	1.5x	1.3x
+ Continuous Batching（batch=32）	5x	15x
+ EAGLE-2（batch=1）	10x	1.5x
全开（batch=1）	7-8x	1.5x

注意：单查询延迟和吞吐量是两个维度。投机解码主攻延迟（单用户体验），Continuous Batching 主攻吞吐量（系统并发）。

---

十二、实际部署案例

12.1 IDE 代码补全场景

特点：

• 极低延迟要求（< 100ms 首 Token）
• 单用户低并发（每个开发者一个会话）
• 输出高度重复（代码模板、API 名称）
• 短生成长度（一行到几行）

最佳方案：N-gram 投机 + 小模型

• N-gram 接受率在代码场景极高（60%+）
• 用 1B-3B 小模型做 Target，配合 N-gram 投机，端到端延迟可压到 50ms 内
• 无需训练 Draft 模型，部署极简

12.2 高并发对话场景

特点：

• 高并发（每秒数百 QPS）
• 中等延迟要求（200-500ms 首 Token）
• 输出多样（开放对话）

最佳方案：关闭投机解码，专注 Continuous Batching

• 大 batch 下投机解码收益消失
• Continuous Batching 已经让 GPU 满载
• 投机解码反而增加调度复杂度

12.3 长文档生成场景

特点：

• 低并发（每会话长生成）
• 长输出（数千 Token）
• 输出结构化程度中等

最佳方案：EAGLE-2 + Target 模型

• 长 Decode 阶段投机收益累积明显
• EAGLE 接受率稳定（70%+），加速比 3x+
• 单次训练 Draft 投入可长期复用

---

十三、投机解码的未来趋势

13.1 更智能的草稿来源

• 基于检索的草稿：从语料库直接检索相似上下文的续写，作为候选
• 基于强化学习的 Draft 训练：用 RL 直接优化 Draft 的接受率，而非最大似然
• 多模型协作：多个 Draft 模型级联，互补不同语义层

13.2 硬件协同设计

• NVIDIA Blackwell 的投机解码加速单元：B200 在硬件层面提供 Tree Attention 加速
• 推测式预取：硬件预取 KV Cache 的候选分支
• 专用 Draft 加速器：与主 GPU 解耦的小型 Draft 加速芯片

13.3 长上下文场景的优化

• 当前投机解码对长上下文（> 32k）收益有限，因为 Draft 难以捕捉长程依赖
• 未来方向：分段投机，对不同上下文窗口使用不同 Draft 策略

13.4 与多模态结合

• 视觉/音频 Token 的投机解码
• 多模态 Draft 模型（同时预测文本和图像 Token）

---

本篇小结

知识点	核心内容
自回归瓶颈	Decode 阶段每步只生成 1 个 Token，GPU 算力严重闲置，访存密集型
投机解码本质	用草稿来源生成 k 个候选 Token，Target 模型一次前向并行验证，接受匹配前缀
无损性	基于拒绝采样，最终分布严格等于 Target 分布，不损失精度
接受率 $\alpha$	草稿与 Target 一致的概率，是加速比的核心决定因素
Draft Model	经典方案，同家族小模型起草，接受率 60-80%，但需双模型
Medusa	多个并行 Head 预测多步 Token，起草并行，但接受率 30-50%
EAGLE-2	预测 Hidden Feature 而非 Token，接受率 70-85%，加速 3-5x
Lookahead Decoding	基于 Jacobi 迭代，零训练零模型，加速 1.5-2x
N-gram 投机	N-gram 统计表起草，零训练，任务敏感（代码/SQL 收益高）
选型核心	任务重复度 → N-gram；通用低延迟 → EAGLE；不能训练 → Lookahead/Draft Model
叠加效果	与量化、Continuous Batching、Prefix Caching 可正交叠加，主攻延迟维度

---

下篇预告

第 19 篇：模型格式转换全链路——从 PyTorch 到生产部署格式

模块三已经讨论了推理引擎、KV Cache、Continuous Batching、量化、投机解码等核心优化技术。但还有个绕不开的工程问题：训练好的模型是 PyTorch checkpoint，生产部署时却要变成 vLLM 的 Safetensors、llama.cpp 的 GGUF、TensorRT 的 Engine——这中间的格式转换链路怎么走？ 下一篇我们将系统梳理 Safetensors、ONNX、GGUF、TensorRT Engine 四大格式的特点与选择决策。

---

如果本篇内容对你有帮助，欢迎点赞收藏！有任何疑问，欢迎在评论区交流。