Guides & Insights

การอธิบาย Quantization ที่คำนึงถึงความไว (Sensitivity-Aware Quantization): OrcaSAQ ตัดสินใจอย่างไรว่าน้ำหนักชุดใดควรได้รับบิตมากขึ้น

ผู้เขียน

Alistair Wren

วันที่เผยแพร่

Aug 28, 2026

โมเดลล่าสุด · 20ดูโมเดลทั้งหมด →

เบนช์มาร์ก: Artificial Analysis · อัปเดตทุกวัน

กลับไปยังโพสต์ทั้งหมด

การควอนไทซ์แบบคำนึงถึงความไวคือแนวปฏิบัติในการจัดสรรงบประมาณบิตให้กับจุดที่สำคัญ: เทนเซอร์ที่การควอนไทซ์ส่งผลกระทบมากที่สุดจะได้รับบิตเพิ่มขึ้น ในขณะที่ส่วนอื่นๆ ยังคงใช้ความกว้างบิตฐานที่ต่ำกว่า บทความนี้อธิบายว่า OrcaSAQ — วิธีการผสมความแม่นยำแบบไม่ต้องปรับเทียบและคำนึงถึงสถาปัตยกรรมของเรา ซึ่งเผยแพร่พร้อมกับGLM-5.3-Flashตระกูลควอนไทซ์orcarouter/GLM-5.3-Flash-MLX— ตัดสินใจว่าเทนเซอร์ใดใน 37,338 เทนเซอร์ของโมเดล Mixture-of-Experts ที่มีพารามิเตอร์ 320 พันล้านตัวสมควรได้รับบิตพิเศษ โดยไม่ต้องใช้ชุดข้อมูลปรับเทียบเลย บทเรียนที่ถ่ายโอนได้สำหรับผู้ที่ควอนไทซ์ MoE ที่ต่างกัน: ผู้เชี่ยวชาญที่ใช้ร่วมกันและ down-projections สมควรได้รับบิตพิเศษ และคุณสามารถค้นหาได้โดยใช้เพียงเมตาดาตาการควอนไทซ์ของรุ่นต้นทางเท่านั้น

คำตอบสั้น ๆ

การควอนไทซ์แบบคำนึงถึงความไวคือการผสมความแม่นยำตามนโยบาย: ความกว้างบิตของแต่ละเทนเซอร์ขึ้นอยู่กับความไวต่อข้อผิดพลาดจากการควอนไทซ์ แทนที่จะใช้ความกว้างเดียวสำหรับทั้งโมเดล งานวิจัยในวรรณกรรมวัดความไวโดยใช้ Hessians, Fisher information หรือ divergence ระหว่างเอาต์พุตของเลเยอร์เดิมกับเลเยอร์ที่ถูกควอนไทซ์ จากนั้นจัดสรรบิตให้กับเลเยอร์ที่เสียหายมากที่สุด OrcaSAQ อยู่ในกลุ่มย่อยที่ข้ามการวัดนี้ทั้งหมด มันเข้ารหัสลำดับความไวไว้ในสถาปัตยกรรมเอง: มันใช้priors เชิงสถาปัตยกรรมและบทบาทของเทนเซอร์เพื่อตัดสินว่าน้ำหนักตัวใดเปราะบาง จากนั้นควอนไทซ์ส่วนที่เหลือทั้งหมดที่ความแม่นยำฐานเป้าหมาย

สิ่งที่คุณได้จากสิ่งนี้คือไปป์ไลน์ที่รวดเร็ว แน่นอน และไม่ต้องปรับเทียบ ไม่ต้องประกอบคลังข้อมูลเพื่อปรับเทียบ ไม่ต้องค้นหาความไวของแต่ละเลเยอร์ และไม่ต้องปรับจูนโมเดลใหม่ต่อรุ่น ดังนั้นสูตรเดียวกันจึงใช้ได้กับสถาปัตยกรรมใหม่ในวันที่น้ำหนักโมเดลออกมา สิ่งที่ยอมสละคือการปรับตัว: วิธีที่ขับเคลื่อนด้วยการปรับเทียบอย่าง GPTQ หรือ AWQ จะพิจารณาการกระจายของแอคติเวชันจริงของโมเดลและข้อมูลของคุณ และโดยปกติแล้วจะบีบคุณภาพจากความกว้างบิตเฉลี่ยเดียวกันได้มากกว่า การเดิมพันของ OrcaSAQ คือสำหรับโมเดล Mixture-of-Experts บทบาทของเทนเซอร์บอกคุณได้เกือบทั้งหมดที่การปรับเทียบจะบอกได้ ในราคาเพียงเศษเสี้ยว

