Qwen3.8-Flash-Next-Uncensored-NVFP4: รันบุ๊กการให้บริการบนแบล็กเวลล์

Qwen3.8-Flash-Next-Uncensored-NVFP4 รันบน GPU เพียงตระกูลเดียวเท่านั้น: Blackwell. NVFP4 ทำงานบน FP4 tensor cores ในระดับฮาร์ดแวร์ และ Hopper (H100/H200) รวมถึงรุ่นที่เก่ากว่า ก็ไม่มี tensor cores เหล่านั้น หากคุณใช้ Hopper ให้หยุดตรงนี้ — Qwen3.8-Flash-Next-Uncensored-FP8 บิลด์คือสิ่งที่คุณต้องการ ทุกอย่างด้านล่างนี้ถือว่าคุณใช้ Blackwell (B100, B200, GB200 หรือการ์ด RTX 50-series), vLLM บิลด์รุ่นใหม่ที่รองรับ qwen4_exp และ transformers ≥ 5.16.

นี่คือการควอนไทซ์ NVFP4 ของบิลด์ abliterated (ที่ลบการปฏิเสธ) ของ Qw​en Qw​en/Qwen3.8-Flash-Next ซึ่งลดลงจาก 330 GB ในรูปแบบ BF16 เหลือ 178 GB บนดิสก์ OrcaRouter เผยแพร่โมเดลนี้ไปยัง Hugging Face เมื่อวันที่ 27 สิงหาคม 2026 ในชื่อ orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4. รีโพนี้ถูกจำกัดการเข้าถึง (gated): คุณต้องล็อกอินเข้าสู่ Hugging Face และยอมรับข้อกำหนดของรีโพ มิฉะนั้น hf download และ vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 ต่างก็ล้มเหลวด้วยข้อผิดพลาดการยืนยันตัวตนก่อนที่ข้อมูลแม้แต่ไบต์เดียวจะถูกถ่ายโอน หน้านี้คือ serving runbook ไม่ใช่รายงานข่าวการเปิดตัว — บิลด์นี้เพิ่งสร้างเมื่อสองวันก่อน และคำถามที่ผู้คนพบจริง ๆ คือเรื่องฮาร์ดแวร์ แฟล็ก และควรเลือกบิลด์ไหน

และก่อนที่ตัวเลขจะเริ่ม: Qwen3.8-Flash-Next-Uncensored ไม่ใช่ Qwen3.8-27B-Uncensored. ทั้งสองโมเดลเป็นโมเดลที่แตกต่างกันซึ่งมีชื่อตระกูลเดียวกันและใช้เทคนิค abliteration ร่วมกัน — น้ำหนักฐานต่างกัน สถาปัตยกรรมต่างกัน คอลเลกชัน Hugging Face ต่างกัน Flash-Next ถูกสร้างด้วยวิธี abliteration จาก Qw​en/Qwen3.8-Flash-Next, ซึ่งเป็นตัวอย่างของสถาปัตยกรรม Qwen4 แบบ routed mixture-of-experts (qwen4_exp): ผู้เชี่ยวชาญ 512 ตัว โดยมี 10 ตัวแบบ routed และ 1 ตัวแบบ shared ที่ทำงานพร้อมกัน, แอตเทนชันแบบไฮบริด (เลเยอร์เชิงเส้น Gated DeltaNet ควบคู่กับเลเยอร์ full-attention), Hyper-Connections, การฝัง n-gram แบบ PLE, ทาวเวอร์วิสัยทัศน์และวิดีโอแบบเนทีฟ, และหัวถอดรหัสแบบคาดเดา MTP ส่วน 27B ถูกสร้างด้วยวิธี abliteration จาก Qw​en/Qwen3.8-27B, ซึ่งเป็นฐานแบบ dense ที่แตกต่างกันโดยสิ้นเชิง ไม่มีสิ่งใดจากตัวเลขการให้บริการของหน้า 27B ที่ถ่ายโอนมายังโมเดลนี้; ในจุดที่หน้า 27B มีประโยชน์จริง ๆ — คู่มือ abliteration, คณิตศาสตร์การเลือกควอนต์ทั่วไป — มันถูกลิงก์ไว้ด้านล่างพร้อมกับสิ่งที่ใช้ได้และใช้ไม่ได้

บิลด์นี้คืออะไร ไล่ทีละความแม่นยำ

Qwen3.8-Flash-Next เป็นสถาปัตยกรรม MoE แบบมีการจัดเส้นทาง (routed MoE): ทุกโทเคนจะเปิดใช้งานผู้เชี่ยวชาญ 10 จาก 512 ตัวพร้อมกับผู้เชี่ยวชาญร่วมอีกหนึ่งตัว และมีพารามิเตอร์เพียงไม่กี่พันล้านตัวที่ทำงานต่อโทเคน แม้ว่าโมเดลที่จัดเก็บไว้จะมีขนาดใหญ่กว่ามากก็ตาม บิลด์ NVFP4 เป็นการควอนไทซ์แบบ mixed-precision compressed-tensors ของสแตกดังกล่าว และการแบ่งแยกนี้คือหัวใจของเรื่องทั้งหมด:

• น้ำหนักเอ็กซ์เพิร์ต MoE — NVFP4 (4 บิต, NVIDIA FP4 E2M1, กลุ่มขนาด 16 พร้อมมาตราส่วนบล็อก FP8)

• ความสนใจ (self_attn.{q,k,v,o}), โปรเจกชัน linear_attn, ผู้เชี่ยวชาญร่วม และ lm_head — FP8 (8 บิต)

• PLE n-gram embedding โทเคนและวิชันเอมเบดดิง (token and vision embeddings), Hyper-Connections, ดัชนี QSA (QSA indexer), Gated-DeltaNet conv/dt, นอร์มทั้งหมด และหอคอยวิชันทั้งหมด (vision tower) — เป็น BF16 ซึ่งคงไว้ที่ความแม่นยำเต็ม (full precision)

คุณสมบัติสามประการของการแปลงนี้มีความสำคัญมากกว่าตัวการแบ่งความแม่นยำเอง ประการแรก มันเป็นการควอนไทซ์เฉพาะน้ำหนัก: แอกทิเวชันถูกควอนไทซ์แบบไดนามิกขณะรันไทม์ ไม่มีการปรับเทียบแบบคงที่ และน้ำหนักได้มาจากเช็คพอยต์ BF16 โดยตรง (การ์ดเรียกการได้มานี้ว่าแบบไม่ใช้ข้อมูล) ประการที่สอง การแก้ไขแบบ abliteration ถูกฝังอยู่ในน้ำหนัก ดังนั้นการลบการปฏิเสธจึงยังคงอยู่หลังการควอนไทซ์ — การแปลง 4 บิตคือการเปลี่ยนแปลงความแม่นยำ ไม่ใช่การแทรกแซงด้านความปลอดภัย ประการที่สาม แคช KV ไม่ถูกควอนไทซ์; มันยังคงเป็น BF16 ขณะรันไทม์ ข้อสุดท้ายนี้มองข้ามได้ง่าย และมันสำคัญที่บริบท 262,144 โทเค็นดั้งเดิมของโมเดล ซึ่งแคช KV เป็นรายการหน่วยความจำจริงที่อยู่ควบคู่ไปกับน้ำหนัก

ขนาดบนดิสก์ส่วนใหญ่มาจากเทนเซอร์ตัวเดียว การ์ดระบุว่า PLE n-gram embedding เป็นเทนเซอร์พารามิเตอร์ ~66B ตัวเดียวซึ่งเก็บในรูปแบบ BF16 ตามการออกแบบ มันเป็นชาร์ดที่ใหญ่ที่สุดและเป็นเหตุผลที่บิลด์มีขนาด 178 GB แทนที่จะเป็นตัวเลขที่น้อยกว่า มีความคลาดเคลื่อนอย่างหนึ่งที่ควรชี้ให้เห็นแทนที่จะกลบเกลื่อน: การ์ด FP8 รุ่นพี่น้องเรียกตารางเดียวกันว่า PLE n-gram ขนาด 51B พารามิเตอร์ และหมายเหตุ W4A4 ของการ์ดใบนี้ระบุว่ามีขนาด ~100 GB การ์ดทั้งสองใบระบุตัวเลขต่างกันสำหรับตารางเดียวกัน ดังนั้นให้ถือว่าแต่ละตัวเลขเป็นตัวเลขของการ์ดใบนั้นๆ และเมื่อคุณคำนวณขนาดสำหรับการปรับใช้ ให้สมมติว่าตารางมีขนาดใหญ่ในรูปแบบ BF16 และวางแผนรองรับไว้

ข้อกำหนดเบื้องต้นด้านฮาร์ดแวร์โดยละเอียด

นี่คือส่วนที่สั้นที่สุดแต่สำคัญที่สุดของหน้าเพจ NVFP4 เป็นฟอร์แมตของ Blackwell: เส้นทางความเร็วสูงคือ GEMM FP4 แบบเนทีฟบนเทนเซอร์คอร์รุ่นที่ห้า และหากไม่มีฮาร์ดแวร์นั้น ฟอร์แมตนี้ก็ไม่มีอะไรให้ทำงานด้วย ข้อกำหนดของตัวการ์ดเองระบุไว้ชัดเจน — ต้องใช้ GPU ของ Blackwell (B100 / B200 / GB200 / RTX 50-series) เนื่องจาก NVFP4 ใช้เทนเซอร์คอร์ FP4 ของฮาร์ดแวร์ และมันจะไม่ทำงานบน Hopper (H100/H200) หรือรุ่นเก่ากว่า ซึ่งขาดความสามารถในการคำนวณ FP4

