Ollama 0.33.1: MLX-runnern får strukturerad utdata – och slutar timeouta på långsam disk

Ollama v0.33.1 publicerades 26 augusti 2026 klockan 18.09.57 UTC och är inte märkt som förhandsversion. Det är en patchutgåva ovanpå 0.33.0, och den handlar om något annat än gårdagens nyhet om Claude Desktop-integrationen: utgåvenoteringens fem punkter nämner inte den kopplingen med ett ord. Två av punkterna rör i stället MLX-runnern, Ollamas egen motor för Apple Silicon. Kör du Linux, Windows eller en Intel-Mac berör de dig inte. Kör du på en Apple Silicon-Mac är den ena av dem skälet att köra om ett schemaprov du kanske trodde att du redan hade svaret på.

Det här är inte 0.33.0-nyheten

Två versionsnyheter om samma program två dagar i rad är lätt att blanda ihop, så skillnaden är värd en egen rad. Utgåvan 0.33.0 förde in ett läge där Ollama konfigurerar Claude Desktop åt dig, med en kravlista som bara stod i dokumentationen. Utgåvan 0.33.1 är en patch och innehåller inget om den kopplingen i sin notering.

Notera formuleringen: i sin notering. GitHubs jämförelse mellan taggarna v0.33.0 och v0.33.1 innehåller femton commits, medan noteringen redovisar fem punkter. Bland de commits som inte fick en punkt finns bland annat justeringar av skrivbordsappens modellväljare för Claude och en borttagning av MLX-portens text-bara gemma3. En utgåvenotering är alltså ett urval, inte en fullständig ändringslogg — och det är en nyttig påminnelse när någon säger att en viss rättning "inte finns i 0.33.1" med noteringen som hela underlaget.

Så avgör du vilken runner din modell körs under

Frågan är förvånansvärt svår att svara på från utsidan, och det är just därför de här två punkterna varit lätta att missa. Tre kontroller räcker långt.

Plattformen först. MLX-runnern startar bara på macOS med arm64. Källkoden i v0.33.1 avvisar allt annat med två distinkta fel: ett för fel operativsystem och ett för macOS på fel arkitektur, där felet uttryckligen anger att MLX på macOS kräver Apple Silicon. En Intel-Mac faller alltså tillbaka på llama.cpp precis som en Linuxburk gör.

Sedan loggen. MLX-runnern körs som en egen underprocess bredvid Ollama-servern och loggar när den startar. I serverloggen ser du raden om att en MLX-runnerunderprocess startar, följd av en rad om att runnern är redo. Syns ingen av dem när modellen laddas gick anropet en annan väg. Det är den mest direkta kontrollen som finns, och den kräver inget annat än att du tittar på loggen medan du laddar modellen en gång.

Till sist modellnamnet. Ollamas MLX-varianter bär suffixet -mlx i taggen; både felrapporten som ligger bakom laddningsrättningen och rättningens egen mätning använder namn som qwen3.6:35b-mlx och nemotron-3.5-lightning:30b-mlx. Suffixet är en stark indikation men inte hela sanningen, eftersom det är arkitekturen som avgör vilken motor som kan ta modellen.

Vilka arkitekturer det är går att läsa i klartext. Filen som registrerar modellerna i MLX-runnern innehåller i v0.33.1 tolv poster: cohere2_moe, dflash, gemma4, glimmer, glm4_moe_lite, laguna, llama, nemotron_h, qwen3, qwen3_5, qwen3_5_moe och qwen4_exp. Läs listan för vad den är — vilka arkitekturer koden registrerar i den här versionen — och inte som en publicerad stödmatris från Ollama. Att registreringen styr vägen framgår av motiveringen till att text-bara gemma3 togs bort i just den här utgåvan: när MLX ges företräde för arkitekturer som båda motorerna hanterar skulle en registrerad gemma3 ha dirigerat modellen till den motor som inte kan hantera bilder. Gemma3 ligger därför kvar på llama-server, och eftersom inga gemma3-manifest i safetensors-format publicerats påverkar borttagningen inga befintliga installationer.

