某團(tuán)隊(duì)的GPU推理賬單一個(gè)月內(nèi)暴漲了40%，溯源后發(fā)現(xiàn)大部分算力消耗并非來(lái)自真實(shí)業(yè)務(wù)請(qǐng)求，而是微服務(wù)鏈路失控的重試風(fēng)暴。當(dāng)模型落地進(jìn)入深水區(qū)，推理成本上漲的成因往往藏在資源調(diào)度、重試策略和可觀測(cè)性的夾縫里。這是一份從GPU閑置識(shí)別到彈性伸縮調(diào)優(yōu)的排查優(yōu)化指南。

一、AI推理成本上漲現(xiàn)象與成因概覽

1. 成本上漲的典型表現(xiàn)

賬單飆升只是最終結(jié)果，中間往往伴隨“高顯存占用、低計(jì)算利用率”的虛假繁榮。DCGM 指標(biāo)顯示 GPU 計(jì)算核心活躍度不足 20%，顯存卻已占滿(mǎn)，大量算力空轉(zhuǎn)。另一個(gè)信號(hào)是請(qǐng)求成功率穩(wěn)定，但后端調(diào)用量呈數(shù)倍放大——一次流量擁塞引發(fā)網(wǎng)關(guān)及業(yè)務(wù)代碼多層重試，下游推理集群承受的壓力可達(dá)原始請(qǐng)求的 3-5 倍，賬單與業(yè)務(wù)量不成比例。

2. 推高成本的核心影響因素

自動(dòng)重試缺乏全局預(yù)算控制是成本倍增的放大器。Kubernetes 原生 HPA 基于 CPU/內(nèi)存觸發(fā)，對(duì) GPU 推理的顯存帶寬瓶頸與計(jì)算核心利用率“視而不見(jiàn)”，導(dǎo)致非必要擴(kuò)容或節(jié)點(diǎn)過(guò)載。多模型共享集群時(shí)，若無(wú)請(qǐng)求級(jí)成本標(biāo)記，根本無(wú)法定位是哪條業(yè)務(wù)線(xiàn)、哪個(gè)模型版本的無(wú)效調(diào)用消耗了高端 GPU 算力，浪費(fèi)持續(xù)堆積。

3. 如何評(píng)估推理成本

不能停留在“每 Token 成本”的粗略估算。必須把 GPU 細(xì)粒度利用率（如 DCGM_FI_PROF_GR_ENGINE_ACTIVE）與請(qǐng)求鏈路掛鉤，區(qū)分有效計(jì)算與數(shù)據(jù)搬運(yùn)、KV Cache 讀寫(xiě)的耗時(shí)占比。建立按業(yè)務(wù)標(biāo)簽聚合的算力消耗視圖，結(jié)合請(qǐng)求量、失敗率與重試放大因子，才能將成本拆解到具體的優(yōu)化動(dòng)作，而非僅做平均水平的估算。

二、GPU閑置：被忽視的成本漏洞

當(dāng)團(tuán)隊(duì)盯住推理延遲和請(qǐng)求成功率時(shí)，GPU 閑置往往是財(cái)務(wù)報(bào)表上最先出現(xiàn)、卻最晚被診斷的成本漏洞。推理的總擁有成本（TCO）早已超過(guò)單次模型訓(xùn)練，而在典型的大模型推理集群中，即使顯存占用率持續(xù)高于 85%，計(jì)算核心的實(shí)際活躍度可能不到 20%。換句話(huà)說(shuō)，企業(yè)很可能正在為大量“預(yù)熱但空轉(zhuǎn)”的硅買(mǎi)單。

1. 什么是GPU閑置

GPU 閑置指的是 GPU 被分配并加載模型后，沒(méi)有執(zhí)行有效矩陣運(yùn)算的狀態(tài)。此時(shí)顯存被 frame buffer 和模型權(quán)重占據(jù)，但 SMs（流式多處理器）或 tensor core 處于空閑。常見(jiàn)誘因有三種：等待數(shù)據(jù)搬運(yùn)（I/O bound）、請(qǐng)求間歇性波動(dòng)導(dǎo)致實(shí)例空等、離線(xiàn)批處理與在線(xiàn)服務(wù)混合部署引發(fā)的顯存帶寬爭(zhēng)搶?zhuān)罱K表現(xiàn)為計(jì)算硬件“占而不用”。

更隱蔽的閑置源于重試放大效應(yīng)。在微服務(wù)推理鏈路中，單次調(diào)用失敗可能觸發(fā)網(wǎng)關(guān)、SDK、業(yè)務(wù)邏輯層的多級(jí)自動(dòng)重試。缺乏統(tǒng)一重試預(yù)算時(shí)，一次后臺(tái)偶發(fā)卡頓就會(huì)將總請(qǐng)求量放大 3~5 倍，大量 GPU 周期用來(lái)重復(fù)計(jì)算完全相同的 prompt，這些算力并沒(méi)有產(chǎn)生任何增量業(yè)務(wù)價(jià)值，卻直接推高賬單。

誤區(qū)提醒：顯存占用率高并不等價(jià)于 GPU 利用率高。監(jiān)測(cè)表明，不少推理服務(wù)雖顯存占用高于 90%，但 DCGM_FI_PROF_GR_ENGINE_ACTIVE 活躍度長(zhǎng)年低于 15%。把顯存當(dāng)利用率的代理指標(biāo)，會(huì)系統(tǒng)性地掩蓋巨大的資源閑置。

2. 如何監(jiān)測(cè)GPU利用率

擺脫顯存迷惑的唯一方法是建立細(xì)粒度的 GPU 利用率監(jiān)控，重點(diǎn)放在計(jì)算核心活躍度與請(qǐng)求排隊(duì)深度上。具體可分三步操作：

第一步，采集真實(shí)負(fù)載指標(biāo)。 在節(jié)點(diǎn)上部署 NVIDIA DCGM 導(dǎo)出器，向 Prometheus 暴露 DCGM_FI_PROF_GR_ENGINE_ACTIVE（圖形引擎活躍度，反映計(jì)算核心使用比例）。與顯存指標(biāo)不同，該數(shù)值直接關(guān)聯(lián)矩陣運(yùn)算時(shí)間。一條典型的 PromQL 查詢(xún)?nèi)缦拢?/p>

avg(rate(DCGM_FI_PROF_GR_ENGINE_ACTIVE{job="gpu-metrics"}[5m])) by (instance)

