![【Bug已解決】[Bug]： EngineDeadError： RPC call to execute model timed out on CPU when running google/gemma](http://pic.xiahunao.cn/yaotu/【Bug已解決】[Bug]： EngineDeadError： RPC call to execute model timed out on CPU when running google/gemma)
【Bug已解決】[Bug] EngineDeadError RPC call to execute model timed out on CPU when running google/gemma-4-26B-A4B-it with large concurrent decode batch 解決方案一、現(xiàn)象長(zhǎng)什么樣在CPU 后端沒(méi)有 GPU用 CPU 跑 vLLM上加載google/gemma-4-26B-A4B-it并發(fā)解碼批量一大進(jìn)程整體崩報(bào)EngineDeadError: RPC call to execute_model timed out或者更完整一點(diǎn)API 側(cè)看到vllm.engine.async_llm_engine.EngineDeadError: Engine is dead due to RPC call to execute_model timed out.幾個(gè)特征只在CPU 后端炸同樣配置換 GPU 后端能跑。小批量比如并發(fā) 8 以?xún)?nèi)正常并發(fā)一上來(lái)比如 64、128就崩。崩潰時(shí)機(jī)是「正在處理大批量解碼的某一步」不是啟動(dòng)階段。報(bào)錯(cuò)前往往有一步「特別慢」CPU 上大矩陣乘耗時(shí)遠(yuǎn)超 GPU。本質(zhì)CPU 上跑大模型單步 forward 的墻鐘時(shí)間本來(lái)就比 GPU 長(zhǎng)得多并發(fā)批量一大單步時(shí)間進(jìn)一步拉長(zhǎng)超過(guò)了框架固定的 RPC 超時(shí)閾值于是「死亡檢測(cè)」誤以為引擎掛了主動(dòng)殺掉引擎。二、背景vLLM 的引擎核心跑在一個(gè)獨(dú)立的 worker 進(jìn)程或線(xiàn)程里API 服務(wù)器通過(guò)RPC進(jìn)程間調(diào)用和它通信。execute_model就是 API 側(cè)讓 worker「跑一步推理」的 RPC。為了防止 worker 真死了還傻等框架給這個(gè) RPC 設(shè)了一個(gè)超時(shí)超過(guò)這個(gè)時(shí)間還沒(méi)回包就判定引擎已死拋EngineDeadError并終止。這個(gè)超時(shí)閾值以及相關(guān)的 heartbeat 間隔是在「面向 GPU」的假設(shè)下調(diào)的GPU 上一個(gè) decode step 通常幾毫秒到幾十毫秒所以超時(shí)可以設(shè)得比較緊比如幾十秒已經(jīng)留了很大余量。但CPU 上完全不是這個(gè)量級(jí)gemma-4-26B-A4B-it是個(gè) 26B 參數(shù)的模型光前向量化后如 int8/int4在 CPU 上跑一步也得秒級(jí)。再加上「large concurrent decode batch」一個(gè) step 要同時(shí)解碼幾十上百條序列CPU 的矩陣乘是串行攤在核上的batch 越大單步越慢輕松從「幾百毫秒」?jié)q到「數(shù)十秒」。于是單步時(shí)間直接撞上甚至超過(guò)那個(gè)為 GPU 設(shè)的 RPC 超時(shí) → 死亡檢測(cè)誤判。特別注意worker并沒(méi)有真死它只是在「認(rèn)真地慢慢算」。但死亡檢測(cè)不管這些超時(shí)即殺于是你看到的是「引擎自己把自己殺了」。三、根因根因是RPC 超時(shí)閾值是固定的、且按 GPU 時(shí)序調(diào)的沒(méi)有隨后端CPU和批量大小縮放三層第一層主因超時(shí)閾值與后端脫鉤。超時(shí)值寫(xiě)死成常量或在配置里默認(rèn)成一個(gè)適合 GPU 的數(shù)CPU 后端加載時(shí)沒(méi)有「我的單步會(huì)更慢請(qǐng)把超時(shí)放寬」的機(jī)制。于是 CPU 上正常的慢 step 被當(dāng)成「引擎死了」。第二層超時(shí)閾值與批量大小脫鉤?？蚣馨础傅湫团俊构烙?jì)單步耗時(shí)但用戶(hù)用max_num_seqs把并發(fā)拉到很大時(shí)單步耗時(shí)線(xiàn)性甚至超線(xiàn)性因?yàn)?CPU 內(nèi)存帶寬瓶頸增長(zhǎng)而超時(shí)閾值沒(méi)跟著漲。批量越大、越容易超時(shí)。第三層死亡檢測(cè)「一超時(shí)就殺」沒(méi)有區(qū)分「真死」和「慢」。EngineDeadError的觸發(fā)邏輯是「RPC 沒(méi)在 T 內(nèi)回包就判定 dead」。但它沒(méi)有「先把 worker 標(biāo)記為 unhealthy、再給一次機(jī)會(huì)、或檢查 worker 進(jìn)程其實(shí)還在跑CPU 占用高」的過(guò)渡態(tài)。一次正常的慢 step 直接被定性為死亡沒(méi)有回旋余地。一句話(huà)固定的、面向 GPU 的 RPC 超時(shí)在 CPU 大批量下被正常的慢 step 擊穿死亡檢測(cè)誤判引擎死亡并殺進(jìn)程。四、最小可運(yùn)行復(fù)現(xiàn)下面用純 Python 的multiprocessingQueue模擬「API 進(jìn)程等 worker 的 RPC 回包worker 在 CPU 上慢慢算超過(guò)了固定超時(shí)就被判死」的控制流不需要 GPUimport multiprocessing as mp import time RPC_TIMEOUT 2.0 # 為 GPU 設(shè)的緊閾值 def worker(result_q: mp.Queue, compute_seconds: float): # 模擬 CPU 上慢慢算一個(gè)大 batch 的一步 time.sleep(compute_seconds) result_q.put(done) # RPC 回包 def api_side(compute_seconds: float): result_q mp.Queue() p mp.Process(targetworker, args(result_q, compute_seconds)) p.start() start time.time() # 固定超時(shí)等待回包 p.join(timeoutRPC_TIMEOUT) if p.is_alive(): # 超時(shí) - 誤判引擎死殺掉 p.terminate() elapsed time.time() - start raise RuntimeError( fEngineDeadError: RPC timed out after {elapsed:.1f}s f(worker 其實(shí)還在算還需 ~{compute_seconds - elapsed:.1f}s) ) return result_q.get() def main(): # CPU 上大 batch 一步要 5 秒但超時(shí)才 2 秒 - 誤判死 try: api_side(compute_seconds5.0) except RuntimeError as e: print(復(fù)現(xiàn)成功:, e) if __name__ __main__: main()跑出來(lái)會(huì)打印復(fù)現(xiàn)成功: EngineDeadError: RPC timed out after 2.0s (worker 其實(shí)還在算還需 ~3.0s)——worker 沒(méi)死、只是慢卻被固定超時(shí)誤殺和線(xiàn)上完全一致。五、解決方案第一層最小直接修復(fù)最省事的救火把 RPC / 引擎相關(guān)的超時(shí)閾值調(diào)大并降低 CPU 上的并發(fā)批量。vLLM 側(cè)可調(diào)的超時(shí)不同版本字段名略有差異常見(jiàn)如下# 增大引擎死亡檢測(cè)的容忍度 llm LLM( modelgoogle/gemma-4-26B-A4B-it, devicecpu, # 關(guān)鍵放寬與引擎通信的超時(shí)單位秒按需放大 engine_rpc_timeout600, # 默認(rèn)可能只有幾十秒 # 降低 CPU 上的并發(fā)避免單步過(guò)慢 max_num_seqs16, # 默認(rèn)可能 256CPU 上砍到 16 max_num_batched_tokens2048, )如果字段名在你的版本里不同退而求其次直接降低max_num_seqs往往就夠——批量小了單步就快了撞不上超時(shí)。這是 CPU 后端最常用的臨時(shí)規(guī)避。六、解決方案第二層結(jié)構(gòu)性改進(jìn)第一層是「手動(dòng)放大超時(shí)」第二層是「讓超時(shí)任 backend 和批量自適應(yīng)」從設(shè)計(jì)上消滅「GPU 閾值套 CPU」from dataclasses import dataclass from enum import Enum class Backend(Enum): GPU gpu CPU cpu dataclass class RpcTimeoutPolicy: backend: Backend base_timeout: float 30.0 per_seq_seconds: float 0.2 # 每個(gè)并發(fā)序列額外的時(shí)間預(yù)算 max_timeout: float 1800.0 def compute(self, max_num_seqs: int) - float: if self.backend Backend.CPU: # CPU 單步遠(yuǎn)慢于 GPU基數(shù)和每序列預(yù)算都放大 base self.base_timeout * 10 per self.per_seq_seconds * 5 else: base, per self.base_timeout, self.per_seq_seconds t base per * max_num_seqs return min(t, self.max_timeout) def configure_engine_timeout(backend: Backend, max_num_seqs: int) - float: policy RpcTimeoutPolicy(backendbackend) t policy.compute(max_num_seqs) # 順帶做健康檢查超時(shí)不是「直接殺」而是先標(biāo)記 unhealthy 再觀(guān)察 return t # 用法 timeout configure_engine_timeout(Backend.CPU, max_num_seqs16) print(CPU 后端、并發(fā)16 的建議 RPC 超時(shí):, timeout, 秒)再補(bǔ)一個(gè)「死亡檢測(cè)柔性化」超時(shí)先標(biāo)記UNHEALTHY并檢查 worker 進(jìn)程是否還活著CPU 占用 / 心跳線(xiàn)程活著就續(xù)命而不是立刻殺def on_rpc_timeout(worker_proc, step_start): if worker_proc.is_alive() and worker_proc.cpu_percent() 5: # worker 還在努力算只是慢續(xù)命并放寬本次等待 return UNHEALTHY_RETRY # 真正死了進(jìn)程沒(méi)了 / 不占 CPU才判 dead return DEAD七、解決方案第三層斷言 / CI 守護(hù)把「CPU 超時(shí)必須大于 GPU」「超時(shí)隨批量增長(zhǎng)」「柔性死亡檢測(cè)」固化成測(cè)試import pytest def test_cpu_timeout_larger_than_gpu(): gpu configure_engine_timeout(Backend.GPU, 64) cpu configure_engine_timeout(Backend.CPU, 64) assert cpu gpu def test_timeout_grows_with_batch(): small configure_engine_timeout(Backend.CPU, 8) large configure_engine_timeout(Backend.CPU, 128) assert large small def test_timeout_capped(): t configure_engine_timeout(Backend.CPU, 100000) assert t 1800.0 def test_dead_detection_flexible_when_worker_alive(): class FakeProc: def is_alive(self): return True def cpu_percent(self): return 50 assert on_rpc_timeout(FakeProc(), 0) UNHEALTHY_RETRY def test_dead_detection_kills_when_worker_gone(): class FakeProc: def is_alive(self): return False def cpu_percent(self): return 0 assert on_rpc_timeout(FakeProc(), 0) DEAD再加一個(gè)端到端回歸CPU 后端 大批量跑若干步不觸發(fā) EngineDeadErrordef test_cpu_large_batch_no_engine_dead(): engine make_engine(devicecpu, modelgemma-4-26B-A4B-it, max_num_seqs64, rpc_timeout600) for _ in range(5): engine.step() # 不應(yīng)拋 EngineDeadError八、排查清單看報(bào)錯(cuò)是否EngineDeadError: RPC call to execute_model timed out且后端是 CPU → 坐實(shí)本問(wèn)題。小批量能跑、大批量崩 → 是超時(shí)閾值被慢 step 擊穿。臨時(shí)救火調(diào)大engine_rpc_timeout或等價(jià)字段并降低max_num_seqs。確認(rèn)超時(shí)字段名不同 vLLM 版本叫engine_rpc_timeout/request_timeout/client_timeoutgrep 報(bào)錯(cuò)棧里的調(diào)用點(diǎn)。長(zhǎng)期修復(fù)超時(shí)任 backendCPU 放大和批量線(xiàn)性增長(zhǎng)自適應(yīng)死亡檢測(cè)先標(biāo)記 UNHEALTHY 再判死。升級(jí) vLLM 到合了 CPU 超時(shí)修復(fù)的版本并跑上面的 CPU 大批量回歸。若 CPU 實(shí)在太慢考慮換量化int4/int8或減max_num_batched_tokens從源頭壓低單步耗時(shí)。九、小結(jié)CPU 后端大批量下的EngineDeadError: RPC timed out不是引擎真死而是固定的、面向 GPU 的 RPC 超時(shí)閾值被 CPU 上正常的慢 step尤其大批量時(shí)擊穿死亡檢測(cè)誤判引擎死亡并殺進(jìn)程。最小修復(fù)是調(diào)大超時(shí) 降max_num_seqs結(jié)構(gòu)性修復(fù)是超時(shí)任 backend 和批量自適應(yīng)、死亡檢測(cè)柔性化先 UNHEALTHY 再判 DEAD最后用 pytest 鎖死「CPU 超時(shí) GPU」「超時(shí)隨批量增長(zhǎng)」「worker 活著就續(xù)命」。抓住「超時(shí)閾值必須和后端算力、批量規(guī)模匹配」這條所有 CPU/NPU 等非 GPU 后端的超時(shí)坑都能照此化解。 【Bug已解決】[Bug]： EngineDeadError： RPC call to execute model timed out on CPU when running google/gemma
【Bug已解決】[Bug] EngineDeadError RPC call to execute model timed out on CPU when running google/gemma-4-26B-A4B-it with large concurrent decode batch 解決方案一、現(xiàn)象長(zhǎng)什么樣在CPU 后端沒(méi)有 GPU用 CPU 跑 vLLM上加載google/gemma-4-26B-A4B-it并發(fā)解碼批量一大進(jìn)程整體崩報(bào)EngineDeadError: RPC call to execute_model timed out或者更完整一點(diǎn)API 側(cè)看到vllm.engine.async_llm_engine.EngineDeadError: Engine is dead due to RPC call to execute_model timed out.幾個(gè)特征只在CPU 后端炸同樣配置換 GPU 后端能跑。小批量比如并發(fā) 8 以?xún)?nèi)正常并發(fā)一上來(lái)比如 64、128就崩。崩潰時(shí)機(jī)是「正在處理大批量解碼的某一步」不是啟動(dòng)階段。報(bào)錯(cuò)前往往有一步「特別慢」CPU 上大矩陣乘耗時(shí)遠(yuǎn)超 GPU。本質(zhì)CPU 上跑大模型單步 forward 的墻鐘時(shí)間本來(lái)就比 GPU 長(zhǎng)得多并發(fā)批量一大單步時(shí)間進(jìn)一步拉長(zhǎng)超過(guò)了框架固定的 RPC 超時(shí)閾值于是「死亡檢測(cè)」誤以為引擎掛了主動(dòng)殺掉引擎。二、背景vLLM 的引擎核心跑在一個(gè)獨(dú)立的 worker 進(jìn)程或線(xiàn)程里API 服務(wù)器通過(guò)RPC進(jìn)程間調(diào)用和它通信。execute_model就是 API 側(cè)讓 worker「跑一步推理」的 RPC。為了防止 worker 真死了還傻等框架給這個(gè) RPC 設(shè)了一個(gè)超時(shí)超過(guò)這個(gè)時(shí)間還沒(méi)回包就判定引擎已死拋EngineDeadError并終止。這個(gè)超時(shí)閾值以及相關(guān)的 heartbeat 間隔是在「面向 GPU」的假設(shè)下調(diào)的GPU 上一個(gè) decode step 通常幾毫秒到幾十毫秒所以超時(shí)可以設(shè)得比較緊比如幾十秒已經(jīng)留了很大余量。但CPU 上完全不是這個(gè)量級(jí)gemma-4-26B-A4B-it是個(gè) 26B 參數(shù)的模型光前向量化后如 int8/int4在 CPU 上跑一步也得秒級(jí)。再加上「large concurrent decode batch」一個(gè) step 要同時(shí)解碼幾十上百條序列CPU 的矩陣乘是串行攤在核上的batch 越大單步越慢輕松從「幾百毫秒」?jié)q到「數(shù)十秒」。于是單步時(shí)間直接撞上甚至超過(guò)那個(gè)為 GPU 設(shè)的 RPC 超時(shí) → 死亡檢測(cè)誤判。特別注意worker并沒(méi)有真死它只是在「認(rèn)真地慢慢算」。但死亡檢測(cè)不管這些超時(shí)即殺于是你看到的是「引擎自己把自己殺了」。三、根因根因是RPC 超時(shí)閾值是固定的、且按 GPU 時(shí)序調(diào)的沒(méi)有隨后端CPU和批量大小縮放三層第一層主因超時(shí)閾值與后端脫鉤。超時(shí)值寫(xiě)死成常量或在配置里默認(rèn)成一個(gè)適合 GPU 的數(shù)CPU 后端加載時(shí)沒(méi)有「我的單步會(huì)更慢請(qǐng)把超時(shí)放寬」的機(jī)制。于是 CPU 上正常的慢 step 被當(dāng)成「引擎死了」。第二層超時(shí)閾值與批量大小脫鉤?？蚣馨础傅湫团俊构烙?jì)單步耗時(shí)但用戶(hù)用max_num_seqs把并發(fā)拉到很大時(shí)單步耗時(shí)線(xiàn)性甚至超線(xiàn)性因?yàn)?CPU 內(nèi)存帶寬瓶頸增長(zhǎng)而超時(shí)閾值沒(méi)跟著漲。批量越大、越容易超時(shí)。第三層死亡檢測(cè)「一超時(shí)就殺」沒(méi)有區(qū)分「真死」和「慢」。EngineDeadError的觸發(fā)邏輯是「RPC 沒(méi)在 T 內(nèi)回包就判定 dead」。但它沒(méi)有「先把 worker 標(biāo)記為 unhealthy、再給一次機(jī)會(huì)、或檢查 worker 進(jìn)程其實(shí)還在跑CPU 占用高」的過(guò)渡態(tài)。一次正常的慢 step 直接被定性為死亡沒(méi)有回旋余地。一句話(huà)固定的、面向 GPU 的 RPC 超時(shí)在 CPU 大批量下被正常的慢 step 擊穿死亡檢測(cè)誤判引擎死亡并殺進(jìn)程。四、最小可運(yùn)行復(fù)現(xiàn)下面用純 Python 的multiprocessingQueue模擬「API 進(jìn)程等 worker 的 RPC 回包worker 在 CPU 上慢慢算超過(guò)了固定超時(shí)就被判死」的控制流不需要 GPUimport multiprocessing as mp import time RPC_TIMEOUT 2.0 # 為 GPU 設(shè)的緊閾值 def worker(result_q: mp.Queue, compute_seconds: float): # 模擬 CPU 上慢慢算一個(gè)大 batch 的一步 time.sleep(compute_seconds) result_q.put(done) # RPC 回包 def api_side(compute_seconds: float): result_q mp.Queue() p mp.Process(targetworker, args(result_q, compute_seconds)) p.start() start time.time() # 固定超時(shí)等待回包 p.join(timeoutRPC_TIMEOUT) if p.is_alive(): # 超時(shí) - 誤判引擎死殺掉 p.terminate() elapsed time.time() - start raise RuntimeError( fEngineDeadError: RPC timed out after {elapsed:.1f}s f(worker 其實(shí)還在算還需 ~{compute_seconds - elapsed:.1f}s) ) return result_q.get() def main(): # CPU 上大 batch 一步要 5 秒但超時(shí)才 2 秒 - 誤判死 try: api_side(compute_seconds5.0) except RuntimeError as e: print(復(fù)現(xiàn)成功:, e) if __name__ __main__: main()跑出來(lái)會(huì)打印復(fù)現(xiàn)成功: EngineDeadError: RPC timed out after 2.0s (worker 其實(shí)還在算還需 ~3.0s)——worker 沒(méi)死、只是慢卻被固定超時(shí)誤殺和線(xiàn)上完全一致。五、解決方案第一層最小直接修復(fù)最省事的救火把 RPC / 引擎相關(guān)的超時(shí)閾值調(diào)大并降低 CPU 上的并發(fā)批量。vLLM 側(cè)可調(diào)的超時(shí)不同版本字段名略有差異常見(jiàn)如下# 增大引擎死亡檢測(cè)的容忍度 llm LLM( modelgoogle/gemma-4-26B-A4B-it, devicecpu, # 關(guān)鍵放寬與引擎通信的超時(shí)單位秒按需放大 engine_rpc_timeout600, # 默認(rèn)可能只有幾十秒 # 降低 CPU 上的并發(fā)避免單步過(guò)慢 max_num_seqs16, # 默認(rèn)可能 256CPU 上砍到 16 max_num_batched_tokens2048, )如果字段名在你的版本里不同退而求其次直接降低max_num_seqs往往就夠——批量小了單步就快了撞不上超時(shí)。這是 CPU 后端最常用的臨時(shí)規(guī)避。六、解決方案第二層結(jié)構(gòu)性改進(jìn)第一層是「手動(dòng)放大超時(shí)」第二層是「讓超時(shí)任 backend 和批量自適應(yīng)」從設(shè)計(jì)上消滅「GPU 閾值套 CPU」from dataclasses import dataclass from enum import Enum class Backend(Enum): GPU gpu CPU cpu dataclass class RpcTimeoutPolicy: backend: Backend base_timeout: float 30.0 per_seq_seconds: float 0.2 # 每個(gè)并發(fā)序列額外的時(shí)間預(yù)算 max_timeout: float 1800.0 def compute(self, max_num_seqs: int) - float: if self.backend Backend.CPU: # CPU 單步遠(yuǎn)慢于 GPU基數(shù)和每序列預(yù)算都放大 base self.base_timeout * 10 per self.per_seq_seconds * 5 else: base, per self.base_timeout, self.per_seq_seconds t base per * max_num_seqs return min(t, self.max_timeout) def configure_engine_timeout(backend: Backend, max_num_seqs: int) - float: policy RpcTimeoutPolicy(backendbackend) t policy.compute(max_num_seqs) # 順帶做健康檢查超時(shí)不是「直接殺」而是先標(biāo)記 unhealthy 再觀(guān)察 return t # 用法 timeout configure_engine_timeout(Backend.CPU, max_num_seqs16) print(CPU 后端、并發(fā)16 的建議 RPC 超時(shí):, timeout, 秒)再補(bǔ)一個(gè)「死亡檢測(cè)柔性化」超時(shí)先標(biāo)記UNHEALTHY并檢查 worker 進(jìn)程是否還活著CPU 占用 / 心跳線(xiàn)程活著就續(xù)命而不是立刻殺def on_rpc_timeout(worker_proc, step_start): if worker_proc.is_alive() and worker_proc.cpu_percent() 5: # worker 還在努力算只是慢續(xù)命并放寬本次等待 return UNHEALTHY_RETRY # 真正死了進(jìn)程沒(méi)了 / 不占 CPU才判 dead return DEAD七、解決方案第三層斷言 / CI 守護(hù)把「CPU 超時(shí)必須大于 GPU」「超時(shí)隨批量增長(zhǎng)」「柔性死亡檢測(cè)」固化成測(cè)試import pytest def test_cpu_timeout_larger_than_gpu(): gpu configure_engine_timeout(Backend.GPU, 64) cpu configure_engine_timeout(Backend.CPU, 64) assert cpu gpu def test_timeout_grows_with_batch(): small configure_engine_timeout(Backend.CPU, 8) large configure_engine_timeout(Backend.CPU, 128) assert large small def test_timeout_capped(): t configure_engine_timeout(Backend.CPU, 100000) assert t 1800.0 def test_dead_detection_flexible_when_worker_alive(): class FakeProc: def is_alive(self): return True def cpu_percent(self): return 50 assert on_rpc_timeout(FakeProc(), 0) UNHEALTHY_RETRY def test_dead_detection_kills_when_worker_gone(): class FakeProc: def is_alive(self): return False def cpu_percent(self): return 0 assert on_rpc_timeout(FakeProc(), 0) DEAD再加一個(gè)端到端回歸CPU 后端 大批量跑若干步不觸發(fā) EngineDeadErrordef test_cpu_large_batch_no_engine_dead(): engine make_engine(devicecpu, modelgemma-4-26B-A4B-it, max_num_seqs64, rpc_timeout600) for _ in range(5): engine.step() # 不應(yīng)拋 EngineDeadError八、排查清單看報(bào)錯(cuò)是否EngineDeadError: RPC call to execute_model timed out且后端是 CPU → 坐實(shí)本問(wèn)題。小批量能跑、大批量崩 → 是超時(shí)閾值被慢 step 擊穿。臨時(shí)救火調(diào)大engine_rpc_timeout或等價(jià)字段并降低max_num_seqs。確認(rèn)超時(shí)字段名不同 vLLM 版本叫engine_rpc_timeout/request_timeout/client_timeoutgrep 報(bào)錯(cuò)棧里的調(diào)用點(diǎn)。長(zhǎng)期修復(fù)超時(shí)任 backendCPU 放大和批量線(xiàn)性增長(zhǎng)自適應(yīng)死亡檢測(cè)先標(biāo)記 UNHEALTHY 再判死。升級(jí) vLLM 到合了 CPU 超時(shí)修復(fù)的版本并跑上面的 CPU 大批量回歸。若 CPU 實(shí)在太慢考慮換量化int4/int8或減max_num_batched_tokens從源頭壓低單步耗時(shí)。九、小結(jié)CPU 后端大批量下的EngineDeadError: RPC timed out不是引擎真死而是固定的、面向 GPU 的 RPC 超時(shí)閾值被 CPU 上正常的慢 step尤其大批量時(shí)擊穿死亡檢測(cè)誤判引擎死亡并殺進(jìn)程。最小修復(fù)是調(diào)大超時(shí) 降max_num_seqs結(jié)構(gòu)性修復(fù)是超時(shí)任 backend 和批量自適應(yīng)、死亡檢測(cè)柔性化先 UNHEALTHY 再判 DEAD最后用 pytest 鎖死「CPU 超時(shí) GPU」「超時(shí)隨批量增長(zhǎng)」「worker 活著就續(xù)命」。抓住「超時(shí)閾值必須和后端算力、批量規(guī)模匹配」這條所有 CPU/NPU 等非 GPU 后端的超時(shí)坑都能照此化解。