Före 0.33.1 var format tyst utan verkan på MLX-vägen

Det här är utgåvans viktigaste uppgift, och den står inte i noteringens korta rad om saken. Commit-meddelandet bakom punkten beskriver det gamla beteendet: MLX-runnern tog emot API:ets format-fält men tvingade inte fram det. Anrop som bad om JSON eller om ett JSON-schema fick obegränsad text tillbaka, utan att klienten hade något sätt att märka skillnaden.

Konsekvensen är obehaglig av ett skäl som har lite med JSON att göra. Ett fel som ger felmeddelande är ett arbetsmoment; ett fel som ger ett svar som ser rätt ut i nio fall av tio är ett mätproblem. Har du kört provet som räknar hur ofta formen håller på en Apple Silicon-Mac före den 26 augusti 2026, och modellen råkade gå via MLX-runnern, mätte du hur ofta modellen själv råkade svara med giltig JSON — inte hur ofta tvånget höll. Det är två helt olika siffror, och den första säger ingenting om vad som händer när du byter modell eller prompt.

Från 0.33.1 tvingas formatet fram med grammatikmotorn xgrammar. Vid varje samplingssteg maskeras logits till de tokens som fortfarande är tillåtna, så att varje utsänd token och varje avslut är giltigt under villkoret. Sampling, straffparametrar och logprobs ser den begränsade fördelningen, och strängen "json" ger ett JSON-objekt enligt dokumentationen — i praktiken villkoret att svaret är ett objekt, inte att det har några bestämda fält.

Läs ändå inte punkten starkare än den är. Utgåvenoteringen säger en rad: att strukturerad utdata stöds i MLX-runnern. Det är ett besked om att villkoret nu tillämpas, inte en utfästelse om att varje schema du skriver kommer att hålla i varje anrop. Någon uppmätt andel giltiga svar redovisas inte, och Ollama publicerar ingen sådan siffra för den här vägen. Skillnaden mellan "tvånget tillämpas" och "ditt schema håller" är precis den skillnad ditt eget prov finns till för att mäta.

Kör om schemaprovet — motorn är en annan

Frestelsen är att avfärda omprovet med att JSON-schema redan var mätt. Det håller inte, av två skäl som båda går att kontrollera.

Det första är att MLX-vägen tidigare inte tvingade fram något, vilket gör den gamla siffran obrukbar som jämförelse. Det andra är att den nya motorn är xgrammar, medan llama.cpp-vägen omvandlar schemat till GBNF. De dokumenterade begränsningarna i GBNF-konverteringen — decimalintervall, nästlade $ref, strängformat och de villkorliga nyckelorden — är begränsningar i den konverteringen. De går inte att flytta över till xgrammar utan att prova, och de går inte heller att avskriva utan att prova. Frys därför samma svit indatafall, samma seed per fall och samma temperatur, notera runtimeversionen som 0.33.1 och kör om. Just notatet om version är poängen: ett låst prov över en uppgradering är meningsfullt först när du vet vilken version det gällde, vilket är samma disciplin som driftguidens rutin kräver för modell, runtime och konfiguration.

Fyra praktiska detaljer ur källkoden är värda att ha med sig innan du felsöker ett underligt utfall:

• Ett saknat grammatikbibliotek ger fel, inte tystnad. Grammatikmotorn ligger som ett dynamiskt bibliotek bredvid MLX. Saknas det påverkas vanlig inferens inte, medan strukturerade anrop avvisas med ett uttryckligt fel om att strukturerad utdata inte är tillgänglig. Det är den verkliga förbättringen mot det gamla beteendet: felet syns.
• Schemat har hårda gränser. Koden avvisar scheman över 1 048 576 byte, scheman med mer än 16 384 JSON-tokens och nästling djupare än 128 nivåer, med ett eget felmeddelande per fall. Gränserna är rejält tilltagna, så träffar du någon av dem är det mer sannolikt att schemat genererats i en loop än att du behöver ett större tak.
• Spekulativ avkodning stängs av under tvång. Begränsade anrop avkodar tills vidare utan spekulativ avkodning. Har du valt en modell just för utkastvinsten förlorar du den i de anrop där du sätter format, och det är en avvägning värd att mäta innan du slår på tvånget överallt.
• Prestandauppgiften i commiten är smal. Utvecklarens egen mätning anger att schemaavkodning matchade takten utan utkastmodell vid ungefär 32 tokens per sekund, och att grammatikkompileringen inte gav någon mätbar extra fördröjning före avkodningen. Ingen maskin anges för den siffran, så behandla den som utvecklarens observation och inte som en förväntad takt på din dator.

En sak till, från dokumentationen snarare än från utgåvan: strukturerad utdata stöds inte i Ollamas moln. Kombinerar du en molnmodell med ett schema är det inte MLX-runnern som är begränsningen.

Metal-timeouten vid laddning från långsam disk

Den andra MLX-punkten träffar en helt annan läsare: den som har flyttat modellkatalogen till en annan disk och sedan sett en modell vägra ladda. Symptomet är felet om att en command buffer inte kunde köras, ibland med tillägget om GPU-timeout. Felrapporten bakom rättningen beskriver en Mac med 64 GB systemminne på Ollama 0.32.14, där gemma4-varianterna laddade utan problem medan tre större MLX-modeller misslyckades — samtidigt som samma modeller startade via MLX egna server. Det är ett tydligt tecken på att felet satt i Ollamas MLX-integration och inte i modellerna.

Orsaken enligt commit-meddelandet är att laddningskoden räknade ut varje viktvikning direkt när den byggdes, med beräkningarna körande på GPU:n mot tensorer som lästes in lat. Metal fick alltså committade command buffers som väntade på filläsningar, och macOS avbryter command buffers som står stilla för länge. Laddning av en stor modell från en långsam volym avbröts därför i stället för att bli långsam. Samma ivriga beräkningar höll dessutom varje lagers källvikter vid liv till efterstädningen, vilket tillfälligt band ungefär dubbla expertvikterna på MoE-modeller.

Rättningen bygger vikningarna lat och låter runnerns viktberäkning köra dem, och på Metal materialiseras de inlästa tensorerna med CPU-läsningar innan något viktgraf finns. Ingen command buffer committas då i väntan på filedata, oavsett lagringens hastighet. CUDA-laddningar läser vid utskick och hoppar över förpasset.

Mätningen i commiten gjordes på en M5 Max med varm sidcache och bitidentiska giriga utdata. Siffrorna är utvecklarens egna och redovisas här som just det:

Den tredje raden är den som betyder något, och den är lätt att sälja fel. 346 sekunder är inte snabbt — det är nästan sex minuter innan modellen svarar första gången. Skillnaden är att laddningen numera går igenom i stället för att avbrytas efter sex sekunder. Är din externa disk långsam har du alltså inte fått en snabbare laddning; du har fått en laddning. Minnesposten på den första raden är den andra vinsten: nästan 15 GiB lägre topp vid laddning av samma MoE-modell, vilket är skillnaden mellan att rymmas och att inte rymmas på en maskin med begränsat enhetligt minne.

Vill du veta vad rättningen ger på din egen dator ska du mäta laddningen separat från genereringen, med samma metod som mätguiden för kall och varm Ollama-start beskriver. Kall cache och varm cache är två olika mätningar, och tabellen ovan gäller det varma fallet utom på den sista raden.

De tre återstående punkterna

Utgåvans övriga tre punkter är kortare men hör till bilden. En punkt anger stöd för Qwen3.8 Flash Next i MLX. En punkt gör byggsystemets externa kompatibilitetspatchar idempotenta, alltså ofarliga att köra igen, och kommer från en bidragsgivares första bidrag i projektet. En punkt uppdaterar både MLX och llama.cpp, där jämförelsen mellan taggarna visar att llama.cpp lyfts till bygge b10630.