การเปลี่ยนเส้นทางทั้งหมดในที่เดียว:

• บน Hopper (H100/H200) — ให้เสิร์ฟ Qwen3.8-Flash-Next-Uncensored-FP8 แทน มันคือชุดน้ำหนักเดียวกันที่ 8-bit รันได้บน Hopper และ Blackwell และเป็นบิลด์ที่ FP8 runbook ของบล็อกนี้ครอบคลุม

• บน GPU NVIDIA ระดับผู้ใช้ทั่วไปหรือเครื่อง CPU — บิลด์ GGUF ที่มีควอนต์ 13 ชนิดของ llama.cpp คือเส้นทางสำหรับการรันในเครื่อง

• บน Apple Silicon — บิลด์ MLX ในระดับ 4/6/8 บิต คือเส้นทาง Metal เนทีฟ

ข้อกำหนดของรันไทม์นั้นผูกพันพอๆ กับตัวซิลิคอน qwen4_exp เป็นสถาปัตยกรรมใหม่เอี่ยม ดังนั้นบิลด์ vLLM มาตรฐานที่มีมาก่อนจะปฏิเสธไม่โหลด checkpoint คุณต้องใช้ vLLM เวอร์ชันล่าสุดที่รองรับ qwen4_exp พร้อมตัวอ่าน NVFP4 ของ compressed-tensors (รูปแบบถูกตรวจจับจาก config.json โดยอัตโนมัติ ไม่ใช่เลือกเอง) และ transformers ≥ 5.16 อินพุตแบบมัลติโมดัลยังต้องใช้สแตกวิทัศน์ Qwen ของรันไทม์เพิ่มเติม ส่วนการให้บริการแบบข้อความล้วนทำงานได้โดยไม่ต้องใช้มัน

คำสั่ง serve ของการ์ด ทีละแฟล็ก

การเรียกใช้ตัวโมเดลการ์ดเองถือเป็นจุดเริ่มต้นที่ดี และควรทำความเข้าใจว่าแต่ละแฟล็กมีไว้เพื่ออะไร แทนที่จะคัดลอกและวางแบบไม่ไตร่ตรอง

vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 --tensor-parallel-size 4 --trust-remote-code --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

• --tensor-parallel-size 4 — น้ำหนักมีขนาดประมาณ 178 GB บนดิสก์ ดังนั้นการ์ดจึงแบ่งมันไปยัง GPU สี่ตัว นี่คือรูปแบบที่บิลด์ถูกปรับขนาดไว้; อย่าตีความว่าเป็นคำแนะนำ

• --trust-remote-code — จำเป็นสำหรับสถาปัตยกรรมแบบกำหนดเอง โค้ดโมเดลของ qwen4_exp ยังไม่ได้อยู่ในรีจิสทรีมาตรฐานของ transformers ดังนั้น vLLM จึงโหลดโค้ดสถาปัตยกรรมจาก repo คุณกำลังเชื่อถือโค้ดนั้น ซึ่งเป็นการตัดสินใจที่ปกติแต่เป็นเรื่องจริงสำหรับสถาปัตยกรรมใหม่เอี่ยม

• --enable-expert-parallel — แบ่งผู้เชี่ยวชาญไปตาม ranks ของ tensor-parallel แทนที่จะทำสำเนาซ้ำกัน ซึ่งเป็นสิ่งที่ทำให้ MoE แบบ 512 ผู้เชี่ยวชาญเป็นไปได้ที่ TP4 การ์ดคู่หู FP8 ระบุเหตุผลที่ชัดเจนกว่าสำหรับบิลด์นั้น: หากไม่มีตัวเลือกนี้ ความกว้างของชั้นกลาง MoE หารด้วย TP จะไม่ลงตัวกับขนาดบล็อก FP8 ให้ถือว่าจำเป็น ไม่ใช่ทางเลือก

• --enable-auto-tool-choice และ --tool-call-parser qwen3_coder — ทั้งสองอย่างนี้เมื่อใช้ร่วมกันจะเปิดใช้งานการเรียกใช้ฟังก์ชัน แฟล็ก auto ช่วยให้โมเดลตัดสินใจว่าจะเรียกใช้เครื่องมือหรือไม่ และพาร์เซอร์ qwen3_coder จะถอดรหัสรูปแบบการเรียกใช้เครื่องมือ ซึ่งเป็นตระกูลพาร์เซอร์เดียวกันกับที่ Qwen3.8-27B และ Qwen3.8-Flash-Next ใช้.

