有必要為 AI 網關設定資源邊界，但目前沒有充分依據把這六個具體數值當作模型能力上限或業界標準。真正需要檢視的，不只是「限制會不會太嚴」，而是試驗參數、網關資源預算、上游協定限制和模型上下文容量，是否被混為同一種限制。

先釐清：這個網關扮演什麼角色？

從目前實作來看，這個網關比較像「OpenAI 相容協定轉接器＋上游會話橋接器」，並非模型推理伺服器，也不是單純透明轉送資料的代理。它會組裝請求酬載、處理工具協定、整理對話歷史，並把圖片轉成上游使用的附件參照。詳見酬載組建與歷史處理及附件訊息編碼。

因此要分清楚三種邊界：

• **模型邊界：**上下文容量、輸出容量和支援的模態，不能由網關任意重新定義。
• **上游介面邊界：**請求大小、訊息格式、附件上傳和工具協定；轉接器必須遵守，但應依實際後端分別處理。
• **網關邊界：**解析所需記憶體、並行量、CPU、磁碟和逾時等。這些限制確實必要，但應明確說明是本機部署的資源考量，不要包裝成模型限制。

「最後進入模型的都是數值表示」，不代表 HTTP 傳輸位元組、JSON 物件數、模型 token 數和本機記憶體可以互相換算。網關沒有模型權重或推理快取；它要保護的是接收、解析和協定轉換的過程。

官方規範能告訴我們什麼？

以下只列出本次取得官方資料支持的數字；沒有核實的參數不以記憶補齊。

廠商／介面	可核實的規範	對網關設計的啟示
OpenAI	GPT-5.5 的上下文容量為 1,050,000 tokens，最大輸出為 128,000 tokens。5	模型 token 預算和 HTTP 請求本文位元組是不同維度；不能從上下文容量直接推算網關應接受多少 MiB。
Anthropic 第一方 API	2026 年 10 月 28 日起，Messages API 和 Token Counting API 的請求大小上限由 32 MB 提高至 128 MB。10	32 MB 已不是現行上限，不能當成通用標準；更不能把網關的 8 MiB 說成 Claude 的能力上限。
Anthropic Messages API	單一請求最多可包含 100,000 則訊息。12	網關設定 1,024 則不是業界共同上限。但官方允許更多，也不代表本機部署必須毫無限制地照收。
Anthropic 圖片輸入	使用 200k 上下文的模型，每個請求最多 100 張圖；其他模型最多 600 張，另有圖片尺寸限制。16	圖片數量和尺寸是不同限制。圖片輸入需要資源防護並無不妥，關鍵在於限制是否有根據。
Google Vertex／AI Studio、xAI	本次未取得足夠的官方參數資料。	不臆測請求大小、工具數或巢狀深度；四家平台的完整參數比較仍未完成。

還有一點容易忽略：Anthropic 的無狀態 Messages API 會在每次請求中帶上完整對話歷史，因此不能只看最後一則短 prompt，就判斷整個請求有多大。15

這些官方資料可以作為相容性設計的參考，但不能直接證明 StudioGlobal 中同名模型的路由具備相同介面或容量。

六項試驗限制，逐一看它們限制的是什麼

這六項數值在程式中明確屬於試驗設定，不應直接視為現行生產規格。詳見設定定義與綁定。

參數	這類防護是否必要？	對目前數值的判斷
請求本文上限：8 MiB	需要，避免無限接收及後續展開。	可以是試驗階段的界線，不宜永久成為所有模型和輸入的統一上限；但模型支援百萬 token，也不能單憑這點證明 8 MiB 一定過小。
本文記憶體預算：64 MiB	需要，這屬於網關內部容量管理。	沒有相對應的「模型業界標準」；應依部署記憶體、並行量和處理流程的額外開銷決定，不能直接拿來和官方請求大小相比。
訊息數：1,024	可用來保護物件數量。	它不等於上下文容量。大量短訊息和一則極大的訊息，對資源的影響不同；設定時應考慮客戶端相容性，而非把訊息輪數當成 token 預算。
工具數：128	可用來限制協定處理量和工具定義帶來的額外開銷。	本次沒有足夠資料證明 128 是四家平台的共同標準。工具數量、定義大小和工具選擇品質也應分開評估。
JSON 深度：32	需要防範異常深的遞迴結構。	限制的是網關的解析結構，不是模型的理解深度。具體數字應參考合法工具參數樣本和解析器特性。
JSON 節點數：65,536	有助於防範物件展開造成的負擔。	它不是 token 數，也沒有經核實的四家通用標準；是否需要這道限制，取決於位元組與記憶體防護是否已足以涵蓋物件開銷。

