推論成本審計
大多數生產環境中的 LLM 呼叫回傳的是標籤，而非 prose（散文）——一個路由、一個分數、一個是/否、一個類別。這些呼叫支付的費用是為未使用的自迴歸生成。此審計會找出它們並為替換方案定價。
交付物：一個附有測量差異的候選排名表。可作為 OneWave 的服務銷售；形狀與 marketing-brain 相同——一個可為每位客戶重複執行的審計流程。
1. 尋找候選項目
搜尋 LLM 呼叫，然後過濾出輸出為標籤的呼叫：
grep -rnE "messages\.create|chat\.completions|generateText|\.invoke\(|anthropic\.|openai\." \
--include=*.{ts,tsx,js,py} . | grep -v node_modules
當所有以下條件成立時，一個呼叫即為候選項目：
- 提示要求一個已知、有限的答案集（≤255）
- 呼叫端解析回應——JSON.parse、正規表達式、列舉查詢、
.trim() - 下游沒有任何部分向人類顯示模型的推論
- 它頻繁執行，或使用者需要等待它
提示文字中的強烈信號：「僅回覆」、「回傳 JSON」、「分類」、「選擇其中一個」、「從 1 到 評分」、「回答是或否」、「不要解釋」。
排除條件：輸出顯示給使用者、用作內容、需要引用或理由，或答案集是開放式的。
2. 測量當前成本
不要估算。進行監控：
- 每日呼叫次數——來自日誌或計數器，而非猜測
- p50 和 p95 延遲——p95 是使用者實際感受到的
- 每次呼叫的輸入/輸出 token 數 → 按提供者目錄價格計算的目前每千次成本
- 是否有任何東西被封鎖——使用者、頁面渲染、代理的下一個步驟
3. 為替換方案定價
使用來自該呼叫實際流量的標記資料集進行基準測試（參見 jev-eval）。永遠不要從供應商基準測試進行推估。
參考數據，基於真實記錄測量，每條記錄 4 個問題：
| 延遲 | 成本/千次 | 準確度 | |
|---|---|---|---|
| Jev 託管 | 399 毫秒 | $0.023 | 在 15 條記錄上與 Claude 匹配 |
| Von 本機 | 174 毫秒 | $0.00 | 僅在良好撰寫條件下匹配 |
| Claude Haiku 4.5 | 2,322 毫秒 | ~$0.55 | 基準線 |
Jev 定價：$0.042/MTok 輸入，輸出免費。
4. 根據回報排序，而非簡易度
對每個候選項目進行排名：
- 數量 × 單位節省——實際的金額數字
- 是否有真人等待——在使用者面對的路徑上，延遲改善比成本改善更有價值
- 如果錯誤的影響範圍——錯誤路由的支援工單成本低；錯誤評分的交易則不然
- 標記資料集上的準確度差異——任何低於平手的項目都需要信心門檻，而門檻本身有其成本
刪除數量低的項目。在每天數百次呼叫的情況下，節省金額幾乎為零，而且你還增加了一個供應商。
5. 撰寫報告
每個候選項目：檔案和行號、它決定什麼、每日呼叫次數、當前延遲和成本、預測延遲和成本、測量的準確度差異、建議的門檻，以及執行/放棄及其理由。
摘要以總計預測每月節省金額和單一最大的延遲改善為開頭。
始終包含限制條件：評估集大小、Jev 為早期存取版本且無 SLA，以及必須保留現有呼叫的備援。
這在 OneWave 技術堆疊中何處有回報
- Sage 小工具路由——建造它。訪客正在觀看；400 毫秒與 2.3 秒的差距就是全部。
- RB2B 訪客資料流——建造它。唯一一個數量龐大且 24 倍成本節省會累積的串流。
- 潛在客戶入門分類——先測量。雖然正確，但每天只有少量潛在客戶。
- 潛在客戶監控——保留它。夜間 cron，沒有什麼在等待它。
相關
jev-eval 產生此審計依賴的準確度數字。jev-integrate 是針對獲得執行決策的項目進行接線的工作流程。