สองวิธีในการค้นหาน้ำหนักที่อ่อนไหว

ก่อนนโยบาย คำถามคือ: คุณจะรู้ได้อย่างไรว่าการควอนไทซ์เทนเซอร์ตัวใดส่งผลเสีย? คำตอบทั้งสองคือพื้นที่การออกแบบทั้งหมด

• ขับเคลื่อนด้วยการปรับเทียบ ป้อนคอร์พัสขนาดเล็กผ่านโมเดล วัดข้อผิดพลาดที่เทนเซอร์หรือบล็อกแต่ละตัวก่อให้เกิด และจัดสรรบิตเพื่อลดข้อผิดพลาดการสร้างใหม่โดยรวม GPTQ ใช้การประมาณแบบเฮสเซียนต่อข้อผิดพลาดการควอนไทซ์รายชั้น ส่วน AWQ ใช้สถิติแอกติเวชันเพื่อระบุน้ำหนักที่สำคัญที่ต้องปกป้อง จุดแข็งคือการปรับให้เข้ากับข้อมูลจริงของคุณ ต้นทุนคือคอร์พัสที่คัดสรรแล้ว การผ่านไปข้างหน้า และการแก้สมการเฮสเซียนผกผันสำหรับทุกชั้น รวมถึงผลลัพธ์ที่เปลี่ยนแปลงเมื่อชุดปรับเทียบเปลี่ยนไป

• ไม่ต้องปรับเทียบกำหนดลำดับความสำคัญของความไวก่อนที่จะเห็นข้อมูลใดๆ จากสถาปัตยกรรม ใน MoE คุณรู้อยู่แล้วว่าบทบาทที่แบกรับภาระหลักคือ: ผู้เชี่ยวชาญที่ทำงานในทุกโทเค็น และโปรเจกชันที่เขียนลงใน residual stream เข้ารหัสลำดับความสำคัญนั้นเป็นนโยบายคงที่และนำไปใช้อย่างเป็นกลไก

OrcaSAQ อยู่ในค่ายที่สองอย่างชัดเจน และบทความนี้คือการปกป้องค่ายดังกล่าวสำหรับการควอนไทซ์ MoE — พร้อมคำอธิบายที่ตรงไปตรงมาว่าคุณต้องยอมเสียอะไรไปเพื่อแลกกับมัน

นโยบาย: เทนเซอร์ใดได้รับบิตมากขึ้น

นโยบายการจัดสรรบิตของ OrcaSAQ ระบุไว้ในโมเดลการ์ดของ orcarouter/GLM-5.3-Flash-MLX, และมันลดรูปเป็นกฎสามข้อบวกกับข้อยกเว้นหนึ่งข้อ ระดับฐานความแม่นยำคือบิลด์ที่คุณกำลังสร้าง — 6, 4, 3 หรือ 2 บิต — และนโยบายจะยกระดับบทบาทเทนเซอร์เฉพาะให้สูงกว่าค่านั้น:

• ผู้เชี่ยวชาญร่วม: พื้นฐาน +2 บิต. ผู้เชี่ยวชาญร่วมทำงานบนทุกโทเคน ดังนั้นข้อผิดพลาดจากควอนไทเซชันของมันจึงถูกถ่ายทอดไปยังทุกเอาต์พุตที่โมเดลผลิตออกมา มันคือเทนเซอร์ที่มีอิทธิพลสูงสุดในโมเดล และได้รับบิตมากที่สุด.

• down_proj: base +1 bit.ในบล็อก SwiGLU MLP down projection คือคอขวดของ residual — ผลลัพธ์ของมันถูกบวกเข้าไปใน residual stream โดยตรง ซึ่งทุกเลเยอร์ที่ลึกกว่าจะอ่าน ข้อผิดพลาดตรงนี้จะทำให้ทุกสิ่งที่อยู่ปลายน้ำเห็นข้อมูลที่ผิดเพี้ยนไปโดยตรง