當(dāng)該指標(biāo)平均值持續(xù)低于 30% 而顯存占用居高不下，即可判定存在嚴(yán)重閑置。

第二步，關(guān)聯(lián)請(qǐng)求側(cè)信號(hào)。 將推理引擎的請(qǐng)求排隊(duì)深度、實(shí)時(shí) QPS 和失敗重試率導(dǎo)入同一監(jiān)控面板。重試導(dǎo)致的“計(jì)算放大系數(shù)”（實(shí)際完成一次成功推理所消耗的 GPU 毫秒數(shù)）是觀測(cè)閑置成本的核心；若該系數(shù)持續(xù)高于 1.5，說(shuō)明大量算力消耗在無(wú)效重試上，需要通過(guò)韌性策略止損。

第三步，避免 HPA 誤判。 原生 Kubernetes HPA 僅基于 CPU/內(nèi)存指標(biāo)，GPU 推理瓶頸常落在顯存帶寬或計(jì)算核心上，直接套用會(huì)產(chǎn)生“節(jié)點(diǎn) CPU 寬松而 GPU 已飽和，HPA 不擴(kuò)容”或“CPU 瞬時(shí)升高觸發(fā)不必要擴(kuò)容”的錯(cuò)配。為此應(yīng)將彈性觸發(fā)指標(biāo)替換為 GPU 計(jì)算活躍度或請(qǐng)求隊(duì)列深度，例如通過(guò) KEDA 直接訂閱 DCGM 數(shù)據(jù)流，確保擴(kuò)縮容與物理瓶頸對(duì)齊。

配置變化后的效果：一家中型 SaaS 在對(duì)推理集群實(shí)施上述監(jiān)控后，發(fā)現(xiàn) 40% 的 A100 實(shí)例在非高峰段活躍度不足 10%，通過(guò)調(diào)整實(shí)例分配策略，首月就削減了約 1/3 的 GPU 小時(shí)計(jì)費(fèi)。

3. 閑置實(shí)例的優(yōu)化策略

監(jiān)測(cè)到閑置只是起點(diǎn)，消滅無(wú)效預(yù)留需要從彈性策略、重試治理和任務(wù)隔離三個(gè)層面協(xié)同。

彈性伸縮精準(zhǔn)化。 基于 GPU 計(jì)算活躍度設(shè)置 KEDA ScaledObject，設(shè)定“快速擴(kuò)容、謹(jǐn)慎縮容”的節(jié)奏——擴(kuò)容觸發(fā)閾值設(shè)定在 70% 活躍度，縮容則輔以至少 300 秒的穩(wěn)定窗口，避免流量微抖引發(fā)頻繁開(kāi)關(guān)實(shí)例。同時(shí)維護(hù)一個(gè)小規(guī)模的預(yù)熱實(shí)例池，消除冷啟動(dòng)導(dǎo)致的流量排隊(duì)，從源頭上減少因超時(shí)而觸發(fā)客戶(hù)端重試的概率。縮容時(shí)先標(biāo)記實(shí)例為不可調(diào)度，等待已有請(qǐng)求處理完畢再銷(xiāo)毀，防止強(qiáng)制中斷引發(fā)重試風(fēng)暴。

實(shí)施全局重試預(yù)算。 在 API 網(wǎng)關(guān)或 sidecar 層為每個(gè)入口請(qǐng)求注入重試配額（例如最多 3 次重試），所有下游調(diào)用共享該配額，配額耗盡即快速失敗并返回明確錯(cuò)誤碼。這種做法將重試放大系數(shù)鎖死在可控范圍內(nèi)，保證故障期間的 GPU 消耗不失控。與簡(jiǎn)單限制單跳重試次數(shù)相比，重試預(yù)算能杜絕指數(shù)級(jí)連帶放大的常見(jiàn)陷阱。

資源隔離與混合部署規(guī)范。 嚴(yán)格分離在線(xiàn)推理實(shí)例（低延遲）和離線(xiàn)批處理作業(yè)（高吞吐）。若必須在同一 GPU 節(jié)點(diǎn)混部，應(yīng)使用 MIG（多實(shí)例 GPU）或時(shí)間片調(diào)度進(jìn)行硬隔離，避免批處理突然搶占顯存帶寬，導(dǎo)致在線(xiàn)服務(wù)重試率飆升。觀察顯示，未隔離混部的集群在批處理高峰期在線(xiàn)推理的 P99 延遲可能惡化 3 倍，連帶大量無(wú)效重試，閑置和浪費(fèi)雙雙走高。

最后，將 GPU 資源消耗按請(qǐng)求頭中的業(yè)務(wù)標(biāo)簽追蹤到具體模型版本和調(diào)用鏈，建立成本歸屬賬單。當(dāng)某一模型版本的單位推理成本異常升高，就能快速定位是否存在 KV Cache 管理低效、冗余模型駐留等結(jié)構(gòu)性浪費(fèi)。閑置優(yōu)化不是一次性的資源下調(diào)，而是持續(xù)數(shù)據(jù)驅(qū)動(dòng)的運(yùn)營(yíng)閉環(huán)。

三、請(qǐng)求重試：隱藏的成本翻倍因子

在一次流量擁塞中，推理服務(wù)返回的并不是錯(cuò)誤，而是“慢”。調(diào)用方等不及，主動(dòng)斷開(kāi)，按照既定策略發(fā)起重試。這在分布式系統(tǒng)中幾乎是一種條件反射——但每一條被重試的請(qǐng)求，都意味著下游GPU需要把完全相同的計(jì)算再跑一遍。更隱蔽的是，原始請(qǐng)求其實(shí)還在GPU上排隊(duì)或執(zhí)行中，直到它超時(shí)返回時(shí)，結(jié)果已經(jīng)被調(diào)用方丟棄。一個(gè)請(qǐng)求，兩次計(jì)算，一次也沒(méi)用上。

行業(yè)數(shù)據(jù)顯示，未經(jīng)精細(xì)調(diào)優(yōu)的微服務(wù)鏈路中，因一次底層服務(wù)抖動(dòng)引發(fā)的多級(jí)重試，能將請(qǐng)求總量放大3到5倍。這意味著GPU集群有60%到80%的算力被消耗在處理注定被丟棄的重試請(qǐng)求上。推理服務(wù)不同于傳統(tǒng)Web服務(wù)，單次調(diào)用本身就是高消耗操作——顯存讀寫(xiě)、KV Cache存取、Token逐個(gè)生成——這些算力不會(huì)因?yàn)榻Y(jié)果被丟棄而返還。

