การให้บริการ Qwen3.8-Flash-Next-Uncensored-FP8: คู่มือปฏิบัติการ vLLM สำหรับบิลด์ block-FP8

Qwen3.8-Flash-Next-Uncensored-FP8 — บิลด์แบบ block-FP8 ของ Flash-Next ฉบับ abliterated — คืออาร์ติแฟกต์ที่คุณดาวน์โหลดจริงเมื่อเซิร์ฟโมเดลนี้บนฮาร์ดแวร์ดาตาเซ็นเตอร์ และเป็นตัวสุดท้ายในคอลเล็กชันที่ได้รันบุ๊กของตัวเอง มันอยู่ที่ orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 บน Hugging Face: โดยเอาทิศทางการปฏิเสธออกจาก Qwen3.8-Flash-Next ของ Qwen แล้ว re-quantize แบบออฟไลน์ให้ตรงกับสคีมา FP8 ของ Qwen3.8-Flash-Next-FP8 ทางการ เพื่อให้ vLLM เซิร์ฟบนเส้นทางเคอร์เนลเดียวกัน มันคือบิลด์ที่ใครก็ตามที่รันโมเดลนี้บน GPU ระดับ Hopper ขึ้นไปจะเลือกใช้ และเส้นทางการเซิร์ฟมีแฟล็กหนึ่งตัวที่ตั้งผิดได้ง่าย และยากต่อการวินิจฉัยเมื่อมันผิด

ประการแรก เรื่องขอบเขต เพราะผู้อ่านมักจะทำให้มันคลุมเครือ และมันเปลี่ยนทุกอย่างด้านล่าง Qwen3.8-Flash-Next-Uncensored และ Qwen3.8-27B-Uncensored เป็นโมเดลสองตัวที่แตกต่างกัน ไม่ใช่สองบิลด์ของโมเดลเดียว น้ำหนักฐานต่างกัน — Qwen3.8-Flash-Next เทียบกับ Qwen3.8-27B — สถาปัตยกรรมต่างกัน ชุดน้ำหนักที่ปล่อยต่างกัน คอลเลกชัน Hugging Face ต่างกัน พวกมันใช้เทคนิค abliteration ร่วมกันและชื่อตระกูลเดียวกัน เท่านั้นแหละ ไม่มีตัวเลขใดจากหน้าของ 27B ที่ใช้กับโมเดลนี้ได้ และหากคุณมาที่นี่จากการค้นหา 27B รันบุ๊คเฉพาะของ 27B ก็เป็นอีกหน้าหนึ่งที่มีชุดการตัดสินใจแยกต่างหาก

หน้านี้เป็นหน้าให้บริการ Flash-Next FP8 เท่านั้น ไม่มีอะไรอื่น รันบุ๊ก GGUF/MLX ครอบคลุมคำอธิบายเรื่อง abliteration สำหรับโมเดลนี้และแนวทางการสร้างสำหรับฮาร์ดแวร์สำหรับผู้บริโภคสองสาย เทคนิคที่อยู่เบื้องหลังทั้งตระกูลอธิบายไว้ใน primer เรื่อง abliteration และในเอกสารอธิบาย uncensored-LLM ในวงกว้าง และ Qwen3.8-27B-Uncensored-FP8 ซึ่งเป็นโมเดลพี่น้องที่คุณอาจถูกชี้ให้ดู ก็มีรันบุ๊ก FP8 ของตัวเอง ในหน้านี้เราจะอยู่กับคำถามเดียว: วิธีให้บริการบิลด์ block-FP8, อะไรที่พังเมื่อทำผิด, และตัวเลขบนการ์ดบอกอะไรและไม่บอกอะไร

ก่อนที่คุณจะเริ่ม: เกตและรันไทม์

มีสองสิ่งที่คอยควบคุม repo นี้ และทั้งคู่ก่อให้เกิดความล้มเหลวที่ดูเหมือนมาจากสิ่งอื่น