เมื่อมันทำงานขึ้นแล้ว เอนด์พอยต์ที่เข้ากันได้กับ OpenAI ที่ /v1/chat/completions จะนำเสนอคุณสมบัติครบชุดผ่านสแตก Qwen4 ของรันไทม์: การเรียกใช้เครื่องมือตามที่กล่าวข้างต้น การใช้เหตุผลผ่าน chat_template_kwargs.enable_thinking และวิทัศน์ผ่านส่วนเนื้อหาแบบ image_url คุณไม่จำเป็นต้องมีเซิร์ฟเวอร์แยกสำหรับมัลติโมดัล เพราะเป็นเอนด์พอยต์เดียวกัน

หมายเหตุเชิงโครงสร้างประการหนึ่งจากการ์ด: ไม่มีตัวแปร W4A4 แบบ static เต็มรูปแบบของ build นี้ และจะไม่มีทางมีแบบนั้นได้ในราคาถูก การแปลงเป็น W4A4 แบบ static จำเป็นต้องมี forward pass สำหรับปรับเทียบ activation และ pass นั้นต้องเก็บ n-gram embedding ขนาด ~100 GB ไว้บน GPU ตัวเดียว นั่นคือเหตุผลเดียวกับที่ตาราง PLE ครองรายการไฟล์ และเป็นเหตุผลที่ build นี้ยังคงเป็นแบบ weight-only ที่มี dynamic activations

รายงานภาคสนามจากชุมชน — การให้บริการนี้ในความเป็นจริงมีลักษณะอย่างไร

ไม่มีตัวเลข throughput หรือ latency ที่เผยแพร่สำหรับ repo นี้โดยเฉพาะ และหน้านี้จะไม่สร้างตัวเลขเหล่านี้ขึ้นมาเอง สิ่งที่มีอยู่คือชุดรายงานภาคสนามที่เพิ่มขึ้นเรื่อย ๆ จากผู้ปฏิบัติงานที่ให้บริการบิลด์ฐาน Qwen3.8-Flash-Next NVFP4 — สถาปัตยกรรมเดียวกัน การแบ่งความแม่นยำ NVFP4/FP8/BF16 แบบเดียวกัน โดยไม่มีการแก้ไข abliteration — และพฤติกรรมการให้บริการดังกล่าวก็ถ่ายทอดโดยตรง สิ่งเหล่านี้เป็นข้อค้นพบจากชุมชน ไม่ใช่คำแนะนำจากผู้จำหน่าย และผู้ที่รายงานข้อมูลเหล่านี้ใช้ฮาร์ดแวร์ Blackwell ที่มีรูปแบบ quantization เดียวกัน

• การถอดรหัสแบบคาดเดาของ MTP เป็นตัวขับเคลื่อนประสิทธิภาพที่ใหญ่ที่สุดเพียงตัวเดียว โมเดลมาพร้อมหัวดราฟต์สำหรับการคาดการณ์หลายโทเค็น และบนการ์ด RTX PRO 6000 หนึ่งตัว (96 GB, SM120) โมดูล MTP โหลดแบบควอนไทซ์เป็น NVFP4 ใช้ VRAM ประมาณ 0.51 GB — รายงานวัดความยาวที่ยอมรับได้ 2.3–3.9 จากสูงสุด 4 และอัตราการยอมรับ 0.86–0.96 รายงานเดียวกันวัดค่ามัธยฐานของการถอดรหัสแบบสตรีมเดียวได้ 180–226 tok/s (216.9 สำหรับงานเขียนโค้ด, 225.8 สำหรับงานเรียกใช้เครื่องมือของเอเจนต์, 136.6 สำหรับงานใช้เหตุผล) เทียบกับค่าพื้นฐานประมาณ 105 tok/s และตอบพรอมต์ 216,685 โทเค็นได้ในเวลา 8.4 วินาที ให้ถือว่าตัวเลขเหล่านี้มาจากเครื่องของคนคนหนึ่ง ไม่ใช่สเปก

• ย้าย PLE n-gram embedding ไปไว้ใน RAM ของโฮสต์ เนื่องจากตารางมีขนาดใหญ่มากและแทบไม่เป็นคอขวดด้าน throughput แนวทางจากคอมมูนิตี้บนการ์ด Blackwell ใบเดียวจึงตรึงมันไว้ที่โฮสต์ (RAM โฮสต์ว่างประมาณ 50 GiB ในรายงาน RTX PRO 6000) และ mmap จาก NVMe โดยแลกกับความหน่วงที่เพิ่มขึ้นเล็กน้อยเพื่อให้โมเดลพอจะใส่ลงในหน่วยความจำได้ คาดว่าคุณจะต้องทำแบบนี้เว้นแต่คุณมีงบ VRAM มากเป็นพิเศษ

