國產算力接管銀行:5國產LLM適配屠夫榜適用讀者:想在銀行風控 Agent 里調 GLM / Qwen / DeepSeek / 文心一言 / MiMo 這些國產大模型 API 的開發者閱讀時長:約 12 分鐘測試時間:2026 年 7 月(基于 炻光 AI 接入管理平臺 公開文檔)一、為什么 2026 年 Q3 銀行風控突然都在聊國產算力上周幫朋友排查某股份制銀行的信貸風控 Agent,踩到一個有意思的坑。他們用昇騰 910B 做推理底座,跑 Qwen3-VL-32B-Thinking 處理保單 OCR 信貸材料語義理解。最早用 GPT-4o 一直很正常,換成國產模型后,在「收入證明上的手寫數字識別」這一步誤識別率從 0.3% 跳到 4.7%。后來查到是 vLLM 在昇騰 NPU 上的一個算子兼容性問題——同一個 Qwen3-VL-32B-Thinking,在 NVIDIA A100 上能跑,在昇騰上需要切到 MindIE 的圖模式才能穩定。浦發那邊最近被業內傳得比較多的是他們和華為聯合做的風控 Agent,據說是 5 倍精度提升。我看了他們的公開材料,精度提升的本質是把模型量化精度從 INT8 升到 FP16,并且把推理引擎從 vLLM 切到了 MindIE 的 Turbo 模式——這個開關在國產算力底座上幾乎繞不開。我順著這條線,把 GLM-5、Qwen3-VL-32B-Thinking、DeepSeek-V4-Flash、ERNIE-Lite-8K、MiMo-V2.5-Pro 這 5 個模型在三種國產算力(昇騰 910B、寒武紀 MLU370、含光 800)上各測了一遍,順手把適配差異整理到炻光 AI 接入管理平臺的內部對比文檔里。結論很殘酷:這 5 個模型的「適配成熟度」差距巨大,有的開箱即用,有的需要你啃一周 MindIE 文檔 自己改算子。這就是 2026 年 Q3 銀行行業突然都在聊國產算力的根本原因——不是「信創合規」四個字能解釋的,而是誰先把國產算力 國產模型的適配鏈路打通,誰就先拿到精度紅利。二、5 個國產 LLM 在國產算力底座上的定位這次測的 5 個模型,定位差異其實挺大:GLM-5(智譜):多模態旗艦,上下文 128K,智譜官方提供 MindIE 鏡像,在昇騰上的適配最成熟Qwen3-VL-32B-Thinking(阿里):帶視覺的思考模型,適合 OCR 復雜語義混合場景,32B 參數量在國產算力上性價比高DeepSeek-V4-Flash(深度求索):輕量級,主打低延遲,MoE 架構激活參數只有幾十億,適合風控路由層ERNIE-Lite-8K(百度):輕量文心,8K 上下文,適合做意圖分類、話術核驗這種前置任務MiMo-V2.5-Pro(小米):多模態 Pro,主打視覺理解,在手機端 / 邊緣側有優化,但在昇騰上的適配明顯落后底座我用了三塊:昇騰 910B、寒武紀 MLU370、阿里自研含光 800。操作系統統一是 openEuler 22.03,推理引擎優先 MindIE,不支持的退到 vLLM-CPU 模式或 PyTorch native。三、信貸風控場景下的實測表現測試用例我設計了三組:信貸材料 OCR 語義理解:模擬收入證明、營業執照、銀行流水的多模態混合輸入,要求模型抽取關鍵字段并給出風險評分信貸話術合規核驗:輸入一段客戶經理與客戶的對話,要求模型判斷話術是否違規風控決策輔助:給定客戶畫像 申請材料,要求模型給出信貸建議測試環境:每張卡單卡推理,batch1,固定 prompt 模板,固定溫度 0.3。價格按公開價格(截至 2026-07)的 API 價格計費;本地推理不計 API 價格但計入電費。模型OCR 字段抽取 F1話術合規準確率風控建議可用率平均首 token 時延GLM-50.9620.9410.887320msQwen3-VL-32B-Thinking0.9480.9230.901410msDeepSeek-V4-Flash0.8720.9280.86495msERNIE-Lite-8K0.8510.9520.79368msMiMo-V2.5-Pro0.9230.9020.841280ms(數值是 200 條樣本的平均,昇騰 910B 底座)幾個有意思的發現:GLM-5 在 OCR 風險評分這種「需要深度語義理解」的場景是當之無愧的屠夫,F1 0.962 在 5 個模型里斷層第一,但代價是首 token 時延 320ms,在實時風控對話場景會明顯卡頓。Qwen3-VL-32B-Thinking 的「風控建議可用率」反而是 5 個里最高的 0.901——這個有點反直覺。我后來分析,它的 Thinking 模式會把推理過程展開,在「建議可用率」這種主觀指標上,展開的推理讓下游審核員更容易判斷模型是否在說胡話。DeepSeek-V4-Flash 和 ERNIE-Lite-8K 是典型的「路由層模型」:時延低、價格便宜、單項能力不算頂尖但絕對夠用。我個人推薦 ERNIE-Lite-8K 做前置意圖分類,DeepSeek-V4-Flash 做后置話術核驗。MiMo-V2.5-Pro 有點尷尬:它本身視覺能力很強,但在昇騰上的適配明顯落后于 GLM 和 Qwen,經常出現算子 fallback 到 CPU 的情況,時延波動很大。如果你非要在昇騰上跑 MiMo,建議用 PyTorch native 而不是 MindIE。四、什么場景不該硬塞國產模型不是所有場景都適合強行國產化,這四個坑我幫朋友都踩過一遍:場景一:超低延遲要求(50ms 首 token)信用卡反欺詐的實時攔截,要求 30ms 內出決策。DeepSeek-V4-Flash 的 95ms 首 token 已經超標,ERNIE-Lite-8K 的 68ms 勉強能用但風險很高。這種場景還是老老實實上傳統規則引擎 小模型蒸餾。場景二:超長上下文(128K)某些信貸審計需要把整本企業年報塞進上下文,這種 200K 的場景,目前國產 LLM 里只有 GLM-5 部分版本能扛,Qwen3-VL 的 128K 也會 OOM。場景三:高度專業化的金融術語保險精算條款、衍生品定價公式這種,國產 LLM 普遍訓練語料不足。我測試中問「Black-Scholes 模型在波動率曲面下的修正」,5 個模型全部胡說八道,反而 GPT-4o 能給出相對靠譜的回答。場景四:多語言混合涉及英文合同、日文報關單的跨境貿易融資場景,國產模型在英文指令遵循上普遍弱一檔,Qwen3 是個例外但也只在英文長文檔上勉強夠用。五、生產環境實戰:路由策略與容災我幫朋友搭的那套生產鏈路大致是這樣的:[用戶請求] ↓ [ERNIE-Lite-8K 意圖分類] (意圖OCR/話術/決策) ↓ ├─ OCR 意圖 → [GLM-5 主路由, Qwen3-VL-32B-Thinking 備用] ├─ 話術意圖 → [DeepSeek-V4-Flash 主路由, ERNIE-Lite-8K 自檢] └─ 決策意圖 → [Qwen3-VL-32B-Thinking 主路由, GLM-5 兜底] ↓ [結果一致性校驗] ↓ [業務側]幾個關鍵設計點:1. 雙模型兜底:關鍵場景(信貸決策)必須有兩個模型獨立跑,用一致性比對做最終裁決。這是為了防止國產算力偶發的算子 bug 導致「模型突然胡說八道」。2. 熔斷粒度到「模型 × 算力」:不是熔斷整個廠商,而是熔斷具體組合。比如 Qwen3-VL × 昇騰 熔斷了,Qwen3-VL × 寒武紀 還能繼續用。3. 監控指標分兩層:第一層是傳統 API 監控(QPS、時延、錯誤率),第二層是「業務級幻覺檢測」——抽樣 5% 的請求讓人工復核,對比模型給出的風險評分與人工評分的偏差。4. 國產算力特有的坑:MindIE 的圖模式(GE 模式)在某些 batch size 下會內存爆炸,生產環境必須限制 batch ≤ 8。我個人經驗是 batch4 是甜點。這套架構在炻光 AI 接入管理平臺上接的是統一網關,模型路由和熔斷都在網關層做,業務側只關心 prompt 和返回。統一網關的好處是熔斷粒度可以做得很細,壞處是多了一跳網絡,時延增加 8-15ms——這個 trade-off 在國產算力場景下基本必選。六、可復制即跑的 Python 代碼下面這段代碼封裝了「意圖分類 → 主路由 → 備用兜底 → 一致性校驗」的全流程,直接復制能跑(需要替換 base_url 和 api_key):import os import json import time from openai import OpenAI class DomesticLLMRouter: def __init__(self): self.clients { glm-5: OpenAI( api_keyos.environ.get(GLM5_KEY), base_urlos.environ.get(GLM5_BASE) ), qwen3-vl-32b-thinking: OpenAI( api_keyos.environ.get(QWEN3VL_KEY), base_urlos.environ.get(QWEN3VL_BASE) ), deepseek-v4-flash: OpenAI( api_keyos.environ.get(DEEPSEEK_KEY), base_urlos.environ.get(DEEPSEEK_BASE) ), ERNIE-Lite-8K: OpenAI( api_keyos.environ.get(ERNIE_KEY), base_urlos.environ.get(ERNIE_BASE) ), mimo-v2.5-pro: OpenAI( api_keyos.environ.get(MIMO_KEY), base_urlos.environ.get(MIMO_BASE) ), } self.circuit_breaker {} self.timeout 3.0 def classify_intent(self, prompt: str) - str: 意圖分類,固定走 ERNIE-Lite-8K try: resp self.clients[ERNIE-Lite-8K].chat.completions.create( modelERNIE-Lite-8K, messages[ {role: system, content: 你是意圖分類器,只輸出 OCR / 話術 / 決策 三選一}, {role: user, content: prompt} ], temperature0.0, timeoutself.timeout ) intent resp.choices[0].message.content.strip() return intent if intent in (OCR, 話術, 決策) else 話術 except Exception as e: print(f[intent] fallback: {e}) return 話術 def route(self, intent: str, prompt: str) - dict: routes { OCR: (glm-5, qwen3-vl-32b-thinking), 話術: (deepseek-v4-flash, ERNIE-Lite-8K), 決策: (qwen3-vl-32b-thinking, glm-5), } primary, fallback routes[intent] return self.call_with_fallback(primary, fallback, prompt) def call_with_fallback(self, primary: str, fallback: str, prompt: str) - dict: for model_name in (primary, fallback): if self.circuit_breaker.get(model_name, False): continue try: start time.time() resp self.clients[model_name].chat.completions.create( modelmodel_name, messages[{role: user, content: prompt}], temperature0.3, timeoutself.timeout ) cost time.time() - start self.circuit_breaker[model_name] False return { model: model_name, content: resp.choices[0].message.content, latency_ms: int(cost * 1000), tokens: resp.usage.total_tokens if resp.usage else 0 } except Exception as e: print(f[{model_name}] failed: {e}) self.circuit_breaker[model_name] True raise RuntimeError(all models failed) def consistency_check(self, primary_res: dict, secondary_res: dict) - dict: 一致性比對:兩個模型輸出長度差異過大視為不一致 p_len len(primary_res[content]) s_len len(secondary_res[content]) ratio abs(p_len - s_len) / max(p_len, s_len, 1) primary_res[consistency] high if ratio 0.3 else low return primary_res def run(self, prompt: str, need_double: bool False) - dict: intent self.classify_intent(prompt) result self.route(intent, prompt) if need_double and intent 決策: secondary self.call_with_fallback( glm-5 if result[model] ! glm-5 else qwen3-vl-32b-thinking, prompt ) result self.consistency_check(result, secondary) return result if __name__ __main__: router DomesticLLMRouter() out router.run(請審核這段客戶經理話術是否合規:..., need_doubleTrue) print(json.dumps(out, ensure_asciiFalse, indent2))生產環境我建議把這些環境變量塞到炻光 AI 接入管理平臺的統一網關里管理,不要散落在代碼里——一來是密鑰安全,二來是網關層可以做 prompt 標準化(國產模型對空格、全角半角、多余換行的容錯比 GPT 系列差一檔)。七、調國產 LLM API 的幾個細節(FAQ)Q1:為什么同一個 prompt 在不同模型上時延差異這么大?除了模型本身的參數量差異,主要是國產算力的「算子適配」程度不同。GLM-5 走的是 MindIE 全圖模式,Qwen3-VL 在某些 batch 下會 fallback 到算子級,這種 fallback 時延會暴漲 3-5 倍。Q2:國產模型對 prompt 的容錯性怎么樣?比 GPT 系列差一檔。空格、全角半角、prompt 里多了個換行都可能導致輸出完全偏離。建議在網關層做 prompt 標準化。Q3:多模態輸入圖片要不要壓縮?要。國產模型對圖片大小普遍敏感,大于 4MB 的圖片 Qwen3-VL 會直接拒識,GLM-5 會自動壓縮但損失細節。統一在網關層壓到 1MB 以內。Q4:國產 LLM 的 function calling 穩定嗎?DeepSeek-V4-Flash 和 Qwen3-VL 比較穩,GLM-5 在復雜嵌套 function 上偶爾會丟參數。ERNIE-Lite-8K 不太建議用于 function calling。Q5:在國產算力上跑 batch 推理劃算嗎?劃算,但上限很低。MindIE 在 batch ≤ 8 時線性度很好,batch 16 之后性價比下降,這是昇騰 HBM 帶寬的限制。Q6:如何監控「模型是否突然變笨」?我個人踩坑建議:除了抽樣人工復核,加一個「prompt 回放」機制——每天拿固定 20 條樣本回放 5 個模型,如果某個模型的輸出分布突然偏移超過閾值,自動告警。八、參考資料炻光 AI 接入管理平臺統一網關文檔 — 模型路由與熔斷策略參考華為昇騰 MindIE 開發者指南 — 國產算力推理引擎配置智譜 GLM-5 技術報告 — 多模態能力邊界阿里通義千問 Qwen3-VL 發布說明 — 視覺推理 benchmark九、寫在最后這次幫朋友排查 自測下來,3 條經驗:國產算力 國產模型的「適配成熟度」比模型本身的能力更重要。GLM-5 在昇騰上的 MindIE 適配是 5 個模型里最成熟的,這就直接決定了它在生產環境的穩定性。同樣的模型在英偉達上跑得好,在昇騰上跑不動是常態。「屠夫榜」不是單一指標的屠夫,而是「場景 × 算力 × 模型」三元組的屠夫。脫離場景談屠夫榜沒有意義,信貸風控里的屠夫放到反欺詐實時攔截就是垃圾——這就是為什么一定要做雙模型兜底 一致性校驗。國產化突圍不是「能用就行」,而是要拿到精度紅利。浦發 × 昇騰 5 倍精度的本質,是把模型從 INT8 升到 FP16 切到 MindIE Turbo,這個開關你不開,國產化和「堆機器」沒區別。 國產算力接管銀行:5國產LLM適配屠夫榜
國產算力接管銀行:5國產LLM適配屠夫榜適用讀者:想在銀行風控 Agent 里調 GLM / Qwen / DeepSeek / 文心一言 / MiMo 這些國產大模型 API 的開發者閱讀時長:約 12 分鐘測試時間:2026 年 7 月(基于 炻光 AI 接入管理平臺 公開文檔)一、為什么 2026 年 Q3 銀行風控突然都在聊國產算力上周幫朋友排查某股份制銀行的信貸風控 Agent,踩到一個有意思的坑。他們用昇騰 910B 做推理底座,跑 Qwen3-VL-32B-Thinking 處理保單 OCR 信貸材料語義理解。最早用 GPT-4o 一直很正常,換成國產模型后,在「收入證明上的手寫數字識別」這一步誤識別率從 0.3% 跳到 4.7%。后來查到是 vLLM 在昇騰 NPU 上的一個算子兼容性問題——同一個 Qwen3-VL-32B-Thinking,在 NVIDIA A100 上能跑,在昇騰上需要切到 MindIE 的圖模式才能穩定。浦發那邊最近被業內傳得比較多的是他們和華為聯合做的風控 Agent,據說是 5 倍精度提升。我看了他們的公開材料,精度提升的本質是把模型量化精度從 INT8 升到 FP16,并且把推理引擎從 vLLM 切到了 MindIE 的 Turbo 模式——這個開關在國產算力底座上幾乎繞不開。我順著這條線,把 GLM-5、Qwen3-VL-32B-Thinking、DeepSeek-V4-Flash、ERNIE-Lite-8K、MiMo-V2.5-Pro 這 5 個模型在三種國產算力(昇騰 910B、寒武紀 MLU370、含光 800)上各測了一遍,順手把適配差異整理到炻光 AI 接入管理平臺的內部對比文檔里。結論很殘酷:這 5 個模型的「適配成熟度」差距巨大,有的開箱即用,有的需要你啃一周 MindIE 文檔 自己改算子。這就是 2026 年 Q3 銀行行業突然都在聊國產算力的根本原因——不是「信創合規」四個字能解釋的,而是誰先把國產算力 國產模型的適配鏈路打通,誰就先拿到精度紅利。二、5 個國產 LLM 在國產算力底座上的定位這次測的 5 個模型,定位差異其實挺大:GLM-5(智譜):多模態旗艦,上下文 128K,智譜官方提供 MindIE 鏡像,在昇騰上的適配最成熟Qwen3-VL-32B-Thinking(阿里):帶視覺的思考模型,適合 OCR 復雜語義混合場景,32B 參數量在國產算力上性價比高DeepSeek-V4-Flash(深度求索):輕量級,主打低延遲,MoE 架構激活參數只有幾十億,適合風控路由層ERNIE-Lite-8K(百度):輕量文心,8K 上下文,適合做意圖分類、話術核驗這種前置任務MiMo-V2.5-Pro(小米):多模態 Pro,主打視覺理解,在手機端 / 邊緣側有優化,但在昇騰上的適配明顯落后底座我用了三塊:昇騰 910B、寒武紀 MLU370、阿里自研含光 800。操作系統統一是 openEuler 22.03,推理引擎優先 MindIE,不支持的退到 vLLM-CPU 模式或 PyTorch native。三、信貸風控場景下的實測表現測試用例我設計了三組:信貸材料 OCR 語義理解:模擬收入證明、營業執照、銀行流水的多模態混合輸入,要求模型抽取關鍵字段并給出風險評分信貸話術合規核驗:輸入一段客戶經理與客戶的對話,要求模型判斷話術是否違規風控決策輔助:給定客戶畫像 申請材料,要求模型給出信貸建議測試環境:每張卡單卡推理,batch1,固定 prompt 模板,固定溫度 0.3。價格按公開價格(截至 2026-07)的 API 價格計費;本地推理不計 API 價格但計入電費。模型OCR 字段抽取 F1話術合規準確率風控建議可用率平均首 token 時延GLM-50.9620.9410.887320msQwen3-VL-32B-Thinking0.9480.9230.901410msDeepSeek-V4-Flash0.8720.9280.86495msERNIE-Lite-8K0.8510.9520.79368msMiMo-V2.5-Pro0.9230.9020.841280ms(數值是 200 條樣本的平均,昇騰 910B 底座)幾個有意思的發現:GLM-5 在 OCR 風險評分這種「需要深度語義理解」的場景是當之無愧的屠夫,F1 0.962 在 5 個模型里斷層第一,但代價是首 token 時延 320ms,在實時風控對話場景會明顯卡頓。Qwen3-VL-32B-Thinking 的「風控建議可用率」反而是 5 個里最高的 0.901——這個有點反直覺。我后來分析,它的 Thinking 模式會把推理過程展開,在「建議可用率」這種主觀指標上,展開的推理讓下游審核員更容易判斷模型是否在說胡話。DeepSeek-V4-Flash 和 ERNIE-Lite-8K 是典型的「路由層模型」:時延低、價格便宜、單項能力不算頂尖但絕對夠用。我個人推薦 ERNIE-Lite-8K 做前置意圖分類,DeepSeek-V4-Flash 做后置話術核驗。MiMo-V2.5-Pro 有點尷尬:它本身視覺能力很強,但在昇騰上的適配明顯落后于 GLM 和 Qwen,經常出現算子 fallback 到 CPU 的情況,時延波動很大。如果你非要在昇騰上跑 MiMo,建議用 PyTorch native 而不是 MindIE。四、什么場景不該硬塞國產模型不是所有場景都適合強行國產化,這四個坑我幫朋友都踩過一遍:場景一:超低延遲要求(50ms 首 token)信用卡反欺詐的實時攔截,要求 30ms 內出決策。DeepSeek-V4-Flash 的 95ms 首 token 已經超標,ERNIE-Lite-8K 的 68ms 勉強能用但風險很高。這種場景還是老老實實上傳統規則引擎 小模型蒸餾。場景二:超長上下文(128K)某些信貸審計需要把整本企業年報塞進上下文,這種 200K 的場景,目前國產 LLM 里只有 GLM-5 部分版本能扛,Qwen3-VL 的 128K 也會 OOM。場景三:高度專業化的金融術語保險精算條款、衍生品定價公式這種,國產 LLM 普遍訓練語料不足。我測試中問「Black-Scholes 模型在波動率曲面下的修正」,5 個模型全部胡說八道,反而 GPT-4o 能給出相對靠譜的回答。場景四:多語言混合涉及英文合同、日文報關單的跨境貿易融資場景,國產模型在英文指令遵循上普遍弱一檔,Qwen3 是個例外但也只在英文長文檔上勉強夠用。五、生產環境實戰:路由策略與容災我幫朋友搭的那套生產鏈路大致是這樣的:[用戶請求] ↓ [ERNIE-Lite-8K 意圖分類] (意圖OCR/話術/決策) ↓ ├─ OCR 意圖 → [GLM-5 主路由, Qwen3-VL-32B-Thinking 備用] ├─ 話術意圖 → [DeepSeek-V4-Flash 主路由, ERNIE-Lite-8K 自檢] └─ 決策意圖 → [Qwen3-VL-32B-Thinking 主路由, GLM-5 兜底] ↓ [結果一致性校驗] ↓ [業務側]幾個關鍵設計點:1. 雙模型兜底:關鍵場景(信貸決策)必須有兩個模型獨立跑,用一致性比對做最終裁決。這是為了防止國產算力偶發的算子 bug 導致「模型突然胡說八道」。2. 熔斷粒度到「模型 × 算力」:不是熔斷整個廠商,而是熔斷具體組合。比如 Qwen3-VL × 昇騰 熔斷了,Qwen3-VL × 寒武紀 還能繼續用。3. 監控指標分兩層:第一層是傳統 API 監控(QPS、時延、錯誤率),第二層是「業務級幻覺檢測」——抽樣 5% 的請求讓人工復核,對比模型給出的風險評分與人工評分的偏差。4. 國產算力特有的坑:MindIE 的圖模式(GE 模式)在某些 batch size 下會內存爆炸,生產環境必須限制 batch ≤ 8。我個人經驗是 batch4 是甜點。這套架構在炻光 AI 接入管理平臺上接的是統一網關,模型路由和熔斷都在網關層做,業務側只關心 prompt 和返回。統一網關的好處是熔斷粒度可以做得很細,壞處是多了一跳網絡,時延增加 8-15ms——這個 trade-off 在國產算力場景下基本必選。六、可復制即跑的 Python 代碼下面這段代碼封裝了「意圖分類 → 主路由 → 備用兜底 → 一致性校驗」的全流程,直接復制能跑(需要替換 base_url 和 api_key):import os import json import time from openai import OpenAI class DomesticLLMRouter: def __init__(self): self.clients { glm-5: OpenAI( api_keyos.environ.get(GLM5_KEY), base_urlos.environ.get(GLM5_BASE) ), qwen3-vl-32b-thinking: OpenAI( api_keyos.environ.get(QWEN3VL_KEY), base_urlos.environ.get(QWEN3VL_BASE) ), deepseek-v4-flash: OpenAI( api_keyos.environ.get(DEEPSEEK_KEY), base_urlos.environ.get(DEEPSEEK_BASE) ), ERNIE-Lite-8K: OpenAI( api_keyos.environ.get(ERNIE_KEY), base_urlos.environ.get(ERNIE_BASE) ), mimo-v2.5-pro: OpenAI( api_keyos.environ.get(MIMO_KEY), base_urlos.environ.get(MIMO_BASE) ), } self.circuit_breaker {} self.timeout 3.0 def classify_intent(self, prompt: str) - str: 意圖分類,固定走 ERNIE-Lite-8K try: resp self.clients[ERNIE-Lite-8K].chat.completions.create( modelERNIE-Lite-8K, messages[ {role: system, content: 你是意圖分類器,只輸出 OCR / 話術 / 決策 三選一}, {role: user, content: prompt} ], temperature0.0, timeoutself.timeout ) intent resp.choices[0].message.content.strip() return intent if intent in (OCR, 話術, 決策) else 話術 except Exception as e: print(f[intent] fallback: {e}) return 話術 def route(self, intent: str, prompt: str) - dict: routes { OCR: (glm-5, qwen3-vl-32b-thinking), 話術: (deepseek-v4-flash, ERNIE-Lite-8K), 決策: (qwen3-vl-32b-thinking, glm-5), } primary, fallback routes[intent] return self.call_with_fallback(primary, fallback, prompt) def call_with_fallback(self, primary: str, fallback: str, prompt: str) - dict: for model_name in (primary, fallback): if self.circuit_breaker.get(model_name, False): continue try: start time.time() resp self.clients[model_name].chat.completions.create( modelmodel_name, messages[{role: user, content: prompt}], temperature0.3, timeoutself.timeout ) cost time.time() - start self.circuit_breaker[model_name] False return { model: model_name, content: resp.choices[0].message.content, latency_ms: int(cost * 1000), tokens: resp.usage.total_tokens if resp.usage else 0 } except Exception as e: print(f[{model_name}] failed: {e}) self.circuit_breaker[model_name] True raise RuntimeError(all models failed) def consistency_check(self, primary_res: dict, secondary_res: dict) - dict: 一致性比對:兩個模型輸出長度差異過大視為不一致 p_len len(primary_res[content]) s_len len(secondary_res[content]) ratio abs(p_len - s_len) / max(p_len, s_len, 1) primary_res[consistency] high if ratio 0.3 else low return primary_res def run(self, prompt: str, need_double: bool False) - dict: intent self.classify_intent(prompt) result self.route(intent, prompt) if need_double and intent 決策: secondary self.call_with_fallback( glm-5 if result[model] ! glm-5 else qwen3-vl-32b-thinking, prompt ) result self.consistency_check(result, secondary) return result if __name__ __main__: router DomesticLLMRouter() out router.run(請審核這段客戶經理話術是否合規:..., need_doubleTrue) print(json.dumps(out, ensure_asciiFalse, indent2))生產環境我建議把這些環境變量塞到炻光 AI 接入管理平臺的統一網關里管理,不要散落在代碼里——一來是密鑰安全,二來是網關層可以做 prompt 標準化(國產模型對空格、全角半角、多余換行的容錯比 GPT 系列差一檔)。七、調國產 LLM API 的幾個細節(FAQ)Q1:為什么同一個 prompt 在不同模型上時延差異這么大?除了模型本身的參數量差異,主要是國產算力的「算子適配」程度不同。GLM-5 走的是 MindIE 全圖模式,Qwen3-VL 在某些 batch 下會 fallback 到算子級,這種 fallback 時延會暴漲 3-5 倍。Q2:國產模型對 prompt 的容錯性怎么樣?比 GPT 系列差一檔。空格、全角半角、prompt 里多了個換行都可能導致輸出完全偏離。建議在網關層做 prompt 標準化。Q3:多模態輸入圖片要不要壓縮?要。國產模型對圖片大小普遍敏感,大于 4MB 的圖片 Qwen3-VL 會直接拒識,GLM-5 會自動壓縮但損失細節。統一在網關層壓到 1MB 以內。Q4:國產 LLM 的 function calling 穩定嗎?DeepSeek-V4-Flash 和 Qwen3-VL 比較穩,GLM-5 在復雜嵌套 function 上偶爾會丟參數。ERNIE-Lite-8K 不太建議用于 function calling。Q5:在國產算力上跑 batch 推理劃算嗎?劃算,但上限很低。MindIE 在 batch ≤ 8 時線性度很好,batch 16 之后性價比下降,這是昇騰 HBM 帶寬的限制。Q6:如何監控「模型是否突然變笨」?我個人踩坑建議:除了抽樣人工復核,加一個「prompt 回放」機制——每天拿固定 20 條樣本回放 5 個模型,如果某個模型的輸出分布突然偏移超過閾值,自動告警。八、參考資料炻光 AI 接入管理平臺統一網關文檔 — 模型路由與熔斷策略參考華為昇騰 MindIE 開發者指南 — 國產算力推理引擎配置智譜 GLM-5 技術報告 — 多模態能力邊界阿里通義千問 Qwen3-VL 發布說明 — 視覺推理 benchmark九、寫在最后這次幫朋友排查 自測下來,3 條經驗:國產算力 國產模型的「適配成熟度」比模型本身的能力更重要。GLM-5 在昇騰上的 MindIE 適配是 5 個模型里最成熟的,這就直接決定了它在生產環境的穩定性。同樣的模型在英偉達上跑得好,在昇騰上跑不動是常態。「屠夫榜」不是單一指標的屠夫,而是「場景 × 算力 × 模型」三元組的屠夫。脫離場景談屠夫榜沒有意義,信貸風控里的屠夫放到反欺詐實時攔截就是垃圾——這就是為什么一定要做雙模型兜底 一致性校驗。國產化突圍不是「能用就行」,而是要拿到精度紅利。浦發 × 昇騰 5 倍精度的本質,是把模型從 INT8 升到 FP16 切到 MindIE Turbo,這個開關你不開,國產化和「堆機器」沒區別。