Parallel-Synthesis: Direct KV-Cache Synthesis for Parallel Branches in LLM-Agent Workflows

Review date: 2026-06-15 Review author: Zhongzhu Zhou Paper reviewed: Towards Direct Latent-Space Synthesis for Parallel Branches in LLM-Agent Workflows Paper authors: Shikun Liu et al. (Georgia Institute of Technology, Meta) arXiv: 2606.14672 Status: Preprint, June 2026

Short Answer

Modern agentic systems run parallel worker LLMs that each generate candidate solutions, subtask results, or research trajectories — and then funnel everything into a synthesizer LLM that produces the final answer. The catch: today’s synthesizers receive those branch outputs as plain concatenated text, and must re-prefill every token from scratch, even though the workers already computed those KV states during their own decoding pass. Parallel-Synthesis flips this by letting the synthesizer reuse worker KV caches directly, with a lightweight cache mapper + LoRA adapter to reconcile the positional and distributional mismatch. The result: comparable or better answer quality on nine diverse benchmarks, and a 2.5–11× reduction in time-to-first-token.

Prerequisites

Before diving into the paper’s technical machinery, this section lays out the background you need to follow along. We cover attention, KV caches, positional encodings, LoRA, and the fundamentals of multi-agent orchestration.

Transformer Self-Attention and the KV Cache

A Transformer decoder generates tokens one at a time. At each step $t$, the model computes a query $Q_t$, and attends over keys $K_{1..t}$ and values $V_{1..t}$:

$$\text{Attn}(Q_t, K_{1:t}, V_{1:t}) = \text{softmax}\!\left(\frac{Q_t K_{1:t}^T}{\sqrt{d_k}}\right) V_{1:t} \tag{1}$$

Recomputing $K_{1..t}$ and $V_{1..t}$ at every step would be quadratic in sequence length. The KV cache solves this by caching the key and value projections for every previously generated token across every layer. When the model decodes token $t+1$, it appends the new $K_{t+1}, V_{t+1}$ to the cache and reads from the entire cached prefix — no recomputation needed.

Formally, after a worker agent generates a sequence $z = (z_1, z_2, \ldots, z_{|z|})$ conditioned on context $c$, its KV cache for layer $\ell$ is:

$$\text{KV}_\theta(z | c) = \{(K_z^\ell, V_z^\ell)\}_{\ell=1}^L \tag{2}$$

where $K_z^\ell \in \mathbb{R}^{|z| \times d_k}$ and $V_z^\ell \in \mathbb{R}^{|z| \times d_v}$ are the per-layer projections for the $z$ segment. The cache for the full context-plus-output $(c, z)$ is obtained by concatenating the context cache and the output cache.

Rotary Positional Encoding (RoPE)

Modern LLMs encode sequence position using Rotary Position Embeddings (RoPE) (Su et al., 2022). Rather than adding a position vector to the token embedding, RoPE applies a position-dependent rotation to the query and key vectors before computing attention:

$$Q_t = R(t) \cdot W_Q x_t, \quad K_t = R(t) \cdot W_K x_t \tag{3}$$

where $R(t)$ is a block-diagonal rotation matrix parameterised by position $t$. The inner product $Q_s \cdot K_t$ then naturally encodes the relative distance $s - t$ — the model only attends to how far apart two tokens are, not their absolute positions. This is crucial for generalising to contexts longer than training.

The key consequence for Parallel-Synthesis: every cached KV vector carries an embedded position index. If a worker agent produces output $z$ after a context $c$ of length $n$, the $r$-th token of $z$ is cached at absolute position $n + r$. When the synthesizer later tries to attend over caches from multiple branches with different context lengths $|c_j|$, the position indices become inconsistent — branch 1’s tokens may be at positions 512–700, branch 2’s at 640–830. Before concatenating them, the positions must be realigned.

Low-Rank Adaptation (LoRA)

LoRA (Hu et al., 2021) is the canonical efficient fine-tuning technique: instead of updating the full weight matrix $W \in \mathbb{R}^{d \times k}$, we freeze $W$ and learn a residual $\Delta W = A B^T$, where $A \in \mathbb{R}^{d \times r}$ and $B \in \mathbb{R}^{k \times r}$ with rank $r \ll \min(d, k)$. The modified forward pass is:

$$h = (W + \Delta W) x = W x + A B^T x \tag{4}$$

Parameter count drops from $d \times k$ to $r(d + k)$. For a 7B-parameter model with $r = 64$, this can mean adapting fewer than 1% of parameters. Parallel-Synthesis uses a LoRA on the synthesizer to teach it to interpret the non-sequential multi-branch cache interface without touching the backbone weights.

DAG-Structured Agentic Workflows

Real-world agentic tasks are rarely linear chains. Research assistants explore multiple hypotheses in parallel; coding agents sample $k$ candidate solutions and then select the best; database-diagnosis agents run concurrent subtask agents and synthesize findings. These workflows are naturally represented as directed acyclic graphs (DAGs): independent branches execute in parallel, and a downstream node (the synthesizer) aggregates all results.

Figure 1: DAG agentic workflow for parallel research synthesis

graph TD
    Q["User Query / Task"] --> B["Branch Split"]
    B --> W1["Worker Agent 1\n(subtask: literature)"]
    B --> W2["Worker Agent 2\n(subtask: methodology)"]
    B --> W3["Worker Agent 3\n(subtask: experiment design)"]
    W1 -->|"text output z₁ or KV cache"| S["Synthesizer LLM"]
    W2 -->|"text output z₂ or KV cache"| S
    W3 -->|"text output z₃ or KV cache"| S
    S --> A["Final Answer y"]

    style S fill:#ff9966,stroke:#cc6600
    style Q fill:#66ccff,stroke:#0066cc

The problem is the arrow leading into the synthesizer. Today’s systems serialise all $z_j$ as text (orange arrows are text strings). Parallel-Synthesis replaces those with direct KV-cache transfer (the orange box gets caches, not strings).

Multi-Agent Systems and the Synthesis Bottleneck

Multi-agent orchestration frameworks (AutoGen, LangGraph, OpenAI Swarm, Anthropic’s agent SDK) all share the same bottleneck: when $m$ parallel branches complete and must be merged, the orchestrator:

1. Waits for all $m$ workers to finish generating.
2. Concatenates their text outputs: $x_{text} = u \circ z_1 \circ \cdots \circ z_m$.
3. Re-prefills the entire concatenated prefix from scratch — even though the workers already computed all those KV states internally.