• gate_proj และ up_proj: ความแม่นยำพื้นฐาน สิ่งเหล่านี้คือเส้นทางขยายและเส้นทางเกต; ผลลัพธ์ของพวกมันถูกคูณแบบรายองค์ประกอบภายในแอคติเวชัน ข้อผิดพลาดเล็กน้อยตรงนั้นถูกชะล้างออกบางส่วนโดยการเกต ดังนั้นพวกมันจึงทนทานต่อความกว้างพื้นฐาน

• ไม่เคยถูกควอนไทซ์ เก็บใน BF16:เลเยอร์ linear-attention 34 ชั้น, ตัวจัดทำดัชนีแบบ sparse ที่เรียนรู้ได้, อาร์เรย์ hyper-connection, ค่านอร์ม,embed_tokens, lm_head, และวิสัยทัศน์ทาวเวอร์ทั้งหมด องค์ประกอบเหล่านี้ไม่ได้ถูกเก็บเป็น FP8 ในรุ่นต้นทาง และยังคงความแม่นยำเต็มรูปแบบ

บิตจะปัดขึ้นเป็นความกว้างที่รองรับโดย MLX ที่ใกล้ที่สุด คือ {2,3,4,5,6,8} อย่างเป็นรูปธรรม บน GLM-5.3-Flash — รวม 320B / แอ็กทีฟ 18B, routed 288 ตัวบวก expert แบบ shared 1 ตัวพร้อมการจัดเส้นทาง top-8, 45 เลเยอร์ — บิลด์แบบ 4 บิตให้ expert แบบ shared ใช้ 6 บิต, down projection ทุกตัวใช้ 5 บิต และ gate กับ up projection ใช้ 4 บิต บิลด์แบบ 6 บิตจะปัด down projections ขึ้นเป็น 8 บิต ขนาด group คือ 64 สำหรับบิลด์แบบ 4 และ 6 บิต, 32 สำหรับแบบ 2 และ 3 บิต และ expert แบบ shared จะใช้ 64 เสมอ

OrcaSAQ bit-allocation policy card titled 'OrcaSAQ — the bit-allocation policy' on GLM-5.3-Flash, listing the rules 'shared expert base +2 bits', 'down_proj base +1 bit', 'gate_proj / up_proj base', 'never FP8 upstream BF16', with a concrete 'At a 4-bit base' column showing shared expert 6 bits, down_proj 5 bits, gate/up projections 4 bits, and BF16 for the linear-attention path, indexer and vision tower, plus a footer citing the orcarouter/GLM-5.3-Flash-MLX model card

กฎ shared-expert คุ้มค่าหรือไม่? ที่เบส 2 บิต shared expert จะอยู่ที่ 4 บิต และที่เบส 6 บิตจะอยู่ที่ 8 — ในทั้งสองกรณี สองบิตที่เพิ่มขึ้นมานี้กินหน่วยความจำที่ routed experts อาจนำไปใช้ได้ และตัวเลขของ model card เอง ซึ่งจะอภิปรายด้านล่าง ชี้ให้เห็นว่าการแลกเปลี่ยนนี้ให้ผลตอบแทนที่คุ้มค่า เป็นเหตุผลเดียวกับที่ทำให้บิลด์ 2bit-lite คุ้มค่าที่จะเผยแพร่: expert ที่ทำงานตลอดเวลาคือจุดเดียวที่ความแม่นยำที่เพิ่มขึ้นอีกเล็กน้อยให้ประโยชน์สูงสุด

กฎการเลือก: _scale_inv เป็นสัญญาณความไวอิสระ

นโยบายการจัดสรรบิตนั้นถือว่าคุณรู้อยู่แล้วว่าเทนเซอร์ใดเป็นตัวเลือก การเลือกชุดนั้นคือจุดที่ OrcaSAQ ฉลาดที่สุด เพราะกฎเป็นกลไกและไม่จำเป็นต้องใช้ข้อมูล: เทนเซอร์จะถูก re-quantized ก็ต่อเมื่อรีลีส FP8 จัดส่งมันมาพร้อมกับ _scale_inv ที่เป็นคู่หู

เหตุผลที่ได้ผล: ฐาน GLM-5.3-Flash ต้นทางเป็น FP8 — แบบ block-wise e4m3 บล็อก 128×128 พร้อมโครงร่าง activation แบบไดนามิก การควอนไทซ์ FP8 แบบ block-wise เก็บ scale รายบล็อกและค่าผกผันไว้คู่กับน้ำหนัก; การมี _scale_inv ใน checkpoint เป็นเครื่องหมายถาวรว่าเทนเซอร์นั้นผ่านเส้นทางควอนไทซ์ต้นทางมา รุ่นต้นทางได้บอกคุณไว้แล้วว่าเทนเซอร์ใดปลอดภัยต่อการควอนไทซ์ — ไม่ต้องใช้ Hessian, ไม่ต้องใช้ calibration corpus, ไม่ต้องใช้ forward passes

