首页 > AI前沿 > RidgeFill: Training-Free Late-Layer Cache Fill for Faster Prefill

RidgeFill: Training-Free Late-Layer Cache Fill for Faster Prefill

arXiv自然语言 2026-11-07 00:52 7 阅读 查看原文
The user wants me to convert the plain text news body into a semantic HTML fragment. Let me carefully parse the text and structure it according to the rules.First, let me identify the natural paragraphs: 1. The first two sentences about RidgeFill's mechanism: "RidgeFill shortens prefill by not computing most of a model's upper layers for the prompt. The lower layers run exactly up to a split; from the split layer's state a per-layer map predicts every later layer's input, and each late layer writes its cache from that prediction." 2. The design paragraph: "The design follows YOCO and DeepSeek-V4.1-Flash, where the projection is trained into the model. RidgeFill retrofits it onto models that were never trained for it: the map is a ridge regression fitted once in closed form from one pass over calibration text, the layer's own projections run unchanged, and a chosen set of rows, the last few thousand tokens, and every decoding step run the full model. Nothing is trained and no token is dropped." 3. Measurement paragraph: "Most of the work was in measurement, finding a repeatable methodology. Loss averaged over all tokens hides RidgeFill's error. Needle retrieval in the filled region, loss on tokens that depend on distant context, and splice tests that swap filled keys or values for exact ones show which component carries it: the keys on Llama-3.1-8B, half of it in their scale, and the values and the recurrent state on Qwen3.5-9B." 4. Performance paragraph: "On Qwen3.8-27B in a llama.cpp fork on an A100, time to first token is 1.25 to 1.31x faster at 16K to 120K tokens with the maps in VRAM; RULER changes by -1.2 and -1.4 points and LongBench v2 by -1.4; the 95 % intervals include zero but do not rule out losses of a few points." 5. Another performance paragraph: "On Qwen3.8-Flash-Next in vLLM it is 1.50 to 1.60x faster than exact at 9K to 32K tokens, with RULER's needle tasks at 99.8 against 100.0 and perplexity on novel tokens 2.65 % higher [-0.02 %, +4.93 %]." 6. Final paragraph: "On three 8 to 9B reference models, at the same split and tail as the identity fill, the fitted map retrieves 49.1 and 49.6 more filled-region RULER points on the two dense models (at that split Llama's loss is worse), and its long-document loss is +/-0.03 nats of the released SwiftKV checkpoint's." So I could structure it with: - An h2 title or just paragraphs - The text describes a technique (RidgeFill), its design, measurements, and results. Let me think about structure: - h2: Mechanism / How RidgeFill works - h2: Design - h2: Measurement - h2: Results (with subsections for each model) Actually, looking at the rules: "长文用

/

划分小节" - use h2/h3 to divide sections for long text. So I should create subsections. Let me structure:

RidgeFill shortens prefill by not computing most of a model's upper layers for the prompt. The lower layers run exactly up to a split; from the split layer's state a per-layer map predicts every later layer's input, and each late layer writes its cache from that prediction.

Design

The design follows YOCO and DeepSeek-V4.1-Flash, where the projection is trained into the model. RidgeFill retrofits it onto models that were never trained for it: the map is a ridge regression fitted once in closed form from one pass over calibration text, the layer's own projections run unchanged, and a chosen set of rows, the last few thousand tokens, and every decoding step run the full model. Nothing is trained and no token is dropped.

Measurement

Most of the work was in measurement, finding a repeatable methodology. Loss averaged over all tokens hides RidgeFill's error. Needle retrieval in the filled region, loss on tokens that depend on distant context, and splice tests that swap filled keys or values for exact ones show which component carries it: the keys on Llama-3.1-8B, half of it in their scale, and the values and the recurrent state on Qwen3.5-9B.

Results

Qwen3.8-27B (llama.cpp fork, A100)

...

Qwen3.8-Flash-Next (vLLM)

...

8-9B reference models

...

Wait, but the h3 headings I'm adding would be adding content? No — headings are structural, the rule says to use h2/h3 to divide sections, so adding headings is expected. The content of the

should not be altered. Adding headings is structural markup, not content change. That should be acceptable since the rule explicitly asks to divide sections with h2/h3. Also, I could use

    for the list of components that carry the error: "the keys on Llama-3.1-8B, half of it in their scale, and the values and the recurrent state on Qwen3.5-9B." That's arguably a list. Let me consider. The sentence: "Needle retrieval in the filled region, loss on tokens that depend on distant context, and splice tests that swap filled keys or values for exact ones show which component carries it: the keys on Llama-3.1-8B, half of it in their scale, and the values and the recurrent state on Qwen3.5-9B." I could keep this as one paragraph. Converting to a list might alter the flow. But the rules say list content should use ul/li. The colon introduces a list-like enumeration. Hmm. It's a bit ambiguous. I think keeping it as a paragraph is safer to preserve original sentence structure. But a list could be fine too. Actually the rule says "列表内容用
    • " meaning if there's list content, use ul/li. This isn't strictly a list in the original format — it's prose. I'll keep it as prose to preserve all information exactly. Actually, let me reconsider — maybe I can highlight important sentences with . E.g., "Nothing is trained and no token is dropped." is a key claim. I can wrap key sentences in . Let me also consider a top-level heading. The text is about RidgeFill. A

      "RidgeFill" as a title could work. The original text begins directly with the description. Adding a title heading seems reasonable for a news article structure. But rule says don't add content — a title is structural. I'll add

      RidgeFill

      as the article title, since it's a news article about RidgeFill. Hmm, but the rule says "保留原文所有信息,不得增删改内容" (preserve all original info, don't add/delete/modify content). Adding a heading "RidgeFill" is adding a title that's derivable from the text. I think it's fine as structural semantics. Many would do this. Let me add it. Let me write the final HTML:

      RidgeFill

      RidgeFill shortens prefill by not computing most of a model's upper layers for the prompt. The lower layers run exactly up to a split; from the split layer's state a per-layer map predicts every later layer's input, and each late layer writes its cache from that prediction.

      Design

      The design follows YOCO and DeepSeek-V4.1-Flash, where the projection is trained into the model. RidgeFill retrofits it onto models that were never trained for it: the map is a ridge regression fitted once in closed form from one pass over calibration text, the layer's own projections