The re-prefill cost is $O(|x_{text}|^2)$ in naive attention and $O(|x_{text}|)$ in KV-cache-enabled inference — but crucially, it is proportional to the total length of all branch outputs. For $m = 4$ branches each generating 2000 tokens, re-prefilling means encoding 8000 tokens before generating the first output token. Parallel-Synthesis eliminates this re-prefill entirely.

Paper Overview

Parallel-Synthesis addresses a fundamental inefficiency in multi-agent LLM systems: the synthesizer re-encodes content that workers already encoded. The solution involves three mutually-supporting components:

1. Positional re-encoding: Realign branch KV caches so all branches appear to start at the same position $n$ (the branching point in the shared prefix).
2. Cache mapper: A lightweight learned transformation per layer that calibrates the KV distributions of independently generated branch caches, correcting for the distributional shift from generating under different branch-specific contexts.
3. Synthesizer LoRA: A low-rank adapter on the synthesizer that teaches it to generate sensibly when attending over non-sequential multi-branch KV caches.

These three components are trained end-to-end using three complementary data sources, and the resulting model can be dropped into any existing multi-agent framework as a plug-and-play synthesizer replacement.

Problem Formulation

Notation and Setup

Consider a parallel agent workflow with $m$ worker agents and one synthesizer, all sharing the same backbone model $f_\theta$. Each worker $j \in \{1, \ldots, m\}$ receives a context $c_j$ and generates output $z_j$:

$$z_j \sim P_\theta(\cdot \mid c_j), \qquad c_j = c^{sh} \circ c_j^{br} \tag{5}$$

where $c^{sh}$ is the shared prefix (e.g., the original task), $c_j^{br}$ is the branch-specific instruction or history, and $\circ$ denotes concatenation. After all workers finish, a synthesizer receives its own instruction $u$ and produces a final answer $\mathbf{y}$.

Text-serialization interface (baseline): The synthesizer forms one sequential input:

$$x^{text} = u \circ z_1 \circ \cdots \circ z_m \tag{6}$$

and generates autoregressively:

$$y_t \sim P_{text}(\cdot \mid x^{text} \circ y_{<t}) \tag{7}$$

This works but forces re-prefill of every token in $z_1, \ldots, z_m$.

Cache-based interface (proposed): The synthesizer only prefills $u$, collecting $\text{KV}_\theta(u) = \{(K_u^\ell, V_u^\ell)\}_{\ell=1}^L$. It then directly concatenates the worker caches:

$$K_{syn}^\ell = [K_{z,1}^\ell \;;\; K_{z,2}^\ell \;;\; \cdots \;;\; K_{z,m}^\ell \;;\; K_u^\ell] \tag{8}$$ $$V_{syn}^\ell = [V_{z,1}^\ell \;;\; V_{z,2}^\ell \;;\; \cdots \;;\; V_{z,m}^\ell \;;\; V_u^\ell] \tag{9}$$

and generates using the assembled cache:

$$y_t \sim P_{kv}\!\left(\cdot \mid \{(K_{syn}^\ell, V_{syn}^\ell)\}_{\ell=1}^L, y_{<t}\right) \tag{10}$$

Objective: Make the cache-based route match the text-serialization route:

$$P_{kv}\!\left(\mathbf{y} \mid u, \{\text{KV}_\theta(z_j | c_j)\}_{j=1}^m\right) \approx P_{text}\!\left(\mathbf{y} \mid u, z_1, \ldots, z_m\right) \tag{11}$$

Why This Is Non-Trivial

The naive concatenation in Equations (8)–(9) has two problems:

Problem 1 — Positional mismatch. Each worker $j$ generates $z_j$ at positions $|c_j|, |c_j|+1, \ldots, |c_j|+|z_j|-1$ (using RoPE). When we concatenate branch caches, worker 1’s tokens appear at positions $[|c_1|, |c_1|+|z_1|)$ and worker 2’s appear at $[|c_2|, |c_2|+|z_2|)$. If $|c_1| \ne |c_2|$ (which happens whenever branches have different histories), the synthesizer sees incompatible position indices, misleading its relative-position attention.

Problem 2 — Distributional shift. Standard autoregressive attention at position $t$ attends to all previous positions $1, \ldots, t-1$. Each worker’s KV state at position $p$ was computed with full access to the worker’s own history up to position $p$. But in the synthesizer’s merged cache, branch 1’s KV states “see” branch 2’s tokens as if they were preceding context — a setting the workers were never trained to produce. The cached K, V vectors are contextually misaligned.

These two problems mean that naive cache concatenation produces garbage output. The Parallel-Synthesis components exist precisely to address each problem.

Three Workflow Scenarios

The formulation covers three common parallel agent patterns:

Scenario 1: Single-turn parallel problem solving. All workers receive the same input $c_j = c^{sh}$, and independently sample candidate solutions (e.g., $m$ solutions to a math problem). The synthesizer picks or aggregates among them.

Scenario 2: Multi-turn parallel trajectory rollout. Workers share the same initial prompt $c^{sh}$ but accumulate branch-specific reasoning and tool calls over $T$ steps, so $c_j^{br}$ captures $j$‘s unique trajectory. The synthesizer integrates multiple exploration paths.

Scenario 3: Distinct sub-task execution. The task is decomposed into $m$ independent sub-tasks, each assigned to a different worker. Sub-tasks may be heterogeneous — e.g., one worker retrieves facts, another runs code, another searches the web.

Method: Parallel-Synthesis Architecture

Figure 2: Full Parallel-Synthesis pipeline

graph LR
    subgraph Workers
        W1["Worker 1\nContext c₁ → z₁"]
        W2["Worker 2\nContext c₂ → z₂"]
        Wm["Worker m\nContext cₘ → zₘ"]
    end

    subgraph CacheProcessing ["Cache Processing"]
        PR["1. Positional\nRe-encoding\n(RoPE realignment)"]
        CM["2. Cache Mapper\n(learnable φ per layer)"]
    end

    subgraph Synthesizer
        KVM["KV Merge\n[KV₁; KV₂; ... KVₘ; KVᵤ]"]
        LORA["Synthesizer LoRA\n(adapter for non-sequential cache)"]
        GEN["Autoregressive\nDecoding → y"]
    end

    W1 -->|KV caches| PR
    W2 -->|KV caches| PR
    Wm -->|KV caches| PR
    PR --> CM
    CM --> KVM
    U["Synthesizer prompt u\n(prefilled fresh)"] --> KVM
    KVM --> LORA --> GEN

    style CacheProcessing fill:#fff3cc
    style Synthesizer fill:#ffe0cc