• กำหนดหน้าต่างบริบทอย่างชัดเจนด้วย BF16 KV cache และ MTP ที่เปิดใช้งาน พูล KV ที่ปรับขนาดอัตโนมัติกลับขยายใหญ่เกินกว่าที่การ์ดจะรองรับได้และเกิด OOM ระหว่าง prefill ที่ยาว; การกำหนด max-model-len / max-total-tokens ไว้ที่ 262144 ทำให้กลับมามีพื้นที่ว่างเพียงพอ ที่ context 262K นั้น KV cache เป็นรายการที่ต้องจัดสรรงบประมาณไว้ ไม่ใช่ค่าเริ่มต้น

• บั๊กการปรับแต่งอัตโนมัติของ FlashInfer ทำให้เอาต์พุตเสียหายอย่างเงียบ ๆ โหมดความล้มเหลวที่สำคัญที่สุดในทางปฏิบัติ: การปรับแต่งอัตโนมัติเลือกกลยุทธ์เคอร์เนล fused-MoE โดยพิจารณาจากความหน่วงเท่านั้นและไม่เคยตรวจสอบค่าตัวเลข ดังนั้นในบางรูปทรง decode จะยุบกลายเป็นโทเค็นซ้ำ รายงานจาก RTX PRO 6000 แสดงให้เห็นว่าการสร้าง 36 จาก 36 รายการเสียหายเมื่อเปิด autotune และ 0 จาก 36 เมื่อปิด — วิธีแก้คือปิดการปรับแต่งอัตโนมัติของ FlashInfer (ใน vLLM ใช้ --no-enable-flashinfer-autotune; ใน SGLang ใช้ --disable-flashinfer-autotune) หากเอาต์พุตที่ให้บริการของคุณเสื่อมสภาพกะทันหัน ให้ตรวจสอบสิ่งนี้ก่อนแตะต้องสิ่งอื่นใด

• DGX Spark (GB10, SM121) ต้องใช้แพตช์ของตัวเอง น้ำหนัก NVFP4 (~126 GiB ในบิลด์ชุมชน) ไม่พอดีกับ Spark ขนาด 128 GB ตัวเดียว ดังนั้นสูตร SGLang จึงรันเทนเซอร์-ขนาน 2 ข้ามสองโหนดผ่าน RoCE และตัวแก้สลับการถอดรหัสแบบ QSA sparse จะล็อกเคอร์เนล FlashInfer ความเร็วสูงไว้หลังการตรวจสอบ is_sm100_supported() ซึ่งล้มเหลวบน SM121 แล้วตกไปใช้เส้นทางที่ตายระหว่างวอร์มอัพ — วิธีแก้คือแพตช์เล็กน้อยบวกกับ PLE offload คาดว่าจะได้ดีโค้ดประมาณ 47–50 tok/s ขึ้นสูงใกล้ 70 เมื่อใช้ MTP4 และ CUDA graphs และควรตรวจสอบว่าเคอร์เนลของคุณรันบน SM121 ได้จริงก่อนจะสัญญาเบนช์มาร์ก

การใช้เหตุผล การเรียกใช้เครื่องมือ และการมองเห็นผ่านสแตก Qwen4

ความเห็นพ้องของชุมชนเกี่ยวกับเจนเนอเรชัน Qwen3.8 ยังคงใช้ได้กับโมเดลนี้ โดยมีข้อแม้ตามปกติว่านี่คือแนวปฏิบัติภาคสนาม ไม่ใช่คำแนะนำจากผู้จำหน่าย

• reasoning_effort คือตัวควบคุมที่สำคัญที่สุด เทมเพลตแชทตั้งค่าเริ่มต้นเป็น xhigh ซึ่งทำให้โมเดลใช้เวลาคิดนานในทุกคำขอ ผู้ดำเนินการ agent-loop ตั้งค่าเริ่มต้นเป็น medium และลดเป็น low สำหรับการเรียกที่ไวต่อความหน่วง การตั้งค่า enable_thinking เป็น false จะปิดการให้เหตุผลทั้งหมดเมื่อคุณไม่ต้องการ บนการ์ด Blackwell ใบเดียว การปล่อยให้ xhigh เปิดอยู่สำหรับการเรียกทั่วไปคือวิธีที่ทำให้โมเดลที่รวดเร็วให้คำตอบที่ช้า

• จับคู่แซมเพลอร์กับโหมดการคิด ผู้ปฏิบัติส่วนใหญ่ใช้ temperature 1.0 / top-p 0.95 เมื่อเปิดโหมดคิด และใช้ temperature 0.7 / top-p 0.80 โดยมี presence penalty ประมาณ 1.5 เมื่อปิดโหมดคิด การผสมค่าทั้งสองชุดเข้าด้วยกันจะทำให้คุณภาพเอาต์พุตลดลง

