halogen 0.12.0: เอนจินที่เขียนเคอร์เนลให้ GPU ตัวเดียวและโมเดลตระกูลเดียว — prefill พรอมต์ 1 ล้านโทเคนบน Strix Halo เหลือ 17.9 นาที จาก 21.2 นาที

19 ก.ย. 2026 โปรเจกต์ peonist-ai/halogen-flash-server ออกเวอร์ชัน 0.12.0 — และมันน่าสนใจเพราะมันเลือกทำสิ่งที่ตรงข้ามกับเอนจินทุกตัวที่เรารู้จัก README เปิดหัวไว้แบบไม่อ้อมค้อม:

“Every kernel is written for this one GPU and this one model family. No general-purpose runtime, no portability layer, no fallback path.”

GPU ตัวเดียวนั้นคือ AMD Strix Halo (gfx1151) — ชิป Ryzen AI Max ที่มีหน่วยความจำรวม 128 GB และโมเดลตระกูลเดียวนั้นคือ Qwen3.8-Flash-Next ไม่มีเส้นทางสำรอง ไม่มี CUDA ไม่มี fallback ไปที่ CPU ถ้าคุณไม่มีเครื่องรุ่นนั้น โปรเจกต์นี้ไม่มีอะไรให้คุณเลย

คำถามคือ การยอมทิ้ง portability ทั้งหมดแลกมาได้เท่าไร

ตัวเลขที่เขาเอามาวางไว้หน้า README

บนพรอมต์ 32K + คำตอบ 256 โทเคน เทียบกับตัวเลขที่ทีมอื่นเผยแพร่ไว้บนฮาร์ดแวร์เดียวกัน:

	ความละเอียด	prefill	decode	รวม
halogen-flash 0.5.3	5.53 bpw	23.0 s	6.1 s	29.1 s
EngramHalo.cpp	3.71 bpw	103.7 s	14.3 s	118.0 s
ROCmFP4	5.51 bpw	104.7 s	13.2 s	117.9 s
CIRU-IU4	5.96 bpw	143.7 s	11.0 s	154.7 s

ประมาณ 4 เท่า end-to-end และที่ควรสังเกตคือ มันไม่ได้ชนะด้วยการตัดบิตทิ้ง — ตัวที่เร็วรองลงมาในสามเจ้านั้นรันที่ 3.71 bpw ซึ่งต่ำกว่า halogen สองในสาม

README เองก็เขียนกำกับว่าคอลัมน์ decode เป็น “the soft one” เพราะไม่รู้ว่าคู่เทียบสองในสามเปิด speculative decoding หรือไม่ และบอกด้วยว่าถ้าให้แต้มต่อคู่แข่งเต็มที่ ตัวเลขรวมก็ยังตกราว 110 s เทียบกับ 31.1 s ของตัวเอง — การเขียนแบบนี้ (ระบุว่าตัวเลขไหนเชื่อได้น้อยกว่า ก่อนที่จะมีคนมาจับผิด) เป็นสิ่งที่หายากในหน้าเบนช์มาร์กของโปรเจกต์ inference

bits-per-weight ก็วัดจากตารางเทนเซอร์ของ checkpoint เอง ไม่ได้อ้างจากชื่อฟอร์แมต — 5.53 bpw ทั่วทั้ง 179.55B พารามิเตอร์ หรือ 4.55 bpw ถ้าไม่นับตาราง n-gram lookup แบบ FP8

0.12.0 แก้อะไร: เคอร์เนลสองตัวของ indexer

เวอร์ชันนี้ไม่แตะน้ำหนัก ไม่เพิ่มการตั้งค่า เปลี่ยนแค่สองเคอร์เนลใน sparse-attention indexer และ changelog ยืนยันว่าเอาต์พุตเหมือนเดิมระดับบิต — block list และ score ถูกเทียบบิตต่อบิตที่ 32k, 262k และ 1M, logits ของ prefill 32,768 โทเคนเท่ากันเป๊ะ

สิ่งที่พังอยู่คือ:

1. decode ที่คอนเท็กซ์ยาวเสียเวลาไปกับการ “เลือก” บล็อก ไม่ใช่การให้คะแนน — indexer ให้คะแนนทุกบล็อก 4 โทเคนแล้วเก็บ top 512 แต่ขั้นตอนเลือกรันเป็น workgroup เดียวต่อ query row ซึ่งตอน prefill มองไม่เห็นเพราะขนานกันเป็นพัน แต่ตอน decode คือ 22 ms จาก step 53 ms ที่ 1M รอบนี้เปลี่ยนเป็น bisection ที่อยู่ใน register กระจายทั้ง GPU ได้ผลลัพธ์เดิมทุกประการ: serial decode 18.9 → 32.1 tok/s ที่ 1M และเมื่อเปิด draft head 27.2 → 41.7
2. prefill ที่ 1M จ่ายค่า indexer สองรอบ — เคอร์เนลให้คะแนนอ่าน key set ใหม่ทุก 16 query rows ตอนนี้เก็บ 128 block keys ไว้ใน register แล้วเดิน query row แทน: prefill 1,044,480 โทเคน 1,191 → 994 วินาที (877 → 1,051 tok/s)

ผลที่ผู้ใช้เห็นจริงผ่าน container: พรอมต์ 1,004,581 โทเคน prefill 17.9 นาที (937 tok/s, cold) decode 38 tok/s — ขณะที่ 0.11.10 ใช้ 21.2 นาทีและ decode 27 และเวอร์ชัน 0.2.0 เคยอยู่ที่ 22–24 นาที decode 19

และรายละเอียดที่คนทำ agent ควรอ่าน: เทิร์นถัดไปไม่ต้อง prefill ใหม่ — prompt cache เก็บ attention state ไว้กับที่ ทำให้คำถามต่อเนื่องที่คอนเท็กซ์ 1,000,000 โทเคนได้โทเคนแรกใน 0.55 วินาที

ค่าใช้จ่ายของ 1M ที่เขียนไว้ครบ

คอนเท็กซ์ 1M ไม่ได้เปิดมาให้โดยอัตโนมัติ ต้องสั่ง HALOGEN_ROPE_YARN=4 HALOGEN_CTX=1048576 และ README ระบุว่ามันคือ “a different model configuration, not a cache setting” เพราะ RoPE ทุกตำแหน่งถูก rescale รวมถึงพรอมต์สั้นด้วย ราคาที่ต้องจ่าย:

• คุณภาพที่ 1k–32k: perplexity เพิ่ม 0.4–0.6% และชุดทดสอบ retrieval 240 เคสได้ 236/240 เทียบกับ 238/240 ตอนไม่ scale
• speculative decode ที่ 8k–30k รับ draft น้อยลง 5–15 จุด ช้าลงราว 10%
• เหนือ 32k — needle retrieval สามเข็มสามตำแหน่ง: 9/9 ทั้งที่ 262,144 (scale และไม่ scale) และ 9/9 ที่ 1,000,000
• หน่วยความจำ: KV cache 1M กิน ~25 GB ซึ่งบนเครื่อง 128 GB ไม่เหลือที่ให้ prefill arena ปกติ เซิร์ฟเวอร์จึงบีบ HALOGEN_MAX_TOK เหลือ 16384 เอง (prefill ช้าลงราว 9%) และพิมพ์บอก

ตั้งแต่ 0.7.0 เอนจินเปิด GGUF ของ llama.cpp ได้ตรง ๆ — ชี้ไปที่ไฟล์ UD-IQ4_XS ของ unsloth ที่คุณมีอยู่แล้วก็รันบนเคอร์เนลชุดนี้ได้ ไม่ต้องแปลง และ 0.11.10 เพิ่งเพิ่มการอ่านไฟล์ที่เทนเซอร์เล็กเป็น F16 (ของ bartowski และ orcarouter) ซึ่งก่อนหน้านี้ถูกปฏิเสธทั้งไฟล์เพราะเทนเซอร์เดียว

เรื่องที่ต้องพูดก่อนจะ podman run

halogen ไม่ใช่โอเพนซอร์ส รีโปมีแค่เอกสาร ตัวเอนจินมาเป็น container image ที่บรรจุไบนารีคอมไพล์แล้ว และอยู่ใต้ EULA ของ Peonist, LLC (เวอร์ชัน 0.1 มีผล 25 ส.ค. 2026) GitHub เองจัดใบอนุญาตนี้เป็น NOASSERTION

