LOCAL LLM FIELD GUIDE

EXL3 คือรหัส trellis ของ ExLlamaV3 ที่ตั้งค่าเฉลี่ยบิตต่อน้ำหนัก

EXL3 เป็นฟอร์แมต quantization ของไลบรารี ExLlamaV3 โดย turboderp เอกสารของโปรเจกต์เรียกมันว่าสายที่ทำให้ QTIP จาก Cornell RelaxML ใช้บนการ์ดผู้ใช้ได้ QTIP เป็นงาน NeurIPS 2024 แบบ Spotlight ชื่อ Quantization with Trellises and Incoherence Processing ตัวแปลงรับค่าเฉลี่ยบิตต่อน้ำหนักเป็นเลขทศนิยม แล้วแจกความกว้างเป็นจำนวนเต็มให้แต่ละเทนเซอร์ รันไทม์จะถอดรหัสนี้ได้ก็ต่อเมื่อมีเคอร์เนล EXL3 ของตัวเอง

TRELLIS WEIGHTS

ค่าเฉลี่ยบิตกับรหัส trellis เป็นคนละชั้น

QTIP: trellis หลัง Hadamard จาก Cornell
mul1: codebook ค่าเริ่มของตัวแปลง EXL3
ค่าเฉลี่ย: เช่น 2.90 แล้วแจกเป็นจำนวนเต็มต่อเทนเซอร์

แผนภาพสรุปสรุปกลไกสำหรับใช้เทียบกับค่าใน calculator

ใช้กับงานจริง

อ่านแพ็ก EXL3 ก่อนเลือกเครื่อง

เริ่มจากค่าเฉลี่ยบิตที่การ์ดประกาศ แล้วเปิดรายการความกว้างรายเทนเซอร์กับชิ้นที่ไม่ได้ถูก quantization

จากนั้นค่อยดูว่าเอนจินในมือมีเคอร์เนลของฟอร์แมตนี้หรือต้องใช้สูตรที่ปักอิมเมจไว้

คำถาม	ดูตรงไหน	หลักที่หน้านี้ใช้
ค่า bpw คืออะไร	ค่าเฉลี่ยหลังจัดสรร เป็นจำนวนเต็มต่อเทนเซอร์	2.90 บนการ์ด Mia ไม่ได้แปลว่าทุกน้ำหนักเป็น 2.9 บิต
codebook ไหน	ค่าเริ่มของตัวแปลงคือ mul1	mcg และ 3inst มีไว้ทดสอบ ตามเอกสารแปลง
ไฟล์ใหญ่กว่าที่คาด	embed เริ่มที่ 16 บิต และ lm_head เริ่มที่ 6 บิต	ตาราง Engram ของ DeepSeek อยู่นอกแพ็ก
จะใส่ vLLM ตรงๆ	ตรวจว่าอิมเมจมีเคอร์เนล EXL3	ล้อสต็อกของ vLLM และ SGLang โหลดฟอร์แมตนี้ไม่ได้
สองสปาร์กจะพอไหม	เทียบ 475.251 GiB ของต้นฉบับกับ 196 GiB ของแพ็ก	256 GB รวมของสองเครื่องใส่ต้นฉบับทั้งก้อนไม่ได้

ก่อนเชื่อคำว่าบิตต่ำแล้วยังชัด

จดชื่อ codebook และค่า --bits ที่ใช้แปลง
แยกค่าเฉลี่ยทั้งก้อนออกจากความกว้างของ attention, expert, หัว และ embedding
ตรวจว่าเอนจินเป็น ExLlamaV3, อิมเมจชุมชน, หรือ fork ที่สูตรปักไว้
ถ้าเป็น DeepSeek ให้หาที่เก็บตาราง Engram คนละที่กับแพ็ก EXL3
วัด KL หรือภาระงานจริงบนพรอมต์ของตัวเอง อย่าใช้คะแนนต้นฉบับแทนแพ็ก quantization

รูปธงแปลงจากเอกสาร ExLlamaV3

bits = 2.90
codebook = mul1
head_bits = 6
embed_bits = 16
hq = on
mtp_bits = 4

QTIP ให้อะไรกับรหัสนี้

QTIP บีบน้ำหนักหลังฝึกเสร็จด้วย trellis coded quantization แทน vector quantization แบบที่ codebook โตตามมิติแบบทวีคูณ โครงสร้างที่งาน QTIP ใช้ถอดแบบขนานได้คือ bitshift trellis ค่าที่ถอดออกมาคำนวณจากสถานะของ trellis ได้โดยไม่ต้องเปิดตารางใหญ่ทั้งก้อน งาน QTIP เรียกชุดคำนวณนี้ว่า computed code และยกตัวอย่าง 1MAD กับ 3INST

