From 8cb7708e119755e97bc04ee8dddc2b8a8b606a3c Mon Sep 17 00:00:00 2001 From: Daniel Han Date: Sun, 3 May 2026 01:33:50 +0000 Subject: [PATCH] studio: tolerate truncated GGUF input so resolver fallback still runs Wraps each iteration of the GGUF KV-pair loop in a try/except that breaks out cleanly on `struct.error` or `UnicodeDecodeError`, instead of letting the outer try eat the exception and skip the SWA resolver fallback at the end. The motivating use case is reading the GGUF metadata via an HF Hub HTTP byte-range fetch. The first ~128 KiB of a typical GGUF contains all the metadata we need (arch, block_count, attention.*, sliding window, ssm, MLA fields, plus the tokenizer config) -- but for models with large tokenizer vocabs (Gemma 3 has 262144 tokens) the tokenizer arrays spill past the 128 KiB boundary. The truncation used to bubble out as `unpack requires a buffer of 8 bytes`, abandoning the resolver fallback and leaving us with no SWA pattern (so the SWA path fell through to the legacy 1/4 estimate). Verified end to end against `unsloth/gemma-3-1b-it-GGUF`: Range-fetch first 128 KiB of `gemma-3-1b-it-Q2_K.gguf` over HTTP (HTTP 206 Partial Content), parse: arch = gemma3 block_count = 26 attention.sliding_window = 512 sliding_window_pattern = set (4 global) <- via Tier 2 bootstrap KV @ ctx=8192 = 54.00 MiB <- matches llama.cpp ground truth This means Studio can preview KV-cache requirements (and therefore auto-context fit) for any HF GGUF without downloading the weights. All 124 tests pass. --- studio/backend/core/inference/llama_cpp.py | 147 ++++++++++++--------- 1 file changed, 82 insertions(+), 65 deletions(-) diff --git a/studio/backend/core/inference/llama_cpp.py b/studio/backend/core/inference/llama_cpp.py index a8614d3b76..a55e2b14db 100644 --- a/studio/backend/core/inference/llama_cpp.py +++ b/studio/backend/core/inference/llama_cpp.py @@ -1361,74 +1361,91 @@ class LlamaCppBackend: _tensor_count, kv_count = struct.unpack("