機構客戶
能力
配置團隊權限及算力需求
責任
帳戶安全、用量管理、數據處理及服務使用
01 · KAI 的方法
穩健算力，始於可預期的交付
把分散的模型服務容量整理成機構能夠規劃、比較及核對的服務，讓算力從供應能力走向真實工作負載。
01
可預期
按已指定的模型、版本、區域及服務時段安排容量。
02
可比較
以一致的服務參數及計量方式描述不同供應商的容量。
03
可驗證
以 Chat Completions 用量及服務質素記錄交付結果。
02 · 交付方法
從可用容量到真實模型服務
KAI 以一條清楚的交付鏈路連結機構需求、供應商容量及真實推理請求。
01
定義
鎖定模型、版本、區域、時區、服務小時及容量單位。
02
調度
服務開始前確認機構需求及供應商可用容量。
03
監測
持續量度 TPM、可用性、系統錯誤率及首 Token 延遲。
04
交付
機構在指定時段使用 KAI Chat Completions 容量，結果落到真實推理請求。
03 · 容量標準
一個清楚的容量單位
容量以指定模型、版本、區域及服務時段共同界定，讓機構在使用前就知道所取得的服務。
每個容量單位
1,000,000 TPM × 1 小時
每個容量單位在整個服務小時內，於每個連續 60 秒計量窗口持續提供 1,000,000 TPM。
加權 TPM = I + W × O
連續 60 秒計量窗口 · 加權 TPM = I + W × O
查看完整服務定義
標準服務參數
- 固定模型名稱及可驗證版本 digest
- 明確 IANA 時區的連續 60 分鐘服務時段
- 固定服務、網絡及數據處理區域
- 每個容量單位為 1,000,000 TPM × 1 小時
使用邊界
- 吞吐量、可用性、延遲及服務標準共同界定容量
- GPU、模型權重及最終使用者身份不屬於服務內容
- 未使用容量不會累積至後續窗口
- 服務小時結束後不再接受該時段的新請求；已接受的請求會繼續完成
04 · 服務保障
用可核對的規則建立交付信心
服務保障不依賴抽象承諾，而是來自事前核准、全程記錄、持續監測及真實交付。
01
事前核准
所有容量聲明均須在提供服務前完成核准及驗證。
02
全程追溯
帳戶權限、使用記錄及數據處理須保持可追溯。
03
持續監測
服務時段內持續記錄 TPM、可用性、系統錯誤率及首 Token 延遲。
04
真實交付
交付結果落到合格、可量度的 Chat Completions 服務。
05 · 責任模型
清晰分工，持續交付
機構客戶、容量供應商及 KAI 營運團隊各自承擔清楚、可追溯的服務責任。
容量供應商
能力
接入 Provider 並登記可用容量
責任
容量來源、服務質素、計量證據及異常補救
KAI 營運團隊
能力
協調容量、監測質素及處理異常
責任
接入審批、服務監察、權限隔離及營運連續性
機構接入
規劃下一個算力時段
如貴機構正為指定模型、區域或時段規劃容量，請聯絡 KAI。