长推理模型正集体撞上一面叫做“吞吐”的墙。你砸进去的算力越堆越厚，每往前走一步模型需要处理的 token 数量滚雪球般膨胀，首 token 延迟还能忍，逐 token 生成的速度已经让人想合上屏幕。小红书技术团队最近抛出的 PIPO 架构，没有去啃 KV cache 压缩这块最硬的骨头，而是从输入和输出两端同时动手——把输入 token 折成一半，再把每步输出的 token 翻倍。一压一扩之间，墙松动了。
墙在哪里：不是显存不够，是每一步都太重
KV cache 不是唯一卡脖子的地方
谈长上下文推理加速，大多数人的反射动作是压 KV cache。这没错，但只对了一半。即使你把 KV cache 压缩到接近零开销，每生成一个 token 仍然要把整个前缀序列重新过一遍自注意力，计算量与输入长度成正比。当输入长度膨胀到几十万 token 时，光这一步的浮点运算就是一笔天文数字。PIPO 的思路干脆利落：缩短输入本身。直接把输入 token 序列压缩一半，计算量立竿见影地砍下来，这和 KV cache 优化完全不矛盾，反而可以叠加。
输出端也不无辜
很多人都忘了，自回归模型一次只吐一个 token，哪怕你批处理再大，每一步的 GPU 计算利用率也高不到哪里去。要想提高吞吐，最直接的办法就是一次多吐几个。多 token 预测不是什么新鲜概念，但把输入压缩和多 token 预测放进同一个框架里、端到端联合优化，PIPO 大概是头一个。它问了一个很挑衅的问题：既然输出端能通过一次计算展开多个 token，为什么输入端就不能通过一次计算把多个 token 折叠起来？
问题统一，解法才能统一
这层直觉贯穿了 PIPO 的设计。传统做法里输入压缩往往依赖单独的编码器或重排序，和生成模型割裂，训练和推理之间还有 gap。PIPO 直接把压缩操作嵌入主干网络，输入侧是一个轻量的压缩器，输出侧是一个多 token 预测头，两边共享同一个隐藏表示，训练时一起更新。这样一来，缩短输入和扩展输出就不再是两张皮，而是一套对称动作——用更少的信息元表征前缀，同时在每次步骤中挤出更多续写结果。
拆开 PIPO：一个 latent，两头开花
把两个 token 折叠成一个脉冲
输入压缩器的原理像是一种可学习的“词汇再编码”。常规流程里，每个 token 经过嵌入层变成一个向量，再送进 Transformer 主干。PIPO 在嵌入层和主干之间插了一刀：相邻的两个 token 向量被馈入一个小型压缩模块，融合成单个 latent 向量。这个 latent 向量携带了两个 token 的语义信息，但只占用一个位置。序列长度直接除以二。主干网络看到的上下文窗瞬间缩短一半，所有后续计算——包括自注意力矩阵——都跟着瘦身。压缩模块参数很少，几乎不影响模型参数量，却把推理的总计算量拽下来一大截。
输出侧：一次前向，多步展开
有了压缩，输出端再采用多 token 预测头就更有底气了。主干在每个时间步产出一个隐藏状态，这个状态不仅用来解码当前 token，还通过 MTP head（Multi-Token Prediction head）直接展开出额外的若干个 token。论文里每步产出两个 token，相当于输出端吞吐翻倍。这样做不只是为了少跑几步前向，还有一个隐秘的好处：多个 token 在同一隐藏状态下生成，彼此共享上下文，比单独生成再拼接更连贯。部署测试也印证了这一点——TPOT 加速 1.86 倍，近九成的提升，足以让重解码场景下的体感完全不一样。
confidence head：把验证器蒸馏进模型
多 token 预测带来的一个隐患是可靠度。吐得快但吐得不准，等于白吐。PIPO 的解法很聪明：训练一个独立的 verifier 模型作为裁判，然后通过 On-Policy 蒸馏把裁判的判断力蒸馏成一个极轻量的 confidence head，直接挂在生成模型上。推理时，模型每输出一个 token，confidence head 同时给出一个置信度分数，低分结果会被即时丢弃或触发回退。这意味着以前需要外部校验器、多轮验证的成本，现在被前置进一步推理里，且几乎没有额外开销。既保住了速度，又不会让准确率血崩，这个技巧比架构本身更值得细看。
数字说话：4B 打 9B，加速看得见
AIME 2025 上的 +7.15，不是调参调出来的
团队用 Qwen3.5 的 4B 和 9B 作为基座来验证 PIPO。在 AIME 2025 这种需要密集长程推理的基准上，PIPO 加持的 4B 模型 pass@4 最高提升 7.15 个点，效果甚至在一定程度上追平了原生 9B 的表现。这不仅是量变，是让一个小得多的模型在困难推理任务上具备了跨量级的竞争力。值得注意的是，这种提升是在输入序列被物理压缩一半的前提下实现的，说明压缩并没有损失关键推理信息，反而可能像某种信息瓶颈一样过滤了噪声。
TTFT 加速 1.23 倍，但真正解渴的是 TPOT
首 token 延迟的优化总是温柔，因为压缩主要砍的是输入侧编码的计算量，而首 token 生成还包含大量冷启动开销。PIPO 的 TTFT 加速约 1.23 倍，不算爆炸。真正让人眼前发亮的是 TPOT 1.86 倍的提速。逐 token 延迟砍掉近一半，意味长序列生成的体感从“等着它一个字一个字往外蹦”变成“看着它两句话一起出来”。对于需要输出成百上千 token 的推理任务，这 1.86 倍是省时间，是省钱，也是让产品能接受的临界点。
两阶段训练里藏着的工程取舍
PIPO 的训练被拆成两个阶段：先用监督微调让模型学会压缩和展开的基本功，再用 On-Policy 蒸馏把 verifier 的判断能力注入 confidence head。第二阶段事实上是用模型自身策略生成的数据来对齐 verifier 的偏好，这样既能避免离策略数据带来的分布偏差，又不需要在推理时真的跑一个重量级 verifier。工程上的代价是训练成本略高，但推理时零额外开销，对于部署端来说是笔再划算不过的账。
这场试验给推理加速指了条什么路
压缩与展开的对称性，不是巧合
PIPO 最核心的贡献或许不是那两个组件本身，而是它把输入压缩和输出展开放到了同一个对称框架下思考。过去我们总是单独优化某一端，好像缩短输入和加速输出是两个不搭界的课题。PIPO 告诉我们，它们共享同一个隐藏表示，完全可以联合训练、互相增强。这种思路一旦被接受，类似的双向压缩-展开架构可能会在长推理场景里迅速铺开，而不再只是某个团队的一次性探索。
把验证器蒸馏进模型，将会成为标配
On-Policy 蒸馏得到的 confidence head 是一个轻量但杀伤力极大的模块。它让你在零推理成本增加的前提下，拥有了接近独立 verifier 的质量控制能力。以往做多 token 预测或投机解码总要面对一个问题：多出来的 token 有多少能用？现在 confidence head 直接给分，低分就丢掉，相当于把验证内化成了模型的一部分。这一招绝不只是 PIPO 的配套技巧，它可能成为未来所有追求高速生成模型的标配。
小模型用架构红利撬动大模型，才刚刚开始
当 4B 模型凭借一套巧妙的输入压缩和多 token 预测设计，在难度空前的基准上摸到 9B 的天花板，我们不得不重新审视“模型尺寸崇拜”。真正的增量往往来自架构和训练策略的重构，而不是无止尽地堆参数。小红书这次把论文和代码一并放出，对正在长推理苦海里挣扎的团队来说，不仅是一篇值得精读的工作，更是一张可以立刻上手改的蓝图。