Component 1: Positional Re-encoding

Let $n$ be the RoPE position immediately after the shared prefix $c^{sh}$ — the point where parallel branches diverge. The idea: re-anchor every branch’s output so it starts at position $n$, regardless of how long the branch-specific context $c_j^{br}$ was.

Re-encoding rule: For the $r$-th token of branch $j$‘s output $z_j$, the original position is $|c_j| + r$. We replace it with $n + r$:

$$\text{pos}(z_{j,r}) : |c_j| + r \;\longrightarrow\; n + r \tag{12}$$

This realignment ensures that all branch outputs structurally branch from the same continuation point. Concretely, we re-apply the RoPE rotation with the corrected position to get new K, V vectors:

$$K_{z,j,r}^{\ell,\text{new}} = R(n+r) \cdot W_K \cdot x_{z,j,r}, \quad V_{z,j,r}^{\ell,\text{new}} = W_V \cdot x_{z,j,r} \tag{13}$$

Note: value vectors $V$ don’t depend on position in standard RoPE (only Q and K do), so the re-encoding only modifies keys. The rotation can be applied after the fact by noting:

$$K_{z,j,r}^{\ell,\text{new}} = R(n+r) \cdot R^{-1}(|c_j|+r) \cdot K_{z,j,r}^{\ell,\text{old}} \tag{14}$$

This is a rotation-based linear transform that can be applied to the cached key vectors without re-running the full forward pass — an important efficiency property.

Why this matters: After re-encoding, the synthesizer’s attention sees all branch outputs as starting at position $n$. The relative attention distance from the synthesizer’s query at position $n + |z_{max}| + t$ to branch $j$‘s token at position $n + r$ is $|z_{max}| + t - r$, which is consistent across branches. Without this correction, the attention would conflate positional distance with branch identity — a severe and unrecoverable confusion.

Component 2: Cache Mapper

After positional re-encoding, the KV vectors still exhibit distributional shift: each branch’s cached states were computed attending over its own private context, but in the merged cache, they’ll be attended alongside each other’s context. A cache mapper $\phi^\ell$ per layer applies a learned linear correction:

$$\hat{K}_{z,j}^\ell = \phi_K^\ell(K_{z,j}^{\ell,\text{re-enc}}), \quad \hat{V}_{z,j}^\ell = \phi_V^\ell(V_{z,j}^{\ell,\text{re-enc}}) \tag{15}$$

The mapper $\phi^\ell$ is parameterised as a lightweight linear layer (or low-rank transform) per attention head or per layer. It is trained jointly with the synthesizer LoRA.

Intuition behind the mapper: Consider how a human reader integrates multiple research reports. If each report was written for a different audience (the worker agents each had different contexts), the reader needs to mentally “normalize” the writing style before comparing them. The cache mapper does the same thing in latent space — it shifts the KV distributions so they are mutually compatible when the synthesizer cross-attends over all branches simultaneously.

Relationship to RAG-style parallel encoding: Prior work on parallel KV encoding for RAG (e.g., SelKV, LongRAG) also calibrates independently-encoded document chunks. However, those methods encode isolated text chunks without any prior state, while here each $z_j$ was generated under a full agent trajectory. The distributional shift is more severe and multi-dimensional. The paper shows that applying RAG-style calibration methods directly to parallel agent synthesis yields weak performance — motivating the training-based mapper.

Component 3: Synthesizer LoRA

The positional re-encoding and cache mapper correct structural problems, but the synthesizer backbone still needs to learn to reason correctly over a non-standard cache topology: instead of attending to a single sequential prefix, it now attends to $m$ parallel blocks plus its own prompt.

The LoRA adapter modifies the attention projections of the synthesizer:

$$h = (W_Q + \Delta W_Q) q + \text{Attn}_{kv}\!\left(W_Q q,\; \hat{K}_{syn}, \hat{V}_{syn}\right) \tag{16}$$

where $\Delta W_Q = A_Q B_Q^T$, rank $r$. The LoRA is applied to the query, key, and value projections of the synthesizer (not the workers, which remain frozen). This teaches the synthesizer to:

• Attend appropriately to multiple parallel branch segments (not just sequential context).
• Understand that branch segments represent independent alternative explorations, not a single linear narrative.
• Reason, compare, and aggregate across branches for judgment tasks.

Training Data Construction

Training Parallel-Synthesis requires data that exposes the model to parallel cache contexts in a supervised way. Three complementary data sources address different aspects:

Data Source 1 — Continued Pretraining on Parallel Cache Contexts: Large-scale dialogue data is reformatted so that multiple turns or documents are presented as independent branches in cache form. This gives the model broad exposure to the parallel cache interface and prevents catastrophic forgetting of general language abilities.

Data Source 2 — Multi-Source Synthesis Tasks: Curated tasks where the synthesizer must aggregate information from $m$ independent sources (multiple retrieved passages, multiple expert opinions, etc.) presented as branch caches. This directly trains the aggregation behaviour needed for Scenarios 1–3.

Data Source 3 — Distillation from Text-Concatenation Pipeline: For complex agentic tasks, reasoning traces from the text-concatenation synthesizer are used as targets. The Parallel-Synthesis model is trained to match these reasoning outputs. This transfers the strong chain-of-thought reasoning behaviour of the text-based baseline into the cache-based synthesizer.

Step-by-Step Algorithm: Parallel-Synthesis Inference

Algorithm 1: Parallel-Synthesis Inference

Input:
  - Shared prefix c_sh (shared task context)
  - Branch contexts c_1^br, ..., c_m^br (per-worker instructions)
  - Synthesizer instruction u
  - Trained cache mapper φ^ℓ (per layer ℓ)
  - Trained synthesizer LoRA ΔW

Output:
  - Final answer y

Step 1: Shared-prefix prefill
  Prefill c_sh through the backbone model f_θ.
  All workers inherit the same shared prefix KV cache:
    KV_sh = {(K_sh^ℓ, V_sh^ℓ)}_{ℓ=1}^L

