同一個模型接了不只一條上游路由
路由分開追蹤健康狀態，一條出問題不影響其他路由。
上游掛掉的時候，
你的使用者不該知道。
同一個模型接了不只一條上游路由。一條失敗時，同一個請求自動改走下一條——不是重新開始，是接手完成。
同一個請求，路由怎麼選
主路由與備援路由分開追蹤健康狀態；決定要不要換路由的，是這次請求當下的健康判定。
真實客戶跑過的長任務
文字串流最長 60 分鐘、影片任務最長 9.8 小時，都完整跑完。
60 分鐘
實測最長文字串流
67,462 tokens，成功完成
9.8 小時
實測最長影片任務
非同步生成，成功完成
平台歷史實測資料，非服務承諾。
長時間任務建議走 api.bazaarlink.ai —— 它是跟網站分開部署的純 API 入口，不會被網站的部署重啟打斷。
怎麼運作
四個機制事實，每一條都對應到實際的請求路徑，不是行銷話術。
熔斷只斷故障的那一條路由
不會因為一條路由出問題就讓整個模型停擺，其他模型完全不受影響。
重試發生在你看到任何內容之前
先確認真的有模型在回應，才開始把內容吐給你——已經開始收到的回答，不會半路換供應商。
失敗會留在你的用量紀錄裡
看得到重試發生過、看得到失敗代碼，不是靜默吞掉；紀錄不會露出實際是哪家上游。
如果連線是在內容開始之後才斷
這種情況我們不會幫你換供應商重接。你看到的會是明確的錯誤提示，不是一個看起來完整、其實斷在半路的回答；這種請求我們也不會跟你收費。這裡講的是機制，不是可用性保證——如果你的合約有 SLA，以合約為準。
想看完整的路由與熔斷邏輯？
路由怎麼排序、熔斷門檻怎麼算、用量紀錄的欄位定義，都在文件裡。
接上你自己的流量測一次
五分鐘接好，一條路由失敗不會讓你的使用者發現。
看容錯機制怎麼運作