Community程式設計與開發github.com

推論工程

制定生成式 AI 模型的架構、效能與生產決策。適用於選擇模型或硬體、診斷延遲或吞吐量、最佳化 LLM 或多模態推論、基準測試、擴充 GPU 服務,或估算服務成本。

推論工程 是什麼?

此技能旨在協助開發者與 AI 代理將 AI 產品的品質、延遲、可靠性與成本要求,轉化為可衡量且可操作的推論系統。它涵蓋了從工作負載特徵化、模型選擇、硬體適配、基準測試建立到瓶頸診斷與最佳化的完整流程。支援包括 LLM、多模態模型、嵌入模型在內的各種模型部署,並強調在最佳化過程中必須同時考慮品質、延遲、吞吐量與成本之間的取捨。技能提供的參考資料與操作手冊可應用於 Claude Code、Cursor 等 AI 編碼代理平台,協助使用者做出基於資料的工程決策,並避免僅最佳化單一指標而忽略整體系統效能。

相容平台~Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add https://github.com/Ayaansiddiq07/Inference-skill/tree/HEAD

Installed? Explore more 程式設計與開發 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

推論工程 是做什麼的?

使用此技能將 AI 產品的品質、延遲、可靠性和成本要求轉化為可衡量的推論系統。這是一個獨立的操作綜合體,其內容參考了 Philip Kiely 的《推論工程》(Baseten Books, 2026),但與作者或出版商無關,也未獲得其背書。供應商功能、模型發行版、硬體可用性和軟體行為變化迅速;在做出實作決策前,請務必查閱官方文件以確認最新細節。

從工作負載開始

在選擇引擎或最佳化之前,請先確定:

  • 產品合約: 所需的輸出品質、模態、上下文/輸入大小、回應形狀、串流需求和故障行為。
  • 流量特徵: 請求率、並行度、突發性、到達模式、輸入/輸出長度分佈以及可快取的前綴頻率。
  • 服務目標: 端到端 P50/P95/P99 延遲、第一個 Token 時間 (TTFT)、Token 間延遲 (ITL)、吞吐量、可用性和復原目標。
  • 限制條件: 預算、區域、資料主權、隱私、授權、硬體存取和營運能力。
  • 基準線: 具代表性的品質評估,以及在真實負載下的端到端效能與成本。

不要孤立地最佳化代理指標。定義工作單位,並在適用的情況下納入客戶端、佇列、網路、前處理、模型和後處理時間。對於代理流程,請測量整個任務,包括工具呼叫和重試。

操作工作流程

  1. 特徵化工作負載。 將即時線上流量與離線/批次工作分開;識別延遲敏感型和吞吐量導向的路徑。記錄真實的輸入/輸出分佈和並行度。
  2. 選擇候選模型。 根據特定任務的品質、模態、上下文、服務限制、授權和營運契合度進行篩選。僅使用公開基準來縮小候選範圍;根據具代表性的產品資料和失敗案例進行評估。
  3. 設定預算。 將端到端目標轉化為佇列、網路、前處理、預填充、解碼和後處理的預算。為突發狀況和降級情況預留餘量。
  4. 將模型適配到硬體。 估算權重記憶體、運行時/激活開銷、KV 快取需求以及可用的餘量。檢查測量到的記憶體頻寬、運算能力、互連和拓撲;名義上的加速器規格並非工作負載基準。
  5. 建立可重現的基準線。 固定模型修訂版、引擎/版本、硬體、精度、配置、提示組合、輸出限制和負載特徵。進行預熱、運行足夠的樣本,並在相同時間報告百分位數和吞吐量。
  6. 定位瓶頸。 首先使用端到端測量,然後進行系統和核心分析。區分佇列、預填充、解碼、記憶體容量/頻寬、運算、通訊和主機開銷。
  7. 一次只改變一個變數。 應用能夠解決所測量瓶頸的最簡單最佳化方法。同時重新檢查品質、尾端延遲、吞吐量、記憶體和成本。
  8. 驗證生產行為。 測試超載、冷啟動、擴展事件、故障、部署、取消、串流和復原。對服務目標中使用的相同指標進行檢測。