Step 2: Parallel worker decoding
  For each j = 1, ..., m in parallel:
    (a) Prefill branch context c_j^br, extending KV_sh.
    (b) Decode output z_j autoregressively.
    (c) Retain only the KV cache for z_j segment:
          KV_θ(z_j | c_j) = {(K_{z,j}^ℓ, V_{z,j}^ℓ)}_{ℓ=1}^L
        (discard the context cache for memory efficiency)

Step 3: Positional re-encoding
  Let n = |c_sh|  (branching point position)
  For each branch j = 1, ..., m:
    For each token r = 0, ..., |z_j| - 1:
      For each layer ℓ:
        K_{z,j,r}^ℓ ← R(n+r) · R⁻¹(|c_j|+r) · K_{z,j,r}^ℓ
        (V vectors: no change, as RoPE only affects keys)

Step 4: Cache mapping
  For each branch j and layer ℓ:
    K̂_{z,j}^ℓ = φ_K^ℓ(K_{z,j}^ℓ)
    V̂_{z,j}^ℓ = φ_V^ℓ(V_{z,j}^ℓ)

Step 5: Synthesizer prompt prefill
  Prefill synthesizer prompt u through the (LoRA-adapted) synthesizer:
    KV_u = {(K_u^ℓ, V_u^ℓ)}_{ℓ=1}^L

Step 6: Cache assembly
  For each layer ℓ:
    K_syn^ℓ = [K̂_{z,1}^ℓ ; ... ; K̂_{z,m}^ℓ ; K_u^ℓ]
    V_syn^ℓ = [V̂_{z,1}^ℓ ; ... ; V̂_{z,m}^ℓ ; V_u^ℓ]

Step 7: Synthesizer decoding
  Decode y autoregressively using {(K_syn^ℓ, V_syn^ℓ)} as the fixed prefix KV cache.
  Each decoding step appends the new token's KV to the cache.

Return y

Complexity comparison:

• Text-based synthesis: prefill cost $\propto |u| + \sum_j |z_j|$, then decode.
• Parallel-Synthesis: prefill cost $\propto |u|$ only; Steps 3–4 are $O(m \cdot L \cdot |z_{max}| \cdot d)$ linear operations — negligible compared to quadratic attention.

The time-to-first-token (TTFT) reduction is exactly proportional to how much shorter $|u|$ is compared to $|u| + \sum_j |z_j|$. For $m = 4$ branches of 1024 tokens each and $|u| = 128$, TTFT drops by roughly $(4096+128)/128 \approx 33\times$ in theory; the reported empirical range of 2.5–11× reflects real-world overheads (router, GPU synchronization, variable $|z_j|$).

Difference from Adjacent Work

Figure 3: Comparison of synthesis interfaces

graph TB
    subgraph TextBased ["Standard Text-Based Synthesis"]
        direction LR
        W1T["Worker 1 output\n(plain text z₁)"] --> CONCAT["Concatenate\nu ∘ z₁ ∘ ... ∘ zₘ"]
        W2T["Worker 2 output\n(plain text z₂)"] --> CONCAT
        CONCAT --> REPREFILL["Re-prefill entire\nconcatenated context\n(expensive!)"]
        REPREFILL --> OUT1["Synthesizer\ngenerates y"]
    end

    subgraph ParallelSynth ["Parallel-Synthesis (Proposed)"]
        direction LR
        W1P["Worker 1\nKV cache"] --> REENC["Positional\nRe-encoding"]
        W2P["Worker 2\nKV cache"] --> REENC
        REENC --> MAP["Cache Mapper\n(learnable φ^ℓ)"]
        MAP --> MERGE["Cache Merge\n+ LoRA Synthesizer"]
        UP["Prompt u\n(only prefill)"] --> MERGE
        MERGE --> OUT2["Synthesizer\ngenerates y"]
    end

    style TextBased fill:#ffe0e0
    style ParallelSynth fill:#e0ffe0
    style REPREFILL fill:#ff6666
    style MERGE fill:#66ff66

Parallel-Synthesis is related to but distinct from:

• KV cache reuse for RAG (SelKV, GoldFinch, StreamingLLM): These cache static documents, not agent-generated trajectories. The caches are positionally anchored to isolated chunk positions, not a branching workflow. The synthesizer’s task (retrieve relevant evidence) differs from multi-branch aggregation/judgment.
• One-to-one latent agent communication: Prior work (CacheBlend, KVSharer) passes one agent’s cache to another in serial. Parallel-Synthesis handles the many-to-one topology: $m$ parallel caches → 1 synthesizer.
• Best-of-N selection (pass@k): Sampling $k$ outputs and scoring them with a reward model doesn’t involve synthesis or aggregation. Parallel-Synthesis produces a new, synthesized output.

Experiments

Setup

Backbone model: The paper uses a Llama-3.1-class 8B model (exact checkpoint not specified in the preprint). Workers and synthesizer share the same backbone; only the synthesizer has the LoRA adapter and cache mapper.

Baselines:

1. Text-concat synthesis: Standard text-serialization (oracle quality, full re-prefill cost).
2. RAG-style parallel encoding: Existing cache-reuse methods adapted from long-context RAG settings, applied to parallel agent caches without re-training.
3. Summary-based synthesis: Each worker produces a short summary, and the synthesizer receives concatenated summaries.

Evaluation datasets (9 total):

• Math: GSM8K, MATH-500, OlympiadBench
• Science QA: ARC-Challenge, MMLU-Pro Science
• Code generation: HumanEval+, MBPP
• Agentic QA: GAIA (tool-use benchmark requiring multi-step web navigation and tool calls)
• Multi-agent DB diagnosis: A custom multi-agent benchmark where multiple database monitoring agents report findings and a synthesizer must diagnose the root cause.

Metric: Pass@1 accuracy / exact match / F1 depending on dataset. TTFT measured on an 8-GPU A100 cluster.

Parallel setup: $m = 4$ branches per task. Workers generate up to 512 tokens (math/code), 1024 tokens (agentic tasks).

Main Results

Figure 4: Parallel-Synthesis results vs. baselines across 9 benchmarks

graph LR
    subgraph Results ["Benchmark Comparison (conceptual summary)"]
        direction TB
        R1["GSM8K: PS ≥ Text-concat\n+0.8% accuracy"]
        R2["MATH-500: PS ≥ Text-concat\n+1.2% accuracy"]
        R3["OlympiadBench: PS ≈ Text-concat\n−0.5% (within margin)"]
        R4["ARC-Challenge: PS > Text-concat\n+1.9%"]
        R5["MMLU-Pro Science: PS ≈ Text-concat\n−0.3%"]
        R6["HumanEval+: PS > Text-concat\n+2.1%"]
        R7["MBPP: PS ≈ Text-concat\n+0.4%"]
        R8["GAIA: PS < Text-concat\n−3.2% (largest gap)"]
        R9["DB Diagnosis: PS > Text-concat\n+4.1%"]
    end

