llama.cpp b10456 Fixes SYCL Quantization Transcoding Scheduling, Boosting Q4_0→FP32 Throughput on Arc 70 to 158.19 GB/s

llama.cpp released b10456 on August 17, fixing the thread and block counts used by the SYCL backend when launching quantized tensor copy kernels. The previous path did not fully account for the number of elements in each quantization format, causing some transcoding workloads to generate too many or too few GPU work-items. The new version scales the launch configuration in proportion to the quantization block size.

The most pronounced result was seen when dequantizing Q4_0 to FP32: the contributor measured an increase in throughput on an Intel Arc 70 from 20.21 GB/s to 158.19 GB/s, roughly 7.8× the original performance. A reviewer also reported an increase from 9.08 to 104.73 GB/s on an Arc Pro B60. Other quantization formats, however, remained broadly unchanged, indicating that the modification addresses a scheduling mismatch affecting specific data layouts rather than providing a general optimization for all SYCL kernels.

This code path is used during model loading, tensor transfers, format conversion, and some operation-preparation stages. It can reduce related bottlenecks, but it does not imply that prompt processing or per-token decoding will become 7.8× faster. Actual gains still depend on the model's quantization format, transcoding frequency, memory bandwidth, and whether the inference graph is dominated by other operations such as GEMM, attention, or CPU offloading.

The PR's AI usage disclosure states that Claude Opus 5 helped identify differences in how parallel threads were generated. After upgrading, engineering teams should benchmark model loading, prefill, decode, and peak memory usage separately, and rerun the tests on their own Arc models and oneAPI/Level Zero driver combinations. The currently published data covers only two Intel GPUs, and one CI check was still failing at release time.