程式設計基礎篇 · 複雜度：一眼看穿程式碼值不值

為什麼上下文越長越貴？O(n²) 的帳單

上一課你拿到了 Big-O 這把尺子，還記得那條起飛的紅線嗎？今天帶你去看大模型裡最有名的一個 O(n²)——注意力機制。學完你會突然理解一堆老問題：為什麼長對話越來越卡、為什麼上下文視窗是「視窗」不是「倉庫」、為什麼大家拼命做上下文壓縮。

先回憶一下 · 注意力在做什麼

前面的課程講過：大模型生成每個新詞元（token）時，都要「回頭看」前面所有的詞元，給每個詞分配注意力權重，才知道接下來該接什麼。一個 token 看一遍所有 token——這句話用上一課的語言翻譯一下：n 個 token，每個都要看 n 個，總共 n × n 次「對視」。這就是一張 n×n 的表格。拖滑塊畫給你看。

互動一 · 注意力矩陣：n² 長什麼樣

下面每一行代表「一個 token 要看所有 token」，深色對角線是它看自己。留意右邊的格子總數：滑塊只是勻速往右拖，數字卻越跳越猛——這就是「平方增長」的手感。

8 個
每行 = 一個 token 要看所有 token
TOKEN 數 n
8
對視次數 n²
64
= 注意力矩陣的格子總數
n 從 4 拖到 48，只翻了 12 倍；格子卻從 16 漲到 2304，翻了 144 倍。真實對話動輒幾萬 token——把這張圖在腦子裡放大一千倍，你就明白 GPU 在替你算什麼了。
互動二 · 同一個問題，兩種上下文

同樣問一句「幫我總結一下重點」，一個人先把歷史精簡到 1 萬 token，另一個人把 10 萬 token 的完整記錄原樣塞進去。token 只差 10 倍，看看帳單差多少。留意「注意力計算量」那一行：它不是 ×10，是 ×100。

精簡派 1 萬 token
只保留和問題相關的段落再提問
注意力計算量1 份
首字延遲（示意）≈ 1 秒
本次輸入費用（示意）≈ ¥0.1
全塞派 10 萬 token
整個歷史記錄一股腦丟進上下文
注意力計算量100 份
首字延遲（示意）≈ 幾十秒
本次輸入費用（示意）≈ ¥1+
※ 延遲與費用為量級示意，非精確報價；不同模型、不同檔位差異很大
核心結論一句話：上下文翻 10 倍，注意力計算翻 100 倍。費用大體跟 token 數走（×10 起步，長上下文檔位往往還要加價），而延遲和顯存壓力跟著計算量走——所以「多塞點總沒壞處」在大模型這裡不成立，塞進去的每一個 token 都要被後面所有 token 反覆回頭看。
知識串聯 · 這解釋了前面課程的三件事
🐢

① 為什麼長對話越來越卡

聊得越久，n 越大，每生成一個新 token 要做的「回頭看」就越多。卡頓不是網路問題，是 n² 在後臺滾雪球。

🗜

② 為什麼要做上下文壓縮

Compaction 把舊對話摘要成一小段再繼續聊。犧牲一點細節，換 n 大幅變小——n 砍一半，計算量砍四分之三，划算。

💾

③ 為什麼 KV Cache 能省錢

前綴部分算過的注意力結果快取下來、下輪不重算（姊妹篇 ds-6 講過）。正因為原始計算是 O(n²) 的貴，快取的折扣才這麼值錢。

把這課帶進日常。下次和 AI 長聊卡了、帳單高了，你知道該做什麼：開新對話、讓它先總結再繼續、RAG 裡只召回相關段落。這些技巧背後是同一條數學：讓 n 小一點，n² 就小很多。

✅ 這一課想和你分享的