Key observations:

1. 7 of 9 datasets: Parallel-Synthesis matches or outperforms text-concatenation. For math and code, the improvement is consistent, suggesting that direct latent-state aggregation of parallel solution candidates is better than serializing them as text — possibly because the model can access richer intermediate representations.

2. GAIA shows the largest gap (−3.2%): GAIA requires very long tool-use trajectories with complex cross-branch dependencies. The current cache mapper may not fully calibrate multi-modal tool-call state across branches with heterogeneous context lengths. This is an explicit limitation.

3. DB diagnosis shows the largest gain (+4.1%): Multiple database agents report structured, similar-format monitoring summaries. The cache mapper excels when branch outputs are structurally regular — a signal about where the method works best.

4. RAG-style parallel encoding fails: Adapting document-chunk cache reuse methods directly to this setting yields 5–15% drops across datasets. This validates the need for the dedicated cache mapper trained on agent trajectory data.

Efficiency Results (TTFT Reduction)

Figure 5: TTFT reduction factor vs. total branch output length

xychart-beta
    title "TTFT Reduction Factor (Parallel-Synthesis vs Text-Concat)"
    x-axis ["512 tok/branch", "1024 tok/branch", "2048 tok/branch", "4096 tok/branch"]
    y-axis "TTFT Reduction Factor" 0 --> 12
    bar [2.5, 4.8, 7.3, 11.0]

The TTFT reduction grows roughly linearly with total branch output length, consistent with the theoretical analysis: the text-concat synthesizer’s prefill cost is $O(\sum_j |z_j|)$, while Parallel-Synthesis prefills only $|u|$. At 512 tokens per branch ($m=4$, 2048 total branch tokens), the 2.5× reduction reflects overhead from positional re-encoding and cache mapping. At 4096 tokens per branch (16K total), the 11× reduction approaches the theoretical maximum.

Wall-clock latency improvement: For a typical research synthesis task with 4 workers each generating 1024 tokens, text-concat synthesis waits an additional 1.8 seconds for prefill before generating the first token. Parallel-Synthesis reduces this to 0.38 seconds — 4.7× faster TTFT. For interactive agentic systems where responsiveness matters, this is substantial.

Ablation Study

The paper ablates each component:

Configuration	GSM8K	HumanEval+	GAIA
Full Parallel-Synthesis	88.4%	82.7%	47.3%
No positional re-encoding	71.2%	65.3%	38.1%
No cache mapper	80.6%	74.5%	41.2%
No synthesizer LoRA	76.8%	69.1%	39.7%
RAG-style mapper only	73.5%	67.2%	36.8%
Text-concat baseline	87.6%	80.6%	50.5%

Positional re-encoding is the most critical component — without it, accuracy drops by 17+ points. Cache mapper and LoRA each contribute roughly 7–8 points. All three components together bring the system within or above text-concat quality.

Critical Assessment: Weaknesses & Improvements

Weaknesses and Flaws

1. GAIA performance gap is non-trivial and unexplained. The −3.2% gap on GAIA is the paper’s main empirical weakness, but the analysis is thin. GAIA involves long multi-step tool interactions where branch outputs can contain web pages, API responses, and intermediate reasoning that span thousands of tokens. The paper acknowledges the gap but attributes it vaguely to “complex cross-branch dependencies.” A concrete analysis of which types of GAIA tasks fail (tool-use vs. web navigation vs. QA), and why the cache mapper fails there specifically, would be far more informative.

2. $m=4$ branches only. All experiments use exactly 4 parallel branches. The theoretical analysis suggests TTFT reduction grows with $m$, but there’s no experiment showing how quality changes as $m$ increases from 2 to 8 or 16. Agentic benchmarks like SWE-bench often use $m = 8$–16 for best-of-N selection. The behaviour of the cache mapper and LoRA at higher $m$ is completely unknown.

3. Backbone is underspecified. The paper uses “a Llama-3.1-class 8B model” without naming the exact checkpoint. Reproducing the work requires knowing the precise model (base vs. instruct), the tokenizer version, and the chat template. This is a reproducibility concern.

4. The cache mapper adds memory overhead. For $m = 4$ branches each generating 1024 tokens with a 32-layer, 8B-parameter model, the mapped KV caches add 4 × 32 × 1024 × $d_{head}$ tensors to GPU memory before the synthesizer can start decoding. For $d_{head} = 128$, this is ~268M float16 values (~537 MB) — significant for memory-constrained deployments. The paper does not discuss peak GPU memory usage.

5. Workers must use the same backbone as the synthesizer. The cache-based interface only works if workers and synthesizer share identical hidden dimensions, layer structure, and KV projection weights (before the LoRA). This precludes heterogeneous agent systems where different workers use specialized or differently-sized models — a common design in production agentic pipelines.

6. Distillation data quality is unexamined. Data Source 3 (distillation from text-concatenation synthesis) is described abstractly. The paper does not report how many distillation samples were used, what fraction came from which task domains, or whether domain mismatch between distillation data and evaluation datasets causes any degradation.

Limitations the Authors Understate or Omit

Synchronization latency in practice. The TTFT improvement assumes that all $m$ worker KV caches are available simultaneously before synthesis begins. In practice, workers finish at different times. If the synthesizer must wait for the slowest worker (the straggler problem), the actual TTFT from the user’s perspective is: $\max_j (\text{worker}_j \text{ latency}) + \text{Parallel-Synthesis TTFT}$. The TTFT benefit only materializes if the bottleneck is synthesis prefill, not worker generation — which may not hold for fast workers on small tasks.

Position re-encoding changes KV semantics. By reassigning all branches to start at position $n$, the model loses the information that branch $j$ was generated after a long $(|c_j|)$ or short $(|c_j^{br}| \approx 0)$ branch-specific context. In multi-turn trajectory rollouts (Scenario 2), this positional erasure could cause the synthesizer to misinterpret how “experienced” each worker trajectory is.

Training distribution generalization. The model is trained on a fixed set of task domains and branch counts. Zero-shot generalization to very different agentic workflows (e.g., scientific simulation agents, code repository exploration agents) is not evaluated.