สำหรับ GLM-5.3-Flash เซตนั้นคือ linear ของ MoE และ dense-MLP รวมถึงโปรเจกชันทั้งสี่ของทุก deepseek_sparse_attention บล็อก — q_a_proj, q_b_proj, kv_a_proj_with_mqa และ o_proj — ครอบคลุมชั้น sparse ทั้ง 11 ชั้นที่ depth 3, 7, 11 … 43 รวมถึงบล็อก MTP รวมเป็น 12 × 4 = 48 เทนเซอร์ อย่างอื่นไม่เคยมีมาร์กเกอร์และยังคงเป็น BF16: 34 linear_attention ชั้น ตัวจัดทำดัชนีแบบ sparse และวิทัศน์ทาวเวอร์ ชั้น MTP — layer 45 — ถูกรวมอยู่ในน้ำหนักที่ถูกควอนไทซ์ แทนที่จะถูกส่งออกเป็นโมดูลแยกต่างหาก

ประเด็นที่คุ้มค่าแก่การหยิบยืมคือตัวเทคนิคนั่นเอง โมเดลที่เผยแพร่ซึ่งทำการ quantize น้ำหนักตั้งแต่ต้นทางได้ทำงานอย่างมากแล้วในการตัดสินใจว่าสิ่งใดสามารถ quantize ได้ และเครื่องหมาย _scale_inv ก็คือการตัดสินใจนั้น ซึ่งถูกทำให้เป็น serialized ในรูปแบบไฟล์ OrcaSAQ อ่านค่าดังกล่าวกลับออกมา นั่นคือสิ่งที่ทำให้ไปป์ไลน์นี้มีความ deterministic และถ่ายโอนได้ — โมเดลใดก็ตามที่มาพร้อมกับน้ำหนัก FP8 และเมทาดาทา scale สามารถจัดการได้ด้วยกฎเดียวกัน โดยไม่ต้องมีไปป์ไลน์ข้อมูลใดๆ เลย

OrcaSAQ selection-rule card titled 'OrcaSAQ — the mechanical selection rule' showing the rule 'Re-quantize a tensor iff the FP8 release shipped it with a _scale_inv companion', with a 'Quantized (had _scale_inv)' column listing the MoE and dense-MLP linears, 11 sparse layers x 4 projections at depth 3, 7, 11 … 43, the MTP block, 12 x 4 = 48 sparse-attention projection tensors and 37,338 tensors total, and a 'Never FP8 upstream (BF16)' column listing 34 linear-attention layers, the sparse indexer, hyper-connections, norms, embed_tokens, lm_head and the vision tower

ข้อควรระวัง: กำหนดค่าแบบต่อโมดูล ไม่ใช่กำหนดที่ระดับบนสุด

ถ้าคุณเขียน MLX quantizer ของคุณเอง — และนี่คือกลุ่มเป้าหมายของส่วนนี้ — สิ่งที่มีประโยชน์ที่สุดใน model card คือคำเตือน: ค่าระดับบนสุดอย่าง bits และ group_size ใน config.json ไม่เพียงพอ.

โดยรวมแล้ว เทนเซอร์ 37,338 ตัวถูกควอนไทซ์ การกำหนดค่าถูกบันทึกไว้ใน config.json → การควอนไทซ์แบบต่อโมดูล {group_size, bits} ซึ่งเป็นการแทนที่ค่าโดยใช้พาธโมดูลของ MLX เป็นคีย์ — เช่น model.layers.3.mlp.switch_mlp.down_proj เนื่องจาก MLX รวม routed experts ของเลเยอร์เข้าเป็น switch_mlp เพียงตัวเดียว 173 รายการจึงครอบคลุมเทนเซอร์ทั้งหมด 37,338 ตัว

