以前的公司接入AI能力時直接讓業(yè)務方裸調(diào)各家大模型API。剛開始問題不大等業(yè)務量起來以后痛點全暴露了有人把密鑰硬編碼在代碼里、有團隊同一個模型的用量忽高忽低把配額打爆、財務月底發(fā)現(xiàn)賬單里一半錢是重復調(diào)用浪費掉的。后來我主導把流量收斂到統(tǒng)一的API網(wǎng)關(guān)層用類似MAI Gateway的方案把模型請求全部收口。這篇文章就從我實際落地的角度聊聊API網(wǎng)關(guān)在AI場景下到底是什么、解決什么問題、怎么設計和部署以及你大概率會碰到的坑。1. 從一個真實痛點說起企業(yè)接入AI流量為什么需要網(wǎng)關(guān)過去我們說的API網(wǎng)關(guān)核心能力是統(tǒng)一入口、鑒權(quán)、限流、灰度發(fā)布、請求轉(zhuǎn)發(fā)。這些在微服務架構(gòu)時代已經(jīng)很成熟了。但到了企業(yè)大規(guī)模接入大模型API的時代事情變得不一樣了。大模型API不是普通的HTTP接口它有這些特殊屬性響應慢動輒幾秒到幾十秒、成本跟Token量直接掛鉤、不同模型能力差異巨大、上下文長度有上限、模型供應商還會頻繁調(diào)整版本和限流策略。如果每個業(yè)務團隊各自為戰(zhàn)直接調(diào)各家模型API會面臨幾個很現(xiàn)實的麻煩。首先是密鑰管理失控一個OpenAI系密鑰在五個內(nèi)部系統(tǒng)里被引用泄露了根本查不到出處而且不同供應商的API格式不統(tǒng)一哪天想從A模型切換到B模型后端代碼全要改。更嚴重的是可觀測性為零某個技能調(diào)用了模型多少次、花了多少錢、成功率多少、延遲分布如何完全是一本糊涂賬。MAI Gateway這類AI網(wǎng)關(guān)本質(zhì)上是在模型服務和業(yè)務之間插入一個統(tǒng)一治理層。它做的事情是把各家模型的API差異屏蔽掉讓內(nèi)部系統(tǒng)用統(tǒng)一的接口格式訪問把鑒權(quán)、計量、頻控、路由、緩存這些橫切能力都收攏到一處給平臺團隊一個入口去觀察所有AI流量。這個思路跟Kong、Nginx在微服務時代的角色很像但治理的對象和維度完全不同——核心從“服務”變成了“Token”和“模型能力”。適合來看這篇文章的主要是三類人一類是正在從小規(guī)模試用AI能力往規(guī)模化生產(chǎn)環(huán)境過渡的技術(shù)負責人一類是負責公司基礎設施和數(shù)據(jù)安全的平臺工程師還有一類是剛開始接觸AI應用開發(fā)、想搞明白網(wǎng)關(guān)層到底解決了什么問題的后端開發(fā)。我會把設計思路和實操細節(jié)都掰開講不搞虛的。2. 模型流量的特殊性理解AI流量治理的核心維度2.1 從服務治理到Token治理的思維切換傳統(tǒng)微服務的流量治理關(guān)注的是QPS、P99延遲、熔斷和降級。到了大模型API這個場景新增了幾個傳統(tǒng)網(wǎng)關(guān)基本不關(guān)心的維度。第一是Token用量這不僅關(guān)系到成本還關(guān)系到模型上下文是否溢出——一次請求消耗了多少輸入Token和輸出Token比請求次數(shù)更本質(zhì)。第二是模型能力差異化每個模型有自己擅長的領域、有自己的上下文窗口、有自己的價格體系一個請求應該路由給哪個模型需要治理層來做決策。第三是語義級的安全有些模型調(diào)用攜帶了敏感數(shù)據(jù)不能簡單按照URL路徑做防護需要結(jié)合Prompt內(nèi)容做審計。我舉一個具體例子。一個客服機器人系統(tǒng)平時調(diào)用A廠商的模型成本每千Token是0.08元因為某段時間做活動流量漲了五倍結(jié)果消耗了遠超預算的Token。如果沒有網(wǎng)關(guān)層做計量和預算控制財務看到的是一張?zhí)靸r賬單但你根本說不清是哪個業(yè)務線、哪些請求打出來的。通過網(wǎng)關(guān)側(cè)的用量計量和預算告警你可以做到每分鐘在儀表盤上看到Token消耗的實時曲線并且按業(yè)務線拆解。這個能力傳統(tǒng)基于HTTP的Nginx是無能為力的。2.2 企業(yè)級模型調(diào)用的三類典型治理場景第一類是統(tǒng)一鑒權(quán)與密鑰托管。企業(yè)內(nèi)部多個系統(tǒng)需要調(diào)用多家模型API但密鑰不能散落在各處。網(wǎng)關(guān)作為統(tǒng)一入口后持有真正的供應商密鑰內(nèi)部系統(tǒng)通過網(wǎng)關(guān)分配的AppID和Secret訪問密鑰永遠不會暴露給業(yè)務方。換一個角度這還天然實現(xiàn)了密鑰輪換供應商密鑰每三個月?lián)Q一次業(yè)務方無感因為密鑰變更只在網(wǎng)關(guān)側(cè)做。第二類是路由與容災。多個供應商的模型各有優(yōu)劣有時候A供應商故障了這類故障我們確實遇到過某些時段時延飆到好幾秒需要自動把流量切到B供應商。在網(wǎng)關(guān)層做路由可以按優(yōu)先級、按比例、甚至按請求特征比如多模態(tài)請求走另一個供應商進行分流業(yè)務方完全不用感知供應商的變化。第三類是限流與配額。大模型API的成本跟Token量強相關(guān)如果不限制單個應用或單個用戶的消耗很容易被個別異常流量拖垮。網(wǎng)關(guān)側(cè)可以配置從每秒請求數(shù)、每分鐘Token數(shù)、每日Token總額三個維度的限制任何一個維度超限就能觸發(fā)拒絕、排隊或降級。3. 核心功能拆解一個AI網(wǎng)關(guān)必須具備的四板斧3.1 協(xié)議轉(zhuǎn)換與模型抽象層這是AI網(wǎng)關(guān)跟普通網(wǎng)關(guān)最核心區(qū)別之一。各家模型的API風格不統(tǒng)一有些兼容OpenAI格式有些不兼容流式輸出SSE和非流式輸出的處理也有差異上下文的消息歷史格式更是五花八門。網(wǎng)關(guān)要做的就是把上游這些差異全部抹平對下游暴露一套穩(wěn)定的協(xié)議面。我在實際項目里用的是快速開始模板上游接了三家廠商的模型下游統(tǒng)一暴露成OpenAI兼容格式。業(yè)務方連網(wǎng)關(guān)的地址根本不知道實際調(diào)用的是哪家供應商。哪天需要換模型在網(wǎng)關(guān)側(cè)改一條路由規(guī)則或者直接改一個模型映射配置即可業(yè)務代碼零改動。這個抽象能力帶來的遷移自由度在模型技術(shù)迭代飛快、供應商價格和政策經(jīng)常調(diào)整的當前環(huán)境下價值極高。協(xié)議轉(zhuǎn)換還有個隱藏作用版本兼容。供應商模型版本升級比如GPT-4到新版本可能伴隨響應格式微調(diào)通過在網(wǎng)關(guān)層保留版本映射和兼容轉(zhuǎn)換邏輯可以減少對業(yè)務方的沖擊。3.2 智能路由不只是按權(quán)重輪詢多數(shù)人理解的模型路由就是round-robin或者按權(quán)重分發(fā)但在真實企業(yè)場景里路由邏輯要比這個復雜得多。我落地過的路由規(guī)則大概有這幾類按請求內(nèi)容特征路由圖片理解請求走多模態(tài)能力強的模型純文本對話走性價比高的模型。按成本預算路由默認走低成本的模型當用戶付費等級更高或者業(yè)務線更重要時自動升級到更強的模型。按供應商可用性路由某個供應商限流或故障時自動將流量切換到備選供應商。按上下文長度路由請求攜帶的上下文特別長但不復雜時走上下文窗口更大、價格更合適的模型。配置這些路由不需要改代碼在網(wǎng)關(guān)側(cè)用規(guī)則和權(quán)重就能組合出來。我遇到過的一個真實案例一個RAG問答應用經(jīng)常出現(xiàn)用戶連續(xù)提問導致上下文膨脹在直接調(diào)用供應商API時因為超出上下文窗口頻繁報錯。通過網(wǎng)關(guān)增加了一個路由規(guī)則當估算上下文超過某個閾值時自動改走支持更長上下文的模型成功率立刻從81%提升到97%以上。3.3 限流與成本治理從QPS限制到Token預算限流是網(wǎng)關(guān)老功能但在AI場景里有了新內(nèi)涵。傳統(tǒng)限流限制的是“每秒請求數(shù)”AI網(wǎng)關(guān)還需要增加兩個維度的限制每分鐘Token消耗、每日Token預算。這三個維度的關(guān)系像是漏斗請求少了Token量不大但一個請求也可能吃掉幾萬Token長文總結(jié)、大文檔分析所以只看QPS完全不夠。Token消耗的限制還需要區(qū)分輸入Token和輸出Token因為它們的計費單價不同。我建議所有企業(yè)都打開按應用、按租戶、按用戶三層維度的Token計量。展開說就是應用維度看各業(yè)務線的消耗情況租戶維度看B端客戶或內(nèi)部部門的消耗情況用戶維度發(fā)現(xiàn)極個別異常用戶——比如有人寫腳本反復調(diào)用大模型做惡意的批量生成這個行為在用戶維度體現(xiàn)得非常明顯。在限流算法上網(wǎng)關(guān)實現(xiàn)的是令牌桶。相比固定窗口的簡單粗暴令牌桶允許具備一定突發(fā)能力比如運營活動瞬間請求量是平時十倍全部拒絕會損失大量真實用戶令牌桶可以緩沖一段區(qū)間同時長時間超限流量會被平穩(wěn)削峰。相關(guān)參數(shù)我以前調(diào)過令牌桶容量、填充速率需要根據(jù)業(yè)務峰值進行計算可以參考業(yè)務的歷史流量樣本調(diào)整。3.4 可觀測性與審計日志把Token流變成可視化曲線AI網(wǎng)關(guān)的日志跟普通網(wǎng)關(guān)日志有一個關(guān)鍵差異不止記錄請求的時間、來源IP、狀態(tài)碼、耗時還要記錄模型供應商、模型名稱、Token消耗量輸入和輸出分開、費用估算和緩存命中情況。我把這套東西做了標準化以結(jié)構(gòu)化日志推到Kafka再由日志平臺做分析面板。從實際操作來看有幾個觀測指標幾乎每個企業(yè)都需要全網(wǎng)關(guān)總Token消耗曲線按小時/按天各路由目標消耗占比比如A供應商占比、B供應商占比模型調(diào)用成功率、平均首Token延遲、總響應耗時分布按模型拆解緩存命中率這個后面細說對成本和延遲優(yōu)化效果巨大各業(yè)務線費用估算審計日志還需要包含Payload采樣記錄經(jīng)過網(wǎng)關(guān)的請求內(nèi)容摘要和回復摘要便于安全審計和問題追溯。但這里有個隱私邊界需要把握好完整的Prompt需要脫敏后才能存儲合規(guī)紅線碰不得。4. 從部署到配置完整實操過程記錄4.1 部署方式選擇容器化單節(jié)點快速驗證我選擇在Kubernetes集群里部署MAI Gateway這個方案的優(yōu)點不多說了資源隔離、水平伸縮、配置管理都比較順手。如果你的團隊規(guī)模不大完全可以在Docker環(huán)境里跑一個單節(jié)點先做驗證后續(xù)再平滑遷移到集群。結(jié)合我自己的操作步驟部署過程分為三步。第一步準備環(huán)境變量文件里面包含網(wǎng)關(guān)管理密鑰、上游模型的API Key列表、日志輸出級別等基礎信息。第二步準備路由配置文件這個文件是最核心的定義了上游模型集合、路由規(guī)則和限流策略。第三步執(zhí)行容器啟動命令將配置文件以Volume方式掛載到容器內(nèi)服務端口暴露出來用于驗證連通性。整個部署過程大概需要半小時如果對容器不太熟悉主要時間會花在理解路由配置文件的語法上。但不需要有壓力它的配置抽象做得還是比較直觀的基本思路是把上游模型先定義成“Upstream”再在一級路由里引用這些Upstream并疊加策略。4.2 路由與限流配置示例一份可以直接抄的作業(yè)下面這份配置是我根據(jù)當時生產(chǎn)環(huán)境簡化而來的去掉了一些內(nèi)部敏感信息但結(jié)構(gòu)和關(guān)鍵參數(shù)都保留了。你可以直接作為初期模型參照再按自己的業(yè)務特征去微調(diào)。用戶提交請求時網(wǎng)關(guān)會根據(jù)規(guī)則匹配選擇上游供應商和模型。gateway: listen: :8080 admin_token_env: MAI_ADMIN_TOKEN upstreams: - name: openai-primary provider: openai base_url: https://api.openai.com/v1 api_key_env: OPENAI_API_KEY models: - gpt-4o - gpt-4o-mini default_model: gpt-4o-mini max_context_tokens: 128000 - name: anthropic-fallback provider: anthropic base_url: https://api.anthropic.com/v1 api_key_env: ANTHROPIC_API_KEY models: - claude-3-5-sonnet default_model: claude-3-5-sonnet max_context_tokens: 200000 routes: - path: /v1/chat/completions methods: [POST] model_selector: strategy: priority_fallback preferred: openai-primary fallback: anthropic-fallback auth: type: api_key keys_env: GATEWAY_API_KEYS rate_limit: - dimension: request limit: 150 period: second - dimension: token_input limit: 200000 period: minute - dimension: token_output limit: 100000 period: minute budget: quota_per_app: 1000000000 period: day cache: enabled: true mode: semantic similarity_threshold: 0.92 ttl_seconds: 300 max_size_mb: 2048這份配置里最值得展開的是限流和緩存兩塊。請求次數(shù)限制比較容易理解每分鐘令牌桶容量150允許一定突發(fā)。Token消耗限制則需要估算如果業(yè)務平均每個請求消耗約2000 Token每分鐘200個請求消耗40萬Token那么把輸入Token限制在每分鐘20萬大約可以支撐100到150個平均請求——這個數(shù)字要與請求次數(shù)限制搭配不能只限制一項。語義緩存這塊我個人推薦打開。它的原理是把請求的Prompt向量化并緩存當新的請求語義相似度超過閾值示例里是92%時直接返回緩存中的回復不再調(diào)用上游模型。這個功能對于RAG問答、客服場景效果極其明顯因為用戶反復問接近的問題很常見。我實測過一組數(shù)據(jù)在客服系統(tǒng)中打開語義緩存后整體Token成本降低了約18%平均響應時間降低了接近一半。4.3 Key輪換與多租戶隔離生產(chǎn)環(huán)境必須提前考慮的設計在多租戶場景下網(wǎng)關(guān)的AppID設計要謹慎。我建議采用主從Key模式每個租戶有一個Master Key用于管理自己的子Key子Key用于實際業(yè)務調(diào)用。Master Key不在業(yè)務代碼中出現(xiàn)只能管理員在控制臺操作。這樣任何一個應用或代碼倉庫泄露了子Key權(quán)限范圍有限可以在控制臺單獨吊銷不影響租戶下其他應用。具體到網(wǎng)關(guān)側(cè)的認證流程請求到達網(wǎng)關(guān)先做Key校驗然后按Key提取租戶和應用信息再把租戶信息注入到轉(zhuǎn)發(fā)的請求頭里下游模型服務可以依靠這個信息實現(xiàn)更細粒度的內(nèi)部隔離。整個鏈路我剛才說的多維度計量也是基于Key提取出的租戶信息和應用信息進行歸集的。Key輪換周期上我的建議是內(nèi)部應用每三個月輪換一次外部客戶端使用短時效Key比如24小時配合刷新機制。這類設計可以讓網(wǎng)關(guān)同時充當安全和合規(guī)的邊界模型側(cè)的密鑰永遠不落地到業(yè)務方。5. 生產(chǎn)環(huán)境常見問題與實戰(zhàn)排坑5.1 模型供應商限流導致業(yè)務降級某個供應商的限流策略比較激進每分鐘請求數(shù)一超直接返回429而且它的限流水位并不是公開的。我第一次直接接它的時候正好趕上業(yè)務推廣期夜里流量突然走高供應商限流觸發(fā)業(yè)務方批量報錯。當時在網(wǎng)關(guān)層查日志看到的清一色是429狀態(tài)碼。后來我調(diào)整了策略在網(wǎng)關(guān)里把該供應商的請求數(shù)上限調(diào)到供應商官方配額的一半左右剩余水位留給突發(fā)彈性。而且打開了自動降級開關(guān)——當主供應商連續(xù)出現(xiàn)10次429錯誤時網(wǎng)關(guān)自動把后續(xù)流量切到備用供應商。那次調(diào)整之后盡管推廣期流量繼續(xù)上漲業(yè)務成功率穩(wěn)定保持在99%以上用戶體驗完全感知不到模型供應商已切換。這里有個經(jīng)驗不要把供應商的限流數(shù)當作可用的安全水位供應商的限流并不是單維度可能有多重策略疊加。5.2 流式響應場景下的超時與半包問題大模型WebSocket和SSE流式響應在生產(chǎn)環(huán)境非常常見但也最容易出問題。最常見的兩個現(xiàn)象一是長時間無增量數(shù)據(jù)導致網(wǎng)關(guān)判定超時服務端在生成長文本時經(jīng)常會出現(xiàn)超過60秒沒有新數(shù)據(jù)的區(qū)間二是客戶端斷開后網(wǎng)關(guān)還在繼續(xù)向上游拉取數(shù)據(jù)浪費Token。針對第一個問題需要把網(wǎng)關(guān)的流式讀取超時從“請求總超時”改為“增量超時”即只要每次有數(shù)據(jù)塊到達就重置計時器。具體參數(shù)配置我一般設置空閑超時120秒總時長上限600秒。針對第二個問題網(wǎng)關(guān)必須支持客戶端斷連檢測一旦檢測到客戶端連接關(guān)閉立即向上游發(fā)送終止信號。這個能力需要在選型時重點確認部分輕量級網(wǎng)關(guān)不支持主動取消上游流式響應會導致Token白白浪費。5.3 語義緩存誤命中導致回復質(zhì)量下降語義緩存上線后有個新問題個別用戶發(fā)現(xiàn)回復內(nèi)容跟上下文對不上。用戶第一句問“怎么退款”第二句問“怎么退貨”兩句語義相似度高如果緩存命中了直接返回了第一句的答案但第二句場景下用戶期望的答案側(cè)重點是不同的。這就是語義緩存的典型副作用相似但不相同的問題返回了完全相同的答案客服場景還好如果用在醫(yī)療或法律咨詢場景風險就比較大了。我的處理方案是分級使用緩存。對事實型知識問答比如產(chǎn)品規(guī)格、價格、地址可以設置較高的相似度閾值并放心開啟緩存對建議型、決策型問題關(guān)閉緩存或把它降到很低的優(yōu)先級別。同時在網(wǎng)關(guān)配置里增加了一個參數(shù)允許按路由維度單獨禁用緩存而不是全局開關(guān)。如果你要在這個坑上做一次排雷建議按業(yè)務類型梳理一遍哪些Prompt適合開緩存不要圖省事全量開啟。5.4 成本歸因口徑不一致導致財務和研發(fā)吵架運營團隊拿著網(wǎng)關(guān)賬單問“為什么你們算出來的Token消耗跟模型供應商后臺對不上”是大概率事件。核心原因是計算口徑不一致網(wǎng)關(guān)獨立統(tǒng)計了輸入Token和輸出Token供應商后臺的Token數(shù)可能在緩存命中時不再記賬而且不同模型對Token的編碼差別也比較大。我一開始沒有規(guī)范這個口徑后來發(fā)現(xiàn)了兩個數(shù)字差異跟財務部門配合查了大半天。建議從上線第一天就明確網(wǎng)關(guān)作為企業(yè)成本結(jié)算的唯一口徑供應商后臺僅用于對賬參考。另外一定要對每個請求實時估算費用并寫入日志注意是“實時估算”因為網(wǎng)關(guān)日志里記錄的Token數(shù)是解析響應正文后的實際計數(shù)供應商后臺的賬單則是另外一套計費邏輯兩者對不上不一定是誰錯了而是口徑不同。只有明確了統(tǒng)一口徑和誤差容忍范圍一般在3%-5%才不會出現(xiàn)扯皮。5.5 常見問題速查表問題現(xiàn)象可能原因排查與解決路徑請求全部返回401Key未配置或密鑰環(huán)境變量加載失敗檢查網(wǎng)關(guān)啟動日志中的Key加載信息確認環(huán)境變量是否生效流量正常但延遲飆升上游模型供應商整體擁塞或路由到了慢速備用節(jié)點查看按模型拆分的延遲分布確認是否觸發(fā)降級路由檢查備用供應商狀態(tài)某業(yè)務線Token消耗異?？赡苡姓{(diào)用方繞過了網(wǎng)關(guān)直連供應商在供應商后臺開啟IP白名單僅允許網(wǎng)關(guān)出口IP訪問流式請求頻繁中斷客戶端代理或負載均衡設備對SSE連接有空閑超時網(wǎng)關(guān)開啟心跳或空包?；钔瑫r調(diào)整負載均衡層的超時參數(shù)緩存命中率突然下降Prompt模板發(fā)生結(jié)構(gòu)性修改語義相似度計算失效重新評估提示詞模板變更對向量相似度的影響必要時調(diào)整閾值單用戶調(diào)用量異常高腳本批量調(diào)用或接口被爬蟲利用查看用戶維度的令牌消耗排行對異常用戶啟用單日預算限制6. 與通用API網(wǎng)關(guān)的對比到底差在哪很多團隊會問一個很直接的問題我已經(jīng)有Kong了為什么還要額外接一個AI網(wǎng)關(guān)我用一張表格表達清楚兩者的差異能力維度傳統(tǒng)API網(wǎng)關(guān)Nginx/KongAI網(wǎng)關(guān)如MAI Gateway請求轉(zhuǎn)發(fā)基礎路由支持按模型能力、Token消耗、成本預算路由限流維度QPS維度請求數(shù)、輸入Token數(shù)、輸出Token數(shù)、日預算多維限流成本治理不涉及按Token實時估算費用、按路由/應用/用戶計量歸集協(xié)議兼容HTTP/REST/WebSocket額外支持SSE流式、OpenAI協(xié)議轉(zhuǎn)換、多供應商協(xié)議適配緩存URL維度緩存語義向量維度緩存可以按相似度命中復用回復模型管理不涉及上游模型生命周期管理、模型版本映射、供應商容災切換從另一個角度說AI網(wǎng)關(guān)并不是要替代傳統(tǒng)網(wǎng)關(guān)。我在實際架構(gòu)里是兩層疊加外層Kong負責南北向的基礎網(wǎng)關(guān)功能TLS終止、通用路由、WAF防護內(nèi)層MAI Gateway專門負責模型服務治理。兩層各司其職邊界清晰。需要特別提示一點如果你們的AI業(yè)務還處在實驗階段、只有少量調(diào)用不一定要立刻部署AI網(wǎng)關(guān)。你完全可以先直連供應商API等真實流量起來、痛點明確之后再做規(guī)范化治理。網(wǎng)關(guān)的價值是治理不是魔法只有到一定流量規(guī)模才體現(xiàn)收益。7. 實際落地效果與后續(xù)演進建議我落地MAI Gateway后整體效果可以分出三個層面來看。第一個是成本層面通過Token計量和預算限制模型調(diào)用費用下降約10%到15%——主要來自光開關(guān)語義緩存和主動攔截重復調(diào)用。第二個是穩(wěn)定性層面通過自動容災切換和流式超時優(yōu)化AI服務的整體成功率從92%提升到99%出頭。第三個是管理層面密鑰和權(quán)限全部收口在網(wǎng)關(guān)業(yè)務側(cè)的敏感信息泄露風險大幅下降配合審計日志安全團隊做事件溯源終于有據(jù)可查了。這個方向后續(xù)還可以演進的地方我認為有三個。一是模型路由算法升級從規(guī)則路由演進到基于強化學習的智能路由網(wǎng)關(guān)根據(jù)當前各模型的負載、價格、歷史成功率動態(tài)做決策正在逐步成熟。二是多模態(tài)流量的治理語音、圖片、視頻類模型調(diào)用也逐漸增多網(wǎng)關(guān)對這類非文本模態(tài)流量進行計量和安全檢測會是下一個重點。三是AI網(wǎng)關(guān)與內(nèi)部零信任架構(gòu)打通把模型訪問權(quán)限跟員工身份、部門、數(shù)據(jù)分級聯(lián)動做成更細粒度的訪問控制。最后分享一個經(jīng)驗不要在文檔和宣傳中把MAI Gateway說成萬能的。它解決的是模型流量治理問題但你企業(yè)內(nèi)部如果連基本的API設計規(guī)范都還沒建立網(wǎng)關(guān)建設也可能只淪為形式主義。先把路由、計量、限流、審計這四件事想明白再選型部署效果是最穩(wěn)的。