Concrete Improvement Suggestions

1. Multi-$m$ scaling experiments. Run experiments with $m \in \{2, 4, 8, 16\}$ and report both quality and TTFT. Include failure modes when $m$ is large (e.g., attention dilution when the synthesizer must attend over many branch blocks simultaneously).

2. Heterogeneous backbone support. Explore whether a cross-model cache projection (analogous to cross-modal adapters in vision-language models) can bridge caches from different model sizes. This would dramatically increase practical applicability.

3. Asynchronous synthesis. Implement a streaming version of Parallel-Synthesis that starts synthesis as soon as a subset of branches complete, integrating remaining branches via cache appending. This would eliminate the straggler problem.

4. Explain the GAIA failure mode. Report per-category GAIA accuracy (web browsing, file manipulation, etc.) broken down by branch output length and tool type. Identify which specific tool call types cause the cache mapper to fail.

5. Memory-efficient cache mapping. Investigate quantization or block-sparse variants of the cache mapper that reduce the peak GPU memory footprint to sub-50MB per configuration.

6. Proper reproducibility. Release the exact model checkpoint, training data processing scripts, and hyperparameters. The current preprint omits too many details for independent reproduction.

Limitations and Boundary Conditions

The paper is explicit about two key limitations:

Same-backbone constraint. All workers and the synthesizer must use the same model architecture and weights (backbone). This is a strong constraint for production systems.

GAIA gap. Complex agentic tasks with diverse long-horizon tool interactions are not fully solved by the current cache mapper.

Beyond what the paper states, the positional re-encoding assumption ($n$ = shared prefix length) breaks down when branches have heterogeneous starting points — e.g., in tree-structured workflows where different sub-subtrees branch at different depths.

Deeper Dive: Why the Cache Mapper Works — A Distributional Analysis

To understand why the cache mapper is necessary and what it is actually correcting, consider what happens to the KV distribution when a worker generates under a branch-specific context $c_j^{br}$.

The key insight is that the KV vectors at any layer $\ell$ are not abstract embeddings — they are conditioned representations. Specifically, the key vector for a token $z_{j,r}$ at position $r$ in branch $j$ is:

$$K_{z,j,r}^\ell = W_K^\ell \cdot \text{LM}_\theta(z_{j,r} \mid c_j, z_{j,<r}) \tag{22}$$

where $\text{LM}_\theta(z_{j,r} \mid c_j, z_{j,<r})$ is the hidden state of the model at token $r$, conditioned on the full worker context $c_j = c^{sh} \circ c_j^{br}$.

Now consider two branches with different branch-specific contexts, say $c_1^{br} \ne c_2^{br}$. Even if both branches produce the same text $z_j$ (identical surface form), their KV states at any given layer will differ:

$$K_{z,1,r}^\ell \ne K_{z,2,r}^\ell \quad \text{(same text, different contexts)} \tag{23}$$

The difference arises because the hidden state computation at position $r$ involves attending over all previous tokens including $c_j^{br}$. The KV cache is not a function of $z_j$ alone but of $(c_j, z_j)$ jointly.

When the synthesizer attends over these branch caches jointly, its attention score between its query $Q_{syn,t}$ and branch $j$‘s key $K_{z,j,r}^\ell$ is:

$$a_{j,r,t}^\ell = \frac{Q_{syn,t}^\ell \cdot (K_{z,j,r}^\ell)^T}{\sqrt{d_k}} \tag{24}$$

The distribution of this attention score is implicitly affected by the statistics of $K_{z,j,r}^\ell$, which depend on $c_j$. The cache mapper corrects for this: it applies a transformation that normalizes the KV statistics across branches, making the attention scores more consistent regardless of which branch a key came from. In the simplest case, this amounts to normalizing the mean and variance of K and V vectors to a common reference distribution — a form of instance normalization in latent space.

This analysis also explains why the mapper is per-layer: the distributional shift differs across layers (early layers encode syntactic features, later layers encode semantic/contextual ones), so a single shared mapper cannot adequately correct for all shifts simultaneously.

Reproducibility Notes

What’s available:

• Paper describes architecture and training procedures at a high level.
• RoPE re-encoding formula is clear and implementable from first principles.
• Three training data categories are described conceptually.

What’s missing (as of preprint):

• Code repository (not linked in the preprint).
• Exact backbone checkpoint name.
• Training dataset sizes and sources.
• Cache mapper architecture details (linear vs. MLP, number of parameters).
• LoRA hyperparameters ($r$, target modules, learning rate).

What you can implement from the paper:

• The positional re-encoding (Equation 14) is fully specified and can be implemented in <50 lines of PyTorch.
• The overall inference pipeline (Algorithm 1) is describable completely.
• The cache concatenation format (Equations 8–9) is standard.

Implementation Details and Engineering Considerations

Cache Mapper Architecture

The paper describes the cache mapper as a “lightweight” per-layer transformation. Based on the description and standard practice in related work, the mapper likely takes one of two forms:

Option A — Per-layer linear projection:

$$\phi_K^\ell(K) = K \cdot W_K^\ell + b_K^\ell, \quad \phi_V^\ell(V) = V \cdot W_V^\ell + b_V^\ell \tag{17}$$

where $W_K^\ell, W_V^\ell \in \mathbb{R}^{d_k \times d_k}$ are small square matrices, one per layer. With $L=32$ layers, $d_k=128$, this adds $32 \times 2 \times 128^2 \approx 1M$ parameters — negligible.

Option B — Per-layer low-rank projection:

$$\phi_K^\ell(K) = K + K \cdot A_K^\ell (B_K^\ell)^T, \quad A_K^\ell \in \mathbb{R}^{d_k \times r_m}, B_K^\ell \in \mathbb{R}^{d_k \times r_m} \tag{18}$$

with mapper rank $r_m \ll d_k$ (e.g., $r_m = 16$). This is a residual correction rather than a full projection, making it easier to initialize near identity (set $A = 0$ at init).

The residual form in Option B is preferable because:

1. It initializes as the identity, so training starts from the “naive concatenation” baseline and improves incrementally.
2. It is guaranteed to be invertible when the low-rank correction is small, preserving the original information.
3. Gradient flow is more stable for fine-grained calibration.

Efficient Implementation of Positional Re-encoding

The rotation correction in Equation (13) requires computing $R(n+r) \cdot R^{-1}(|c_j|+r)$ for every cached key vector. In practice, this simplifies considerably. RoPE applies pairs of 2D rotations with angle $\theta_k t$ for each frequency $k$ and position $t$. The rotation correction becomes:

$$\Delta\theta_k^{(j)} = \theta_k \cdot (n - |c_j|) \tag{19}$$

This is a fixed angular offset per branch $j$ — the same offset applies uniformly to all positions $r$ within branch $j$. Therefore the correction can be precomputed once per branch (not per token), and applied as a batch operation:

# Pseudocode: efficient positional re-encoding
def reposition_branch_keys(K_branch, c_j_len, n, rope_freqs):
    # K_branch: [|z_j|, num_heads, d_head]
    delta_pos = n - c_j_len  # scalar, fixed for this branch
    # Create position offset correction rotation
    # rope_freqs: [d_head // 2] (frequency bands)
    delta_angles = rope_freqs * delta_pos  # [d_head // 2]
    cos_d = torch.cos(delta_angles)  # [d_head // 2]
    sin_d = torch.sin(delta_angles)  # [d_head // 2]
    # Apply rotation to key vectors (in-place possible)
    K_even = K_branch[..., 0::2]  # even dimensions
    K_odd  = K_branch[..., 1::2]  # odd dimensions
    K_even_new = K_even * cos_d - K_odd * sin_d
    K_odd_new  = K_even * sin_d + K_odd * cos_d
    K_branch[..., 0::2] = K_even_new
    K_branch[..., 1::2] = K_odd_new
    return K_branch

This operation is $O(|z_j| \times n_{heads} \times d_{head})$ — linear in branch length and embarrassingly parallelizable across branches, heads, and tokens.

Memory Management in Practice

When $m$ parallel workers each generate sequences of length up to $T$ tokens, and the synthesizer must hold all their KV caches simultaneously in GPU memory, the peak memory footprint for the KV portion is:

$$\text{Mem}_{KV} = m \times T \times L \times 2 \times d_k \times \text{sizeof(dtype)} \tag{20}$$

For $m=4$, $T=1024$, $L=32$, $d_k=128$, FP16:

$$4 \times 1024 \times 32 \times 2 \times 128 \times 2 = 2^{26} \text{ bytes} = 67 \text{ MB}$$

This is manageable on modern A100/H100 GPUs. For $m=4$, $T=4096$ (GAIA tasks), it grows to 268 MB — still feasible but a larger fraction of available VRAM.

Optimization: CPU offloading for inactive branches. After workers finish and their caches are mapped, the caches for all branches can be stored on CPU and streamed back to GPU during synthesis — especially effective when only a small number of attention heads actively attend to branch caches at any given step.

Training Procedure

Based on the paper’s description and standard practice, the training procedure is approximately:

Phase 1 — Broad adaptation (Data Type 1):

• Train cache mapper $\phi$ and Synthesizer LoRA jointly.
• Objective: standard next-token prediction on parallel-cache-formatted dialogue.
• Exposure to varied branch counts and lengths ensures generalization.

Phase 2 — Synthesis-specific fine-tuning (Data Types 2 and 3):

• Continue training on multi-source synthesis tasks (Data Type 2) with task-specific loss.
• Add distillation loss against text-concat baseline outputs (Data Type 3):

$$\mathcal{L}_{distill} = -\sum_t \log P_{kv}(y_t^* | \text{cache context}) \tag{21}$$

where $y_t^*$ is the token generated by the text-concat synthesizer. This KD objective teaches the cache-based model to match the high-quality reasoning chains of the text baseline.

Hyperparameter guidance (standard range for this class of models):

• LoRA rank: $r \in \{32, 64, 128\}$
• LoRA target modules: Q, K, V, O projections (all attention layers)
• Learning rate: $1 \times 10^{-4}$ (mapper), $5 \times 10^{-5}$ (LoRA)
• Batch size: 128–256 sequences, each containing $m$ branch caches + synthesizer prompt
• Training steps: ~10K–50K (estimated from similar works)

Integrating Parallel-Synthesis into an Existing Agent Framework

A concrete integration into LangGraph-style orchestration would look like:

Figure 6: System integration diagram for Parallel-Synthesis in a multi-agent framework

graph TD
    subgraph Framework ["Multi-Agent Orchestration Layer"]
        ORC["Orchestrator\n(task decomposition + dispatch)"]
    end

    subgraph Workers ["Parallel Worker Pool"]
        W1["Worker 1\n(GPU 1, stream 1)"]
        W2["Worker 2\n(GPU 2, stream 2)"]
        W3["Worker 3\n(GPU 3, stream 3)"]
        W4["Worker 4\n(GPU 4, stream 4)"]
    end

    subgraph PSModule ["Parallel-Synthesis Module"]
        COLLECT["KV Cache Collector\n(waits for all workers)"]
        REENC["Positional Re-encoder\n(per-branch angular correction)"]
        MAP["Cache Mapper\n(φ^ℓ per layer)"]
        SYN["Synthesizer LLM\n(+ LoRA adapter)"]
    end

    ORC --> W1 & W2 & W3 & W4
    W1 & W2 & W3 & W4 -->|"KV caches (not text!)"| COLLECT
    COLLECT --> REENC --> MAP --> SYN
    SYN --> OUT["Final Answer\n(low TTFT)"]

    style PSModule fill:#e8f5e8
    style Workers fill:#e8f0ff

The key API change from the framework’s perspective: instead of calling synthesizer.generate(text=concatenated_outputs), it calls synthesizer.generate_from_caches(kv_list=worker_kv_caches, prompt=synthesis_instruction). The framework internals remain unchanged; only the communication protocol between workers and synthesizer differs.

Comparison with Best-of-N Decoding Strategies

Best-of-N (BoN) is a popular alternative for leveraging parallel computation: sample $N$ solutions, score each with a reward or verifier model, return the highest-scoring one. How does Parallel-Synthesis relate?

Dimension	Best-of-N	Parallel-Synthesis
Output format	Selects one of $N$ solutions	Synthesizes a new combined output
Requires reward model	Yes	No
Information aggregation	None (selection only)	Full aggregation/reasoning
TTFT advantage	No (text-based selection)	Yes (2.5–11×)
Quality on complex tasks	Limited by individual worker quality	Can exceed any single worker

For tasks where the correct answer requires combining insights from multiple branches (multi-hop QA, complex coding), synthesis strictly dominates selection. For tasks with clear correct/incorrect answers (arithmetic, unit tests), BoN with a verifier may be competitive with lower overhead. Parallel-Synthesis is the stronger baseline for the class of tasks where integration, comparison, and reasoning across branches is necessary.

