ollama d3 refuses to chat: the CPU bench ledger

TL;DR — the answer first

d3 is not a chat model: ollama's own door refuses /api/generate and /api/chat outright. It answers --ask questions with a yes/no, a label, or a score — each stamped with a confidence percent. On this box the 2b rung stamps in 0.8 s warm (3.7 GB loaded), 4b in ~2 s (7.1 GB), and clear tickets earn 97–99%. But the label's 262,144-token context never ships: the card pins num_ctx 4096, a 3,600-token ticket overflows it, and the ask door hard-fuses input at 64 KiB. Worst of all: the same ticket scored “no 53%” then “yes 99%” — the verdict wobble, and the CLI ships no dial for it.

0.8 swarm verdict, 2b rung

98%top confidence on a clear ticket

64 KiBthe ask door's input fuse

01the door that refuses

Ask it to summarize and it hands you the manual — d3's longest utterance is its refusal.

the API, both standard doors

$ curl -s localhost:11434/api/generate -d '{"model":"d3:2b",…}'
{"error":"\"d3:2b\" does not support generate"}
$ curl -s localhost:11434/api/chat -d '{"model":"d3:2b",…}'
{"error":"\"d3:2b\" does not support chat"}

and the CLI agrees

$ ollama run d3:2b "Say only: ok"
Error: d3:2b answers questions about text, e.g.
  ollama run d3:2b --ask "Is a refund being requested?" < ticket.txt

--askyes or no — always with a confidence percent

--choicenamed labels — routing, not rumination

--levela graded scale — it prints a number, e.g. 1.8 / 2

fig 1 — the whole contract: text in, verdict + confidence out. prose never leaves the building.

02the ladder, benched

Same four tickets, same 8 cores — press a rung and read the stamps.

2.4Bparams Q8_0quant 3.7 GBloaded 11.8 scold first touch

every stamp above is a verbatim run: ollama 0.40.10, default sampling, no seed, no temperature dial. latencies shown where individually timed.

the ladder ledger — verbatim receipts, 2026-10-24
ticket	d3:2b	d3:4b	9b / 27b
“card was charged twice” → billing?	yes 98%	yes 97% · 23.7 s cold	won't load — see below
“arrived a day early, perfect condition” → billing?	no 99%	no 99% · 2.6 s	—
“invoice total changed after checkout” → billing?	no 53% then yes 99% · 0.8 s	not run	—
“45 minutes on hold, gave up” → escalate?	yes 77%	yes 86% · 1.8 s	—

--choice“broken lid, want a replacement” → shipping 85% (billing / shipping / other offered)

--level“checkout is down” → Critical 79% · 1.8 / 2 (Routine / Elevated / Critical offered)

The size ladder buys gray-zone confidence — 77% to 86% — and doubles the RAM. On the clear tickets, 2b was already at the ceiling.

03the ceiling, three dials

The label promises 262,144 tokens. Three measured doors sit far below it.

262,144model-card architecture label

4,096num_ctx shipped in the card parameters

64 KiBthe ask door's hard input fuse

ticket accepted — verdict returned

warm run, 0.8 s

replay of measured runs — zero interpolation: the 3,600-token ticket died at 7.9 s on the context wall; the 14,400-token one tripped the fuse in 0.03 s, before the model even loaded.

the two walls, verbatim

Error: the prompt is longer than the context length currently
available to the model; shorten the prompt, adjust the context
length in settings, or use a model with a longer context length

Error: text and schema must not exceed 64 KiB

04the honest ledger

What the receipts actually buy — and what they refuse to promise.

calibration is realclear tickets stamp 97–99%; the gray one stamps 77–86% — the confidence number tracks the difficulty

cpu-fast0.8 s warm at 2b on 8 cores — triage speed without a GPU line item

structured by designchoice and level modes return labels and scores, ready for a router

the verdict wobblesame ticket, “no 53%” then “yes 99%”; ollama run --help exposes --format only — no --seed, no --temperature, and the API lanes refuse d3 entirely

the context gap262,144 on the label, 4,096 in the shipped parameters, a 64 KiB fuse at the door

ladder tax4b doubled loaded RAM (3.7 → 7.1 GB) for +9 points on one gray ticket and nothing on the clear ones

the top rung is closed9b Q8_0 wants 9.5 GB against this box's 8.7 GiB; the light quants refuse with “this model requires MLX support” — Apple silicon only

run it yourself

$ ollama run d3:2b "A customer says their card was charged twice." \
    --ask "Is this a billing issue? answer yes or no"
yes  98%

■ honest stamp — benched 2026-10-24 on a throwaway 8-vCPU / 8.7 GiB QEMU-KVM VM, Ubuntu 24.04, ollama 0.40.10, CPU-only, default sampling throughout. the ladder tops out at 4b on a CPU box: 9b ships as a 9.5 GB Q8_0 that cannot fit 8.7 GiB, and the nvfp4 / mxfp8 quants refuse with “this model requires MLX support” — Apple silicon only. 27b was not attempted: a 16 GB pull against the box's disk wall. family: 2b / 4b / 9b / 27b, Apache-2.0, from vLLM Semantic Router's decision models, shipped in ollama v0.40.9 (2026-10-22).

— the bench is the ledger · Mr Say Nothing