為什麼「100 萬 Token」不是勝利: 從 Gemini 3 的崩潰現象，看 LLM 真正的瓶頸在哪
為什麼「100 萬 Token」不是勝利
—— 從 Gemini 3 的崩潰現象，看 LLM 真正的瓶頸在哪
近來不少討論提到：Gemini 3 能處理高達 100 萬個 token，遙遙領先其他大型語言模型（LLM）。
這個數字乍看之下確實震撼，也很容易被理解為「能力碾壓」。
但在實際、重度使用中，卻出現一個明顯矛盾的現象：
同樣的命令、同一次對話、甚至還在當前任務裡，Gemini 仍然會忽略指令、行為漂移，甚至直接當機。
這不是零星案例，而是可重現、可預期的系統性問題。
本文要談的不是「哪個模型比較聰明」，
而是一個更關鍵、卻常被忽略的問題：
長上下文（long context）究竟在解決什麼？又沒有解決什麼？
一、100 萬 Token 到底代表什麼？
先釐清一個被行銷大量模糊的概念。
「能吃下 100 萬 token」≠「能穩定理解與治理 100 萬 token」
在工程現實中，這個數字通常意味著：
特定 attention 近似策略（非 full attention）
分段（chunked / sliding window）
壓縮、摘要、再拼接
多半是在 batch / 非即時互動 的條件下成立
換句話說：
這是一個「理論可達上限」，不是「日常可控工作範圍」。
二、為什麼實際使用反而更容易崩？
關鍵不在 token 數量，而在輸入的熵（entropy）與互動型態。
多數 benchmark 與展示場景是：
靜態文件
單向理解
結構相對穩定
不要求回溯一致性
但真實重度使用，尤其是工程與架構推演，通常是：
多輪對話
反覆修正
引用早期指令
混合自然語言、規則、程式碼與抽象概念
這會同時對系統造成三種壓力：
Attention 對齊壓力
KV cache 管理壓力
推理一致性壓力
長 context 在這裡不是解藥，而是乘法器。
三、真正的問題：命令在系統裡沒有「治理地位」
這是整個問題的核心。
在多數 LLM（尤其是主打超長 context 的模型）中：
指令
補充說明
文件內容
模型自己產生的中間推理
👉 在 attention 機制裡，本質上都是 token
系統裡沒有一個明確的結構告訴模型：
「這一段是不可違反的命令」
結果就是：
指令只是語義權重之一
會被後續內容稀釋、覆蓋、漂移
即使還在同一次對話，也可能失效
所以你看到的不是「偶爾犯錯」，而是：
同一個命令，在同一輪任務裡，被無視。
這不是智商問題，是命令沒有制度地位。
四、長 context + 近似 attention 的致命組合
為了撐到 100 萬 token，幾乎不可能使用完整 attention。
這代表：
指令所在的 chunk 可能已不在當前注意力視野
系統「知道你講過」，但「不再認為仍然有效」
回指、反問、回溯時，對齊容易失敗
於是出現三種典型現象：
忘東忘西
軍令錯置
最後直接當機
這些都不是隨機的，而是結構必然結果。
五、為什麼其他 LLM 反而比較穩？
答案其實很現實：因為它們沒那麼貪心。
context 較短（8k / 16k / 32k）
attention 策略較保守
系統負擔較可控
代價是：
記得比較少
但換來的是：
行為穩定
命令不容易漂
推理不容易崩
這在工程上是一種非常合理的取捨。
六、這暴露的不是模型缺陷，而是架構選擇
如果把 LLM 當成「單一大腦」，那 context 越大越好。
但如果你把它當成「系統的一個角色」，那你會立刻發現：
沒有治理的長記憶，只會放大混亂。
真正缺失的不是 token，而是：
命令的結構化
優先級與不可違反性
記憶的角色分工
錯誤的制度化回饋
七、結語：為什麼這不是 Gemini 的問題，而是整個產業的
Gemini 3 只是把這個問題提早暴露出來。
當大家還在比：
32k
128k
1M token
真正的戰場其實已經轉移到：
誰知道什麼該忘
誰能讓命令不被語義淹沒
誰能把錯誤變成制度，而不是上下文
一句話總結：
LLM 會無視命令，不是因為它不聽話，而是因為系統裡沒有人負責「讓命令一定要被聽話」。
而這，才是下一代 AI 系統真正的分水嶺。
========
本著作由大力士的AI天地創造 製作，以創用CC 姓名標示–非商業性– 禁止改作 4.0 國際授權條款釋出
留言
張貼留言