และตัวโหลดจะอ่านรายการเหล่านั้นในเวลาโหลด หากคุณควอนไทซ์ทั้งไฟล์ที่ความกว้างฐาน เทนเซอร์ทุกตัวที่เพิ่มความแม่นยำ — shared expert ที่ base +2, down projection ทุกตัวที่ base +1 — จะออกมาที่ความกว้างผิด และโมเดลจะโหลดออกมามีรูปทรงผิดเพี้ยน แผนที่ต่อโมดูลไม่ใช่การปรับให้เหมาะสมที่คุณจะข้ามได้ มันคือเส้นทางการโหลด เมื่อคุณเขียนควอนไทเซอร์ของคุณเอง ให้ส่ง overrides สำหรับทุกเทนเซอร์ที่นโยบายยกขึ้น และตรวจสอบเทียบกับค่าเริ่มต้นระดับบนสุดก่อนจะวางจำหน่าย

นโยบายนี้คุ้มทุนหรือไม่?

หลักฐานนี้เป็นของเราเอง วัดจากแบบจำลองหนึ่งตัว: GLM-5.3-Flash, แต่ละบิลด์ถูก dequantize และรันผ่านตัวเดียวกัน glm5_next forward เพื่อให้ตัวแปรเดียวคือ quantization. ตัวเลขด้านล่างมาจาก model card และไม่ใช่เกณฑ์มาตรฐานของผู้ขายหรือตัวเลขของบุคคลที่สาม — ให้ถือเป็นข้อมูลจุดเดียว ไม่ใช่กฎ

• Perplexity เทียบกับค่าอ้างอิง FP8 ที่ 2.7797: 6-bit 2.7864 (+0.24%), 4-bit 2.8620 (+2.96%), 3-bit 3.0566 (+9.96%), 2-bit 4.3622 (+56.9%)

• ความสอดคล้องของโทเค็นอันดับ 1 กับข้อมูลอ้างอิง ในลำดับเดียวกัน: 97.76%, 96.13%, 92.06%, 86.56%

การอ่านค่าคือสิ่งที่โพลิซีคาดการณ์ไว้พอดี ทุกระดับจนถึง 3 บิตเสื่อมลงอย่างนุ่มนวล — นั่นคือลายเซ็นของงบประมาณบิตที่ถูกใช้กับเทนเซอร์ที่ถูกต้อง — และ 2 บิตคือหน้าผา เพราะต่ำกว่าจุดหนึ่งการชดเชยตามบทบาทจะไม่ครอบคลุมความเสียหายอีกต่อไป ที่ 4 บิต ค่า perplexity เพิ่มขึ้น +2.96% สำหรับบิลด์ที่เล็กกว่า FP8 reference ประมาณ 38% ถือเป็นการแลกเปลี่ยนที่ดีจริง ๆ และเป็นโพลิซีเดียวกันที่ถูกใช้อย่างเข้มข้นขึ้น ซึ่งทำให้บิลด์ 102 GB แบบ 2bit-lite โหลดได้เลย ผู้ปฏิบัติอิสระที่ quantize เบสเดียวกันรายงานลำดับเดียวกัน — ขั้นบนสุดใกล้กับ noise floor, 4 บิตจริงแต่พอประมาณ — ด้วยตัวเลขสัมบูรณ์ที่ต่างกันจากการประเมินบนคลังข้อมูลที่ต่างกัน

OrcaSAQ quality card titled 'OrcaSAQ — quality versus the FP8 reference' listing perplexity versus the FP8 reference at 2.7797: 6-bit 2.7864 (+0.24%), 4-bit 2.8620 (+2.96%), 3-bit 3.0566 (+9.96%), 2-bit 4.3622 (+56.9%), with top-1 agreement 97.76%, 96.13%, 92.06%, 86.56%, and a footer noting these are OrcaRouter's own measurements on GLM-5.3-Flash, not vendor benchmarks

สิ่งที่ถ่ายโอนไปยัง MoE ของคุณเอง

การให้เหตุผลที่ใช้ซ้ำได้ สำหรับโมเดลที่ไม่ใช่ของเรา:

• ค้นหาผู้เชี่ยวชาญที่ทำงานอยู่เสมอ อะไรก็ตามที่ทำงานในทุกโทเค็น — โดยปกติคือผู้เชี่ยวชาญแบบใช้ร่วมกันหรือถูกจัดเส้นทางเสมอ — จะได้รับบิตมากที่สุด ข้อผิดพลาดของมันจะถูกเล่นซ้ำทุกที่

• ค้นหาคอขวดที่เหลืออยู่โปรเจกชันที่เขียนลงใน residual stream (โดยทั่วไปคือ down projection ของแต่ละ MLP block) จะได้รับ base +1 ข้อผิดพลาดตรงนั้นจะถูกมองเห็นโดยทุกเลเยอร์ที่ลึกลงไป

