先講結論：要設防線，但唔好將所有限制當成同一回事

有必要為 AI 網關設定資源邊界，但目前嘅證據不足以證明六個指定數值就係模型上限或業界標準。真正要檢視嘅，係試驗參數、網關本身嘅資源預算、上游 API 規格，同模型上下文容量，會唔會被混成同一種限制。

按現有實作描述，呢個網關唔係模型推理伺服器，亦唔係完全透明嘅字節代理；佢會組裝上游載荷、處理工具協議、整理對話歷史，亦會將圖片轉成上游附件引用。相關處理可見 internal/upstream/studioglobal/payload.go 同 internal/upstream/studioglobal/media_protocol_production.go。

所以最好分開睇三種界線：

• 模型能力：上下文容量、輸出容量同支援嘅模態，唔應該由網關自行重新定義。
• 上游 API 規格：請求大小、訊息格式、附件上載同工具協議；適配器要遵守實際使用嘅後端規格。
• 網關資源防護：解析所需記憶體、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 同名路由具備完全相同嘅接口或容量。

六項設定：邊啲係防護，邊啲只係待驗證數字？

以下六項喺提供嘅實作資料中屬於試驗配置，唔應該直接當成生產環境嘅通用規格；其定義同綁定位置見 internal/chatadmission/config.go。

參數	呢類防線有冇需要？	對現有數值嘅判斷
正文上限：8 MiB	有需要，避免無限接收大型請求，再進入更耗資源嘅處理。	可以係試驗門檻，但未足以成為所有模型、所有輸入嘅長期上限。另一方面，模型支援百萬 token，亦唔代表網關一定應接收更大正文。
正文記憶體預算：64 MiB	有需要，屬網關內部資源管理。	冇一個對應嘅「模型業界標準」；要按部署記憶體、並發同處理流程決定，唔應直接同上游 API 嘅請求大小比較。
訊息數：1,024	可以用嚟保護物件數量。	呢個數字唔等於上下文容量。一大堆短訊息同一條超大訊息，資源形態唔同；訊息數唔可以代替 token 預算。
工具數：128	可以控制協議處理同工具定義帶來嘅開銷。	未有足夠證據話呢個係四家供應商嘅共同標準。工具數量、定義大小同工具選擇質素，應分開評估。
JSON 深度：32	有需要防止過深嘅遞迴結構拖累解析。	限制嘅係網關解析結構，唔係模型理解深度；門檻要用合法工具參數樣本同解析器行為去驗證。
JSON 節點數：65,536	有機會幫手防止大量物件展開造成負擔。	呢個唔係 token 數，亦未有核實為四家通用標準。值唔值得保留，要睇正文大小同記憶體防線有冇涵蓋物件額外開銷。

有兩點要特別分清：

• 官方對結構化輸出 schema 嘅巢狀限制，唔可以直接當成所有輸入 JSON 嘅通用限制。一般訊息文字入面嘅深層 JSON，如果只係字串內容，就唔等於 HTTP 請求物件本身有同樣嘅遞迴結構。
• 工具定義唔係愈多愈好。OpenAI 提供按需要搜尋、延遲載入工具定義嘅做法，反映減少一次過注入嘅內容亦係合理方向，唔係一味提高硬上限。2

比舊上限更值得查嘅，是限制喺實作入面點樣運作

同一個節點上限，計法未必一樣

提供嘅程式碼分析指出，舊預檢會將鍵和值都計入節點，亦會按正文、節點同解碼字串估算衍生容量；目前嘅串流掃描則主要喺值入口計數。即使兩邊都寫住 65,536，實際代表嘅請求複雜度都可能唔同。相關位置包括 internal/chatadmission/preflight.go 同 internal/chatadmission/phase3_scan.go。

記憶體估算唔等於實際記憶體保證

舊預檢用「正文四倍、每個節點 512 bytes，再加解碼字串估算」去預計衍生容量。資料亦指出，程式碼將呢個方法描述為保守估算，而唔係實際堆記憶體或 RSS。處理階段另會預留整個單請求衍生額度；相關位置見 internal/chatadmission/preflight.go 同 internal/chatadmission/processing.go。

保守估算可以幫手控制准入，但單靠 64 MiB 呢個預算，唔足以證明整個程序一定唔會超出實際記憶體使用量。

現時較窄嘅文字入口，未必係舊嘅 8 MiB

目前流式設定另有約 53.8 MiB 嘅總正文上限，但非媒體 JSON 上限只有 512 KiB，預設衍生額度則為 4 MiB；資料位置見 internal/chatadmission/phase3.go。

換言之，只改舊試驗設定嘅 8 MiB，未必會改變現時文字請求最先遇到嘅限制。若提高 JSON 上限，亦要一併重新檢查解析方式同衍生容量，唔可以假設其他防護自然足夠。

網關亦自行設定咗上下文處理策略