1. 重試機(jī)制的“雪崩放大器”效應(yīng)

多數(shù)團(tuán)隊(duì)對(duì)重試策略的認(rèn)知停留在“配置最大重試次數(shù)就夠了”。但問(wèn)題恰恰出在這里。

一個(gè)典型的AI推理調(diào)用鏈路是這樣的：API網(wǎng)關(guān)→業(yè)務(wù)編排服務(wù)→模型路由層→推理引擎。每一層都獨(dú)立配置了重試機(jī)制，通常是3次，采用指數(shù)退避。表面看每層都有防護(hù)，但當(dāng)推理引擎出現(xiàn)200ms的響應(yīng)延遲時(shí)，路由層等待超時(shí)，觸發(fā)3次重試；這3次重試加上原始的1次調(diào)用，在業(yè)務(wù)編排層看來(lái)是4次獨(dú)立請(qǐng)求，其中可能有2次觸發(fā)該層的重試邏輯；繼續(xù)向上傳導(dǎo)，網(wǎng)關(guān)層最終向推理集群發(fā)起的可能已經(jīng)是十幾倍于原始請(qǐng)求量的調(diào)用。

這不是理論推演。某SaaS企業(yè)在2024年大促期間，推理服務(wù)賬單較日常暴漲近7倍，事后排查發(fā)現(xiàn)，一個(gè)弱依賴(lài)的權(quán)限校驗(yàn)服務(wù)響應(yīng)變慢，觸發(fā)了調(diào)用鏈路上五層服務(wù)的重試機(jī)制。GPU集群的實(shí)際有效計(jì)算中，超過(guò)82%消耗在重復(fù)請(qǐng)求上。真正到達(dá)用戶(hù)的成功響應(yīng)所消耗的算力占比不到20%。

排查這類(lèi)問(wèn)題，不能只看各層的獨(dú)立監(jiān)控。需要沿調(diào)用鏈路向下追溯：在網(wǎng)關(guān)層統(tǒng)計(jì)請(qǐng)求總數(shù)，在推理引擎?zhèn)冉y(tǒng)計(jì)實(shí)際接收的請(qǐng)求數(shù)，兩相比較。如果比值超過(guò)2:1，說(shuō)明重試放大效應(yīng)已經(jīng)存在；超過(guò)5:1，意味著鏈路中存在“重試風(fēng)暴”，每一次底層抖動(dòng)都在被逐層放大。

2. 從“重試次數(shù)”到“重試預(yù)算”的策略升級(jí)

問(wèn)題的根源在于：重試配額是逐層獨(dú)立分配的，而非整個(gè)調(diào)用鏈路共享。

每層3次重試，五層就是15次潛在重試機(jī)會(huì)，而每層只能控制自己“觸發(fā)”的那部分，無(wú)法感知下游已經(jīng)在處理重復(fù)請(qǐng)求。這像是給每個(gè)搬運(yùn)工都發(fā)了一把倉(cāng)庫(kù)鑰匙，但沒(méi)人統(tǒng)計(jì)今天同一個(gè)箱子被搬了幾次。

解決思路是將重試配額從“逐層分配”改為“請(qǐng)求級(jí)別的一次性預(yù)算”。具體做法是：在請(qǐng)求進(jìn)入系統(tǒng)時(shí)，在Header中注入重試預(yù)算（如X-Retry-Budget: 3），鏈路上的每一層在決定是否重試前，先扣減該預(yù)算，耗盡則直接快速失敗返回。這個(gè)機(jī)制需要網(wǎng)關(guān)或服務(wù)網(wǎng)格層統(tǒng)一實(shí)施。

一個(gè)落地配置示例如下（基于Envoy的retry budget策略思路）：

retry_policy:
  retry_budget:
    budget_percent:
      numerator: 20
      denominator: 100
    min_retry_per_second: 10
  retry_on: "5xx,reset,connect-failure"
  num_retries: 3

這里的關(guān)鍵參數(shù)是budget_percent——它限制了重試請(qǐng)求在總請(qǐng)求中的占比上限。即使下游服務(wù)仍在返回錯(cuò)誤，只要重試占比超過(guò)20%，系統(tǒng)就會(huì)主動(dòng)拒絕額外重試，防止算力被重復(fù)計(jì)算耗盡。配合請(qǐng)求Header中的X-Retry-Budget逐跳遞減，整條鏈路的總體重試量被控制在一個(gè)可控范圍內(nèi)，而不是各層獨(dú)立決策導(dǎo)致的指數(shù)級(jí)放大。

值得注意的是，單單把重試次數(shù)從3改成2并不能解決結(jié)構(gòu)性問(wèn)題。雪崩的根源在于“每層都有完整的重試權(quán)限”，而非某一層“多試了一次”。在推理服務(wù)這類(lèi)單次調(diào)用成本極高的場(chǎng)景中，快速失敗遠(yuǎn)比反復(fù)重試更具經(jīng)濟(jì)理性。一個(gè)被快速拒絕的請(qǐng)求，調(diào)用方可以立即感知并切換到降級(jí)策略；一個(gè)被反復(fù)重試直到超時(shí)的請(qǐng)求，既消耗了GPU算力，也拖延了用戶(hù)體驗(yàn)。

3. 排查鏈路中的隱性重試源

有些重試并非來(lái)自你顯式配置的策略。

Kubernetes的kube-proxy在轉(zhuǎn)發(fā)失敗時(shí)可能自動(dòng)重試；某些服務(wù)網(wǎng)格的Sidecar在連接池耗盡時(shí)也會(huì)發(fā)起隱式重試；甚至部分推理引擎客戶(hù)端SDK，為了“提升成功率”，在未經(jīng)聲明的情況下內(nèi)置了重試邏輯。這些隱性重試疊加到業(yè)務(wù)層顯式配置的重試策略上，讓實(shí)際重試量遠(yuǎn)超預(yù)期。

排查方法分三步走：第一，在推理引擎?zhèn)冉y(tǒng)計(jì)同一request_id的出現(xiàn)次數(shù)，超過(guò)1即存在重試；第二，對(duì)比網(wǎng)關(guān)與推理引擎之間的請(qǐng)求量差值，差值越大說(shuō)明中間鏈路的隱式重試越嚴(yán)重；第三，逐一檢查鏈路中每個(gè)組件的默認(rèn)配置——Istio/Envoy的retryOn條件、Kubernetes Service的sessionAffinity設(shè)置、以及模型服務(wù)框架的內(nèi)部超時(shí)與重試參數(shù)。

