推論系統
llama.cpp b10456 修正 SYCL 量化轉碼排程，Arc 70 的 Q4_0→FP32 吞吐提高至 158.19 GB/s
新版依量化區塊大小配置執行緒與工作群組，避免 SYCL copy kernel 過度或不足訂閱。Arc 70 微基準吞吐由 20.21 升至 158.19 GB/s，但這不是完整模型的 token 生成加速比。
llama.cpp 於 8 月 17 日發布 b10456，修正 SYCL 後端啟動量化 tensor copy kernel 時的執行緒與 block 數量。舊路徑未充分考慮每種量化格式所含元素數，令部分轉碼工作產生過多或過少的 GPU work-item；新版把啟動規模改為與 quant block 大小成比例。
最明顯的結果出現在 Q4_0 解量化至 FP32：提交者在 Intel Arc 70 測得吞吐由 20.21 GB/s 增至 158.19 GB/s，約為原來 7.8 倍。審查者在 Arc Pro B60 亦回報由 9.08 增至 104.73 GB/s。不過其他量化格式大致持平，說明修改針對的是特定資料版型與排程失配，而非所有 SYCL kernel 的通用最佳化。
這條路徑會在模型載入、tensor 搬移、格式轉換或部分運算準備階段出現；它可縮短相關瓶頸，卻不能直接推導出 prompt processing 或逐 token 解碼會快 7.8 倍。實際收益仍取決於模型量化格式、轉碼頻率、記憶體頻寬及推論圖是否由其他 GEMM、attention 或 CPU offload 主導。
PR 的 AI 使用揭露指出，Claude Opus 5 協助發現平行執行緒生成方式的差異。工程團隊升級後應分別量測模型載入、prefill、decode 與峰值記憶體，並在自身 Arc 型號和 oneAPI／Level Zero 驅動組合上重跑；目前公開數據只涵蓋兩款 Intel GPU，而且發版時仍有一項 CI 檢查未通過。