Pular para o conteúdo
← Back to Skalablog

Published article

What Is Cache to Cache (C2C) and Why Skip Text?

Software Engineering

Cache to Cache (C2C) lets one language model share its understanding with another by passing a KV cache instead of writing text. In the paper's timing test, that cut about 1,312 milliseconds of sharer decoding to roughly 90 milliseconds of fusion for one model pair. This article walks through how the fuser works, what the accuracy numbers actually cover, and where the method's limits sit.

What Is Cache to Cache (C2C) and Why Skip Text?

Cache to Cache (C2C) is a method that lets one language model transfer its understanding of a question directly to another model by passing a KV cache through a trained fuser, so the sharer writes no text at all. Fu and colleagues first posted the paper in October 2025, and ICLR 2026 accepted it. The method targets a specific cost in model chaining: the decoding time of a sharer model that summarizes what it knows into a sentence before a receiver model answers.

In the paper's text baseline, a sharer model receives the question and writes one sentence of background knowledge, following a prompt like 'describe the most essential background knowledge needed to answer the question.' The receiver reads that sentence and answers. The sharer writes one token at a time, so 80 tokens means 80 sequential steps. The paper's test on MMLU Redux measured 80 tokens and 1,312 milliseconds for that step, roughly 16 milliseconds per token. C2C removes this wait because the sharer's decode time is 0 milliseconds; the fuser works during prefill, while both models are still reading the question.

How a KV Cache Holds a Model's Working Understanding

A KV cache is the memory a transformer model builds while it reads. For each token at each layer, the model stores two lists of numbers: a key that says what the token is about, and a value that holds what the token hands over when a later token matches its key. The model consults this memory to choose the next token. In C2C, the sharer reads the question and builds this cache without generating anything.

The paper addresses a natural question: could one model's cache work inside a different model at all? The authors trained a three-layer MLP to map the cache of the 4 billion Qwen 3 into the 0.6 billion Qwen 3. A t-SNE plot showed the mapped cache landed on the receiver's own distribution of points, which the paper takes as evidence that caches are generally convertible across models. This finding, from the paper's own analysis, grounds the whole approach: if caches were incompatible by architecture, no fuser could bridge them.

Inside the Fuser: Alignment, Projection, and Gating

The fuser is a small trained network placed between the two frozen models. It has to solve several problems at once, because different models use different layer counts and different tokenizers. The paper describes each step of the pipeline.

Layer and Token Alignment

The fuser must know which sharer layer corresponds to which receiver layer. The paper uses terminal alignment: it pairs the final layers first, then works backward through the remaining layers. Token alignment faces a separate issue, since different models can split the same text into different tokens. The paper turns each receiver token back into text, then splits that text again with the sharer's tokenizer. If one token matches several tokens, a rule called maximal coverage selection picks the match. The paper's text does not spell out how that rule resolves ambiguity.

Projection, Dynamic Waiting, and Learnable Gates

For each paired layer, a projection module joins the receiver's cache and the sharer's cache. A projection layer and a feature fusion layer then turn the joint data into information in the receiver space. The paper does not specify what each of those two layers does individually. A dynamic waiting module, called an input-aware head modulation layer, rescales the projected information based on the current input.

A learnable gate decides per layer whether the sharer's contribution enters at all. Each layer has one trained gate value. During training the gate is soft and can be partly open; the paper uses a Gumbel sigmoid and lowers its temperature from 1.0 to 0.001, pushing each gate toward fully open or fully closed as temperature falls. At inference, each gate is simply on or off. Finally, the fuser adds the result to the receiver's own cache through a residual connection, so the receiver keeps its original reading and gets the sharer's information on top.

Training Cost: One Fuser Per Model Pair

Both models stay frozen. Only the fuser's weights change, trained with supervised fine-tuning on 500,000 samples from OpenHermes 2.5 for 1,929 steps. This training produces a fuser for one specific pair of models. A new pair requires training a new fuser from scratch.

The paper names the training cost of scaling to many models as an open problem, and that cost grows with the number of models involved. On the practical side, seven pairs have released fusers in the Apache 2.0 GitHub repository. Five pair Qwen 3 0.6 billion with another model; the remaining two pair Qwen 3 1.7 billion or Qwen 3 8 billion with a Qwen 2.5 model. The repo says custom pairs are supported, but you must train the fuser yourself. Released weights are on Hugging Face.

How Much Faster Is C2C Than Writing a Sentence?