一個(gè)曾被反復(fù)踩中的坑是：推理引擎配置了300秒的超時(shí)，但上游服務(wù)網(wǎng)格的默認(rèn)超時(shí)只有30秒。結(jié)果是推理引擎還在認(rèn)真計(jì)算，上游已經(jīng)判定超時(shí)并發(fā)起重試，而第二次請(qǐng)求到達(dá)時(shí)，原始請(qǐng)求仍在占用GPU顯存，計(jì)算資源被兩份請(qǐng)求同時(shí)消耗。正確的做法是全鏈路統(tǒng)一超時(shí)設(shè)定，確保下游超時(shí)大于上游，或在網(wǎng)關(guān)上配置“請(qǐng)求去重”——如果已經(jīng)有一個(gè)相同的推理請(qǐng)求在處理中，后續(xù)重試請(qǐng)求直接掛起等待原結(jié)果，而非重新進(jìn)入計(jì)算隊(duì)列。

四、彈性伸縮：成本與性能的平衡術(shù)

1. 彈性伸縮的基本原理

彈性伸縮的核心邏輯并不復(fù)雜：依據(jù)實(shí)時(shí)負(fù)載指標(biāo)，自動(dòng)增減推理實(shí)例的數(shù)量，讓集群在低延遲與低成本之間找到一個(gè)動(dòng)態(tài)平衡點(diǎn)。當(dāng)請(qǐng)求量飆升時(shí)，系統(tǒng)迅速拉出新的 GPU 實(shí)例分擔(dān)壓力；當(dāng)流量回落到低谷，則逐步回收閑置資源，避免高端計(jì)算卡空轉(zhuǎn)燒錢(qián)。這個(gè)機(jī)制聽(tīng)起來(lái)像是一劑萬(wàn)靈藥，但在真實(shí)的生產(chǎn)環(huán)境中，伸縮策略一旦配置失當(dāng)，反而會(huì)成為成本黑洞的放大器。

問(wèn)題出在“依據(jù)什么來(lái)判斷該擴(kuò)還是該縮”。大多數(shù)團(tuán)隊(duì)習(xí)慣沿用 Kubernetes 原生的 Horizontal Pod Autoscaler（HPA），直接綁定 CPU 或內(nèi)存利用率。但在 GPU 推理場(chǎng)景里，這兩個(gè)指標(biāo)幾乎是盲人摸象。模型一旦加載，顯存就被全量占用，靜態(tài)看起來(lái)接近 100%，而計(jì)算核心可能完全閑在那里等待數(shù)據(jù)搬運(yùn)。如果 HPA 只看 CPU 打滿(mǎn)、內(nèi)存告急就觸發(fā)擴(kuò)容，就會(huì)出現(xiàn)節(jié)點(diǎn)連 GPU 計(jì)算單元都還沒(méi)跑熱，就被動(dòng)拉起新實(shí)例的荒誕局面。更糟的是，真正的瓶頸常出現(xiàn)在顯存帶寬或編解碼單元被榨干，此時(shí) CPU 曲線(xiàn)平滑如鏡，HPA 卻毫無(wú)反應(yīng)，服務(wù)直接被流量擊穿，觸發(fā)客戶(hù)端無(wú)止境的重試——這在一套未經(jīng)精細(xì)調(diào)校的微服務(wù)鏈路里，一次擁堵引發(fā) 3～5 倍的請(qǐng)求量翻倍是很常見(jiàn)的工程事故。

因此，討論彈性伸縮的落地，必須先打破兩個(gè)幻覺(jué)：一是“顯存占用高 = GPU 利用率高”，二是“自動(dòng)伸縮可以閉眼配置”。只有把監(jiān)控粒度下沉到計(jì)算單元活躍度、隊(duì)列深度這些指標(biāo)，伸縮才能真正為成本兜底，而不是給賬單火上澆油。

2. 伸縮策略配置要點(diǎn)：從“看 CPU”切換到“看 GPU 心跳”

要實(shí)現(xiàn) GPU 感知的彈性伸縮，操作層面需要把觀測(cè)管線(xiàn)整個(gè)換掉，大致可以分為三步。

第一步，建立 GPU 細(xì)粒度指標(biāo)采集通道。
在驅(qū)動(dòng)層面，NVIDIA 的 DCGM（Data Center GPU Manager）已經(jīng)暴露了一組遠(yuǎn)比顯存占用更有價(jià)值的指標(biāo)。關(guān)鍵字段如 DCGM_FI_PROF_GR_ENGINE_ACTIVE，代表圖形/計(jì)算引擎活躍時(shí)間占比，能真實(shí)反映計(jì)算核心是在跑矩陣運(yùn)算，還是在空轉(zhuǎn)等待。還有 DCGM_FI_PROF_PCIE_TX_BYTES、DCGM_FI_PROF_DRAM_ACTIVE 等，分別對(duì)應(yīng)數(shù)據(jù)傳輸壓力和顯存帶寬使用率。將這些指標(biāo)推送到 Prometheus，并配合 Node Exporter 或 DCGM Exporter，就能在 Grafana 上繪制推理集群的“真實(shí)心電圖表”。

第二步，利用 KEDA 等事件驅(qū)動(dòng)伸縮器訂閱自定義指標(biāo)。
HPA 的局限在于只認(rèn)得 CPU 和內(nèi)存，而 KEDA（Kubernetes Event-driven Autoscaling）允許將任何 Prometheus 查詢(xún)結(jié)果作為伸縮判據(jù)。具體配置并不復(fù)雜，只要定義一個(gè) ScaledObject，在觸發(fā)器里寫(xiě)一段 PromQL 查詢(xún)即可。例如，設(shè)定當(dāng)過(guò)去 1 分鐘內(nèi) GPU 計(jì)算引擎活躍度中位數(shù)超過(guò) 85% 時(shí)觸發(fā)擴(kuò)容，低于 50% 時(shí)開(kāi)始縮容。關(guān)鍵配置片段大致如下：

triggers:
- type: prometheus
  metadata:
    serverAddress: http://prometheus-service.monitoring.svc:9090
    metricName: gpu_engine_active_median
    query: |
      avg_over_time(DCGM_FI_PROF_GR_ENGINE_ACTIVE{pod=~"inference-.*"}[1m])
    threshold: '85'
    activationThreshold: '90'