Relation to Prior Work

Parallel-Synthesis sits at the intersection of three lines of work:

1. KV cache sharing/reuse (VeriCache, GoldFinch, CacheBlend): These optimize cache utilization for single-agent settings or document retrieval. Parallel-Synthesis extends this to multi-agent many-to-one synthesis.

2. Multi-agent orchestration (AutoGen, MetaGPT, LangGraph): These frameworks handle agent communication at the text level. Parallel-Synthesis provides a lower-level, latent-space communication primitive that these frameworks could use as a drop-in synthesizer.

3. Latent space communication (between transformers): Several papers (FusedSyn, TokenFusion) study passing intermediate representations between models. Parallel-Synthesis is the first to study the specific DAG-structured many-to-one setting for agent workflows.

Broader Implications and Future Directions

Towards a Native Latent-Space Agent Communication Protocol

The deepest implication of this paper is a reframing of how agents should communicate. Today’s multi-agent systems are designed around text as the universal interface: every agent produces text, every agent consumes text. This is practical and highly general, but it is also inefficient — the computational work done inside a model during generation (building up KV state, attending over context, forming representations) is discarded the moment it becomes text and re-encoded by the next model.

Parallel-Synthesis is one of the first papers to seriously challenge this assumption for the synthesis bottleneck. The natural trajectory is:

1. Single synthesis step (this paper): Worker KV caches → Synthesizer directly.
2. Multi-hop latent routing: Could a chain of three LLMs pass latent states between them, not just at the final synthesis step but at every intermediate step?
3. Heterogeneous latent translation: Can we build cross-model KV projections (like a “latent interpreter”) that let agents with different architectures share states?
4. Persistent latent memory: Could a long-lived agent accumulate KV state across many turns, serving subsequent agents not with summaries but with raw cached states?

Each of these represents a step toward a fundamentally different architecture for multi-agent AI — one where “understanding” is passed between agents in its raw representational form, not translated to and from natural language at every boundary.

Impact on Production Agentic Inference Infrastructure

From a systems perspective, Parallel-Synthesis implies a new design point for inference servers. Current LLM serving systems (vLLM, SGLang, TGI) are designed around a key abstraction: a request is a sequence of tokens, and the server’s job is to prefill those tokens and then decode. Parallel-Synthesis breaks this abstraction by introducing a new request type: a request that comes pre-equipped with external KV blocks that were computed by a different model instance.

This requires:

• Distributed KV cache storage: Worker caches must be accessible to the synthesizer, potentially across GPU nodes.
• Cache versioning: The synthesizer must verify that worker caches were generated by the same model weights (before LoRA), since the mapper is trained for a specific base model.
• Dynamic cache topology: The serving system must understand the DAG structure of agent workflows, not just individual request sequences.

Systems papers at venues like OSDI and MLSys are likely to pick up these infrastructure challenges in the next 1–2 years, building on Parallel-Synthesis’s problem framing.

Key Takeaways for Practitioners

For a practitioner building multi-agent systems today, here are the immediately actionable insights from this paper:

1. The re-prefill problem is real and measurable: If your multi-agent pipeline has a synthesis step that concatenates outputs from multiple parallel workers, measure the TTFT before and after — the re-prefill overhead is probably your dominant latency bottleneck for short worker outputs.

2. Positional re-encoding is a zero-cost improvement: Even without training Parallel-Synthesis’s mapper and LoRA, applying the positional re-encoding correction (shifting all branch keys to start at position $n$) before any cache concatenation attempt will improve coherence of naive cache-reuse experiments.

3. Branch count matters: Design experiments with varying $m$ to understand the quality-efficiency tradeoff in your domain. The TTFT benefit grows linearly with $m$; quality may plateau or decline at large $m$ due to attention dilution.

4. Same-backbone constraint is a hard wall: If your workflow uses specialized Worker models (different sizes or fine-tunes), Parallel-Synthesis cannot be applied directly. Watch for follow-up work on cross-model KV projection.

Conclusion

Parallel-Synthesis makes a clean and well-motivated contribution: it identifies the re-prefill inefficiency in multi-agent synthesis, formalises the problem precisely, proposes three cooperating components (positional re-encoding, cache mapper, synthesizer LoRA), and demonstrates compelling results across 9 benchmarks. The 2.5–11× TTFT reduction is practically meaningful for latency-sensitive agentic applications.

The remaining challenges — same-backbone constraint, GAIA gap, straggler problem, memory overhead — are real but tractable. The most impactful follow-up would be extending the method to heterogeneous backbone models and demonstrating multi-$m$ scaling behaviour. As agentic systems grow more complex (dozens of parallel workers, long multi-step trajectories), the inefficiency of text-based synthesis will compound — making the cache-based paradigm introduced here increasingly relevant.

This is a well-executed systems paper at the intersection of multi-agent AI and LLM inference optimization. For practitioners building multi-agent pipelines, the positional re-encoding insight alone is immediately actionable: even without the full trained system, re-anchoring all branch positions to the branching point $n$ before cache concatenation is likely to improve naive cache-reuse attempts.

Quick Reference

Core equations to remember:

The cache-based synthesis target:

$$P_{kv}\!\left(\mathbf{y} \mid u, \{\text{KV}_\theta(z_j \mid c_j)\}_{j=1}^m\right) \approx P_{text}\!\left(\mathbf{y} \mid u, z_1, \ldots, z_m\right)$$

The positional re-encoding correction:

$$K_{z,j,r}^{\ell,\text{new}} = R(n+r) \cdot R^{-1}(|c_j|+r) \cdot K_{z,j,r}^{\ell,\text{old}}$$

Key numbers:

• 7/9 benchmarks: Parallel-Synthesis matches or beats text-concat.
• 2.5–11×: TTFT reduction range across tasks.
• $m=4$: branch count used in all experiments.
• $n$: position of the shared-prefix / branch split point.

Components checklist for implementing Parallel-Synthesis:

• Positional re-encoding (RoPE angular correction per branch)
• Per-layer cache mapper $\phi^\ell$ (linear or low-rank, residual form)
• Synthesizer LoRA (Q/K/V/O projections, rank 32–128)
• Training data: pretraining dialogue + synthesis tasks + distillation
• Inference: branch caches collected → re-encoded → mapped → merged → decoded