AI 大模型為什麼越來越大？參數、Token、Context Window 與 JSON 資料處理詳解

閱讀前速覽

概念	一句話	和 JSON 的關係
參數	模型裡可學習的權重數量，近似「容量」	影響能否穩定吐出合法 JSON
Token	模型讀寫文字的計長與計費單位	括號、引號、重複鍵名都要付錢
Context Window	單次請求能裝下的 token 上限	大 JSON 與多輪 tool 結果最先撞牆

更大 ≠ 更會處理 JSON。參數給容量，Token 是帳單，Context Window 是水桶。水桶變大後，第一反應不該是把整份 API 響應倒進去。

大模型為什麼越來越大？

經驗規律很簡單：在資料和算力跟上的前提下，參數更多、訓練更久，損失曲線通常更好。廠商因此把「更大」寫成預設敘事——評測榜、演示和採購清單都更好講。

2024–2026 年「大」其實裂成了三條軸，不再只等於參數個數：

• 參數規模：稠密模型繼續漲；MoE 用「總參數很大、每次啟用一部分」控制推理成本。
• Context Window：從 8K、32K 擴到 128K，再到百萬級。Agent 和長文件是主要藉口。
• 輸出約束：Structured Outputs / JSON Schema 讓「更大」必須換成「更穩的物件」，而不是更長的散文。

對寫 JSON 的人，真正要問的不是「這個模型有多少 B」，而是：它吐 Schema 的穩定度、每千 token 的價格、以及你那份 tool 結果還裝不裝得進視窗。

參數是什麼？

參數是訓練結束後留在模型裡的權重。推理時它們不再更新，只參與計算。參數量常被寫成 7B、70B、405B——B 是十億。它描述的是容量，不是這一次請求讀了多少字。

參數變多，通常帶來三件事：

• 擬合複雜約束的能力上升。 巢狀物件、enum、required 不再動輒寫錯。
• 推理更貴、更慢。 同一段 JSON，大模型每個 token 的延遲和單價都更高。
• 不等於 Context Window 更大。 小參數模型也可以掛 128K 視窗；大參數模型也可能只有 32K。

2026 年的產品頁還喜歡把 MoE 的「總參數」和「啟用參數」寫在一起。採購時要問清楚：帳單按哪一個算，延遲按哪一個算。GPT-6 Astra 指南 裡寫過：對 JSON 開發者，穩的 Structured Outputs 往往比再大一號的稠密模型更值錢。

Token 是什麼？

Token 是分詞器切出來的片段，不是字元，也不是單詞。英文常見 1 token ≈ 4 個字元；中文、程式碼、JSON 標點往往更「碎」，同樣視覺長度會更貴。

API 按 token 計費，也按 token 截斷。你貼進去的系統提示、工具定義、對話歷史、工具返回的 JSON、模型吐出的 JSON，全部進同一本賬。

JSON 天生貴。括號、引號、逗號、縮排空格、重複的鍵名，每一個都可能佔 token。下面這份「完整訂單」讀起來友好，送進模型卻浪費：

{
  "order": {
    "order_id": "A-1042",
    "customer": {
      "full_name": "Ada Lovelace",
      "email": "ada@example.com",
      "locale": "en-GB"
    },
    "line_items": [
      {"sku": "KB-1", "title": "Keyboard", "qty": 1, "price": 99.00}
    ],
    "shipping": {"city": "London", "method": "express"},
    "debug": {"trace_id": "tr_9f", "retries": 0}
  }
}

同一筆業務，Agent 下一跳往往只需要：

{
  "order_id": "A-1042",
  "amount": 99.00,
  "status": "paid"
}

先在本地 格式化 看清結構，再用 JSONPath 提取 抽出 order_id / amount / status，然後 minify 再送進模型。除錯用美化，推理用瘦身——不要把兩者當成同一份 payload。

Context Window 是什麼？

Context Window 是單次請求能同時裝下的 token 上限。不同廠商把輸入、輸出算進同一個視窗，或給輸出另留一截。文件沒寫清之前，按「輸入 + 預留下的輸出 ≤ 視窗」來做預算。

視窗從 8K 漲到 128K、再到百萬級，並不自動讓 JSON 處理變簡單。它只是讓「把整份響應貼進去」變得看起來可行。可行和便宜、穩定，不是一回事。

Agent 迴圈裡，視窗通常被這樣吃掉：

{
  "context_window": 128000,
  "spent": {
    "system": 1200,
    "tools": 3400,
    "history": 18000,
    "tool_result_json": 42000
  },
  "reserved_output": 4000,
  "remaining": 59400
}

上表是示意，不是某一家的官方帳單。要點是：tool 結果的 JSON 往往比 prompt 更肥。多輪 AI Agent 完整指南 如果不做投影和摘要，第三跳就會截斷半個物件——下游把它當成完整訂單。

參數、Token、Context Window 怎麼疊在一起？

三個詞經常被寫成「模型更大」。拆開之後，職責完全不同：