ก่อนเข้าตัวเข้ารหัส งานนี้อาศัย incoherence processing ด้วย random Hadamard transform ซึ่งสืบจาก QuIP# เพื่อให้ค่าน้ำหนักกระจายใกล้ Gaussian มากกว่าที่จะเหลือ outlier ก้อนใหญ่บนช่องไม่กี่ช่อง การทดลอง lookup-free ในงาน QTIP ตั้งบล็อกเป็นตาราง 16×16 คือ 256 ค่า ต่อหนึ่งลำดับ trellis เพื่อให้เข้ากับไทล์คูณเมทริกซ์ 16×16 และใช้ tail-biting trellis เพื่อไม่ต้องเก็บสถานะตั้งต้นแยกต่างหาก เคอร์เนลแปลงของ EXL3 ก็คาดการเรียงไทล์ 16×16 ในไฟล์ quantize.py ของ ExLlamaV3

งาน QTIP วัดคุณภาพด้วย perplexity บน Llama เทียบกับ QuIP# และ AQLM ที่บิตเรต 2, 3 และ 4 ผลในตารางนั้นเข้าใกล้ต้นฉบับมากกว่าสองวิธีนั้นในชุดที่งาน QTIP รายงาน งาน QTIP ไม่ได้ตีพิมพ์ตารางเทียบ GGUF Q4 หรือ Q5 ดังนั้นหน้านี้ไม่สรุปว่า EXL3 ชนะ GGUF ทุกโมเดล

ตัวแปลง EXL3 ตั้งอะไรได้

สคริปต์ convert.py รับโมเดล Hugging Face ที่ยังไม่ quantization กับค่า -b หรือ --bits เป็นจำนวนบิตต่อน้ำหนักเป้าหมายแบบทศนิยม เอกสารแปลงระบุ codebook สามชื่อผ่าน --codebook คือ mul1 ซึ่งเป็นค่าเริ่ม mcg และ 3inst ข้อความในเอกสารบอกให้ใช้ mul1 เป็นหลัก เพราะเส้นทางที่ปรับแล้วบางเส้น เช่น int8 GEMV และ CPU expert offload ต้องการ mul1 และการเลือก codebook อื่นมีเหตุผลก็เมื่อกำลังทดสอบ

ธง -hq หรือ --hq ยกพื้นบิตของเลเยอร์ที่ตัวแปลงเลือกไว้ เช่น attention และ shared expert ขนาดไฟล์อาจสูงกว่าค่า --bits ที่ขอ เอกสารบอกว่าบนโมเดล MoE การเพิ่มนี้มักอยู่ในช่วง 0.05 ถึง 0.10 bpw ต่อครั้งที่คูณโปรโมชันตามค่าเริ่มของสถาปัตยกรรม -hq 2 จะคูณโปรโมชันนั้นเป็นสองเท่า

ค่าเริ่มอื่นที่ทำให้ไฟล์ใหญ่กว่าค่าเฉลี่ยของตัวถอดรหัส ได้แก่ --embed_bits ที่เริ่มที่ 16 คือเก็บตาราง embedding แบบไม่ quantization, --head_bits ของ lm_head ที่เริ่มที่ 6, --mtp_bits ที่เริ่มที่ 4 และ --vision_bits ที่เริ่มที่ 6 หรือ 16 ตามสถาปัตยกรรม เลเยอร์ vision และ MTP ถูก quantization โดยไม่มี calibration ตามเอกสารแปลง

เลข 2.9 bpw คือค่าเฉลี่ย ไม่ใช่ความกว้างของทุกเทนเซอร์

เมื่อการ์ดโมเดลเขียนว่า 2.9 bpw ความหมายในตัวแปลง EXL3 คือค่าเฉลี่ยหลังจัดสรรบิต ไม่ใช่รหัสลอยที่เก็บ 2.9 บิตในทุกน้ำหนัก การ์ด Mia-AiLab/DeepSeek-V4.1-Flash-1017-EXL3-EAQ-v1-2.9-bpw ระบุค่าเฉลี่ย 2.90 บนตัวถอดรหัส routed expert ส่วนใหญ่เป็น 3 บิต และเลเยอร์ 18 ถึง 22 อยู่ที่ 2 บิต attention อยู่ที่ 5 บิต shared expert อยู่ที่ 4 ถึง 5 บิต indexer wk อยู่ที่ 8 บิต หัวอยู่ที่ 6 บิต และเทนเซอร์ MTP กับ DSpark อยู่ที่ 4 บิต