ประการแรกคือการเข้าถึง ที่เก็บโมเดล (repository) มีการจำกัดการเข้าถึง: คุณต้องเข้าสู่ระบบ Hugging Face และยอมรับข้อกำหนดของที่เก็บโมเดลก่อน การดาวน์โหลดใดๆ จึงจะทำงานได้ หน้าของโมเดลเองอ่านได้โดยไม่ต้องมีบัญชี — เนื้อหาทั้งหมดบนการ์ดโมเดลเปิดเผยต่อสาธารณะ — แต่ไฟล์น้ำหนัก (weights) ไม่ใช่ พูดตรงๆ หากไม่มีเซสชันที่ล็อกอินและยอมรับข้อกำหนดแล้ว ทั้ง hf download และ vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 ต่างก็จะล้มเหลวด้วยข้อผิดพลาดในการยืนยันตัวตน ไม่ใช่ข้อความที่เป็นมิตรอย่าง “คุณต้องคลิก Agree” ให้ทำการคลิกยอมรับเพียงครั้งเดียวก่อน จากนั้นจึงดาวน์โหลดประมาณ 186 GB ด้วย hf CLI หรือปล่อยให้ vLLM จัดการที่เก็บโมเดลให้เองในการรันครั้งแรก

ประการที่สองคือรันไทม์ เช็คพอยต์ลงทะเบียนภายใต้สถาปัตยกรรม qwen4_exp (Qwen4ExpForConditionalGeneration) ซึ่ง vLLM แบบมาตรฐานและ Transformers แบบมาตรฐานไม่สามารถโหลดได้ คุณต้องใช้ vLLM อิมเมจแบบ day-0 และ transformers 5.16+ นี่คือความล้มเหลว “มันโหลดไม่ได้” ที่พบบ่อยที่สุดใน runbooks ของชุมชนในสัปดาห์นี้ — ไม่ใช่การดาวน์โหลดที่เสียหาย แต่เป็นรันไทม์ที่มาก่อนสถาปัตยกรรม อิมเมจไม่ใช่ทางเลือก; มันคือเส้นทาง

ฮาร์ดแวร์ เพื่อให้คุณวางแผนได้ก่อนจะลงมือทำอะไร: การเรียกใช้การ์ดกำหนดเป้าหมายไปที่โหนดแบบ 8 GPU และคำแนะนำตามสูตรอย่างเป็นทางการของ vLLM สำหรับเช็คพอยต์ FP8 ก็นำมาใช้ได้ที่นี่ เนื่องจากบิลด์ต่าง ๆ ตรงกันแบบเทนเซอร์ต่อเทนเซอร์ — ใช้ VRAM ของ GPU ประมาณ 265 GB สำหรับการปรับใช้แบบเต็มโหนด โดย TP2 ถือเป็นขั้นต่ำในระดับ GB300 และ TEP4/TEP8 เป็นการกำหนดค่าเต็มถาดที่ผ่านการตรวจสอบแล้ว

เหตุผลที่ FP8 build มีอยู่ — และเหตุใด “เส้นทางเคอร์เนลที่เหมือนกัน” จึงเป็นประเด็นสำคัญทั้งหมด

น้ำหนัก BF16 ที่ผ่านการ abliterated คือแหล่งความจริง (source of truth); พื้นที่เก็บนี้คือโมเดลนั้นที่ถูก re-quantize แบบออฟไลน์ โดยจงใจสร้างสูตร (recipe) อย่างเป็นทางการของ Qwen3.8-Flash-Next-FP8 ขึ้นมาใหม่ ตัว quantizer สัมผัสเฉพาะ projections ของ routed-expert ทั้ง 512 ตัว — experts.{e}.down/gate/up_proj — โดยแยก它們ออกจาก layout แบบ 3D ของ BF16 build และจัดเก็บแต่ละตัวเป็นน้ำหนัก float8_e4m3fn พร้อมกับ scale weight_scale_inv แบบ BF16 ในบล็อก 128×128 แอคติเวชันเป็นแบบ FP8 แบบไดนามิกต่อโทเคน; ไม่มีชุด calibration ทุกอย่างอื่นยังคงเป็น BF16: attention และ linear_attn, shared expert, โมดูล MoE router (mlp.gate), ตัวผสม Hyper-Connection, embeddings, lm_head, หัว speculative-decoding แบบ MTP และ vision tower ทั้งหมด