1. 參數決定質量上限：能不能跟上 Schema、會不會在 additionalProperties 上自由發揮。
2. Token決定每一跳的帳單和延遲。同一視窗裡，肥 JSON 會擠掉歷史和輸出餘量。
3. Context Window決定一次能看見多少。視窗再大，也補不回「參數太小、約束跟不住」或「token 太貴、不敢重試」。

2026 年的預設事故是：買了大視窗，就把 2MB 的 pretty-printed JSON 倒進去，再抱怨模型「忘記」前面的欄位。它不是忘了，是你先把視窗喂滿了。

對 JSON 資料處理意味著什麼？

把上面三層落到日常流水線，差別會非常具體：

• 美化給人類，壓縮給模型。 縮排和換行在編輯器裡值回票價，在 token 帳單上是純浪費。
• 投影優於原文。 工具返回 80 個欄位時，只把下一跳 required 的鍵留下。
• Schema 是重試保險。 Structured Outputs 用校驗換「少生成幾次非法 JSON」，直接省輸出 token。
• arguments 的字串化 JSON 會算兩遍形態。 轉義引號既難讀又佔額度，宿主側必須二次 parse。
• 長上下文不是資料庫。 需要查詢時用工具；需要對比時在本地 Diff，而不是把兩個 5000 行檔案塞進同一條訊息。

AI Agent 為什麼開始需要 JSON Schema 把 Schema 寫成執行時門禁；語法見 JSON Schema 教程。版本漂移時，先 JSON Diff 上週能跑的物件和今天被拒的物件，再決定要不要換更大的模型。

2026 年怎麼控成本（先動 JSON，再換模型）

1. 給每個 Agent 步寫一份「允許進入上下文的欄位清單」，而不是 JSON.stringify(fullResponse)。
2. 工具定義本身也要瘦：description 寫清約束，刪掉不會改變呼叫的散文。
3. 開啟 strict: true / json_schema，用校驗換重試。
4. 歷史只留狀態物件，不留完整 tool 原文。checkpoint 用小 JSON，不用聊天記錄。
5. 金鑰和使用者欄位本地看、本地裁，不上傳到公共 JSON 站點，也不應無必要地進模型。

控成本的順序是：投影 → 壓縮 → Schema → 再考慮換更小或更大的模型。倒置這個順序，視窗和參數都會被浪費。

常見誤區

• 把參數量當成 Context Window。 70B 和 128K 是兩件採購項，寫在同一張幻燈片上也不等於綁在一起。
• 按字元數估 token。 JSON 標點和中文會讓「看起來不長」的物件先觸頂。
• 視窗更大就不再投影。 百萬上下文仍然按 token 計費，肥 JSON 只是把帳單變長。
• 用更大的模型修非法 JSON。 先檢查 Schema 和宿主校驗。許多「模型變笨」是多了一個 required。
• 把 pretty JSON 和線上 payload 當成同一份。 編輯器裡的空格，不該出現在推理請求裡。

FAQ

參數越大，JSON 就會越合法嗎？

傾向更好，不是保證。沒有 Schema 和宿主校驗，大模型一樣會漏欄位、把數字寫成字串。容量幫你降低事故率，門禁決定事故會不會進入下一跳。

Token 和字元可以按 4:1 換算嗎？

英文散文大致可以當經驗值。JSON、程式碼、中文不行。以廠商 tokenizer 或官方計數介面為準，不要用編輯器裡的字數估算帳單。

Context Window 包含模型輸出嗎？

多數 Chat / Responses API 把輸出算進同一預算，或單獨設 max output。按「輸入 + 預留輸出 ≤ 視窗」做最壞打算，避免最後一個花括號被截斷。

已經有 1M 視窗，還要不要裁 JSON？

要。視窗解決「塞得下」，不解決「付得起」和「下跳還穩」。投影和 minify 仍然是預設動作。

怎麼在本地檢查一份 JSON 會不會撐爆上下文？

先格式化看結構，再按欄位投影，最後把將要傳送的字串拿去計數。JSONSort 在瀏覽器本地做格式化、提取和 Diff，不上傳資料。

結論

大模型變大，是因為更大的參數、更長的視窗和更多的資料，在評測上仍然好賣。對處理 JSON 的人，參數是容量，Token 是帳單，Context Window 是水桶。把整份 pretty JSON 倒進更大的桶，只是換一種方式超支。

從今天起，先寫「這一跳只允許哪些鍵」，再決定要不要換更大的模型。模型還會再大；口徑應該先變小。

延伸閱讀

• AI Agent 是什麼？Tool Calling 與 JSON 指南 執行時、工具呼叫與 JSON 契約
• AI Agent 為什麼開始需要 JSON Schema 從 Tool Calling 到結構化工作流
• GPT-6 Astra 與 JSON / API 指南 Structured Outputs 在新模型上的用法
• JSON Schema 是什麼 required、enum 與 additionalProperties
• JSONSort 本地工具箱 格式化、提取、Diff
• 全部文章 更多 JSON 與 AI 開發筆記

更新記錄： 2026-09-05 首次釋出；2026-09-07 修正繁中用語與中文用詞