現有上游載荷設定使用 56 條安全訊息預算，同 480,000 嘅提交計數預算；文字計數採用字元估算，唔係各家模型嘅精確 tokenizer。純文字超出預算時，可以逐組淘汰完整歷史；帶媒體嘅載荷則唔會進入同一條壓縮路徑。相關邏輯見 internal/upstream/studioglobal/payload.go。

所以，加入圖片支援唔止係增加圖片大小或數量限制，亦會影響長對話點樣處理。呢個歷史壓縮策略，值得同圖片入口一齊檢視。

三個設計取捨，唔可以靠加大數字帶過

• 如果定位係輕量適配器，就要講清楚協議轉換同對話管理嘅分界。網關若自行刪減歷史、改寫計數，就唔應同時令人以為佢只係透明轉發。
• 如果沿用 256 MiB 容器配置（docker-compose.yml），就要衡量請求大小、解析副本、並發同記憶體之間嘅取捨。唔可以一方面要求接受所有供應商容許嘅最大請求，另一方面又假設處理方式同部署容量完全唔使變。
• 如果主要用途係本地 Cline，應先用真實編程請求驗證兼容性，再評估通用音訊、影片等情境嘅需求。現有本地監聽設定見 docker-compose.yml；但定位窄，唔等於可以取消資源防護。
• 如果打算刪除深度、節點或數量限制，就要交代剩低嘅字節、時間同記憶體防線，點樣應付大量細小物件。請求最後會變成 token，解答唔到分詞之前嘅解析開銷問題。

實際方向：防止資源濫用，唔好無根據削窄模型能力

• 保留有上限嘅請求接收、解析防護、並發控制、逾時同資源釋放。
• 唔好將六個試驗數值直接升格為通用生產契約；每項限制都要註明保護目標、設定依據，同對合法請求嘅影響。
• 優先查清媒體入口點解會令文字 JSON 受 512 KiB 限制，並同步檢視衍生容量；唔好只改一個常數就當問題解決。
• 上游規格由適配層處理，本地資源限制由部署層管理；上下文壓縮最好由客戶端負責。若網關要承擔壓縮工作，就應清楚說明行為同契約。

核心原則係：限制資源濫用，唔係無根據地限制模型可用能力；但輕量網關亦唔可以靠放大常數，扮成有無限容量。目前資料不足以提出另一組具體門檻，仍要按真實客戶端請求、實際上游協議同部署資源去定。本次分析只涵蓋程式碼與官方資料，未有修改檔案、執行驗證，亦未核實運行中二進制版本。

先講結論：要設防線，但唔好將所有限制當成同一回事

有必要為 AI 網關設定資源邊界，但目前嘅證據不足以證明六個指定數值就係模型上限或業界標準。真正要檢視嘅，係試驗參數、網關本身嘅資源預算、上游 API 規格，同模型上下文容量，會唔會被混成同一種限制。

按現有實作描述，呢個網關唔係模型推理伺服器，亦唔係完全透明嘅字節代理；佢會組裝上游載荷、處理工具協議、整理對話歷史，亦會將圖片轉成上游附件引用。相關處理可見 internal/upstream/studioglobal/payload.go 同 internal/upstream/studioglobal/media_protocol_production.go。

所以最好分開睇三種界線：

• 模型能力：上下文容量、輸出容量同支援嘅模態，唔應該由網關自行重新定義。
• 上游 API 規格：請求大小、訊息格式、附件上載同工具協議；適配器要遵守實際使用嘅後端規格。
• 網關資源防護：解析所需記憶體、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 同名路由具備完全相同嘅接口或容量。

六項設定：邊啲係防護，邊啲只係待驗證數字？

以下六項喺提供嘅實作資料中屬於試驗配置，唔應該直接當成生產環境嘅通用規格；其定義同綁定位置見 internal/chatadmission/config.go。

參數	呢類防線有冇需要？	對現有數值嘅判斷
正文上限：8 MiB	有需要，避免無限接收大型請求，再進入更耗資源嘅處理。	可以係試驗門檻，但未足以成為所有模型、所有輸入嘅長期上限。另一方面，模型支援百萬 token，亦唔代表網關一定應接收更大正文。
正文記憶體預算：64 MiB	有需要，屬網關內部資源管理。	冇一個對應嘅「模型業界標準」；要按部署記憶體、並發同處理流程決定，唔應直接同上游 API 嘅請求大小比較。
訊息數：1,024	可以用嚟保護物件數量。	呢個數字唔等於上下文容量。一大堆短訊息同一條超大訊息，資源形態唔同；訊息數唔可以代替 token 預算。
工具數：128	可以控制協議處理同工具定義帶來嘅開銷。	未有足夠證據話呢個係四家供應商嘅共同標準。工具數量、定義大小同工具選擇質素，應分開評估。
JSON 深度：32	有需要防止過深嘅遞迴結構拖累解析。	限制嘅係網關解析結構，唔係模型理解深度；門檻要用合法工具參數樣本同解析器行為去驗證。
JSON 節點數：65,536	有機會幫手防止大量物件展開造成負擔。	呢個唔係 token 數，亦未有核實為四家通用標準。值唔值得保留，要睇正文大小同記憶體防線有冇涵蓋物件額外開銷。