有兩個細節尤其容易混淆：

• 官方對結構化輸出 Schema 的巢狀限制，不應直接套用到所有輸入 JSON。一般訊息文字中即使包含很深的 JSON，只要它是以字串傳入，就不等同於 HTTP 請求物件本身的遞迴深度。
• 工具定義並非越多越好。OpenAI 官方提供延後載入工具定義的機制，讓應用程式按需載入較少使用的工具。這表示減少一次注入的工具定義也可以是合理做法，不必只靠不斷提高硬性上限。2

比起試驗數字，現行實作還有幾處更值得留意

名稱相同的預算，不一定代表相同的複雜度

舊版預檢會把鍵和值都計入節點數，並根據本文、節點和解碼後的字串估算衍生容量；目前的串流掃描則主要在讀取值時計數。因此，同樣是 65,536 個節點，未必代表相同的請求複雜度。詳見舊版節點計數、鍵的計數及串流計數。

記憶體估算，不等於實際記憶體保證

舊版預檢以「本文的四倍＋每個節點 512 位元組＋解碼字串的額外估算」計算容量。原始碼明確指出，這是保守估算，不是實際堆積記憶體或常駐記憶體（RSS）。處理階段還會為單一請求預留整筆衍生容量。詳見估算初始化及衍生容量預留。

保守准入本身有價值，但不能因此宣稱 64 MiB 的預算就能保證整個程序不會超出記憶體限制。

目前較緊的瓶頸，可能不是舊版的 8 MiB

現行串流設定另有約 53.8 MiB 的總本文上限，但非媒體 JSON 請求限制在 512 KiB；預設衍生容量則為 4 MiB。詳見現行串流常數與設定。

換句話說，只修改舊版試驗常數，未必能改善目前文字請求的瓶頸；只提高中繼資料上限，也不代表現有解析和衍生容量的記帳方式仍然足夠。

網關本身也在管理上下文

目前的上游酬載採用 56 則安全訊息預算，以及 480,000 的送出計數預算。文字長度是以字元估算，並非使用各家廠商精確的 tokenizer。純文字超出預算時，可以淘汰完整的歷史訊息組；帶有媒體的酬載則不會走這條壓縮路徑。詳見酬載預算及計數方式。

因此，「順便支援圖片」不只涉及單張圖片的大小，也會改變長對話歷史的處理方式；這部分比單一圖片上限更值得審查。

三個取捨，不能只靠調高數字解決

• **若網關定位是輕量轉接器，**就不能一方面強調透明轉送，另一方面又自行刪除歷史、改寫計數，卻不向客戶端說明。協定轉換和上下文管理的界線必須清楚。
• **若維持目前的 256 MiB 容器設定，**就不能同時要求接收各家平台允許的最大請求、保留多份解析副本、提高並行量，還維持原本的小記憶體目標。必須在處理方式、部署容量和可接受的請求範圍之間取捨。
• **若主要服務本機 Cline，**應優先確認真實程式開發請求是否相容，不要為了涵蓋通用影音場景，反而把合法文字請求壓在 512 KiB 以下。目前的本機監聽設定符合這種應用定位，但不代表可以取消資源防護。
• **若要移除深度、節點數或數量限制，**就需要說明剩餘的位元組、處理時間和記憶體防線，如何應付大量小物件。只說輸入最後會轉成 token，無法解釋分詞之前可能發生的解析開銷。

結論：限制資源風險，不要憑空限制模型能力

• 保留有限的請求接收、解析防護、並行控制、逾時和資源釋放機制。
• 不要把這六項試驗數值直接升格為通用的生產規格；每個門檻都應說明保護對象、設定依據，以及對合法請求的影響。
• 優先檢查媒體入口是否把文字請求一併限制在 512 KiB，並同步檢視衍生容量；只替換一個常數可能不足以解決問題。
• 把上游明確規定的限制放在轉接層，把本機容量限制放在部署層。上下文壓縮則盡量交由客戶端處理；若由網關接手，就必須明確說明規則。

核心原則是：應限制資源濫用，而不是沒有根據地限制模型可達能力；但輕量網關也不能靠放大常數，假裝自己擁有無限容量。現有資料不足以提出新的具體門檻，仍需依真實客戶端請求結構、實際上游協定和部署資源來決定。本次僅分析原始碼與官方資料，未修改檔案、執行驗證，也未核實執行中二進位檔的版本。