การ์ดเดียวกันเรียกแพ็กนี้ว่า EAQ v1 และเขียนว่าฟอร์แมตไฟล์ยังเป็น EXL3 ธรรมดา quant_method เป็น exl3, codebook เป็น mul1, out_scales เป็น always กุญแจเทนเซอร์หลักและความกว้างรายเทนเซอร์ของตัวโมเดลหลักตรงกับแพ็ก EXL3 2.9 bpw มาตรฐานที่การ์ดเทียบไว้ สิ่งที่ EAQ v1 เปลี่ยนคือขั้นตอนแปลง บน exllamav3 v1.6.1 พร้อมชุดแพตช์ EAQ ตัวโหลดที่อ่าน EXL3 ของ DeepSeek-V4.1 อยู่แล้วจึงอ่านแพ็กนี้ได้โดยไม่ต้องมีโค้ดเฉพาะ EAQ

การ์ดรายงาน KL แบบ teacher-forced ต่อน้ำหนักต้นฉบับรีวิชัน 1bae0e10 ในพอร์ตประเมินของตัวเอง บนบทสนทนาสั้น 100 ชุด ได้ KL 0.0137 nats และ top-1 ตรงกัน 96.6 เปอร์เซ็นต์ จากโทเคนผู้ช่วยที่นับ 89,880 โทเคน ช่วงความเชื่อมั่นและตารางรายงานอยู่ในหน้าการ์ด การวัดนี้ไม่ใช่การสร้างคำตอบอิสระ ไม่ได้วัดคุณภาพภาพ ไม่ได้วัด DSpark และไม่ได้วัดบริบทยาวกว่าเซสชันที่ยาวสุดในการ์ดที่ 31.2k โทเคน

รันได้บนสแตกไหน

เส้นทางที่เอกสาร ExLlamaV3 ระบุตรงๆ คือไลบรารีเอง และเซิร์ฟเวอร์ที่โปรเจกต์แนะนำคือ TabbyAPI ซึ่งเปิด API แบบ OpenAI ทางติดตั้งที่เผยแพร่คือ PyTorch บน CUDA 12.4 ขึ้นไป หน้านี้ไม่พบเคอร์เนล EXL3 สำหรับ AMD ในเอกสารติดตั้งนั้น

สต็อก vLLM และสต็อก SGLang ไม่ได้โหลดไฟล์ EXL3 เป็นฟอร์แมตในตัว อิมเมจชุมชนที่พอร์ตเคอร์เนลมาจึงเป็นคนละเส้นกับล้อมาตรฐาน TensorFold ระบุในตารางโมเดลของรีลีสว่า GLM-5.3-Flash แบบ EXL3/TR3 เป็นเช็กพอยต์ทดลองบน CUDA สองแรงก์ ส่วน DeepSeek ไม่อยู่ในตารางที่ไบนารีรีลีสรองรับ สูตร 2 สปาร์กด้านล่างจึงปักเอนจินคนละกิ่ง

คุณภาพยังผูกกับ calibration เอกสารแปลงใช้คลังตัวอย่างที่มากับโปรแกรมเป็นค่าเริ่ม หรือรับไฟล์ --cal_data ที่เป็นแถวโทเคนจากร่องรอยงานจริง การมีร่องรอยที่ใกล้ภาระงานเป็นตัวเลือกของตัวแปลง ไม่ได้รับประกันคะแนนงานปลายทาง ต้องวัดบนพรอมต์ที่จะใช้จริง

ทำไมแพ็ก 2.9 bpw ถึงถูกใช้บน 2 DGX Spark

ต้นไม้ไฟล์ทางการของ DeepSeek-V4.1-Flash-1017 ที่เครื่องคิดเลขนี้ตรวจเมื่อ 2026-10-19 มี safetensors 48 ไฟล์รวม 510,296,708,312 ไบต์ หรือ 475.251 GiB สปาร์กสองเครื่องเครื่องละ 128 GB มีหน่วยความจำรวม 256 GB จึงใส่ต้นไม้ทั้งก้อนแบบ resident ไม่ได้ ถ้าหักตาราง Engram สองชาร์ดที่วัดได้ 189.127 GiB ออกไป ส่วนที่เหลือยังราว 286 GiB ซึ่งก็ยังเกิน 256 GB สามเครื่องรวม 384 GB จึงพอวางส่วนที่เหลือเมื่อตาราง Engram อยู่บนดิสก์ และสี่เครื่องรวม 512 GB จึงพอวางทั้งก้อนแบบ resident ตัวเลขชุดนี้เป็นเลขคณิตจากขนาดไฟล์ที่วัดแล้ว ไม่ใช่ผลเบนช์ของสูตร 3 หรือ 4 เครื่อง

