HopBase先說答案:衡量大模型 API 的性能,看三個可測的東西——首字延遲(TTFT)的 P95/P99 分布、串流全程的穩定性(斷流率)、以及 prompt cache 命中對兩者的放大作用。總耗時和平均值都會騙人。「高性能」不該是供應商頁面上的形容詞,而應該是你終端裡跑出來的數字,方法在下面,全部可復現。
為什麼「總耗時」是個壞指標
一次生成的總耗時由輸出長度主導:輸出 2000 字自然比 200 字慢十倍,這和鏈路質量無關。串流場景下用戶的真實體感是兩段:首字什麼時候出來(TTFT),之後出字穩不穩。TTFT 才是鏈路指標——它包含了接入、網關調度、上游排隊的全部開銷,鏈路上任何一環擁堵都會體現在這裡。
看分布,別看均值
均值會被長尾抹平:100 次請求裡 90 次 1 秒、10 次 8 秒,均值 1.7 秒看著不錯,但你的用戶每十次就撞上一次 8 秒。P95/P99 抖動大,說明鏈路在排隊或重試——這正是保真檢測裡「工程質量面」的判據之一。實測要點:固定提示、溫度 0、同一時段連續 N≥30 次,記錄每次 TTFT 後看分位數,而不是平均。
斷流率:最被忽視的性能指標
長輸出中途靜默截斷,是串流場景最惡劣的故障形態:你拿到了一半內容,卻沒有任何錯誤碼。測法很簡單:讓模型穩定輸出長內容(比如 2000 字),重複 N 次,統計「流正常走完」的比例;同時檢查流的收尾是否規範(SSE 是否有明確的結束標記)。斷流率高的通道,再快的 TTFT 都沒有意義。
快取命中:性能與成本是同一枚硬幣
prompt cache 命中時,輸入側按折扣價計費,TTFT 也顯著下降——性能和成本在這裡是同一件事。而命中率取決於通道拓撲:請求必須落在同一個上游帳號上才可能命中,隨機路由的池子命中率趨近於零。網關側怎麼用親和調度保住命中率,見高並發網關工程實錄;cache 的計費結構與省錢寫法,見Prompt Cache 能省多少錢。
錯誤碼與重試行為
性能測試裡容易漏掉的一項:網關是否原樣透傳上游錯誤碼。把 429 吞掉改造成超時的通道,會讓你的客戶端退避邏輯失效,高峰期性能雪崩。測法:故意觸發限流或傳錯參數,對比返回行為與官方文檔是否一致。
一條命令起步的測法
TTFT 用 curl 就能量(串流下 time_starttransfer 即首塊到達時間):
curl -N -s -o /dev/null \
-w "TTFT %{time_starttransfer}s | total %{time_total}s\n" \
https://api.hop-base.com/v1/chat/completions \
-H "Authorization: Bearer $HOPBASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"<模型ID>","stream":true,"messages":[{"role":"user","content":"用一句話介紹你自己"}]}'把它放進循環跑 30 次,再換高峰時段複測一輪,P95 和抖動就都有了。完整的評測紀律:固定任務集、溫度 0、剔除首次冷啟動、隔時段複測、官方直連與被測通道同條件對照。
我們自己怎麼埋點
HopBase 對每個請求記錄模型、用量、耗時、狀態——這既是計費審計的留痕,也是我們自己的性能監控數據源;常駐探針持續撥測各通道,異常在用戶感知之前處理。這也是我們敢把測法公開的原因:你測出來的數字,和我們看到的是同一條鏈路。
常見問題
TTFT 多少算「好」?
絕對值受模型、地域、接入點影響,橫向可比的是同條件下的對照:官方直連與被測通道各跑一輪,差距和分布穩定性比絕對值更說明問題。
經過網關會比直連慢嗎?
網關多一跳的固定開銷是毫秒級;而調度帶來的排隊減少、快取命中帶來的 TTFT 下降是百毫秒到秒級。孰大孰小,用上面的方法各測一輪就有答案,不需要相信任何一方的說法。
怎麼排除測試噪聲?
溫度 0、固定提示、N≥30、剔除首次冷啟動、隔時段複測;對比測試必須同時段進行,跨時段對比會把上游的時段性波動誤判成通道差異。