有必要為 AI 網關設定資源邊界，但目前沒有充分依據把這六個具體數值當作模型能力上限或業界標準。真正需要檢視的，不只是「限制會不會太嚴」，而是試驗參數、網關資源預算、上游協定限制和模型上下文容量，是否被混為同一種限制。

先釐清：這個網關扮演什麼角色？

從目前實作來看，這個網關比較像「OpenAI 相容協定轉接器＋上游會話橋接器」，並非模型推理伺服器，也不是單純透明轉送資料的代理。它會組裝請求酬載、處理工具協定、整理對話歷史，並把圖片轉成上游使用的附件參照。詳見酬載組建與歷史處理及附件訊息編碼。

因此要分清楚三種邊界：

• **模型邊界：**上下文容量、輸出容量和支援的模態，不能由網關任意重新定義。
• **上游介面邊界：**請求大小、訊息格式、附件上傳和工具協定；轉接器必須遵守，但應依實際後端分別處理。
• **網關邊界：**解析所需記憶體、並行量、CPU、磁碟和逾時等。這些限制確實必要，但應明確說明是本機部署的資源考量，不要包裝成模型限制。

「最後進入模型的都是數值表示」，不代表 HTTP 傳輸位元組、JSON 物件數、模型 token 數和本機記憶體可以互相換算。網關沒有模型權重或推理快取；它要保護的是接收、解析和協定轉換的過程。

官方規範能告訴我們什麼？

以下只列出本次取得官方資料支持的數字；沒有核實的參數不以記憶補齊。

廠商／介面	可核實的規範	對網關設計的啟示
OpenAI	GPT-5.5 的上下文容量為 1,050,000 tokens，最大輸出為 128,000 tokens。5	模型 token 預算和 HTTP 請求本文位元組是不同維度；不能從上下文容量直接推算網關應接受多少 MiB。
Anthropic 第一方 API	2026 年 10 月 28 日起，Messages API 和 Token Counting API 的請求大小上限由 32 MB 提高至 128 MB。10	32 MB 已不是現行上限，不能當成通用標準；更不能把網關的 8 MiB 說成 Claude 的能力上限。
Anthropic Messages API	單一請求最多可包含 100,000 則訊息。12	網關設定 1,024 則不是業界共同上限。但官方允許更多，也不代表本機部署必須毫無限制地照收。
Anthropic 圖片輸入	使用 200k 上下文的模型，每個請求最多 100 張圖；其他模型最多 600 張，另有圖片尺寸限制。16	圖片數量和尺寸是不同限制。圖片輸入需要資源防護並無不妥，關鍵在於限制是否有根據。
Google Vertex／AI Studio、xAI	本次未取得足夠的官方參數資料。	不臆測請求大小、工具數或巢狀深度；四家平台的完整參數比較仍未完成。

還有一點容易忽略：Anthropic 的無狀態 Messages API 會在每次請求中帶上完整對話歷史，因此不能只看最後一則短 prompt，就判斷整個請求有多大。15

這些官方資料可以作為相容性設計的參考，但不能直接證明 StudioGlobal 中同名模型的路由具備相同介面或容量。

六項試驗限制，逐一看它們限制的是什麼

這六項數值在程式中明確屬於試驗設定，不應直接視為現行生產規格。詳見設定定義與綁定。

參數	這類防護是否必要？	對目前數值的判斷
請求本文上限：8 MiB	需要，避免無限接收及後續展開。	可以是試驗階段的界線，不宜永久成為所有模型和輸入的統一上限；但模型支援百萬 token，也不能單憑這點證明 8 MiB 一定過小。
本文記憶體預算：64 MiB	需要，這屬於網關內部容量管理。	沒有相對應的「模型業界標準」；應依部署記憶體、並行量和處理流程的額外開銷決定，不能直接拿來和官方請求大小相比。
訊息數：1,024	可用來保護物件數量。	它不等於上下文容量。大量短訊息和一則極大的訊息，對資源的影響不同；設定時應考慮客戶端相容性，而非把訊息輪數當成 token 預算。
工具數：128	可用來限制協定處理量和工具定義帶來的額外開銷。	本次沒有足夠資料證明 128 是四家平台的共同標準。工具數量、定義大小和工具選擇品質也應分開評估。
JSON 深度：32	需要防範異常深的遞迴結構。	限制的是網關的解析結構，不是模型的理解深度。具體數字應參考合法工具參數樣本和解析器特性。
JSON 節點數：65,536	有助於防範物件展開造成的負擔。	它不是 token 數，也沒有經核實的四家通用標準；是否需要這道限制，取決於位元組與記憶體防護是否已足以涵蓋物件開銷。