• การเรียกใช้เครื่องมือยังคงทำงานได้ทั้งหลังจากการทำ abliteration และการแปลงเป็น 4-bit. เส้นทางการเรียกใช้ฟังก์ชันยังคงสมบูรณ์ ซึ่งคือสิ่งที่ parser qwen3_coder และแฟล็ก auto-tool-choice ใช้เชื่อมต่อกัน สำหรับทีมแดง นี่คือข้อเท็จจริงสองคม เนื่องจากหมายความว่าการนำไปใช้ในทางที่ผิดแบบ agentic ทำงานได้อย่างเต็มรูปแบบบนโมเดลที่ไม่ได้ align — กล่าวถึงด้านล่าง.

• การมองเห็นยังคงถูกรักษาไว้ และนั่นทำให้พื้นผิวการโจมตีกว้างขึ้น vision tower ไม่เคยถูกแตะต้องโดย abliteration และยังคงอยู่ใน BF16 ดังนั้นอินพุตรูปภาพจึงทำงานผ่านส่วนเนื้อหา image_url ผู้ปฏิบัติงานที่ประเมินโมเดลสาย uncensored ถือว่าเส้นทางมัลติโมดัลเป็นเป้าหมายการประเมินระดับแนวหน้า: prompt injection ที่บรรจุในรูปภาพจะไปถึงโมเดลที่ไม่มีพฤติกรรมการปฏิเสธให้โจมตี

คุณควรให้บริการ build ไหน

คอลเลกชัน Flash-Next มีห้าบิลด์ — BF16, GGUF, MLX, FP8 และบิลด์ NVFP4 นี้ — และตรรกะการเลือกที่ตรงไปตรงมาก็เกี่ยวกับฮาร์ดแวร์และข้อแลกเปลี่ยน ไม่ใช่การจัดอันดับ

• NVFP4 (บิลด์นี้ ~178 GB บนดิสก์) — ตัวเลือกของ Blackwell, เทนเซอร์คอร์ FP4, เอ็กซ์เพิร์ต 4 บิต, บิลด์ล่าสุดในคอลเลกชัน และเล็กที่สุดในบรรดาบิลด์เซิร์ฟเวอร์ vLLM และเป็นตัวที่หน้านี้กล่าวถึง

• FP8 (~186 GB บนดิสก์) — ตัวเลือกสำหรับ Hopper และทำงานได้ดีไม่แพ้กันบน Blackwell น้ำหนักชุดเดียวกันที่ 8 บิต ซึ่งเป็นเส้นทาง vLLM ที่ผ่านการตรวจสอบอย่างกว้างขวางกว่า และมีข้อกำหนดด้าน expert-parallel ที่ชัดเจนกว่า

• GGUF (13 ควอนต์, IQ2_XXS ~52 GB ถึง Q5_K_M ~125 GB) — ตัวเลือกของ llama.cpp สำหรับเครื่องระดับผู้บริโภคที่ใช้ NVIDIA, AMD หรือ CPU ไม่ต้องใช้ Blackwell, ไม่ต้องใช้ vLLM.

• MLX (ระดับ 4/6/8 บิต ประมาณ 163–221 GB) — ตัวเลือกสำหรับ Apple Silicon, รองรับ Metal แบบเนทีฟ, พร้อม MTP head

ข้อสังเกตที่ซื่อสัตย์สองประการก่อนที่คุณจะเลือก อย่างแรก บิลด์ NVFP4 และ FP8 ต่างกันเพียงประมาณแปด GB บนดิสก์ เนื่องจากทั้งคู่เก็บตาราง n-gram ขนาดใหญ่ในรูปแบบ BF16 — การประหยัดแบบ 4 บิตกระจุกตัวอยู่ในน้ำหนักของผู้เชี่ยวชาญ ไม่ใช่ในขนาดไฟล์ทั้งหมด ข้อได้เปรียบที่แท้จริงของ NVFP4 บน Blackwell คือความเร็วของ FP4 tensor core บนผู้เชี่ยวชาญเหล่านั้น ไม่ใช่ไฟล์ที่เล็กกว่าอย่างมีนัยสำคัญ อย่างที่สอง การ์ดอธิบายว่า NVFP4 เป็นการได้มาซึ่งน้ำหนักแบบกำหนดได้ (deterministic) ที่สืบทอดการประเมินจาก abliteration โดยมีการแลกเปลี่ยนคุณภาพเพิ่มเติมเล็กน้อยจากผู้เชี่ยวชาญแบบ 4 บิต และไม่ได้ระบุปริมาณการแลกเปลี่ยนนั้น มันไม่ได้ถูกระบุปริมาณ — จงถือว่ามันเป็นต้นทุนที่แท้จริงแต่ไม่ระบุรายละเอียดของขนาดผู้เชี่ยวชาญที่เล็กลง ไม่ใช่สิ่งที่เล็กน้อย