ประโยคที่ว่า 'identical kernel path' เป็นมากกว่าคำโปรยทางการตลาด และสมควรได้รับคำอธิบายสักหนึ่งประโยค บิลด์นี้ได้รับการตรวจสอบเทียบกับเช็คพอยต์ FP8 อย่างเป็นทางการ: block scales ให้ผลลัพธ์เหมือนกันทุกประการ (scale_relerr = 0) และ FP8 codes ตรงกันในระดับการปัดเศษย่อย ULP นั่นคือเหตุผลที่ vLLM ใช้ FP8 kernels แบบ block-scaled ชุดเดียวกันและ MTP speculative decoding ชุดเดียวกันกับเวอร์ชันทางการ — เทนเซอร์เหล่านี้แท้จริงแล้วคือเทนเซอร์เดียวกัน เพียงแต่ไม่มีทิศทางการปฏิเสธ

ในเชิงรูปธรรม นั่นหมายถึงคุณจะได้ ~186 GB ใน 131 ชาร์ด (เทนเซอร์ 152,089 ตัว ในจำนวนนั้น 75,264 ตัวเป็น FP8), บริบทดั้งเดิม 262,144 โทเคน, tower ของ vision + video ที่ถูกเก็บรักษาแบบไบต์ต่อไบต์ (เทนเซอร์ visual.* 333 ตัว) และ MTP head ที่สมบูรณ์ น้ำหนักถูก abliterate เป็นลำดับแรก — ทิศทางการปฏิเสธหนึ่งเดียวที่ประเมินที่เลเยอร์ 24 และถูกทำ orthogonalize ออกจากเทนเซอร์ที่เขียน residual 149 ตัวใน float32 ตาม Arditi et al. (2024) — และตัวเขียน residual ของ MTP head ก็ถูกแก้ไขอย่างสอดคล้องกัน ดังนั้น speculative decoding จึงยังคงทำงาน รายละเอียดสุดท้ายนี้ไม่ใช่สิ่งที่เห็นได้ชัด และมันคือความแตกต่างระหว่าง head ที่เร่งการถอดรหัส กับ head ที่ทำให้มันเสื่อมลงอย่างเงียบ ๆ

แฟล็กเดียวที่ตัดสินว่าการโหลดจะสำเร็จหรือล้มเหลว

Serve build นี้โดยไม่ใช้ --enable-expert-parallel แล้วคุณจะพบความล้มเหลวที่ดูเหมือน shape bug ไม่ใช่ความผิดพลาดของการ config นี่คือความล้มเหลวในการ serve ที่ถูกรายงานมากที่สุดสำหรับ checkpoint นี้ และมัน deterministic โดยสิ้นเชิง

นี่คือเลขคณิต: โปรเจกชันเกต+อัพแบบฟิวส์ของรูตเอกซ์เพิร์ตมีขนาดกลางเท่ากับ 640 Block-FP8 ควอนไทซ์เป็นบล็อกกว้าง 128 ภายใต้เทนเซอร์พาราเลลิซึมแบบธรรมดา 640 นั้นถูกแบ่งข้ามแรงก์ — 640 ÷ TP — และสำหรับระดับ TP ทั่วไป (2, 4, 8) สไลซ์ต่อแรงก์ไม่หารด้วย 128 ลงตัว: TP8 ได้ 80, TP4 ได้ 160, TP2 ได้ 320 จากนั้น vLLM จะปฏิเสธโหลดเวตพร้อมข้อผิดพลาดที่อ่านแล้วเหมือนรูปร่างไม่ตรงกัน: output_size ของเวตของเกตและอัพ = 80 ไม่หารด้วย block_n การควอนไทซ์เวต = 128 ลงตัว

Expert parallelism แก้ปัญหาโดยการแบ่งน้ำหนักของ expert ไปยัง expert-parallel ranks แทนที่จะเป็น tensor-parallel ranks ซึ่งช่วยรักษาขอบเขตของบล็อก FP8 ไว้ นี่คือเหตุผลที่ flag นี้จำเป็นสำหรับ build นี้: เมื่อใช้ --enable-expert-parallel แล้ว TP8 จะกลายเป็น TEP8 ที่ทำงานได้ (มันไม่เป็นอันตรายสำหรับ build แบบ BF16 ซึ่งไม่มีบล็อก FP8 ที่ต้องรักษา) สูตรของ vLLM อย่างเป็นทางการระบุชัดเจนว่า TP8 แบบธรรมดาเข้ากันไม่ได้กับบล็อก quantization กว้าง 128 ของ checkpoint และ issue ใน vLLM ที่ถูกเปิดสองวันหลังจาก weights ถูกปล่อยออกมาได้บันทึกความล้มเหลวแบบเดียวกันบน node 8×L40s ที่ TP2, TP4 และ TP8 หากการโหลดตายด้วย error ที่ดูเหมือนเกี่ยวกับ shape ให้ตรวจสอบ flag ก่อนที่จะตรวจสอบ download

