Twitter/X

Used Qwen3.6-27B-MTP-GGUF on four 64×64 images

2026-06-28 · 14:34 UTC ·@ivanfioravanti ·0 min read

Brief

@ivanfioravanti (2026-06-28) previews experiments with Qwen3.6-27B-MTP-GGUF on four 64×64 images (three plain, one MTP), claims “An image is worth 16x16 words,” and says DGX Spark excels at prefill but is too slow at decode. They emphasize real-life use sends smaller chunks cached on SSD and are working to enable flawless 128K context on M5 Max and DGX Spark with llamacpp.

Why it matters

Used Qwen3.6-27B-MTP-GGUF on four 64×64 images: three processed plain and one with MTP, encapsulated by the claim “An image is worth 16x16 words.”

Key details

  • DGX Spark is described as the “prefill king” but “too slow” on decode for the author’s workflow; they warn prefill speed can mislead because real coding sessions send smaller chunks, not full 128K-token loads, relying on SSD cache.
  • Author @ivanfioravanti (published 2026-06-28 14:34:17+00:00) is previewing results while debugging 128K-context support on M5 Max and DGX Spark using llamacpp.
Source evidence

An image is worth 16x16 words.
Four image 64x64
All that glitters is not gold 🏅
Qwen3.6-27B-MTP-GGUF model 3 images plain, 1 MTP find it.

DGX Spark is the prefill king, but on decode is too slow, at least for me. And don't be fooled by prefill, in real life you don't load 128K tokens while coding, you send smaller chunks that are processed and stored on SSD cache. This leads to a good interaction overall.

Consider this a preview of the results, while I fight to get 128K context working flawlessly on M5 Max and DGX Spark with llamacpp.