這段配置把決策權(quán)交給 GPU 自身的工作節(jié)奏，徹底擺脫 CPU 假象。同時(shí)設(shè)定 activationThreshold 高于 threshold，防止指標(biāo)在閾值線(xiàn)附近抖動(dòng)時(shí)造成擴(kuò)容/縮容反復(fù)震蕩。

第三步，設(shè)置“快擴(kuò)慢縮”的穩(wěn)定窗口。
GPU 實(shí)例的啟動(dòng)不像無(wú)狀態(tài) Pod 那么輕盈，模型加載和顯存預(yù)熱往往需要數(shù)分鐘。因此縮容策略必須極度保守：可以將縮容穩(wěn)定窗口拉長(zhǎng)到 10～15 分鐘，確保流量確實(shí)進(jìn)入穩(wěn)態(tài)低谷后再回收資源；擴(kuò)容則在 30 秒左右即可觸發(fā)，但要防止對(duì)突發(fā)毛刺的過(guò)度反應(yīng)——可疊加一個(gè)短時(shí)聚合窗口，取 1～2 分鐘的平均活躍度而非瞬時(shí)尖峰。

完成這三步之后，效果立竿見(jiàn)影：非高峰時(shí)段的 GPU 計(jì)算核心不再“空燒”，縮容及時(shí)性明顯提高；高峰時(shí)擴(kuò)容命中率上升，由 GPU 過(guò)載引發(fā)的請(qǐng)求超時(shí)比例通常會(huì)下降一半以上。最關(guān)鍵的是，顯存占用與計(jì)算活躍度終于脫鉤，團(tuán)隊(duì)第一次能看清哪些實(shí)例在“裝忙”，哪些真正在產(chǎn)出。

3. 避免伸縮延遲帶來(lái)的損失：預(yù)熱池與優(yōu)雅下線(xiàn)

伸縮策略配置再精確，也繞不開(kāi)冷啟動(dòng)這道物理屏障。一個(gè)典型的 LLM 推理實(shí)例從 Pod 啟動(dòng)到完成模型權(quán)重加載、KV Cache 分配，耗時(shí)在 2～5 分鐘都很常見(jiàn)。如果流量是脈沖式的——比如營(yíng)銷(xiāo)活動(dòng)一推送，每秒查詢(xún)率瞬間翻了 10 倍，這幾分鐘的延遲就意味著前端的海量請(qǐng)求會(huì)被直接限流或排隊(duì)超時(shí)，然后觸發(fā)客戶(hù)端的指數(shù)退避重試，進(jìn)一步燒掉后端算力。要對(duì)抗這種延遲，必須從擴(kuò)縮容的兩個(gè)端點(diǎn)上做文章。

預(yù)熱實(shí)例池（Warm Pool）是應(yīng)對(duì)突發(fā)流量的最直接手段。
在集群中常駐一小批已加載模型、只待接收請(qǐng)求的備用 Pod，數(shù)量不需要多，通常按峰值容量的 10%～20% 預(yù)留即可。一旦監(jiān)控捕捉到請(qǐng)求隊(duì)列長(zhǎng)度迅速攀升，調(diào)度器優(yōu)先將這些預(yù)熱 Pod 投入服務(wù)，幾分鐘的冷啟動(dòng)窗口被壓縮到秒級(jí)。需要注意的是，預(yù)熱 Pod 本身會(huì)產(chǎn)生持續(xù)顯存占用，因此必須定期清理并重建，以避免模型版本過(guò)舊或 KV Cache 碎片累積，這一點(diǎn)可以通過(guò) CronJob 定時(shí)觸發(fā)滾動(dòng)更新來(lái)實(shí)現(xiàn)。

優(yōu)雅縮容是防止“踩踏式重試”的最后一道防線(xiàn)。
當(dāng) HPA 或 KEDA 下達(dá)縮容指令時(shí)，如果直接 SIGTERM 殺死實(shí)例，上面正在處理的推理請(qǐng)求會(huì)全部強(qiáng)行中斷，客戶(hù)端立即收到連接斷開(kāi)或超時(shí)錯(cuò)誤，大概率觸發(fā)重試風(fēng)暴，導(dǎo)致“縮容省下的錢(qián)，全都燒在了重試上”。正確的做法是：先摘除待下線(xiàn) Pod 的 Service Endpoint，讓它不再接收新請(qǐng)求，然后等待一段 60～90 秒的“排空窗口”，讓已經(jīng)在跑的請(qǐng)求自然完成。如果窗口耗盡仍有未完成請(qǐng)求，才強(qiáng)制終止。這個(gè)邏輯可以通過(guò) preStop hook 和 terminationGracePeriodSeconds 配合實(shí)現(xiàn)：

lifecycle:
  preStop:
    exec:
      command:
      - /bin/sh
      - -c
      - "sleep 60"
terminationGracePeriodSeconds: 90

當(dāng)然光靠容器側(cè)的手段不夠，應(yīng)用層還需保證推理服務(wù)在處理期檢測(cè)到 SIGTERM 后，完成當(dāng)前請(qǐng)求并立即退出，不再拉取新的流。雙管齊下，縮容動(dòng)作對(duì)線(xiàn)上請(qǐng)求的成功率幾乎無(wú)感。

以上措施組合之后，延遲性資源浪費(fèi)和過(guò)載損失會(huì)進(jìn)入可控區(qū)間：預(yù)熱池消除冷啟動(dòng)盲區(qū)，優(yōu)雅下線(xiàn)截?cái)嘀卦嚪糯蠡芈?，再結(jié)合前文基于 GPU 活躍度的精準(zhǔn)伸縮配置，整體推理集群的彈性能力才能真正對(duì)齊成本目標(biāo)。很多團(tuán)隊(duì)在落地這一套后，非高峰時(shí)段的 GPU 占用時(shí)間平均下降 30% 以上，而峰值時(shí)段的超時(shí)率不增反降——這正是“平衡術(shù)”該有的數(shù)字。

五、逐項(xiàng)排查：從監(jiān)控到優(yōu)化的閉環(huán)實(shí)踐

GPU推理成本的治理難點(diǎn)，在于問(wèn)題往往跨多個(gè)技術(shù)層級(jí)——業(yè)務(wù)代碼的一次無(wú)心重試，可能在下游集群被放大成數(shù)倍的計(jì)算開(kāi)銷(xiāo)；顯存管理的一個(gè)參數(shù)配置偏差，可能讓半數(shù)算力空轉(zhuǎn)。單點(diǎn)優(yōu)化難以奏效，必須建立從“看見(jiàn)”到“定位”再到“驗(yàn)證”的完整閉環(huán)。以下三個(gè)步驟構(gòu)成了一套經(jīng)多家團(tuán)隊(duì)驗(yàn)證行之有效的排查路徑。