指標與診斷

  • TTFT: 從明確起始事件(例如,客戶端發送或伺服器接受)到生成第一個 Token 的時間。在比較不同運行時,請保持該邊界的一致性;它對佇列、提示長度、預填充和啟動效果很敏感。
  • ITL: 生成的 Token 之間的時間;反映了解碼的回應能力。報告每個請求的分佈,而不僅僅是總 Token 速率。
  • 端到端延遲: 客戶端觀察到的完成時間;包括網路和應用程式工作。
  • 吞吐量: 在指定的工作負載和延遲/品質範圍內,單位時間內完成的請求或 Token 數量。明確指出 Token/秒是針對單一使用者還是整個系統。
  • 百分位數: 報告 P50 以及 P95/P99 等尾端目標;平均值可能會隱藏慢請求。
  • 有效吞吐量 (Goodput): 在滿足相關延遲和品質目標的情況下完成的工作。使用此指標來比較那些在速度與品質或尾端行為之間取捨的配置。

將症狀解讀為假設,然後使用追蹤/分析進行驗證:

症狀可能需要測量的區域
TTFT 高,ITL 正常佇列等待、長提示、預填充運算、冷啟動、前處理
TTFT 正常,ITL 差解碼頻寬、批次爭用、KV 快取壓力、核心效率
兩者皆隨並行度增加而惡化佇列、記憶體容量、批次策略、准入控制、飽和
GPU 使用率低,延遲高CPU/Token 化、資料傳輸、同步、網路、排程
吞吐量上升但尾端延遲違反服務等級目標 (SLO)批次/並行策略、佇列限制、工作負載隔離

這些是診斷線索,並非結論。在更改配置之前,請先確認活躍的瓶頸。

模型與硬體決策

  • 優先選擇能通過產品品質評估並具有可接受餘量的最小/成本最低的模型。僅在評估發現特定差距且生命週期成本合理時,才考慮提示工程、檢索、微調或蒸餾。
  • 當線上與離線部署的延遲、批次或可用性目標衝突,且測量到的流量證明營運開銷合理時,將它們分開。
  • 將模型和運行時狀態放入加速器記憶體中,並為 KV 快取、激活、碎片化和並行度預留明確的餘量。僅考慮權重適配是不夠的。
  • 對於自迴歸 LLM,預填充和解碼對硬體的壓力不同:預填充通常運算密集;解碼通常會變成記憶體頻寬受限。請針對實際的序列和批次組合測量兩者。
  • 多 GPU 的選擇需要在記憶體/延遲/吞吐量與通訊/複雜性之間進行取捨。張量平行可以減少拆分模型的每個請求延遲;專家平行可以在大規模情況下服務稀疏專家。請驗證互連和同步成本。多節點執行需要特別仔細的通訊測量。
  • 對於影像、影片、音訊、嵌入和視覺語言工作負載,請使用特定於模態的管道和指標。包括前處理、分塊、編碼器/解碼器和後處理成本;不要盲目套用 LLM Token 指標。
  • 在部署前檢查模型和資料集授權以及相關的安全、隱私和法規要求。

關於這些選擇背後的理由,請參閱模型和硬體基礎知識。關於框架、格式和服務引擎的相容性,請參閱軟體堆疊選擇。這些參考資料提供決策方法,而非永恆的排名:請驗證對確切模型、加速器、運行時版本和功能集的支援。

最佳化手冊

僅在建立基準線並識別出相容的瓶頸後才套用:

批次與排程

批次處理可以提高加速器利用率並分攤開銷,但同時會增加佇列和每個請求的延遲。根據實際到達情況調整並行度、批次限制、等待窗口和准入控制。當互動式流量的目標發生衝突時,保護其免受批次工作的影響。

量化

將量化視為一個品質/效能光譜,而不是一個二進位設定。根據測量到的記憶體、頻寬、運算和品質限制,選擇要更改的元件和精度。在每次更改後評估代表性的任務品質、邊緣案例和回歸集;在引擎允許的情況下,分別觀察權重、激活、注意力機制和 KV 快取的影響。如果未能達到產品品質底線或可靠性目標,請復原變更。

推測解碼

僅當草稿/提案機制的提案成本和接受行為能為目標工作負載帶來淨收益時才使用。測量接受率、記憶體開銷、批次大小影響、每個使用者的 ITL、總吞吐量和成本。在高並行度或接受率低的情況下,效益可能會縮小甚至逆轉。

KV 與前綴快取

當前綴重複出現且正確性/隔離要求允許時,重複使用快取狀態。測量命中率、節省的預填充工作、儲存/記憶體成本、驅逐行為和路由局部性。定義快取金鑰和租戶/安全邊界,以防止一個請求重用另一個租戶的私有上下文。長上下文和高並行度會增加 KV 壓力;請考量放置和傳輸成本。