เงื่อนไขที่ให้จริง ๆ กว้างกว่าที่คำว่า “EULA” ทำให้กลัว: ใช้เชิงพาณิชย์และ production ได้ ไม่จำกัดจำนวนเครื่อง ไม่มี license key ไม่มีค่าธรรมเนียม และ redistribute image ที่ไม่แก้ไขได้ สิ่งที่ห้ามคือ แจก image ที่ดัดแปลงแล้วให้คนอื่น แก้สำเนาของตัวเองใช้เองได้ ที่น่าชมคือส่วน reverse engineering เขียนไว้ตรงไปตรงมาว่า “We do not prohibit it, and we would rather say so plainly than pretend otherwise” เพราะใครมี disassembler ก็อ่านเคอร์เนล gfx1151 ได้อยู่ดี

และ น้ำหนักโมเดลไม่ได้อยู่ในนั้น — EULA ระบุชัดว่าไม่ครอบคลุมน้ำหนัก ต้องไปตามเงื่อนไขของเจ้าของโมเดลเอง (checkpoint 118 GiB ดาวน์โหลดตอนสตาร์ตครั้งแรก)

มุมมอง AI Curator

สิ่งที่ halogen พิสูจน์ไม่ใช่ว่า AMD เร็วกว่าที่คิด แต่คือ ต้นทุนที่ซ่อนอยู่ใน “ความยืดหยุ่น” ของเอนจินทั่วไปนั้นสูงกว่าที่เราเคยยอมรับกัน llama.cpp รันได้ทุกที่ vLLM รองรับทุกโมเดล และนั่นคือเหตุผลที่มันดี — แต่พอมีคนยอมเขียนเคอร์เนลให้ชิปตัวเดียวกับโมเดลตระกูลเดียว ช่องว่างที่โผล่ออกมาคือระดับ 4 เท่า ไม่ใช่ 20% นี่เป็นเรื่องเดียวกับที่เกิดกับ Apple MLX บน Mac และกับ TensorRT-LLM บน NVIDIA เพียงแต่ครั้งนี้มันมาจากโปรเจกต์ที่มีดาวไม่ถึงหกร้อยดวง

ส่วนที่ผมคิดว่าสำคัญกว่าสำหรับคนไทยและ SEA คือเรื่อง ฮาร์ดแวร์ที่ซื้อได้จริง Strix Halo คือมินิพีซีราคาหลักแสนต้น ๆ ไม่ใช่ H100 และการที่พรอมต์หนึ่งล้านโทเคนรันบนมันได้ในเวลา 18 นาทีโดยไม่ต้องส่งข้อมูลออกนอกประเทศ เป็นความสามารถที่เมื่อหกเดือนก่อนยังต้องเช่าคลาวด์ สำหรับงานที่แตะข้อมูลอ่อนไหว — เวชระเบียน สัญญา เอกสารราชการ — สมการนี้เปลี่ยนไปแล้ว

แต่ผมจะไม่แนะนำให้ใครสร้างระบบ production ทับ halogen ตอนนี้ ด้วยเหตุผลเดียว: มันเป็นไบนารีปิด ของบริษัทเดียว บนชิปเดียว ถ้าวันหนึ่ง Peonist หยุดทำ คุณไม่มีทางแพตช์เอง ไม่มีทาง fork ค่าที่ต้องจ่ายสำหรับ 4 เท่านั้นคือความเสี่ยงแบบเดียวกับที่ระบบนิเวศโมเดลเปิดพยายามหนีออกมาตลอด ใช้มันเป็นเครื่องมือวัดว่า “เครื่องนี้ทำได้เร็วแค่ไหนถ้าเขียนโค้ดให้มันจริง ๆ” ได้เต็มที่ — แต่ถ้าเดิมพันคือระบบที่ต้องอยู่ไปอีกสามปี llama.cpp ที่ช้ากว่าสี่เท่าแต่คุณ fork ได้ ยังเป็นคำตอบที่ถูกกว่า

แหล่งข่าว

• peonist-ai/halogen-flash-server — README และตารางเปรียบเทียบ
• CHANGELOG 0.12.0 — รายละเอียดเคอร์เนล indexer ที่ถูกรื้อ
• LICENSE.md — EULA ของ Peonist, LLC เวอร์ชัน 0.1
• peonist-ai/halogen-qwen3.8-flash-next — checkpoint บน Hugging Face