用量與分析
「資料」選單下有兩個視角看同一份賬本:「用量」(/admin/usage)是逐條呼叫記錄,用於對賬、排障和清理;「分析」(/admin/analytics)是聚合看板,用於看趨勢、找大戶。資料來源都是用量日誌表:每一次底層模型呼叫記一行,不只是使用者可見的聊天回覆,標題生成、查詢路由、壓縮摘要、記憶抽取、嵌入、圖片、審校、深度研究的規劃與核驗等內部呼叫也各記一行(它們同樣產生費用,應計入使用者成本)。
用量報表(資料 > 用量)
每條 API 呼叫一行,按呼叫時間倒序,每頁 50 條。
表格列
| 列 | 內容 |
|---|---|
| 呼叫時間 | 精確到秒,按介面語言格式化 |
| 使用者 | 郵箱(無郵箱時顯示 ID) |
| 關聯對話 | 對話標題,點選直達管理員會話檢視頁;對話發生在工作空間時,下方附「空間」徽標;**對話已被刪除時顯示「已刪除」**而非懸空 ID |
| 模型 | 模型顯示名 |
| 渠道 | 實際服務本次請求的上游渠道;走了兜底渠道時附橙色「兜底」徽標 |
| 用途 | 見下表;失敗請求在用途旁附紅色「錯誤」徽標,點選檢視詳情 |
| 輸入 / 輸出 | 本次呼叫的輸入與輸出 token 數 |
| 費用 | 按模型配置價算出的本次呼叫費用(美元) |
| 操作 | 行內刪除按鈕 |
用途(purpose)取值
| 用途 | 含義 |
|---|---|
| 對話 | 使用者聊天的主模型呼叫,一次多輪工具迴圈裡的每次上游呼叫各記一行 |
| 圖片 | 圖片生成(繪圖模式與聊天中的圖片工具共用) |
| 嵌入 | RAG 文件入庫與查詢的向量化呼叫 |
| 標題生成 / 查詢路由 / 上下文壓縮 | 任務模型的內部小呼叫 |
| 記憶抽取 / 記憶裁決 | 記憶系統的非同步任務呼叫 |
| 跨廠商降級 | 歷史跨廠商回放時的轉換呼叫 |
| 圖片提示詞 | 繪圖前的提示詞潤色 |
| 研究規劃 / 研究核驗 / 研究交叉驗證 | 深度研究管線的任務模型呼叫 |
| 內容稽核 | 「模型」模式稽核的判定呼叫 |
verify | 審校模式下審計模型的核查呼叫 |
費用按模型編輯頁配置的單價計算:文本模型分輸入 / 輸出 / 快取讀 / 快取寫四檔(每百萬 token 單價),圖片模型按張計價,貨幣為美元。只記賬、不在這裡扣減,積分扣費是另一層(見使用者、配額與積分)。
篩選與統計
| 篩選器 | 說明 |
|---|---|
| 時間範圍 | 最近 1 / 7 / 30 / 90 天(滾動視窗) |
| 使用者 | 郵箱或 ID 子串,輸入 400ms 後自動查詢 |
| 模型 | 下拉選擇單個模型,或「全部模型」 |
| 狀態 | 全部 / 僅錯誤 |
表格上方兩張統計卡即時反映當前篩選的總費用與記錄數。任何篩選變化都會回到第一頁。
工作空間歸屬
共享工作空間裡的呼叫遵循"誰傳送誰付費":成員在共享對話中續聊,配額與積分消耗記在傳送者自己名下,用量行同時記錄所屬空間並在關聯對話下方顯示「空間」徽標。給團隊做成本分攤時,按使用者篩選看到的就是每個人的真實消耗,空間徽標用來區分個人使用與協作使用。
刪除記錄
- 行內垃圾桶:刪除單條記錄。
- 「刪除篩選結果」:批次刪除當前篩選命中的全部記錄,確認彈窗會顯示命中條數;不可撤銷。
用量日誌不只是報表:服務重啟後,使用者的視窗配額計數和時效積分消耗都從這張表重新播種。清理近期(仍在配額視窗內)的記錄,可能讓相關使用者的"已用次數 / 已用積分"被低估。清理歷史歸檔資料沒有影響,建議只按較早的時間範圍批次刪除。
錯誤請求與失敗載荷日誌
錯誤也入賬
上游呼叫失敗(連線錯誤、401 / 403 / 429 / 5xx 等)時同樣記一行,標記為錯誤狀態,token、費用、積分全部為零。這讓失敗次數可統計、可按「僅錯誤」篩選,渠道質量問題一眼可見。
配套的口徑保證:錯誤行不佔使用者任何額度。它被排除在配額視窗回填、使用者側可見的用量計數和分析看板之外,失敗請求既不消耗使用者的免費次數,也不會把"呼叫數 / 活躍使用者"灌成與 token / 費用不一致的水分。計費時點遵循"發出即算,失敗不算":
| 情形 | 計次 | 扣積分 |
|---|---|---|
| 正常完成 | 是 | 是 |
| 使用者中途停止(已產出內容) | 是 | 按已產出部分實扣 |
| 上游報錯(含兜底也失敗) | 否 | 否 |
| 傳送前被攔(配額超限 / 內容稽核) | 否 | 否 |
失敗載荷詳情(僅管理員可見)
點選錯誤行的「錯誤」徽標,彈窗展示排障所需的全部現場:
| 區塊 | 內容 |
|---|---|
| 上游報錯 | 上游返回的原始錯誤(狀態碼 + 響應體,超長截斷) |
| 請求方法與 URL | 實際發往上游的方法與完整地址 |
| 請求頭 | 發出的請求頭快照 |
| 請求體 | 發出的請求體快照(JSON 格式化) |
快照經過脫敏:Authorization、API Key、token、secret、password、cookie 等敏感欄位一律替換為 [redacted],內嵌的 base64 圖片資料被摘除為佔位說明,請求體預設截斷到 128 KB、單值截斷到 8 KB。這些詳情只經管理員介面下發:終端使用者遇到同一失敗只會看到泛化的錯誤提示,不會看到上游原文。
排障常用姿勢:狀態篩「僅錯誤」+ 模型篩選,逐條開啟錯誤詳情,把請求體原樣複製到 curl 裡對上游復現,即可快速區分"渠道 Key 失效 / 上游改了協議 / 請求內容超限"。
兜底徽標
模型配置了兜底渠道時,主渠道失敗會自動改走兜底重試一次。走過兜底的呼叫在渠道列帶橙色「兜底」徽標(一輪工具迴圈內任何一次子請求切了兜底,整輪都標記)。「兜底」徽標頻繁出現,說明主渠道不穩,該修渠道了。
分析看板(資料 > 分析)
看板把同一份日誌聚合成趨勢檢視,所有統計排除錯誤行,呼叫數、活躍使用者與 token / 費用總是一致口徑。
視窗與指標
- 時間視窗:右上角選擇最近 1 / 7 / 30 / 90 天(滾動視窗,介面最大支援 365 天)。
- 指標切換:呼叫次數 / 令牌 / 費用,一個開關驅動頁面上所有圖表;令牌 = 輸入 + 輸出之和。
KPI 卡
| 卡片 | 含義 |
|---|---|
| 總呼叫次數 | 視窗內成功呼叫總數 |
| 總令牌數 | 輸入 + 輸出 token 總和 |
| 總費用 | 按模型配置價累計的費用(美元) |
| 活躍使用者 | 視窗內產生過成功呼叫的去重使用者數 |
趨勢圖
豎向柱狀圖展示視窗內的整體走勢:選 1 天視窗時按小時分桶,其餘按天分桶;懸停任意柱子顯示該時段的精確數值。
Top 模型 / Top 使用者
兩張並排卡片分別列出視窗內消耗最高的前 8 個模型與前 8 個使用者(按費用排序,費用相同按呼叫量):
- 每行一個橫向佔比條(相對當前指標的最大值),右側數值;
- 行尾附一條迷你趨勢線(sparkline),與趨勢圖共用分桶,一眼看出該模型 / 使用者的消耗是持續的還是突發的;
- 使用者行顯示郵箱,模型行顯示模型名稱。
費用異常排查的典型路徑:分析頁發現某使用者費用突增,記下郵箱,切到「用量」頁按該使用者篩選,逐條看它在調什麼模型、什麼用途、單次多少 token,必要時進入關聯對話核實內容。
運營場景速查
| 場景 | 操作路徑 |
|---|---|
| 使用者反饋"一直失敗" | 用量頁篩該使用者 + 「僅錯誤」,開啟錯誤詳情看上游原文;若行帶「兜底」徽標,說明主渠道也在失敗 |
| 某渠道疑似失效 | 用量頁篩「僅錯誤」,看錯誤行集中在哪個渠道;修復渠道 Key 或給模型配兜底渠道 |
| 內部用途費用偏高 | 分析頁切「費用」指標,若標題生成 / 壓縮等任務呼叫佔比高,到全域性設定換一個更便宜的任務模型 |
| 給團隊分攤成本 | 分析頁 Top 使用者找大戶,用量頁按使用者篩選逐條核對,空間徽標區分個人與協作消耗 |
| 免費額度疑似被刷 | 記住錯誤行與被稽核攔截的訊息都不計次;真實消耗以本頁記錄為準,按使用者 + 時間範圍篩選統計 |
線上使用者判定
線上狀態顯示在「使用者 > 使用者」列表:每行郵箱前有一個狀態點,綠色為線上、灰色為離線;使用者資訊彈窗裡還能看到「最近活躍」的精確時間。判定規則:
- 使用者最近 5 分鐘內發出過任意帶認證的請求,即視為線上。
- 服務端在處理請求時重新整理使用者的最近活躍時間,為了控制寫入頻率至多每分鐘重新整理一次,因此線上判定有最多約 1 分鐘的滯後。
- 判定完全基於請求觸達,沒有獨立的心跳通道:使用者開著頁面但長時間無任何操作(不發訊息、不切頁面)會逐漸顯示為離線,這屬於預期行為。
使用者列表的"線上"是此刻的近即時狀態;分析看板 KPI 裡的"活躍使用者"是統計視窗內產生過模型呼叫的去重人數。前者答"現在有誰在",後者答"這段時間誰在用"。