2026 年 10 月，llama.cpp 連續兩個建置修復了 GGUF 相關工具在輸入檔案被截斷時靜默輸出損壞張量資料的問題。10 月 19 日的 b11727 為 gguf-split 和 export-lora 加上張量資料邊界檢查與短讀檢查，改動分別位於 gguf-split.cpp 的 copy_file_to_file（split_strategy）和 export-lora.cpp 的 read_tensor_data，並附帶回歸測試，驗證截斷輸入會被拒絕、合法張量資料仍被保留。10 月 25 日的 b11880 把拒絕截斷資料的檢查擴充套件到 GGUF 張量合併流程（提交 #31044，改動位於 tools），避免合出損壞的模型檔案。兩版建置仍覆蓋 macOS Apple Silicon、iOS、Linux（CUDA 12/13、ROCm、Vulkan、SYCL、OpenVINO）、Android 與 Windows 等平台；b11880 中啟用 KleidiAI 的 macOS Apple Silicon 建置與 openEuler 建置被標記為停用，其中 KleidiAI 建置在 b11727 同樣處於停用狀態。對使用 split、export-lora 或合併工具處理下載不完整模型檔案的本地推理使用者，這類輸入現在會被直接拒絕，而不再產出看似正常卻已損壞的 GGUF。
AI 根據 2 則報導生成 · 更新
沿著報導，了解事件的不同側面；點標題看單篇報導的摘要與原文連結。
llama.cpp 新建置 b11880 在合併 GGUF 張量資料時，會拒絕被截斷的資料，避免合出損壞的模型檔案；對應提交為 #31044，改動位於 tools。該版本仍覆蓋 macOS Apple Silicon、iOS、Linux（CUDA 12/13、ROCm、Vulkan、SYCL、OpenVINO）、Android 與 Windows 等平台，但啟用 KleidiAI 的 macOS Apple Silicon 建置和 openEuler 建置在本期被標記為停用。
llama.cpp 建置 b11727 為 gguf-split 和 export-lora 加上張量資料邊界檢查與短讀檢查，輸入 GGUF 檔案被截斷時直接拒絕，不再靜默產出損壞的張量資料。修復點位於 gguf-split.cpp 的 copy_file_to_file（split_strategy）與 export-lora.cpp 的 read_tensor_data，並附帶回歸測試，驗證截斷輸入被拒絕、合法張量資料仍被保留。
過去 48 小時，有 0 個獨立來源報導，最近 6 小時新增 0 個。熱度 0.0。
熱度以 48 小時內的獨立來源計，同一來源只算一次，每 24 小時權重減半。
同一事件的報導集中在這裡，新的進展會繼續補充。