有兩點要特別分清：

• 官方對結構化輸出 schema 嘅巢狀限制，唔可以直接當成所有輸入 JSON 嘅通用限制。一般訊息文字入面嘅深層 JSON，如果只係字串內容，就唔等於 HTTP 請求物件本身有同樣嘅遞迴結構。
• 工具定義唔係愈多愈好。OpenAI 提供按需要搜尋、延遲載入工具定義嘅做法，反映減少一次過注入嘅內容亦係合理方向，唔係一味提高硬上限。2

比舊上限更值得查嘅，是限制喺實作入面點樣運作

同一個節點上限，計法未必一樣

提供嘅程式碼分析指出，舊預檢會將鍵和值都計入節點，亦會按正文、節點同解碼字串估算衍生容量；目前嘅串流掃描則主要喺值入口計數。即使兩邊都寫住 65,536，實際代表嘅請求複雜度都可能唔同。相關位置包括 internal/chatadmission/preflight.go 同 internal/chatadmission/phase3_scan.go。

記憶體估算唔等於實際記憶體保證

舊預檢用「正文四倍、每個節點 512 bytes，再加解碼字串估算」去預計衍生容量。資料亦指出，程式碼將呢個方法描述為保守估算，而唔係實際堆記憶體或 RSS。處理階段另會預留整個單請求衍生額度；相關位置見 internal/chatadmission/preflight.go 同 internal/chatadmission/processing.go。

保守估算可以幫手控制准入，但單靠 64 MiB 呢個預算，唔足以證明整個程序一定唔會超出實際記憶體使用量。

現時較窄嘅文字入口，未必係舊嘅 8 MiB

目前流式設定另有約 53.8 MiB 嘅總正文上限，但非媒體 JSON 上限只有 512 KiB，預設衍生額度則為 4 MiB；資料位置見 internal/chatadmission/phase3.go。

換言之，只改舊試驗設定嘅 8 MiB，未必會改變現時文字請求最先遇到嘅限制。若提高 JSON 上限，亦要一併重新檢查解析方式同衍生容量，唔可以假設其他防護自然足夠。

網關亦自行設定咗上下文處理策略

現有上游載荷設定使用 56 條安全訊息預算，同 480,000 嘅提交計數預算；文字計數採用字元估算，唔係各家模型嘅精確 tokenizer。純文字超出預算時，可以逐組淘汰完整歷史；帶媒體嘅載荷則唔會進入同一條壓縮路徑。相關邏輯見 internal/upstream/studioglobal/payload.go。

所以，加入圖片支援唔止係增加圖片大小或數量限制，亦會影響長對話點樣處理。呢個歷史壓縮策略，值得同圖片入口一齊檢視。

三個設計取捨，唔可以靠加大數字帶過

• 如果定位係輕量適配器，就要講清楚協議轉換同對話管理嘅分界。網關若自行刪減歷史、改寫計數，就唔應同時令人以為佢只係透明轉發。
• 如果沿用 256 MiB 容器配置（docker-compose.yml），就要衡量請求大小、解析副本、並發同記憶體之間嘅取捨。唔可以一方面要求接受所有供應商容許嘅最大請求，另一方面又假設處理方式同部署容量完全唔使變。
• 如果主要用途係本地 Cline，應先用真實編程請求驗證兼容性，再評估通用音訊、影片等情境嘅需求。現有本地監聽設定見 docker-compose.yml；但定位窄，唔等於可以取消資源防護。
• 如果打算刪除深度、節點或數量限制，就要交代剩低嘅字節、時間同記憶體防線，點樣應付大量細小物件。請求最後會變成 token，解答唔到分詞之前嘅解析開銷問題。

實際方向：防止資源濫用，唔好無根據削窄模型能力

• 保留有上限嘅請求接收、解析防護、並發控制、逾時同資源釋放。
• 唔好將六個試驗數值直接升格為通用生產契約；每項限制都要註明保護目標、設定依據，同對合法請求嘅影響。
• 優先查清媒體入口點解會令文字 JSON 受 512 KiB 限制，並同步檢視衍生容量；唔好只改一個常數就當問題解決。
• 上游規格由適配層處理，本地資源限制由部署層管理；上下文壓縮最好由客戶端負責。若網關要承擔壓縮工作，就應清楚說明行為同契約。

核心原則係：限制資源濫用，唔係無根據地限制模型可用能力；但輕量網關亦唔可以靠放大常數，扮成有無限容量。目前資料不足以提出另一組具體門檻，仍要按真實客戶端請求、實際上游協議同部署資源去定。本次分析只涵蓋程式碼與官方資料，未有修改檔案、執行驗證，亦未核實運行中二進制版本。