Context Window 排序怎麼做？這篇把 LLM 工程直覺做了對抗式查證
作者把社團討論的 5 條 context、KV cache、長度相關直覺，逐條做 adversarial 查證，分成已證事實、工程默認與純屬猜測，釐清哪些操作有效、哪些只是好用但未必為真。
【20240604 AI模型與技術】【LLM 工程討論】【Context Window 排序怎麼做？這篇把直覺拆成已證、好用、猜測】 發布者：anson4139 前幾天在社團聊 context、KV cache、長度問題聊得很過癮，但作者提醒： 「聽起來很對」跟「真的對」是兩回事 ，所以把當晚討論整理成 5 條 claim，做了一輪 adversarial 查證。🤔 查證範圍以 peer-reviewed 與 arXiv 為主，vendor doc 為輔，blog 說法則明確標記。最後作者把結果分成三層： 已證事實 、 工程默認 、 純屬猜測 ，避免把好用的說法偷渡成事實。📚 在已證事實部分，長 context 會退化，而且往往比官方標稱更早發生；RULER（NVIDIA，ICLR 2024）測了 17 個模型，雖然很多都標 32K+，但實際只有一半能在 32K 真正 work。連 1M 模型的有效長度，也普遍只有標稱的 60–70%。 另一個已證結論是：RoPE 一旦超出訓練長度就會出現 extrapolation 失效，必須靠 YaRN、NTK 或 Position Interpolation 等方法處理；而生產級長 context 模型，多數是 繼續預訓練到那個長度 ，不是單純裸外推。 至於 prefix cache，則必須 token 級完全一致，任何改動只要發生在前面，後面就會全部 cache miss。OpenAI、Anthropic、vLLM、SGLang 的官方文件都一致，因此實務上的排法很明確： 穩定內容放前面、變動內容放後面 ，才能最大化 cache 命中。⚙️ 在工程默認裡，作者也修正了一個常見誤解： 「當前任務指令放最後」確實有效，但原因不是 MQA/GQA 。MQA/GQA 只是 KV cache 的記憶體最佳化，不改變 attention 分佈；真正影響的是 RoPE 的 recency bias 與 causal masking。 作者最後整理出一個 hybrid 排法： 穩定 prefix 放最前吃 cache → 動態內容放中間 →
https://blog.buclaw.org/posts/context-window-llm-mpzpgjyp