1. 構(gòu)建成本與負(fù)載監(jiān)控儀表盤(pán)

多數(shù)團(tuán)隊(duì)上線(xiàn)推理服務(wù)時(shí)只關(guān)注兩個(gè)數(shù)字：QPS和P99延遲。這兩個(gè)宏觀指標(biāo)能告訴你“服務(wù)是否健康”，但無(wú)法回答“成本花到哪里去了”。成本可觀測(cè)性的第一步，是將GPU物理資源消耗與業(yè)務(wù)請(qǐng)求量建立起實(shí)時(shí)關(guān)聯(lián)。

操作說(shuō)明：

在GPU節(jié)點(diǎn)部署DCGM（Data Center GPU Manager）并接入Prometheus生態(tài)，采集三類(lèi)核心指標(biāo)：

# 計(jì)算核心真實(shí)活躍度（這是真正的“干活”指標(biāo)）
DCGM_FI_PROF_GR_ENGINE_ACTIVE

# 顯存帶寬利用率（判斷數(shù)據(jù)搬運(yùn)是否成為瓶頸）
DCGM_FI_PROF_DRAM_ACTIVE

# 張量核利用率（針對(duì)混合精度推理的關(guān)鍵效率指標(biāo)）
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE

將上述指標(biāo)與業(yè)務(wù)層指標(biāo)（請(qǐng)求量、Token生成速率、首Token延遲）繪制在同一時(shí)間軸面板上。Grafana的典型配置是：上排顯示QPS和GPU計(jì)算利用率曲線(xiàn)，下排按model_version和business_line標(biāo)簽拆分的單請(qǐng)求成本估算。成本估算邏輯為：GPU計(jì)費(fèi)單價(jià) × (推理耗時(shí) / 總時(shí)間) × 實(shí)例數(shù)量，實(shí)時(shí)滾動(dòng)窗口計(jì)算過(guò)去5分鐘的每分鐘等效支出。

效果說(shuō)明：

這套儀表盤(pán)上線(xiàn)后，一個(gè)典型的“Aha時(shí)刻”是：某團(tuán)隊(duì)發(fā)現(xiàn)其深夜低峰時(shí)段QPS下降超過(guò)80%，但GPU計(jì)算利用率僅從72%跌到65%，等效每分鐘成本幾乎持平。排查后發(fā)現(xiàn)是離線(xiàn)評(píng)測(cè)任務(wù)在凌晨被crontab自動(dòng)觸發(fā)，且直接連到線(xiàn)上推理實(shí)例。在實(shí)施資源隔離之前，該團(tuán)隊(duì)每個(gè)月多花費(fèi)約40%的非高峰GPU費(fèi)用卻毫無(wú)感知。

2. 定位異常開(kāi)銷(xiāo)的三個(gè)切入點(diǎn)

成本異常通常表現(xiàn)為兩種模式：用量曲線(xiàn)與成本曲線(xiàn)出現(xiàn)非等比背離，或某個(gè)時(shí)段出現(xiàn)費(fèi)用尖峰但對(duì)應(yīng)當(dāng)前并無(wú)流量突增。面對(duì)這類(lèi)情況，逐層排查比盲目加規(guī)則更有效。

切入點(diǎn)一：重試放大因子的量化檢測(cè)

自動(dòng)重試是分布式系統(tǒng)的常規(guī)容錯(cuò)手段，但在多層推理鏈路中，無(wú)節(jié)制的重試會(huì)將一次上游超時(shí)演變成數(shù)次甚至數(shù)十次重復(fù)推理計(jì)算，直接造成成本翻倍。

操作步驟是先取服務(wù)網(wǎng)格或網(wǎng)關(guān)的請(qǐng)求日志，按trace_id聚合，計(jì)算“重試放大因子”——即后端推理引擎實(shí)際接收的請(qǐng)求數(shù)除以網(wǎng)關(guān)收到的原始請(qǐng)求數(shù)。正常情況下該比值應(yīng)接近1.0，超過(guò)1.5就值得警惕。查詢(xún)邏輯可參考：

SELECT 
    trace_id, 
    COUNT(*) AS backend_requests,
    COUNT(DISTINCT original_request_id) AS upstream_requests,
    COUNT(*) / COUNT(DISTINCT original_request_id) AS retry_amplification_factor
FROM inference_log
WHERE timestamp > NOW() - INTERVAL '1 hour'
GROUP BY trace_id
HAVING retry_amplification_factor > 2.0;

在未作重試預(yù)算控制的服務(wù)中，這個(gè)因子達(dá)到3-5并不少見(jiàn)。曾有電商場(chǎng)景的推理集群在一次依賴(lài)服務(wù)5秒抖動(dòng)期間，因三級(jí)調(diào)用鏈路各自獨(dú)立設(shè)置了3次重試，最終放大因子飆升至8.7，對(duì)應(yīng)時(shí)段GPU費(fèi)用達(dá)到平日的9倍。一旦量化出重試成本占比，優(yōu)化優(yōu)先級(jí)自然浮出水面。

切入點(diǎn)二：GPU真實(shí)利用率與顯存占用的背離診斷

這是最隱蔽也最普遍的浪費(fèi)形態(tài)。模型加載完成后顯存占用率穩(wěn)定在85%以上是常態(tài)，管理者很容易據(jù)此判斷“資源已充分利用”。但DCGM細(xì)粒度指標(biāo)常常揭示另一個(gè)故事：計(jì)算核心實(shí)際活躍度不足30%，其余時(shí)間消耗在顯存碎片整理、KV Cache換入換出等非計(jì)算等待中。

操作上，持續(xù)觀測(cè)DCGM_FI_PROF_GR_ENGINE_ACTIVE與顯存占用率的比值。若該比值持續(xù)低于0.5，說(shuō)明大量顯存雖有數(shù)據(jù)駐留但并未參與有效計(jì)算。此時(shí)需要檢查KV Cache的塊大小配置與請(qǐng)求長(zhǎng)度分布是否匹配——塊大小過(guò)大則短請(qǐng)求浪費(fèi)顯存、塊大小過(guò)小則長(zhǎng)請(qǐng)求頻繁換頁(yè)。vLLM等框架中調(diào)整max_model_len和block_size參數(shù)即可顯著改善這一指標(biāo)。

