Q64：冻结大模型主干，联合适配读出网络提效

多问题共享文档的场景里，每次问答都重算一遍文档表示，是当下大模型推理中一笔不小的浪费。一篇来自 rss 的技术报告提出了 Q64——一个候选打分系统，思路很直接：把 64 层 Qwen3.8-27B 文本主干完全冻结，复用它的混合前缀状态和中间文档表示，再联合训练一个残差适配器、一个四层解码器和一个以候选答案为条件的读出网络。

两个机会：复用计算与重学打分

原文把共享文档上的重复决策拆成两个独立的机会。其一是复用文档计算：同一份文档被多个问题反复读取时，文档侧的表示可以只算一次。其二是适配打分方式：问题表示如何给候选答案打分，本身是可以学习的，不必沿用主干原有的读出逻辑。

Q64 同时押注这两点。冻结主干保证了文档表示的一致性，也让复用成为可能；联合训练残差适配器与读出网络，则是在冻结表示之上重新组织“问题—候选”的打分关系。这个组合是系统层面的设计，而不是某个孤立组件的改进——原文在结论里也特意强调了这一点。

前缀状态复用（Prefix State Reuse）：在 Transformer 类模型中，处理同一段文档时，各层产生的键值缓存（KV Cache）与前缀隐藏状态只依赖文档本身，与后续问题无关。多问题共享同一文档时，若主干被冻结，这些状态可计算一次并在后续请求中直接复用，避免对每个问题重复前向传播。这是 Q64 延迟收益的主要来源，也解释了为何收益只在“一文档多问题”负载中出现，单问题请求无法摊薄首次计算成本。

候选条件读出网络（Candidate-Conditioned Readout）：传统做法是用问题表示与候选答案表示做点积或简单拼接打分。候选条件读出则把候选答案作为额外输入，让读出网络动态生成打分权重，从而在冻结主干之上重新学习“问题—候选”的交互方式。它不改变文档表示，只改变最终决策层，因此可训练参数少、对主干知识干扰小。

88.66M 参数与 8,192 个训练视图

最终适配阶段只更新 88.66 万级参数中的 88.66 million，即 8866 万个参数，训练数据为 8,192 个精选视图。相对于 27B 的主干，这个可训练规模相当克制，说明作者希望把改动集中在读出与适配层，而不去动主干的知识。

设计探索过程借助了 ZiYor——一个自进化的 AI 系统。作者用它来探索和细化 Q64 的设计，随后自行指定打分方法、实现系统，并评估准确率与延迟。这种“AI 辅助设计 + 人工实现验证”的流程，本身也是当前系统研究里值得留意的一种工作方式。

残差适配器（Residual Adapter）：一种轻量微调结构，通常在冻结层旁插入一个小型可训练模块，其输出以残差方式加回原层输出。它不修改主干权重，只学习对冻结表示的偏移量，因此能在保持原模型知识的同时适配新任务。Q64 中的残差适配器与四层解码器、读出网络联合训练，共同承担从冻结文档表示到候选打分的映射。

自进化 AI 系统 ZiYor：指能够借助自身迭代来探索、生成和优化设计方案的 AI 系统。在本文中，作者用 ZiYor 辅助搜索 Q64 的架构与训练配置，但最终打分方法、系统实现和评估仍由人工完成并验证。这种“AI 探索设计空间 + 人工落地验证”的分工，是当前系统研究中逐渐出现的一种协作范式，其价值在于扩大设计搜索覆盖面，而非替代工程判断。

准确率：74.32% 的进步与差距

评估集是固定的 5,112 条样本，混合了 ARC-Challenge、ANLI-R3，以及 MMLU-Pro 和 CMMLU 的分层子集。联合适配把四基准宏平均准确率从 66.46% 提升到 74.32%，提升幅度明显。

但原文没有回避短板：这一数字仍低于原生 27B 基线的 75.68%，也低于 AnyJev Qwen3-32B L0 的 76.68%。也就是说，Q64 在准确率上并未超越未做改动的原生模型，更不用说更大的对照配置。原文对此的定性是，证据支持的是一个准确率—延迟的权衡，而不是主干缩减或孤立组件的优势。

延迟：2.237 秒与 56.872 秒

延迟数据来自一个单独的合成负载：4,096 个文档 token、50 个问题。Q64 的中位冷请求延迟是 2.237 秒，原生基线为 5.383 秒，而实测的批处理 AnyJev 配置为 56.872 秒。在多问题共享长文档的设定下，复用文档计算带来的收益是数量级层面的。

原文同时给出了一条重要的边界条件：短的单问题请求并不共享这一优势。这符合直觉——文档只被读一次时，前缀复用无从谈起，适配层反而可能带来额外开销。因此 Q64 的适用面是有明确前提的，即“同一文档、多个问题”的重复决策负载。

中位冷请求延迟（Median Cold-Request Latency）：冷请求指不依赖已有缓存、需从头处理文档的请求。报告取中位数而非平均值，是为了降低个别长尾请求对整体指标的拉扯，更稳健地反映典型体验。Q64 的 2.237 秒对应 4,096 文档 token、50 个问题的合成负载，其中文档侧计算被复用，因此摊到每个问题上的延迟显著低于逐问题重算的原生基线 5.383 秒；批处理 AnyJev 配置的 56.872 秒则反映了未做前缀复用时的串行开销。

证据边界与开放问题

作者对结论的表述相当克制。公开基准只用于早期开发阶段，真实文档上的多问题验证仍然开放。换句话说，目前的结果建立在固定评估集和合成负载之上，距离生产环境的真实文档场景还有一段验证距离。

从工程视角看，Q64 的价值不在于刷新某个榜单，而在于给出了一种可复用的系统范式：冻结主干、复用前缀状态、在读出层做联合适配，用少量可训练参数换取多问题场景下的延迟收益。至于这套范式在真实文档分布上能否保持同样的权衡曲线，是后续最值得关注的问题。