สูตร MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-DGX-Sparks ใช้แพ็ก EXL3 196 GiB ข้างต้น วางน้ำหนักราว 98 GiB ต่อสปาร์ก ผ่าน TensorFold สาย Zig 0.17.0 ของครอบครัว dsv41 จาก BertholomusAI ที่ TP เท่ากับ 2 หนึ่งแรงก์ต่อเครื่อง สายเชื่อมคือพอร์ต ConnectX-7 แบบ RoCE v2 หน้าต่างที่ประกาศคือ 1,048,576 โทเคน พร้อมภาพเข้า เครื่องมือ thinking และ DSpark จากบล็อกดราฟต์ในเช็กพอยต์ บนหัวเครื่องที่มีโปรแกรมอื่น README บอกว่าเพดานใช้งานจริงของ CONTEXT มักอยู่ที่ 524288

ตาราง Engram ไม่ได้อยู่ในแพ็ก quantization ต้องใช้ชาร์ด 47 และ 48 ของต้นฉบับรีวิชันเดียวกัน การ์ดระบุไฟล์ละประมาณ 95 GiB README ของสูตรบอกว่าต้องวางตารางนี้บนดิสก์ท้องถิ่นของทั้งสองเครื่อง ถ้าอ่านข้าม NFS ความเร็ว prefill ในรายงานนั้นตกไปราว 690 ถึง 890 tok/s

ตัวเลข tok/s ของสูตรนี้อ่านพร้อมเงื่อนไข

README ของสูตรรายงานจาก sparkDash บนคู่สปาร์กหนึ่งคู่ การ์ดจอทั้งสองล็อกเพดาน 2,200 MHz เซิร์ฟเวอร์ตั้ง CONTEXT ไว้ 524288 ดราฟต์เปิดอยู่ หัวเครื่องยังเปิดเดสก์ท็อปและคอนเทนเนอร์เล็กประมาณ 18 ตัว ส่วนเครื่องลูกว่างกว่านั้น ที่หนึ่งสตรีม ร้อยแก้วอุณหภูมิ 0 และปิด thinking ได้ 80.7 tok/s โดย TTFT 133 ms ร้อยแก้วอุณหภูมิ 0.7 และเปิด thinking ได้ 63.9 tok/s โดย TTFT 214 ms โค้ดอุณหภูมิ 0 และปิด thinking ได้ 118.1 tok/s โดย TTFT 213 ms

prefill ในตารางเดียวกันอยู่ใกล้ 2,100 tok/s ตั้งแต่พรอมต์ราว 4K ถึงราว 256K เมื่อตาราง Engram อยู่บนดิสก์ท้องถิ่นทั้งสองเครื่อง จุด 4,114 โทเคนวัดได้ 2,105.9 tok/s และจุด 262,163 โทเคนวัดได้ 2,065.0 tok/s

ข้อควรระวัง ตัวเลขทั้งชุดเป็นรายงานของคู่เครื่องและเงื่อนไขข้างต้น ไม่ใช่ค่า tok/s ที่เครื่องคิดเลข llm-cal คำนวณจาก roofline และไม่ควรยกไปเทียบกับรันคนละนาฬิกา คนละความยาวบริบท หรือคนละสถานะดราฟต์

คำถามที่พบบ่อย

EXL3 กับ GGUF ใช้แทนกันได้ไหม

ใช้แทนกันไม่ได้ EXL3 เป็นฟอร์แมตน้ำหนักของ ExLlamaV3 ที่เข้ารหัสแบบ trellis หลังหมุน Hadamard และตั้งเป้าค่าเฉลี่ยบิตได้เป็นทศนิยม GGUF เป็นภาชนะของ llama.cpp ที่มีระดับอย่าง Q4_K_M อยู่ข้างใน คนละเคอร์เนล ต้องเทียบบนโมเดลเดียวกันด้วยตัวเลขที่มีแหล่ง

เลข 2.9 bpw หมายถึงทุกน้ำหนักใช้ 2.9 บิตหรือไม่

ไม่ใช่ เลข 2.90 บนแพ็ก Mia เป็นค่าเฉลี่ยของตัวถอดรหัส ในการ์ดนั้น expert ส่วนใหญ่เป็น 3 บิต บางเลเยอร์เป็น 2 บิต attention เป็น 5 บิต และหัวเป็น 6 บิต ตาราง embedding กับตาราง Engram อยู่ที่ความละเอียดสูงกว่าและไม่ได้นับในค่าเฉลี่ยนี้

แหล่งอ้างอิง

ลองกับ configuration ของคุณ

นำ model, quantization, context, framework และ hardware ที่คิดไว้ไปลองใน calculator จากนั้นยืนยันด้วย benchmark ที่ใกล้ production

เปิดเครื่องคำนวณ