การประเมิน อ่านอย่างถูกต้อง

การ์ดรายงานผลการวัด abliteration บนบิลด์ BF16 ที่ให้บริการด้วย vLLM เทียบกับ Qw​en/Qwen3.8-Flash-Next ตัวทางการ: การปฏิเสธพรอมต์อันตรายลดลงจาก 64–100% เป็นประมาณ 0–3.3% การปฏิเสธเกินควรสำหรับพรอมต์ปกติยังคงใกล้ศูนย์ และความสามารถอยู่ในช่วง ±2 จุดจากฐาน ต้องเข้าใจสามเรื่องเกี่ยวกับตัวเลขเหล่านี้ให้ถูกต้อง ประการแรก สิ่งเหล่านี้เป็นการวัดบนบิลด์ BF16 ซึ่งบิลด์ 4-bit นี้ได้รับสืบทอดโดยการอ้างเหตุผล มิได้วัดจากบิลด์นี้จริง ประการที่สอง สิ่งเหล่านี้เป็นตัวเลขจากตัวผู้พัฒนาเอง ซึ่งสร้างด้วยตัวจำแนกวลีเปิดแบบอิงกฎ (rule-based opening-phrase classifier) ที่การ์ดของคอลเลกชันนี้อธิบายว่าเป็นตัวชี้แนวโน้ม มากกว่าระดับงานตีพิมพ์ — เป็นการวัดภายในของการแก้ไขของตัวเอง ไม่ใช่การตรวจสอบโดยอิสระ และประการที่สาม สิ่งเหล่านี้ไม่ได้กล่าวถึงข้อแลกเปลี่ยนคุณภาพของ NVFP4 ที่กล่าวข้างต้น ซึ่งการ์ดไม่ได้ระบุเป็นปริมาณ

ขอบเขตความปลอดภัย — เพื่อการวิจัยเท่านั้น

ข้อความปฏิเสธความรับผิดชอบของการ์ดใบนี้ตรงไปตรงมา และเป็นส่วนหนึ่งของหน้านี้ที่ต้องไม่อ่านเหมือนข้อความสำเร็จรูปทั่วไป โมเดลนี้ถูกนำการปรับจูนด้านความปลอดภัยออกไปอย่างมีนัยสำคัญ: ทิศทางการปฏิเสธถูกกำจัดออกจาก residual stream ด้วยเทคนิค orthogonalization และโมเดลจะปฏิบัติตามคำขอที่เป็นอันตราย ผิดจริยธรรม หรือผิดกฎหมาย ซึ่ง Qwen3.8-Flash-Next เวอร์ชันดั้งเดิมจะปฏิเสธ โมเดลนี้เผยแพร่เพื่อการวิจัยที่ถูกต้องตามกฎหมายเท่านั้น — การศึกษาด้านการตีความได้ ความปลอดภัยของ AI และกลไกการปฏิเสธ การทดสอบเชิงรุก (red-teaming) และการประเมินความทนทาน — และผู้เขียนไม่รับผิดชอบใดๆ ต่อการนำไปใช้ในทางที่ผิด คุณต้องรับผิดชอบอย่างเต็มที่ต่อสิ่งที่โมเดลสร้างขึ้น และคุณต้องเพิ่มชั้นความปลอดภัยและการกลั่นกรองของคุณเองก่อนที่สิ่งใดจะเข้าถึงผู้ใช้ Apache 2.0 เป็นเกณฑ์ขั้นต่ำ และข้อกำหนดการใช้งานเพื่อการวิจัยตั้งอยู่เหนือเกณฑ์นั้น

วาทกรรมเกี่ยวกับโมเดลไร้เซ็นเซอร์เข้าใจผิดอยู่สองเรื่อง และการ์ดใบนี้ทำให้มองข้ามไม่ได้ ประการแรก {{1}}การทดสอบเจลเบรกที่สำเร็จต่อโมเดลนี้ไม่ใช่การประเมินความปลอดภัยที่ผ่านเกณฑ์ — มันคือพฤติกรรมที่ถูกโฆษณาไว้{{/1}} โมเดลที่ถูก abliterate ล้มเหลวในการทดสอบเหล่านั้นโดยตั้งใจ; การวัดด้วยการทดสอบ "เจลเบรกได้ไหม" เพียงครั้งเดียวคือการวัดว่าการปรับแต่งได้ผล ไม่ใช่ว่าการ์ดป้องกันแข็งแกร่ง ประการที่สอง {{2}}ทาวเวอร์วิทัศน์ที่ยังคงอยู่และเส้นทางการเรียกใช้เครื่องมือที่สมบูรณ์ทำให้พื้นผิวการโจมตีจริงกว้างเกินกว่าข้อความ: การฉีดพรอมพ์ผ่านรูปภาพและการใช้เครื่องมือแบบ agentic ในทางที่ผิดต่างทำงานได้เต็มรูปแบบ{{/2}} ซึ่งเป็นเหตุผลที่กรอบคิดแบบเรดทีมถือว่านี่คือการทดสอบความสามารถ ไม่ใช่ตัวเลือกแชทบอท ถ้ากรณีการใช้งานของคุณคือการส่งมอบผู้ช่วยที่ผู้ใช้โต้ตอบด้วย โมเดลนี้ไม่ใช่สำหรับคุณ และนั่นคือสิ่งที่ตั้งใจไว้

