halogen-flash-server è un engine di inferenza HIP scritto da Peonist per un solo modello e un solo GPU: Qwen3.8-Flash-Next su AMD Strix Halo (gfx1151). Non è un fork di llama.cpp, non ha un layer di portabilità e non accetta altre architetture. L'immagine corrente è 0.5.6; i pesi dedicati in formato .hgn pesano 118 GiB e l'endpoint OpenAI-compatibile sale sulla porta 8731.
Il motivo per cui esiste è numerico. Su un prompt da 32.768 token e una risposta da 256 token, Peonist pubblica prefill a 1.424 tok/s (23,0 s) e decode speculativo a 41,7 tok/s medi (6,1 s), per un totale di 29,1 s. Nelle stesse condizioni i numeri pubblicati da EngramHalo.cpp, ROCmFP4 e CIRU-IU4 stanno tra 118 s e 155 s. Il vantaggio è nel prefill, che su un contesto reale è quasi tutto il wall-clock: 2,9× a 8K, 4,5× a 32K, 6,9× a 131K rispetto al miglior fork dichiarato.
Cosa gira davvero sul silicio
Qwen3.8-Flash-Next è il checkpoint open-weight del 26 agosto 2026: MoE multimodale da 125B parametri con 6B attivi per token, più una tabella n-gram da 51B e un blocco MTP da 4B. Contesto nativo 262.144 token, estendibile a 1.000.000 con YaRN. L'API ospitata si chiama Qwen3.8-Flash e parte già a 1M; le pesi scaricabili restano a 262K finché non abiliti l'estensione. Su Strix Halo il BF16 (335 GiB) e l'FP8 (173 GiB) non entrano nei 124 GB di memoria unificata. Halogen serve un base 4-bit più un sidecar di qualità da 2,31 GiB: precisione misurata 5,53 bpw su tutti i parametri, 4,55 bpw se si mette da parte la tabella n-gram in FP8. I 4 bit, qui, non sono un'ottimizzazione: sono la condizione per far stare il modello in macchina.
L'engine è closed-source. Il repository GitHub pubblica wrapper, flag, compose e documentazione; il binario HIP arriva solo come container. La EULA Peonist consente l'uso, anche commerciale, ma non la modifica né la redistribuzione di immagini alterate.
Auto non è 8K, e non è 262K
Nei client — Unsloth Desktop, LM Studio, Open WebUI, molti frontend sopra llama.cpp — la voce Auto sulla finestra di contesto non legge i 262.144 token nativi del modello. Prende un default del programma o i metadati del GGUF. Nella pratica è spesso 4096 o 8192. Se la UI mostra 8K, è il client che ha scelto 8K, non Qwen che «è» 8K.
Halogen separa due manopole. HALOGEN_CTX (default 262.144) è il massimo che una singola richiesta può occupare. HALOGEN_MAX_TOK (default 32.768) è la larghezza del chunk di prefill. HALOGEN_KV_POOL_POSITIONS (default 524.288) è il pool condiviso: due conversazioni a contesto pieno, fino a quattro generate in parallelo. Il 1M è opt-in e cambia il layout di memoria: su una macchina da 128 GB il server taglia il prefill a 16.384 token e un prompt da un milione richiede 22–24 minuti di prefill.
Chi confronta «Auto» con i 41 tok/s di Halogen a 32K sta confrontando due budget di contesto diversi.
Perché l'MTP di Unsloth qui rende poco
Unsloth documenta MTP su Qwen3.8-Flash con un guadagno di 1,3–1,7× e un esempio a 170 tok/s su una RTX 6000 PRO rispetto a una baseline a 100. Quel percorso è maturo su CUDA.
Su gfx1151 la situazione è diversa. Il supporto nativo a Gated DeltaNet, QSA, tabella n-gram e testa NextN in llama.cpp è arrivato a pezzi, con PR ancora aperti o fusi da pochi giorni. Sopra quel basamento sono nati fork e quant custom: EngramHalo.cpp, CIRU-IU4, ROCmFP4, stack «Vitronia», sidecar MTP Q8. L'MTP c'è, ma l'acceptance e i kernel ROCm/Vulkan non regalano lo stesso multiplo visto su NVIDIA. È un'osservazione coerente con quello che misura chi gira il modello in casa: l'MTP «ufficiale» Unsloth, da solo, non sposta l'ago.
Halogen implementa la speculation dentro l'engine, non come sidecar GGUF. A contesto 32.768 il decode seriale greedy è 34,1 tok/s; quello servito con MTP è 41,7 tok/s medi su dieci prompt reali. A temperatura 0 l'output è dichiarato byte-identico al greedy: la speculation è solo velocità, non un compromesso di qualità. Il prompt cache di default rende un follow-up a 100K token dell'ordine di 2 s, non un secondo prefill da 23 s.
Come si avvia e cosa non fa
Il percorso minimo è un container Podman (o Docker, con video e render al posto di keep-groups):
podman run --rm -p 8731:8731
--device /dev/kfd --device /dev/dri --group-add keep-groups
--security-opt seccomp=unconfined --ipc=host --ulimit memlock=-1:-1
-e HALOGEN_DOWNLOAD=peonist-ai/halogen-qwen3.8-flash-next
-v ~/halogen-models:/models
ghcr.io/peonist-ai/halogen-flash-server:0.5.6
I pesi si possono scaricare prima con hf download peonist-ai/halogen-qwen3.8-flash-next. Esistono /v1/chat/completions, /v1/responses (quindi Codex CLI con wire_api = "responses"), tool call e input immagine. Non genera immagini, non accetta audio o video, non tiene uno store di previous_response_id. Quattro conversazioni, non quaranta.
La qualità dichiarata sul tratto 1K–32K è 148/150 needle-in-a-haystack e 182/192 passi allineati a Transformers BF16 su sei prompt. Oltre i 32K il contesto è servito ma non è lo stesso set di test.
Halogen non è la scelta giusta se ti serve un runtime portabile, un GGUF scambiabile o una GPU che non sia gfx1151. Lo è se hai uno Strix Halo da 128 GB e vuoi il numero di prefill più alto pubblicato oggi su questo modello, senza scendere a 3,71 bpw per comprare velocità. Fonti: repository halogen-flash-server, pesi .hgn, model card Qwen3.8-Flash-Next.
Testo: assistito da AI · revisionato da Carlos H. P. Ross