Ingen av de tre kräver något av dig. Den sista är ändå värd att notera i din egen versionsanteckning: när både MLX och llama.cpp byts i samma patchutgåva har båda vägarna genom Ollama fått ny kod, och en beteendeförändring du märker efter uppdateringen behöver inte komma från de två MLX-punkterna som fick rubrikerna.

Fyra kontroller innan du drar slutsatser

• Plattform. macOS på Apple Silicon, annars startar MLX-runnern inte över huvud taget och ingen av de två punkterna gäller dig.
• Runner. Ladda modellen en gång med serverloggen framme och leta efter raderna om att MLX-runnerns underprocess startar och blir redo. Det är svaret, inte modellnamnet.
• Schemaprov. Kör om sviten på MLX-vägen under 0.33.1 och notera versionen i protokollet. Den gamla siffran mätte modellens vana, inte tvånget.
• Laddning. Laddade en modell från extern disk inte tidigare, prova igen och tidsstämpla försöket. Räkna med att det tar lång tid på en långsam volym även när det fungerar.

Sammanfattningsvis är 0.33.1 en liten utgåva med en stor konsekvens för en avgränsad grupp. Den som kör JSON-schema mot en MLX-modell på en Apple Silicon-Mac har fram till nu haft ett tvång som inte tvingade, utan att något i API-svaret avslöjade det. Det är rättat, med den reservation som källan själv bär: punkten säger att stödet finns, inte hur ofta ditt schema håller. Den siffran får du fortfarande mäta själv.

Källor

• Ollama v0.33.1 — utgåvenoteringen med de fem punkterna och avsnittet om ny bidragsgivare
• GitHubs utgåvedata för v0.33.1 — publiceringstidpunkt i UTC och att utgåvan inte är en förhandsversion
• GitHubs jämförelse v0.33.0…v0.33.1 — antalet commits och vilka ändringar som saknar egen punkt i noteringen
• Commiten som inför strukturerad utdata i MLX-runnern — det gamla tysta beteendet, xgrammar, logitmaskningen, det saknade biblioteket, den avstängda spekulativa avkodningen och prestandauppgiften
• Commiten som rättar Metal-timeouten vid laddning från långsam lagring — orsaken, åtgärden och de tre mätfallen på M5 Max
• Felrapport 17902 — felmeddelandena om command buffer, maskinen med 64 GB och vilka MLX-modeller som misslyckades på 0.32.14
• Commiten som tar bort text-bara gemma3 ur MLX-porten — motiveringen om att MLX ges företräde för arkitekturer båda motorerna hanterar
• Registreringsfilen i v0.33.1 — de tolv arkitekturer MLX-runnern registrerar
• Grammatikkoden i v0.33.1 — gränserna för schemastorlek, JSON-tokens och nästlingsdjup samt felmeddelandena
• Klientkoden i v0.33.1 — kravet på macOS med arm64 och loggraderna när MLX-runnerns underprocess startar
• Ollamas dokumentation för strukturerad utdata — format-fältet, schemat i anropet och att Ollamas moln inte stöder strukturerad utdata

Källorna kontrollerades 27 augusti 2026, då v0.33.1 var den senaste utgåvan. Utgåvedata, commit-meddelanden och källkodsfiler är lästa direkt hos Ollamas arkiv på GitHub vid taggen v0.33.1. Ingen egen installation och ingen egen mätning ligger bakom texten; samtliga tidsangivelser och minnesposter är utvecklarens egna, redovisade med de villkor som anges i commiten. Kontrollerat igen 19 september 2026: Ollama har sedan dess släppt v0.33.2 (27 augusti), v0.33.3 (2 september) och v0.34.0–v0.34.2 (5–15 september). Texten beskriver v0.33.1 och uppdateras inte för varje ny utgåva; kontrollerna av runner, format och Metal-laddning gäller även för senare versioner, men läs utgåvenoteringen för den version du kör.