• ปล่อยให้เส้นทางขยายและเส้นทางเกตอยู่ที่ค่าฐาน. หากผลลัพธ์ถูกคูณแบบองค์ประกอบต่อองค์ประกอบภายในแอกติเวชัน ความคลาดเคลื่อนจากการควอนไทซ์ในนั้นจะถูกดูดซับบางส่วน.

• การไม่ถูกหาปริมาณที่ต้นทาง หมายความว่าคุณไม่ต้องหาปริมาณ. หากเวอร์ชันฐานมีเทนเซอร์เหล่านั้นในความแม่นยำเต็ม ก็ให้คงความแม่นยำเต็มไว้.

• ใช้ข้อมูลเมตาสเกลของรุ่นต้นทาง (upstream release) เป็นเกณฑ์ในการคัดเลือกของคุณหากโมเดลพื้นฐานทำการควอนไทซ์น้ำหนักของมัน เครื่องหมายสเกล/สเกลผกผันที่มันทิ้งไว้คือแผนที่ฟรีของสิ่งที่สามารถควอนไทซ์ได้ — ไม่จำเป็นต้องค้นหาความไว (sensitivity search)

• บันทึกการแทนที่ต่อโมดูล ความกว้างบิตแบบ global จะทำให้เทนเซอร์ที่ยกขึ้นทุกตัวมีรูปร่างผิดเพี้ยนเมื่อโหลด เขียนแผนที่เส้นทางโมดูล

และหากคุณสามารถเก็บชุด calibration ได้เลย ก็ใช้มันเพื่อตรวจสอบนโยบาย — ไม่ใช่เพื่อแทนที่นโยบาย ดำเนินการ quantization ที่ขับเคลื่อนด้วย calibration ที่ค่าเฉลี่ยบิตเดียวกัน และตรวจสอบว่าลำดับของ role prior ตรงกับสิ่งที่ข้อมูลบอกหรือไม่ บนโมเดลแบบ dense หรือสถาปัตยกรรมใหม่ล่าสุด การตรวจสอบดังกล่าวคือความแตกต่างระหว่างค่าเริ่มต้นที่สามารถป้องกันได้กับการเดา

เมื่อ OrcaSAQ เป็นตัวเลือกที่ไม่ถูกต้อง

นี่คือส่วนที่ควรทำให้วิธีการคงความซื่อตรง เพราะข้อแลกเปลี่ยนของการไม่ต้องปรับเทียบนั้นเป็นเรื่องจริง

• เมื่อเพดานคุณภาพสำคัญกว่าความเร็วของไปป์ไลน์ และคุณมีชุดคาลิเบรชัน วิธีการแบบ GPTQ หรือ AWQ จะปรับตัวเข้ากับสถิติแอ็กทิเวชันจริงของโมเดลและข้อมูลของคุณ และที่ค่าเฉลี่ยบิตเท่ากัน วิธีเหล่านี้มักจะให้ผลลัพธ์ที่ดีกว่านโยบายแบบอิงบทบาทตายตัว หากคุณกำลังทำ quantization ให้โมเดลเพียงครั้งเดียวและไม่ต้องทำซ้ำอีก ชั่วโมงที่เพิ่มขึ้นสำหรับการคาลิเบรชันคือต้นทุนเพียงครั้งเดียวที่ให้คุณภาพที่วัดผลได้จริง

• โมเดล Dense ที่ไม่ใช่ MoE prior เชิงบทบาท — ผู้เชี่ยวชาญร่วม, gate/up/down — ไม่มีอยู่จริง นโยบายจึงสูญเสียโครงสร้างที่ทำให้น่าเชื่อถือ สิ่งที่เหลืออยู่คือ “ทุกอย่างที่ถูกควอนไทซ์ตั้งแต่ต้นทางยังคงถูกควอนไทซ์” ซึ่งเป็นข้อกล่าวอ้างที่อ่อนแอกว่า

• โมเดลที่ไม่มีการรีลีส FP8 ต้นทาง. สำหรับ _scale_inv กฎการเลือกไม่มีอะไรให้ยึดเป็นเกณฑ์ คุณต้องตัดสินใจเลือกเซตที่สามารถ quantize ได้ด้วยวิธีอื่น และข้อโต้แย้งเรื่องความสามารถในการถ่ายโอนเชิงกลก็พังทลาย.