คำสั่งที่แน่นอน

นี่คือการเรียกใช้ docker ของการ์ด ซึ่งคัดลอกมาอย่างถูกต้อง:

docker run -d --name flashnext --gpus all --ipc host -p 8000:8000 -v /path/to/Qwen3.8-Flash-Next-Uncensored-FP8:/model vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 --model /model --served-model-name Qwen3.8-Flash-Next-Uncensored --tensor-parallel-size 8 --trust-remote-code --max-model-len 262144 --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

จัดการกับธงที่ไม่ชัดเจน:

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — อิมเมจ day-0 ของ qwen4_exp นี่ไม่ใช่ vLLM ทั่วไป แต่เป็นอิมเมจเฉพาะสถาปัตยกรรม และอิมเมจมาตรฐานที่มีมาก่อน qwen4_exp จะโหลด checkpoint ไม่ได้เลย

• --trust-remote-codeโหลดโค้ดโมเดล qwen4_exp ที่มาพร้อมกับ repo หากไม่มีสิ่งนี้ ตัวโหลดจะปฏิเสธโดยหลักการ

• --max-model-len 262144 — ตรงกับหน้าต่างบริบทดั้งเดิมของโมเดล ควรระบุไว้อย่างชัดเจนที่นี่ แทนที่จะปล่อยให้เป็นค่าเริ่มต้น

• --enable-expert-parallel — จำเป็นสำหรับการสร้างแบบ FP8 ตามเหตุผลในส่วนด้านบน การ์ดระบุว่าไม่มีผลเสียต่อ BF16

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — เปิดใช้งานการเรียกใช้เครื่องมือและฟังก์ชันโดยใช้รูปแบบ XML ของ Qwen3-Coder หากปล่อยไว้โดยไม่เปิดใช้งาน โมเดลยังคงแชทได้ แต่การใช้เครื่องมือแบบเอเจนต์จะถูกปิด

• --tensor-parallel-size 8 — การเรียกใช้การ์ดนี้ถือว่าใช้โหนดที่มี GPU 8 ตัว (8× คลาส Hopper) เมื่อใช้ --enable-expert-parallel จะเป็นการปรับใช้แบบ TEP8

เมื่อคอนเทนเนอร์เริ่มทำงานแล้ว endpoint จะเข้ากันได้กับ OpenAI ที่ :8000/v1 ตั้งค่า --served-model-name ตามที่ไคลเอนต์ของคุณคาดหวัง การ์ดใช้ Qwen3.8-Flash-Next-Uncensored

ทางเลือกทั้งหมด ในการ์ดหรือที่ได้รับการยืนยันจากผู้ปฏิบัติในสัปดาห์นี้: vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 โดยตรงเมื่อเซสชัน HF ของคุณได้รับการรับรองความถูกต้องแล้ว; SGLang ผ่านอิมเมจ lmsysorg/sglang:qwen38flashnext พร้อมกับ --tp 8 --ep 8 — ข้อกำหนดแบบ expert-parallel เดียวกัน เหตุผลเดียวกัน; และ Transformers ด้วย pipeline("image-text-to-text", ...) บน transformers 5.16+ หากคุณต้องการเขียนสคริปต์โต้ตอบกับโมเดลแทนที่จะให้บริการ

สิ่งที่ใช้ได้ผลจริงเมื่อเสิร์ฟ

รูปแบบในส่วนนี้เป็นข้อค้นพบจากชุมชนจาก runbooks ของผู้ปฏิบัติงานและกระทู้ฟอรัมในสัปดาห์นี้ ไม่ใช่คำแนะนำจากผู้จำหน่าย เมื่อการตั้งค่ามากกว่าหนึ่งแบบรายงานพฤติกรรมเดียวกัน ก็ควรถือว่าเป็นเรื่องจริง:

• การถอดรหัสแบบคาดเดา (speculative decoding) ของ MTP ทำงานได้ เพิ่ม --speculative-config '{"method":"mtp","num_speculative_tokens":3}' แล้ว vLLM จะใช้ MTP head ที่เก็บรักษาไว้ โดย runbook หลายฉบับรายงานว่า MTP คือเหตุผลที่ทำให้การถอดรหัสของโมเดลนี้ยังคงใช้งานได้แม้จะมีขนาดใหญ่

• OOM ตอนโหลด? ย้ายตาราง n-gram ออกไป PLE n-gram embedding ที่มีพารามิเตอร์ 51B คือตัวการที่ทำให้หน่วยความจำเต็มอย่างไม่คาดคิดในสถาปัตยกรรมนี้ VLLM_PLE_CPU_OFFLOAD=1 ย้ายมันไปยัง RAM ของโฮสต์ — ให้พื้นที่ตรงนั้นอย่างน้อย ~51 GB ทั้งสูตรอย่างเป็นทางการและ runbook แบบ multi-node ของชุมชนต่างก็ใช้แฟล็กนี้

• วิทัศน์เป็นของจริง ไม่ใช่สิ่งหลงเหลือ ทาวเวอร์วิทัศน์ + วิดีโอถูกเก็บรักษาไว้แบบไบต์ต่อไบต์ ดังนั้นนี่จึงยังคงเป็นโมเดลวิทัศน์-ภาษาที่เต็มรูปแบบ ส่ง content part ที่เป็น image_url ใน chat completion และเอนด์พอยต์เดียวกันรองรับความเข้าใจภาพ; การตรวจสอบ OCR ของชุมชนในบิลด์นี้รายงานว่าผ่านอย่างไม่มีข้อผิดพลาด

• การให้เหตุผลเปิดใช้งานโดยค่าเริ่มต้น — และมันเปลี่ยนภาพรวมด้านความปลอดภัย เทมเพลตแชทจะเปิดใช้การคิด เว้นแต่คุณจะระบุเป็นอย่างอื่น คุณสามารถสลับได้ในแต่ละคำขอด้วย chat_template_kwargs={"enable_thinking": true|false} และเพิ่มตัวแยกการให้เหตุผล (reasoning parser) หากคุณต้องการแยกข้อความการคิดออกจากคำตอบ เนื่องจากค่าเริ่มต้นนี้ คุณจะให้บริการโมเดลที่เปิดการคิดอยู่เกือบตลอดเวลา เว้นแต่คุณจะปิดมันอย่างชัดเจน

• 262K ดั้งเดิม, 1M พร้อมการโอเวอร์ไรด์ rope บริบทดั้งเดิมคือ 262,144 โทเคน การขยายไปสู่ 1M ต้องใช้การโอเวอร์ไรด์การปรับสเกล rope แบบ YaRN อย่างชัดเจน พร้อมตัวแปรสภาพแวดล้อมที่ยกเพดาน max-model-len ของ vLLM — และคุณควรทดสอบการถดถอยของคุณภาพบริบทสั้นก่อน เพราะการขยาย 4 เท่าแบบมืดบอดคือจุดที่คุณภาพบริบทยาวมักจะเสื่อมลง

ตัวเลขบนการ์ดบอกอะไร — และอะไรที่มันไม่ได้บอก

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

หัวข้อหลักคือการล่มสลายของการปฏิเสธเมื่อปิดโหมดคิด ในชุด harmful-prompt ของการ์ด (n ตั้งแต่ 50 ถึง 150 ต่อเกณฑ์มาตรฐาน) การปฏิเสธพื้นฐานอยู่ที่ 64–100% และบิลด์นี้อยู่ที่ 0–2.7%: AdvBench 100%→2.0%, JailbreakBench 94%→0.0%, StrongREJECT 99.3%→1.3%, HarmBench 100%→1.3%, MaliciousInstruct 98%→0.0%, SimpleSafetyTests 64%→2.0%, ForbiddenQuestions 75.3%→2.7% และโพรบภาษาจีน/อังกฤษแบบกำหนดเอง 63.6%→0.0%

