一句话看懂：小红书技术团队提出了名为 PIPO 的大模型推理架构，通过“成对输入、成对输出”的设计，在保持模型推理质量的同时，将首字延迟（TTFT）加速最高 2.64 倍，逐 token 生成速度（TPOT）加速最高 2.07 倍。这一做法直接回应了长链推理场景下日益突出的效率瓶颈。
事件核心：发生了什么
小红书大模型基建团队近日公开了其新架构 PIPO（Pair-In, Pair-Out）。该架构的核心思路是用一个轻量压缩器将两个输入 token 折叠为一个 latent 表示，从而将模型输入序列长度减半；同时在输出侧，借助多 token 预测头，让模型每一步解码同时产生一个主 token 和一个草稿 token。为解决草稿 token 的校验成本问题，PIPO 在训练阶段将原本需要推理时反复调用的验证模型“蒸馏”进了一个极轻量的置信度头，推理时只需一次前向即可决定是否接受草稿 token。基于 Qwen3.5-4B 和 9B 骨干模型，PIPO 在 AIME 2025、GPQA-Diamond、LiveCodeBench v6 和 LongBench v2 四个高难度基准上，pass@4 最高提升了 7.15 个百分点。在部署级测试中，模型推理质量无损，TTFT 加速约 1.23 倍，TPOT 加速约 1.86 倍。相关论文和项目代码已在 arXiv 与 GitHub 上公开。
为什么重要
当前大模型能力提升的重要路径之一是长链推理，但推理轨迹动辄上万 token，自回归解码的逐 token 成本和首字延迟已成为瓶颈。已有的优化路线分为两派：一类专注输出侧加速（如 speculative decoding、EAGLE），但验证成本高；另一类专注输入侧压缩（如 Coconut、CoLaR），但未改变单步只出一个 token 的节奏。PIPO 的贡献在于将这两个方向统一到了同一个“token pair”框架下，并借助训练阶段的蒸馏，绕开了推理时反复调用大模型验证器的开销。这意味着，在长上下文推理成为常态的今天，PIPO 提供了一条在不大幅改动现有模型骨干的前提下系统性地提升推理效率的路径。对于自研或部署长链推理模型的技术团队来说，这个架构提供了一个可直接复用的加速方案。
对用户/开发者/创作者的影响
对于开发者与 AI 应用团队：PIPO 已在 GitHub 开源，开发者可以直接在已有模型上尝试采用 pair-in/pair-out 模式，有望在保持模型输出质量的同时降低推理成本与延迟。尤其对于需要处理超长上下文（如代码生成、数学推理、长文档分析）的场景，TTFT 的减半将显著改善用户体验。对于 AI 模型能力使用方：如果小红书后续将 PIPO 集成到其业务模型或 API 中，用户将感知到更快的回复速度和更低的响应延迟，而推理质量的提升则意味着复杂问题的回答更准确。对于算力规划者：同等工作量下，PIPO 减少了 prefill 阶段的计算量和新 token 生成时的 backbone 调用次数，或在相同延时预算下支持更长的推理轨迹。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
1. 产品落地路径：目前 PIPO 仍是一个研究架构，小红书是否会将其集成到自身搜索、推荐或内容生成业务中，值得跟踪；若集成，用户体验的变化将是直接验证。2. 竞品与生态反应：Qwen、DeepSeek 等模型已内置 MTP 头，PIPO 的 pair-in 压缩思路是否会启发这些团队在自己的训练或推理管线中加入类似设计。3. 长上下文场景的实际收益验证：论文数据基于 32K slot 的 response budget 评估，未来在实际生产环境（更长上下文、更大并发）下的效率数据和部署经验将决定该架构的实用价值。
