llama.cpp Daily Builds Fall Back to F32 on Older GPUs and Prevent Divide-by-Zero Crashes in Nemotron MTP Weights

llama.cpp released several prerelease builds in succession on September 13–14, focusing not on new model features but on failure handling across heterogeneous hardware and newer speculative decoding weights. b10950 changes `ggml-cuda` so that only devices with hardware-accelerated BF16 use the BF16 path, including NVIDIA Ampere and newer architectures, as well as AMD RDNA3 or CDNA. Other CUDA/HIP devices now run the relevant paths in F32. This turns configurations that might previously have failed to run into a slower but functional fallback mode, although the release notes provide no figures for the performance impact or increase in VRAM usage.

b10947 addresses the trailing NextN/MTP layers in Nemotron-H. When a layer does not provide `expert_feed_forward_length`, the loader derives the expert FFN size using `n_ff / n_expert_used`. However, both fields may legitimately be zero for non-MoE layers, so the previous implementation divided by zero and terminated with SIGFPE during loading without a diagnostic message. The new version adds a guard that explicitly reports a format problem when it encounters this type of checkpoint metadata.

During the same window, b10952 also fixed an issue where the oneDNN scratchpad disrupted the deallocation order of the SYCL memory pool. Meanwhile, b10951 moved the `llama_n_rs_seq` check to before `llama_decode`, allowing sequences that do not require decoding to return early. Although these changes affect different backends, together they reflect the compatibility burden llama.cpp now carries across new model architectures, speculative heads, and execution paths for GPUs from multiple vendors.

Engineering teams should not treat daily builds as stable releases and roll them out across the board without validation. The F32 fallback may change throughput, memory usage, and numerical results. The Nemotron fix only converts a crash into an understandable error; it cannot repair a defective GGUF file. A safer approach is to compare outputs before and after the upgrade using fixed models and prompts, then measure VRAM usage, prefill performance, and decode performance with representative long-context and MTP configurations before deciding whether to deploy the build to production.