In the paper's timing test using the Qwen 3 0.6B and Qwen 3 4B pair, 1,312 milliseconds of sharer decoding became about 90 milliseconds of fusion. The text route required the sharer to decode 80 tokens; the C2C route has 0 milliseconds of sharer decoding. For that one step, the speedup is more than 14 times. The paper's average across all its settings is 2.5 times, and the text does not explain why the average is lower. The paper also cites single cases at 1.51 times, 3.46 times, and 14.41 times.

Two caveats keep these numbers honest. The text baseline was one sentence of about 80 tokens; a longer text exchange would change the cost comparison. Also, the test ran both models together on the same hardware, so the results say nothing about the latency of sending caches over a network. Treat the 14x figure as specific to that configuration, not as a general property of the method.

Accuracy Results: Where C2C Beats the Text Route

The paper tested pairs from four model families, Qwen 2.5, Qwen 3, Llama 3.2, and Gemma 3, on four benchmarks: open book QA, MMLU Redux, ARC Challenge, and CEval. These are multiple-choice benchmarks, and the models range from 0.6 to 14 billion parameters. Comparing C2C to the text route on the same pair, C2C wins by 1.9 points on MMLU Redux, 8.6 points on Open Book QA, and 5 points on ARC Challenge. Open Book QA shows the widest gap of the three.

The abstract's averages differ depending on the paper version. The version 2 figures from March 2026 report 6.4 to 14.2% over individual models and 3.1 to 5.4% over text. The GitHub page and the Hugging Face card list 8.5 to 10.5%, 3.0 to 5.0%, and 2.0 times, which appear to be first-version figures. Before quoting any number, check which version of the paper it comes from.

Limits, Failure Cases, and the Readability Trade-off

The benchmarks are multiple-choice tasks with models up to 14 billion parameters. The results do not tell you anything about long-form answers or frontier-scale models. With text, a receiver can read the hint and spot a mistake. A cache is a list of numbers, so the receiver has no words to check the hint against. That limit comes from the format itself, and the paper does not report it as a measured result.

Appendix A 4.6 states a failure case directly: C2C can fail because the contextual understanding from the shared model is not always accurate and can mislead the receiver into generating a wrong answer. The limitation section adds a second case: a much weaker sharer can pass noisy information and make a stronger receiver worse. Separately, a Qwen 3 4B base sharer scored 43.95 on MMLU Redux with C2C and 43.87 with text, almost no gain. The paper does not say that sharer was weaker than the receiver, so treat it as a separate observation.

The paper reports no test of a poisoned cache or a sharer built to mislead, and no source shows how a receiver could detect a bad cache. Any claim about adversarial attacks on this method would be speculation.

Should You Use C2C or Stick With Text?

The verdict depends on your setup. C2C trades a readable hint and freedom to swap models for zero sharer decoding and higher scores on the paper's multiple-choice tests. Here is a summary of the trade-offs:

FAQ

  • What is cache to cache (C2C)? C2C is a method that passes a KV cache from one language model to another through a trained fuser, skipping text generation entirely. Both models stay frozen, and only the fuser is trained.
  • How much faster is C2C than writing a sentence? In the paper's timing test, 1,312 milliseconds of sharer decoding became about 90 milliseconds of fusion, more than 14 times shorter for that step. The paper's average across all settings is 2.5 times, so the top figure is specific to one configuration.
  • Does C2C work with any pair of models? No. A fuser must be trained for each specific pair. Seven pairs have released fusers in the Apache 2.0 repository, and the repo says custom pairs are supported but require training.
  • Can a weaker model hurt a stronger one through C2C? The paper's limitation section says a much weaker sharer can pass noisy information and make a stronger receiver worse. One tested pair showed almost no gain from C2C.
  • Is the cache transfer secure against attacks? The paper reports no test of a poisoned cache or a deliberately misleading sharer, and no source shows how a receiver could detect a bad cache.

Turn Your Own Video Insights Into a Written Article

This article started as a YouTube video walking through the C2C paper, a method that trades a readable text hint for raw numeric caches between models. If you have similar knowledge, explanations, interviews, or opinions sitting inside your own videos, those ideas deserve a written form that search engines and readers can actually find.

Skala Blog turns a YouTube video into a structured blog article. Paste the URL, transcribe the video, and generate a draft you can edit and publish. The same process that shaped this breakdown of Fu and colleagues' cache-to-cache work can shape yours.

Source video