平行與分離

當模型適配、延遲或吞吐量測量證明通訊開銷合理時,引入平行化。僅當工作負載足夠大且穩定,能夠從獨立資源分配中獲益,且系統能夠管理 KV 傳輸/路由時,才將預填充和解碼分離。在比較時,請納入網路頻寬、傳輸延遲、故障模式和營運複雜性。

核心與執行時最佳化

在編寫或選擇專用核心之前先進行分析。核心融合可以減少記憶體流量和啟動開銷,但相容性和數值行為很重要。使用相同的模型修訂版、硬體、提示組合、輸出長度、負載和品質檢查來比較框架/執行時/引擎候選方案。

有關量化方法、推測解碼家族、快取放置、長上下文服務和分散式執行的詳細比較,請閱讀最佳化手冊。

基準測試與分析

  • 使用生產追蹤或保留請求大小、到達模式和快取特性的隱私安全工作負載。合成測試對於受控實驗很有用,但請說明其限制。
  • 分別記錄冷啟動和熱啟動行為。包括預熱、足夠的持續時間/樣本數、重複運行、變異數以及硬體/軟體版本。
  • 掃描負載以找出飽和點以及在服務等級目標 (SLO) 下的最大有效吞吐量。避免比較輕載運行和超載運行。
  • 一次更改一個因素以進行歸因;調整後,執行組合的端到端測試,因為最佳化措施可能會相互作用。
  • 將系統基準測試與任務品質評估配對。效能提升如果導致輸出品質低於產品門檻,則不算勝利。
  • 基準測試顯示什麼慢;分析則有助於解釋為什麼慢。使用侵入性最小的分析器來隔離活躍的瓶頸,並使用新的基準測試驗證建議的修復方案。

生產就緒

  • 容量與自動擴展: 根據領先指標(佇列深度、使用率、記憶體/KV 壓力、到達率)以及完成的工作進行擴展。考慮供應和模型載入時間;當冷啟動違反目標時,保持足夠的容量或優雅降級。
  • 佇列與超載: 限制佇列和請求大小、設定逾時/取消、使用准入控制,並定義明確的超載回應。無限制的佇列會將飽和轉化為尾端延遲故障。
  • 可靠性: 測試健康檢查、帶有限制的重試、必要的冪等性、實例遺失、區域/供應商故障、推出、回滾和容量耗盡。重試可能會加劇超載。
  • 部署: 鎖定模型工件和依賴項、驗證啟動/就緒、金絲雀發布變更、比較品質和服務指標,並保留經過測試的回滾路徑。避免在映像檔、日誌或基準測試工件中暴露機密。
  • 可觀測性: 將請求追蹤與模型、引擎、硬體和配置版本相關聯。追蹤 TTFT、ITL、端到端百分位數、佇列時間、吞吐量/有效吞吐量、錯誤、快取命中率、使用率、記憶體、冷啟動和成本。
  • 成本: 比較在所需品質和服務等級目標 (SLO) 下每個成功請求或有用輸出的成本,包括閒置容量、複寫、網路、儲存和工程/營運負擔。縮減至零可以減少閒置支出,但會增加冷啟動延遲。
  • 安全性與合規性: 控制模型和資料存取、隔離租戶、保護日誌中的提示和輸出、定義保留策略、驗證依賴項和工件,並滿足適用的資料主權和法規要求。

有關容器可重現性、容量和路由、多區域操作、客戶端協定和推出實踐,請閱讀生產操作。有關按模態進行的測量,請閱讀特定模態的推論考量。

參考資料索引

任務閱讀
建立工作負載卡、建立基準線或定位瓶頸本文件,然後是最佳化手冊
了解模型執行、加速器適配或硬體取捨模型和硬體基礎知識
選擇框架、模型格式、核心路徑或服務引擎軟體堆疊選擇
調整量化、推測、快取、平行或分離最佳化手冊
服務視覺、嵌入、音訊、影像或影片工作負載特定模態的考量
規劃自動擴展、部署、可靠性、API/用戶端行為和成本生產操作

推論任務的回應格式

在提供建議或實作時,請提供:

  1. 工作負載假設和缺少的測量。
  2. 目標和基準指標。
  3. 主要的瓶頸假設以及如何證明。
  4. 帶有預期取捨的排序實驗計畫。
  5. 品質、尾端延遲、可靠性、安全性和成本的驗收標準。
  6. 當前的供應商/模型/運行時事實,並在影響建議時提供官方來源的連結。

相關技能