有兩個細節尤其容易混淆：

• 官方對結構化輸出 Schema 的巢狀限制，不應直接套用到所有輸入 JSON。一般訊息文字中即使包含很深的 JSON，只要它是以字串傳入，就不等同於 HTTP 請求物件本身的遞迴深度。
• 工具定義並非越多越好。OpenAI 官方提供延後載入工具定義的機制，讓應用程式按需載入較少使用的工具。這表示減少一次注入的工具定義也可以是合理做法，不必只靠不斷提高硬性上限。2

比起試驗數字，現行實作還有幾處更值得留意

名稱相同的預算，不一定代表相同的複雜度

舊版預檢會把鍵和值都計入節點數，並根據本文、節點和解碼後的字串估算衍生容量；目前的串流掃描則主要在讀取值時計數。因此，同樣是 65,536 個節點，未必代表相同的請求複雜度。詳見舊版節點計數、鍵的計數及串流計數。

記憶體估算，不等於實際記憶體保證

舊版預檢以「本文的四倍＋每個節點 512 位元組＋解碼字串的額外估算」計算容量。原始碼明確指出，這是保守估算，不是實際堆積記憶體或常駐記憶體（RSS）。處理階段還會為單一請求預留整筆衍生容量。詳見估算初始化及衍生容量預留。

保守准入本身有價值，但不能因此宣稱 64 MiB 的預算就能保證整個程序不會超出記憶體限制。

目前較緊的瓶頸，可能不是舊版的 8 MiB

現行串流設定另有約 53.8 MiB 的總本文上限，但非媒體 JSON 請求限制在 512 KiB；預設衍生容量則為 4 MiB。詳見現行串流常數與設定。

換句話說，只修改舊版試驗常數，未必能改善目前文字請求的瓶頸；只提高中繼資料上限，也不代表現有解析和衍生容量的記帳方式仍然足夠。

網關本身也在管理上下文

目前的上游酬載採用 56 則安全訊息預算，以及 480,000 的送出計數預算。文字長度是以字元估算，並非使用各家廠商精確的 tokenizer。純文字超出預算時，可以淘汰完整的歷史訊息組；帶有媒體的酬載則不會走這條壓縮路徑。詳見酬載預算及計數方式。

因此，「順便支援圖片」不只涉及單張圖片的大小，也會改變長對話歷史的處理方式；這部分比單一圖片上限更值得審查。

三個取捨，不能只靠調高數字解決

• **若網關定位是輕量轉接器，**就不能一方面強調透明轉送，另一方面又自行刪除歷史、改寫計數，卻不向客戶端說明。協定轉換和上下文管理的界線必須清楚。
• **若維持目前的 256 MiB 容器設定，**就不能同時要求接收各家平台允許的最大請求、保留多份解析副本、提高並行量，還維持原本的小記憶體目標。必須在處理方式、部署容量和可接受的請求範圍之間取捨。
• **若主要服務本機 Cline，**應優先確認真實程式開發請求是否相容，不要為了涵蓋通用影音場景，反而把合法文字請求壓在 512 KiB 以下。目前的本機監聽設定符合這種應用定位，但不代表可以取消資源防護。
• **若要移除深度、節點數或數量限制，**就需要說明剩餘的位元組、處理時間和記憶體防線，如何應付大量小物件。只說輸入最後會轉成 token，無法解釋分詞之前可能發生的解析開銷。

結論：限制資源風險，不要憑空限制模型能力

• 保留有限的請求接收、解析防護、並行控制、逾時和資源釋放機制。
• 不要把這六項試驗數值直接升格為通用的生產規格；每個門檻都應說明保護對象、設定依據，以及對合法請求的影響。
• 優先檢查媒體入口是否把文字請求一併限制在 512 KiB，並同步檢視衍生容量；只替換一個常數可能不足以解決問題。
• 把上游明確規定的限制放在轉接層，把本機容量限制放在部署層。上下文壓縮則盡量交由客戶端處理；若由網關接手，就必須明確說明規則。

核心原則是：應限制資源濫用，而不是沒有根據地限制模型可達能力；但輕量網關也不能靠放大常數，假裝自己擁有無限容量。現有資料不足以提出新的具體門檻，仍需依真實客戶端請求結構、實際上游協定和部署資源來決定。本次僅分析原始碼與官方資料，未修改檔案、執行驗證，也未核實執行中二進位檔的版本。