ตอนนี้มาถึงครึ่งที่ซื่อสัตย์ อัตราการปฏิเสธของโมเดลพื้นฐานเองร่วงลงอย่างมากเมื่อเปิดใช้งานการคิด — AdvBench ลดลงจาก 100% บนโมเดลพื้นฐานเหลือ 7.0% เมื่อเปิดใช้การให้เหตุผล — ดังนั้นการเปรียบเทียบแบบเปิดการคิดจึงไม่น่าตื่นเต้นเท่า: บิลด์นี้อยู่ที่ 0.0% ในชุดทดสอบเดียวกัน แต่มันเป็นการลดตัวเลขเล็กน้อยจากตัวเลขที่โมเดลพื้นฐานลดลงไปแล้ว หากอ้างอิงเฉพาะตัวเลขตอนปิดการคิด คุณกำลังนำเสนอเรื่องราวเพียงครึ่งที่ดูดี และนั่นคือครึ่งที่การประเมินความปลอดภัยต้องไม่พึ่งพา

การปฏิเสธมากเกินไปต่อพรอมป์ที่ไม่มีอันตราย (XSTest-safe, n=250) ลดลงจาก 9.6% บนฐานเป็น 1.2% บนบิลด์นี้เมื่อปิดการคิด — เป็นการปรับปรุงที่แท้จริง เนื่องจากโมเดลที่ปฏิเสธพรอมป์ที่ไม่มีอันตรายเป็นโหมดความล้มเหลวที่เงียบกว่า การคงไว้ซึ่งความสามารถบน MMLU / MMLU-Pro / GSM8K / CMMLU แสดงเดลต้าที่ −2.0, −1.2, −1.3 และ −0.6 จุดตามลำดับ ซึ่งสอดคล้องกับข้อกล่าวอ้างที่ว่าการทำ orthogonalizing หนึ่งทิศทางมีต้นทุนความสามารถทั่วไปใกล้ศูนย์ การเรียกใช้เครื่องมือ วิทัศน์/OCR และการให้เหตุผลทั้งหมดรายงานว่าทำงานบนบิลด์นี้

ข้อควรระวังสองประการครอบคลุมทุกสิ่งที่กล่าวมาข้างต้น เมตริกการปฏิเสธมาจากตัวจำแนกวลีเปิดแบบอิงกฎ ซึ่งการ์ดเองเรียกว่าเป็นเพียงตัวบ่งชี้ ไม่ใช่ตัวเลขระดับ LLM-judge หรือระดับที่ตีพิมพ์ได้ — คณะกรรมการมนุษย์หรือโมเดลผู้ตัดสินจะไม่ให้ตัวเลขที่ตรงกันทุกประการ และคอลัมน์ข้อควรระวังก็สำคัญ: ในชุดทดสอบแบบปิดการคิด ประมาณครึ่งถึงสามในสี่ของผลลัพธ์ของบิลด์นี้ยังคงเปิดด้วยข้อความปฏิเสธความรับผิดชอบสั้น ๆ ก่อนจะปฏิบัติตาม โมเดลแทบไม่ปฏิเสธ แต่จะเลี่ยงพูดตรง ๆ “Uncensored” ในที่นี้หมายความว่ามันตอบคำถาม ไม่ใช่ว่ามันตอบโดยไม่มีคำนำ

ส่วนความปลอดภัยไม่ใช่เพียงพิธีการ

อ่านอันนี้ก่อนที่จะดึงเวท ไม่ใช่หลังจากนั้น

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

มีสองสิ่งที่ต้องทำให้ถูกต้องแม่นยำ เพราะ build นี้ทำให้พลาดได้ง่าย

ประการแรก การทดสอบเจลเบรกที่ “ประสบความสำเร็จ” กับโมเดลนี้ไม่ใช่การประเมินความปลอดภัยที่ผ่าน มันคือพฤติกรรมที่โฆษณาไว้ หากข้ออ้างของการประเมินของคุณคือ “ความปลอดภัยของโมเดลนี้ถูกบายพาส” คุณได้วัดการออกแบบ ไม่ใช่ช่องโหว่ สิ่งที่จะถือเป็นข้อค้นพบจริงๆ คือการปฏิเสธที่ยังคงอยู่หลังการทำ abliteration หรือการถดถอยของความสามารถ — และตัวเลขในการ์ดชี้ให้เห็นว่าทั้งสองอย่างหายาก

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

