llama.cpp 在 10 月 3 日與 5 日先後合併兩個修復圖重分配（graph reallocation）中止的補丁。10 月 3 日的 PR #29856（b11375）把迴圈狀態的收集改為一次 get_rows，ubatch 狀態與額外狀態都作為它的檢視，節點大小隻取決於 n_rs，而 reserve 已把 n_rs 設為最大值。此前 build_rs 用獨立的 get_rows 收集額外狀態，最壞情況（n_rs == n_seqs）下該節點被設為 0 行，任何 cell 不連續的 ubatch 都會在節點數不變時觸發圖重分配，進而在 GGML_SCHED_NO_REALLOC 下中止。10 月 5 日的 PR #29958（b11412）修復 k-pool 模型的同類問題：qwen4exp 依據 inp->cache_safe 分支，llama_memory_seq_cp 共享 cell 後該值變為 false，QSA 層改用 fill+concat 並丟棄 new_pool_rep 葉節點，decode 圖比預留圖少 12 個節點；glm5-next 依據 n_tokens <= 16 && n_kv > n_sel 選擇 gather，TG decode 是 gather 形狀，最後一次 reserve（PP）卻是 dense 形狀。任一不匹配都會迫使 decode 時重新 reserve 並固化當前狀態，下一次狀態增長時在圖大小不變的情況下就需要更多空間，在 GGML_SCHED_DEBUG_REALLOC=1 下中止。
AI 根據 2 則報導生成 · 10/5 11:31 更新
沿著報導，了解事件的不同側面；點標題看單篇報導的摘要與原文連結。
llama.cpp 發布 b11412，修復 k-pool 模型（qwen4exp、glm5-next）解碼時意外重新預留計算圖並中止的問題。原因是兩模型按 cache_safe、n_tokens 等 reserve 無法預知的狀態分支，解碼圖與預留圖節點數不一致（如 7564 對 7762），解碼時被迫按當前狀態重預留、丟掉最壞情況尺寸，在 GGML_SCHED_DEBUG_REALLOC=1 下直接 abort。
llama.cpp 合併 PR #29856，將迴圈狀態改為一次 get_rows 收集，ubatch 狀態與額外狀態都作為其檢視，節點大小隻取決於 n_rs，而 reserve 已將其設為最大值。此前 build_rs 用獨立 get_rows 收集 n_rs - n_seqs 行額外狀態，最壞情況下該節點被設為 0 行，非連續 ubatch 會在節點數不變時觸發圖重分配，進而在 GGML_SCHED_NO_REALLOC 下中止。
過去 48 小時，有 1 個獨立來源報導，最近 6 小時新增 0 個。熱度 0.3，熱門榜第 152 名。
熱度以 48 小時內的獨立來源計，同一來源只算一次，每 24 小時權重減半。
同一事件的報導集中在這裡，新的進展會繼續補充。