切入點(diǎn)三：彈性滯后成本的量化

彈性伸縮策略的評(píng)估不能只看“有沒(méi)有擴(kuò)出來(lái)”，還要看“擴(kuò)出來(lái)的時(shí)間是早于還是晚于流量峰值”。將Kubernetes HPA事件日志與業(yè)務(wù)QPS曲線(xiàn)疊加，定位擴(kuò)容觸發(fā)時(shí)間戳與QPS起漲點(diǎn)的時(shí)差。HPA默認(rèn)采集周期15秒、縮容穩(wěn)定窗口默認(rèn)5分鐘，加上模型加載時(shí)間，實(shí)際擴(kuò)容有效響應(yīng)往往滯后3-5分鐘。如果沒(méi)有預(yù)熱池，這段時(shí)間內(nèi)的請(qǐng)求要么被限流、要么排隊(duì)超時(shí)觸發(fā)重試，均轉(zhuǎn)化為隱性成本。

3. 實(shí)施優(yōu)化并驗(yàn)證效果

定位到具體瓶頸后，優(yōu)化動(dòng)作須按可控粒度分批上線(xiàn)，每次只調(diào)整一個(gè)變量，觀察儀表盤(pán)上的成本曲線(xiàn)變化。三項(xiàng)最直接的干預(yù)依次為：

首先，在網(wǎng)關(guān)層統(tǒng)一注入重試預(yù)算——例如每個(gè)請(qǐng)求進(jìn)入系統(tǒng)時(shí)在Header中標(biāo)記X-Retry-Budget: 3，所有下游服務(wù)的重試需消費(fèi)該預(yù)算并透?jìng)魇Ｓ囝~度，耗盡后返回快速失敗，不再層層自決重試。部署一周后對(duì)比重試放大因子與GPU成本曲線(xiàn)，多數(shù)團(tuán)隊(duì)可實(shí)現(xiàn)放大因子從3-5降至1.2以下，對(duì)應(yīng)的無(wú)效算力消耗占比從峰值期的45%-60%壓縮到5%以?xún)?nèi)。

其次，將彈性伸縮的觸發(fā)指標(biāo)從CPU/內(nèi)存切換到GPU計(jì)算利用率與請(qǐng)求排隊(duì)深度。使用KEDA的Prometheus Scaler訂閱DCGM_FI_PROF_GR_ENGINE_ACTIVE，設(shè)定閾值為75%觸發(fā)擴(kuò)容、50%觸發(fā)縮容，并配置縮容穩(wěn)定窗口至少10分鐘以避免頻繁震蕩。同時(shí)維持一個(gè)最小預(yù)熱實(shí)例池（通常為預(yù)期的10%在線(xiàn)實(shí)例數(shù)），吸收冷啟動(dòng)間隙的流量壓力。效果上，資源浪費(fèi)比例可從“全天候預(yù)留安全余量”的30%-50%降至接近J型曲線(xiàn)——用多少、配多少。

最后一步是驗(yàn)證閉環(huán)：將優(yōu)化前后的兩周成本數(shù)據(jù)按business_line維度拆分對(duì)比，確認(rèn)高成本調(diào)用路徑的支出變化。成本歸屬的透明化可以倒逼上游業(yè)務(wù)優(yōu)化重復(fù)調(diào)用和價(jià)值存疑的推理請(qǐng)求——當(dāng)某個(gè)內(nèi)部實(shí)驗(yàn)?zāi)Ｐ桶姹颈幻鞔_關(guān)聯(lián)到月均數(shù)千元的GPU支出時(shí)，移除或降配的決策會(huì)遠(yuǎn)比模糊的“優(yōu)化一下”來(lái)得快。

六、工具選型與長(zhǎng)效成本治理建議

把GPU成本控制住，不能只靠一次性的排查和調(diào)參，需要把觀測(cè)、決策和文化擰成一股持續(xù)運(yùn)轉(zhuǎn)的閉環(huán)。這一節(jié)不談某個(gè)產(chǎn)品的廣告，只從可落地的技術(shù)組合與管理機(jī)制出發(fā)，給出幾條已經(jīng)被云原生團(tuán)隊(duì)驗(yàn)證過(guò)的路徑。

1. 開(kāi)源與商業(yè)監(jiān)控工具的組合策略

“看不到”是成本失控的根源。只盯著顯存占用率，等于只看了個(gè)寂寞——模型一加載，顯存就接近滿(mǎn)格，但計(jì)算核心可能長(zhǎng)時(shí)間空閑。真正需要拉通的，是請(qǐng)求量、推理耗時(shí)、GPU計(jì)算活躍度、重試放大系數(shù)這四個(gè)維度的實(shí)時(shí)關(guān)聯(lián)。

操作步驟：- 第一步，統(tǒng)一采集GPU細(xì)粒度指標(biāo)。 在所有節(jié)點(diǎn)部署NVIDIA DCGM，通過(guò)DCGM_FI_PROF_GR_ENGINE_ACTIVE、DCGM_FI_PROF_SM_ACTIVE這類(lèi)指標(biāo)暴露SM核心、張量核的實(shí)際活躍占比。Prometheus拉取這些指標(biāo)，并給Grafana配上“GPU真實(shí)計(jì)算利用率”面板，區(qū)分出數(shù)據(jù)搬運(yùn)等待與有效矩陣運(yùn)算。 - 第二步，構(gòu)建推理維度的可觀測(cè)性。 推理請(qǐng)求在進(jìn)入模型前，植入業(yè)務(wù)標(biāo)簽（模型版本、調(diào)用方、場(chǎng)景ID），并在推理框架側(cè)按階段打點(diǎn)：Token生成首token延遲、KV Cache讀寫(xiě)耗時(shí)、排隊(duì)長(zhǎng)度。Jaeger或OpenTelemetry將這些trace信息與DCGM指標(biāo)做關(guān)聯(lián)，讓每一分GPU時(shí)間都能追溯到具體調(diào)用鏈。 - 第三步，實(shí)施基于“重試預(yù)算”的限流。 在網(wǎng)關(guān)或Sidecar層為每個(gè)入口請(qǐng)求分配一個(gè)重試總配額（例如3次），多級(jí)調(diào)用共享該配額。一旦耗盡，下層不再重試，直接返回失敗。這比“每跳最多重試N次”更能抑制連鎖放大。Envoy的retry budget機(jī)制、Istio的retryPolicy都可以配置，關(guān)鍵是要把重試放大系數(shù)作為核心告警指標(biāo)。