• สถาปัตยกรรมใหม่เอี่ยมข้อสันนิษฐานก่อนหน้าคือสมมติฐานที่อาจไม่เป็นจริง วิธีการที่ขับเคลื่อนด้วยการปรับเทียบจะตรวจจับเทนเซอร์ที่เปราะบางซึ่งนโยบายตามบทบาทมองข้ามไป แต่ OrcaSAQ จะไม่เป็นเช่นนั้น เพราะมันไม่เคยมองหา

• เป้าหมายต่ำกว่า 3 บิตนโยบายนี้ไม่ได้ช่วยคุณ ที่ระดับ 2 บิต โมเดลมีค่า perplexity เพิ่มขึ้น +56.9% ไม่ว่าบิตพิเศษจะถูกจัดสรรไปที่ใดก็ตาม เวอร์ชัน 2bit-lite ถูกสร้างขึ้นเพื่อความพอดี ไม่ใช่เพื่อคุณภาพ

• เมื่อคุณต้องการการรับประกันการรับประกันแบบต่อเทนเซอร์ งบประมาณการฝึกอบรมที่คำนึงถึงการควอนไทซ์ (QAT) หรือคุณภาพที่ดีที่สุดเท่าที่เป็นไปได้สำหรับขนาดที่กำหนดโดยไม่คำนึงถึงต้นทุนไปป์ไลน์ ล้วนอยู่ในขอบเขตของการปรับเทียบ

สรุป

การตรึงปริมาณที่คำนึงถึงความไวคือแนวทางปฏิบัติ; OrcaSAQ เป็นหนึ่งในสูตรที่กำหนดขึ้นเองและไม่ต้องปรับเทียบสำหรับเรื่องนี้ บทเรียนที่ยั่งยืนคือการเพิ่มขึ้นของ shared-expert และ down-projection เชิงกลไก _scale_inv กฎการเลือก และการกำหนดค่าต่อโมดูลที่ loader อ่านจริง สำหรับ MoE ที่มีพารามิเตอร์ 320 พันล้าน เช่น GLM-5.3-Flash สูตรนั้นให้ MLX build แบบ 4-bit ที่ perplexity +2.96% — และ orcarouter/GLM-5.3-Flash-MLX พื้นที่เก็บข้อมูลนี้เผยแพร่นโยบายเดียวกันที่ 2, 3, 4 และ 6 บิต พร้อม build แบบ 2bit-lite แยกสำหรับเครื่อง 128 GB และในส่วนของเรา GLM-5.3-Flash-MLX การเดินชมครอบคลุมว่าควรใช้ build ใดบนเครื่องใด ทีละขั้นตอน

หากสิ่งที่คุณให้ความสำคัญคือคุณภาพส่วนสุดท้ายที่ขนาดคงที่ และคุณสามารถรวบรวมคลังข้อมูลสำหรับการปรับเทียบได้ ให้ใช้เครื่องมือที่ขับเคลื่อนด้วยการปรับเทียบแล้วปล่อยให้มันปรับตัว หากสิ่งที่คุณให้ความสำคัญคือการควอนไทซ์ที่ทำซ้ำได้ รวดเร็ว และไม่ต้องใช้ข้อมูล ซึ่งถ่ายโอนไปยังสถาปัตยกรรมถัดไป — หรือคุณเพียงแค่ไม่ต้องการสร้างไปป์ไลน์ข้อมูลเลย — นโยบายตามบทบาทก็เป็นค่าเริ่มต้นที่สมเหตุสมผล และหากคุณไม่อยากควอนไทซ์ตั้งแต่แรก โมเดลความแม่นยำเต็ม GLM-5.3-Flashจะถูกให้บริการผ่าน OrcaRouter ในชื่อ z-ai/glm-5.3-flash ทางเลือกนี้คือเรื่องที่ว่าคุณยินดีจะรันไปป์ไลน์มากแค่ไหน ไม่ใช่เรื่องที่ว่าการควอนไทซ์ที่คำนึงถึงความไวนั้นคุ้มค่าที่จะทำหรือไม่

ไม่อยาก quantize อะไรเลยใช่ไหม? z-ai/glm-5.3-flash คือโมเดล full-precision ที่ให้บริการบน OrcaRouter ในราคาของผู้ให้บริการ โดยไม่มีการคิด markup (0%)