OrcaRouter เหมาะกับที่ใด

บิลด์อายุสองวัน แบบ gated และ self-host เท่านั้น คือกรณีตัวอย่างโดยแท้สำหรับการใช้ routing มากกว่าการ hardwiring เมื่อคุณรันบิลด์ NVFP4 นี้ด้วยตัวเอง คุณสามารถตั้ง route ที่ชี้ไปที่บิลด์นั้น และให้ failover ไปยัง hosted model ได้หากบิลด์ทำงานผิดปกติภายใต้โหลด — อินเทอร์เฟซเดียว ไม่ต้อง rewiring ระหว่างผู้ให้บริการเมื่อสลับ สำหรับงาน eval โดยเฉพาะ baseline แบบ censored ที่ serve อยู่คือตัวเปรียบเทียบที่คุณต้องการ และคุณไปถึงมันได้ด้วยการกดปุ่มเดียว: แคตตาล็อกมี Qwen3.8-Flash ของ Alibaba ในราคา 0.15 ดอลลาร์ต่อล้าน input และ 0.47 ดอลลาร์ต่อล้าน output ส่งผ่านในราคารายการของผู้ให้บริการโดยมี markup 0% ดังนั้น red-team harness จึงสามารถสลับไปมาระหว่างโมเดลฐานแบบ censored ที่โฮสต์อยู่กับบิลด์ uncensored ในเครื่องของคุณได้โดยไม่ต้องมีสัญญาฉบับที่สอง และการเปลี่ยนแปลงราคาของผู้ให้บริการรายใดก็ตามจะตกถึง endpoint ของคุณในวันเดียวกัน

ใครควรดาวน์โหลดสิ่งนี้ — และใครไม่ควร

ดาวน์โหลด orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 หากคุณอยู่บน Blackwell คุณต้องการพื้นที่เซิร์ฟเวอร์ที่เล็กที่สุดในคอลเลกชัน Flash-Next ด้วยความเร็ว FP4-tensor-core และคุณกำลังทำงานวิจัยที่ไลน์โมเดลนี้มีไว้สำหรับ ดาวน์โหลด Qwen3.8-Flash-Next-Uncensored-FP8 หากคุณอยู่บน Hopper หรือคุณต้องการเส้นทางที่ผ่านการตรวจสอบอย่างกว้างขวางกว่า ดาวน์โหลดบิลด์ GGUF หากคุณใช้ GPU สำหรับผู้บริโภคหรือเครื่อง CPU ดาวน์โหลดบิลด์ MLX หากคุณใช้ Apple Silicon และไม่ต้องดาวน์โหลดอะไรเลยหากเป้าหมายคือการปรับใช้สำหรับผู้ใช้โดยตรง อ่าน gate และ disclaimer ก่อนที่คุณจะยอมรับอย่างใดอย่างหนึ่ง — สิ่งเหล่านี้คือข้อกำหนดของโมเดล ไม่ใช่เพียงพิธีการ

Flash-Next ทั้งห้าบิลด์ — BF16, GGUF, MLX, FP8 และ NVFP4 — ถูกรวบรวมไว้ในคอลเลกชัน Qwen3.8-Flash-Next-Uncensoredบน Hugging Face

โมเดลคนละตัว ไม่ใช่บิลด์อื่นของตัวนี้: Qwen3.8-27B-Uncensored ถูก abliterated จากเบสคนละตัว และมีคอลเลกชันและรันบุ๊กเป็นของตัวเอง

น้ำหนักโมเดลเหล่านี้ออกแบบมาให้ใช้งานเฉพาะในเครื่องเท่านั้น สำหรับเบสไลน์ที่โฮสต์ไว้เพื่อใช้วัดผลบิลด์ที่ผ่านการ abliterate นั้น Qwen3.8-Flash ให้บริการบน OrcaRouter ในราคารายการของผู้ให้บริการโดยไม่มีการบวกเพิ่ม 0% — เป็นโมเดลมาตรฐานที่ยังคงการปรับความปลอดภัยไว้ครบถ้วน