效果說(shuō)明：
一個(gè)典型的12節(jié)點(diǎn)推理集群，在接入上述監(jiān)控體系后，團(tuán)隊(duì)發(fā)現(xiàn)因離線(xiàn)批處理和在線(xiàn)服務(wù)混部導(dǎo)致的SM活躍度頻繁跌至15%以下，重試預(yù)算機(jī)制將故障期的無(wú)效請(qǐng)求壓制為原先的1/4，月度GPU成本回調(diào)約28%。這種效果不需要換硬件，純粹來(lái)自“看見(jiàn)”和“管控”。

2. 多云環(huán)境的成本管理

無(wú)論出于議價(jià)、保供還是災(zāi)備考慮，推理負(fù)載常常分布在多個(gè)云或混合云上。多云帶來(lái)的最大成本陷阱不是單價(jià)差異，而是彈性策略、監(jiān)控指標(biāo)的割裂導(dǎo)致資源閑置。統(tǒng)一管理的關(guān)鍵是把自定義彈性指標(biāo)和成本歸屬打通。

操作流程：- 統(tǒng)一彈性接口： 使用KEDA而不是某云專(zhuān)有的AutoScaler。KEDA可以直接訂閱各集群內(nèi)Prometheus中的GPU計(jì)算利用率或請(qǐng)求隊(duì)列深度，擴(kuò)縮容策略由同一套YAML定義，在不同環(huán)境下發(fā)。設(shè)置scaleTargetRef與minReplicaCount時(shí)，以GPU真實(shí)利用率60%為擴(kuò)容閾值，避免基于CPU/內(nèi)存的滯后觸發(fā)。 - 構(gòu)建成本歸屬標(biāo)識(shí)： 每個(gè)推理請(qǐng)求從入口注入標(biāo)簽：“team:rec","model:v3.1","env:prod”，這些標(biāo)簽被KEDA的ScaledObject傳遞給云實(shí)例Tag或命名空間注解。月結(jié)賬單通過(guò)標(biāo)簽聚合，可以清晰看到非核心模型的成本占比。 - 實(shí)施預(yù)熱與優(yōu)雅縮容： 多云下冷啟動(dòng)差異大，統(tǒng)一的預(yù)熱實(shí)例池設(shè)置在總?cè)萘康?0%左右，以成本最低區(qū)域的算力為優(yōu)先池?？s容時(shí)執(zhí)行preStop鉤子，先將實(shí)例從負(fù)載均衡摘除，等待已有請(qǐng)求排空再銷(xiāo)毀，避免異地重試風(fēng)暴。

效果說(shuō)明：
某團(tuán)隊(duì)將三朵云的推理實(shí)例由各自的HPA遷至KEDA，并統(tǒng)一使用GPU計(jì)算利用率作為觸發(fā)指標(biāo)。遷移后跨云資源閑置率由32%降至12%，并且成本歸屬標(biāo)簽讓一支非核心業(yè)務(wù)發(fā)現(xiàn)了冗余模型調(diào)用鏈，單模型成本下降40%。多云不再是漲價(jià)理由，而是彈性冗余的籌碼。

3. 建立成本意識(shí)文化

工具再?gòu)?qiáng)，也治不了“先擴(kuò)了再說(shuō)”的慣性。成本治理的最后一步，是把指標(biāo)放到工程師的日常徑路上，讓成本與服務(wù)的穩(wěn)定性同等重要。

落地機(jī)制：- 設(shè)置GPU成本SLO： 除延遲、成功率之外，為每個(gè)推理服務(wù)定義單次請(qǐng)求的GPU成本預(yù)算（例如每千次推理成本<0.15元）。該指標(biāo)接入告警系統(tǒng)，連續(xù)3小時(shí)超預(yù)算觸發(fā)通知。 - 成本回顧例會(huì)： 每?jī)芍芤淮?，展示各業(yè)務(wù)線(xiàn)的GPU成本趨勢(shì)與推理請(qǐng)求量增減的匹配度。將“請(qǐng)求量下降但成本未降”的異常點(diǎn)挑出來(lái)，交由對(duì)應(yīng)團(tuán)隊(duì)排查是否彈性策略收斂過(guò)慢或存在無(wú)效輪詢(xún)。 - 自助成本分析看板： 讓任何工程師都能在Grafana上拉出本組模型過(guò)去7天的GPU成本、重試放大系數(shù)、真實(shí)計(jì)算利用率，不用等著運(yùn)維給報(bào)表。

這種機(jī)制并非“省錢(qián)運(yùn)動(dòng)”，而是將成本優(yōu)化變成一種工程能力。當(dāng)重試放大系數(shù)和計(jì)算利用率像QPS一樣實(shí)時(shí)可見(jiàn)時(shí)，資源浪費(fèi)會(huì)被自然收斂。

常見(jiàn)問(wèn)題FAQ

Q：顯存占用率90%，但SM活躍度只有10%，這正常嗎？
A：在加載了大模型但請(qǐng)求稀疏的場(chǎng)景下極其常見(jiàn)，這就是典型的“顯存駐留、計(jì)算空閑”。應(yīng)從SM活躍度判斷是否需要縮容或合并模型。

Q：彈性伸縮配置后，為什么成本反而上升了？
A：大概率是縮容窗口太激進(jìn)，或基于不相關(guān)指標(biāo)（如CPU）頻繁觸發(fā)擴(kuò)縮，導(dǎo)致實(shí)例反復(fù)冷啟動(dòng)。建議縮容穩(wěn)定窗口設(shè)在300秒以上，并使用GPU計(jì)算利用率或請(qǐng)求排隊(duì)深度作為觸發(fā)指標(biāo)。

Q：重試預(yù)算在服務(wù)網(wǎng)格中如何實(shí)現(xiàn)？
A：以Istio為例，在VirtualService的retryPolicy中可全局限制請(qǐng)求級(jí)重試次數(shù)，并在DestinationRule中結(jié)合連接池設(shè)置熔斷。關(guān)鍵是跨跳共享預(yù)算，Envoy的retryBudget機(jī)制直接支持。

Q：成本歸屬標(biāo)簽會(huì)導(dǎo)致性能下降嗎？
A：在請(qǐng)求header中注入少量標(biāo)簽字符串，對(duì)延遲影響通常在微秒級(jí)別，遠(yuǎn)低于推理本身數(shù)百毫秒的耗時(shí)，可忽略不計(jì)。