ห้ามนำไปใช้งานกับผู้ใช้ปลายทางหรือนำไปใช้ในระบบจริง (production) โดยไม่เพิ่มชั้นความปลอดภัย การกลั่นกรอง และการป้องกันการนำไปใช้ในทางที่ผิดของคุณเอง ข้อกำหนดของ repo ระบุไว้อย่างชัดเจน และไม่ใช่แค่ถ้อยคำมาตรฐาน: ผลลัพธ์ที่ได้ไม่ได้สะท้อนความคิดเห็นของผู้อัปโหลดหรือของ Qwen / Alibaba

วิธีการรับค่าพื้นฐานที่ถูกเซ็นเซอร์เพื่อใช้เปรียบเทียบ

หากงานของคุณคือการวิจัยกลไกการปฏิเสธหรือการทดสอบแบบ red-teaming คุณแทบจะต้องมีโมเดลเวอร์ชันที่ถูกเซ็นเซอร์วางเคียงข้างกันอย่างแน่นอน — สถาปัตยกรรมเดียวกันแต่ไม่มีการแก้ไข — เพื่อวัดค่าความแตกต่าง (delta) บิลด์ที่ไม่ได้เซ็นเซอร์นี้ออกแบบมาให้ใช้ได้เฉพาะในเครื่องเท่านั้น: ที่เก็บโค้ด (repo) ถูกจำกัดการเข้าถึงและไม่มีบริการอนุมานผล (inference) ที่โฮสต์ไว้ ซึ่งเป็นความตั้งใจเพื่อให้เพย์โหลดที่ละเอียดอ่อนไม่ต้องส่งผ่าน API ของบุคคลที่สาม

สำหรับเบสไลน์แบบโฮสต์ OrcaRouter จะจัดเส้นทางโมเดลตระกูล Qwen ในราคารายการของผู้ให้บริการโดยไม่บวกกำไรเพิ่ม — Qwen3.8-Flash ที่ $0.15 ต่อล้านโทเค็นนำเข้า และ $0.47 ต่อล้านโทเค็นส่งออก ส่งผ่านตามที่เป็น พร้อมการเฟลโอเวอร์อัตโนมัติและคีย์เดียวสำหรับโมเดล 200+ รายการ หากราคาผู้ให้บริการเปลี่ยนแปลง จะแสดงผลภายในวันเดียวกัน หากคุณกำลังชั่งใจว่าจะรันบิลด์นี้เลยหรือไม่ หรือมันจะรับภาระในสแตกของคุณได้มากแค่ไหน นั่นคือวิธีที่ถูกที่สุดในการนำเวอร์ชันที่ถูกเซ็นเซอร์มาเทียบกับมัน โดยไม่ต้องมีสัญญาที่สองหรือโค้ดเบสที่สอง

เริ่มที่นี่

สรุปการตัดสินใจ คุณต้องมี: บัญชี Hugging Face ที่ยอมรับข้อกำหนดของ repo แล้ว; โหนดระดับ Hopper หรือใหม่กว่า — คำสั่งของการ์ดกำหนดเป้าหมาย 8 GPU และ VRAM ของ GPU ประมาณ 265 GB ตามคำแนะนำของสูตรอย่างเป็นทางการสำหรับ checkpoint FP8 ที่ตรงกัน; อิมเมจ vLLM แบบ day-0 และ transformers 5.16+; และพื้นที่ดิสก์ประมาณ 186 GB สำหรับน้ำหนักของโมเดล

ลำดับการรัน: ยอมรับข้อกำหนดของ repo → ดาวน์โหลด weights → ดึง image ของ day-0 → serve ด้วย --enable-expert-parallel → ตรวจสอบด้วยคำขอไปยัง :8000/v1/chat/completions → จากนั้นเริ่ม evals ของคุณ หากการโหลดล้มเหลวด้วยข้อผิดพลาดที่ดูเกี่ยวกับ shape ให้ตรวจสอบ flag ก่อนที่จะตรวจสอบการดาวน์โหลด

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

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% — เป็นโมเดลมาตรฐานที่ยังคงการปรับความปลอดภัยไว้ครบถ้วน