تقديم Qwen3.8-Flash-Next-Uncensored-FP8: دليل تشغيل vLLM لبناء block-FP8

Qwen3.8-Flash-Next-Uncensored-FP8 — نسخة block-FP8 من Flash-Next المُجرَّد من الرفض — هي البناء الذي تُنزّله فعليًا عند تشغيل هذا النموذج على أجهزة مراكز البيانات، وهي آخر بناء في المجموعة يحصل على دليل تشغيل خاص به. وهو متاح على orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 في Hugging Face: تمت إزالة اتجاه الرفض من Qwen3.8-Flash-Next من Qwen، ثم أُعيد تكميمه دون اتصال وفق مخطط FP8 الدقيق لنموذج Qwen3.8-Flash-Next-FP8 الرسمي، بحيث يخدمه vLLM على نفس مسار النواة. وهو البناء الذي سيلجأ إليه أي شخص يشغّل هذا النموذج على وحدات معالجة رسومية من فئة 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) لهذا النموذج وخطي البناء الخاصين بعتاد المستهلك؛ أما التقنية الكامنة وراء العائلة بأكملها فموضحة في مقدمة الإزالة (abliteration primer) والشرح الأوسع لنماذج LLM غير الخاضعة للرقابة؛ وQwen3.8-27B-Uncensored-FP8، النموذج الشقيق الذي ربما أُحلت إليه، له دليل تشغيل FP8 خاص به. هنا نقتصر على سؤال واحد: كيف تخدم بناء block-FP8، وما الذي يحدث عند القيام بذلك بشكل خاطئ، وما الذي تخبرك به أرقام البطاقة نفسها وما لا تخبرك به.

قبل البدء: البوابة ووقت التشغيل

هناك شيئان يتحكمان في الوصول إلى هذا المستودع، وكلاهما يُنتج أخطاءً تبدو كأنها شيء آخر.

الأول هو الوصول. المستودع مقيد: يجب أن تكون مسجلاً الدخول إلى Hugging Face وقبلت شروط المستودع قبل أن يعمل أي تنزيل. صفحة النموذج نفسها قابلة للقراءة بدون حساب — النص الكامل للبطاقة عام — لكن الأوزان ليست كذلك. بوضوح، بدون جلسة تسجيل دخول قبلت الشروط، يفشل كل من hf download و vllm serve ocarouter/Qwen3.8-Flash-Next-Uncensored-FP8 بخطأ مصادقة، وليس برسالة ودية مثل "تحتاج إلى النقر على موافق". قم بالنقر لمرة واحدة أولاً، ثم اسحب حوالي 186 جيجابايت باستخدام hf CLI أو دع vLLM يجلب المستودع عند التشغيل الأول.

الثاني هو وقت التشغيل. تُسجَّل نقطة التحقق ضمن معمارية qwen4_exp (Qwen4ExpForConditionalGeneration)، والتي لا يمكن لـ vLLM القياسي وTransformers القياسي تحميلها. تحتاج إلى صورة vLLM من يوم الإصدار (day-0) ونسخة transformers 5.16+. هذا هو الفشل الأكثر شيوعًا الذي يظهر كـ “لا يتم تحميله” عبر أدلة التشغيل المجتمعية هذا الأسبوع — ليس تنزيلًا تالفًا، بل وقت تشغيل يسبق المعمارية. الصورة ليست اختيارية؛ إنها المسار.

الأجهزة، حتى تتمكن من التخطيط قبل سحب أي شيء: استدعاء البطاقة يستهدف عقدة من 8 وحدات GPU، وتوجيهات وصفة vLLM الرسمية لنقطة فحص FP8 تنطبق هنا نظرًا لأن البنيات متطابقة موترًا بموتر — في حدود 265 جيجابايت من ذاكرة GPU VRAM لنشر كامل العقدة، مع معاملة TP2 كحد أدنى على فئة GB300 وتكوينات TEP4/TEP8 كتهيئات الصينية الكاملة المعتمدة.

لماذا يوجد إصدار FP8 — ولماذا "مسار النواة المتطابق" هو بيت القصيد

أوزان BF16 المُجرَّدة (abliterated) هي مصدر الحقيقة؛ هذا المستودع هو إعادة تكميم لهذا النموذج دون اتصال، ويعيد عمدًا إنتاج وصفة Qwen3.8-Flash-Next-FP8 الرسمية. يمسّ الكمّم فقط إسقاطات الخبراء الـ512 المُوجَّهة — experts.{e}.down/gate/up_proj — مفكّكًا إيّاها من التخطيط ثلاثي الأبعاد في بناء BF16، ويخزّن كلًا منها كأوزان float8_e4m3fn مع مقاييس weight_scale_inv بصيغة BF16 في كتل بحجم 128×128. التنشيطات تكون FP8 ديناميكية لكل توكن؛ ولا توجد مجموعة معايرة. كل شيء آخر يبقى BF16: الانتباه (attention) و linear_attn، والخبير المشترك، وموجّه MoE (mlp.gate)، وخلاطات Hyper-Connection، والتضمينات (embeddings)، و lm_head، ورأس فك الترميز التخميني MTP، وبرج الرؤية بأكمله.

إن عبارة «مسار النواة المطابق» هي أكثر من مجرد تسويق، وتستحق جملة واحدة. تم التحقق من البناء مقابل نقطة تفتيش FP8 الرسمية: تتطابق مقاييس الكتل تمامًا (scale_relerr = 0) وتتطابق رموز FP8 حتى تقريب أدق من ULP. ولهذا السبب يديرها vLLM باستخدام نفس نواة FP8 ذات المقاييس الكتلية ونفس فك التشفير التخميني MTP كما في الإصدار الرسمي — فالموترات هي في الواقع نفس الموترات، ناقصًا اتجاه الرفض.

بشكل ملموس، يمنحك ذلك نحو 186 غيغابايت موزّعة عبر 131 جزءًا (152,089 موترًا، منها 75,264 بنمط FP8)، وسياقًا أصليًا يبلغ 262,144 رمزًا، مع الحفاظ على برج الرؤية والفيديو بايت ببايت (333 موترًا من نمط visual.*)، ورأس MTP سليمًا. تم أولاً إخضاع الأوزان لعملية إزالة الرفض (abliteration) — حيث تم تقدير اتجاه رفض واحد في الطبقة 24 وإزالته تعامديًا من 149 موترًا يكتبون إلى المسار المتبقي بصيغة float32، وفقًا لما ورد في Arditi وآخرين (2024) — كما تم تعديل كتّاب المسار المتبقي في رأس MTP بشكل متسق، لذلك يستمر فك الترميز التخميني في العمل. هذا التفصيل الأخير ليس أمرًا بديهيًا، وهو الفرق بين رأس يسرّع فك الترميز وآخر يدهوره بصمت.

العلم الوحيد الذي يحدد نجاح التحميل أو فشله

قدّم هذا الإصدار دون --enable-expert-parallel وستواجه فشلًا يبدو وكأنه خطأ في الشكل، وليس خطأ في الإعداد. إنه فشل التقديم الأكثر شيوعًا المُبلَّغ عنه لنقطة التحقق هذه، وهو حتمي تمامًا.

هذه هي العملية الحسابية. الإسقاط المدمج للبوابة والرفع للخبراء الموجَّهين له حجم وسيط يبلغ 640. يقوم Block-FP8 بتكميم الكميات في كتل بعرض 128. تحت التوازي التنسوري البسيط، يتم تقسيم هذا الرقم 640 عبر الرتب — 640 ÷ TP — وبالنسبة لدرجات TP الشائعة (2، 4، 8) فإن شريحة كل مرتبة غير قابلة للقسمة على 128: TP8 تعطي 80، وTP4 تعطي 160، وTP2 تعطي 320. بعد ذلك يرفض vLLM تحميل الأوزان بخطأ يبدو كعدم تطابق في الشكل: حجم مخرجات وزن البوابة والرفع = 80 غير قابل للقسمة على كتلة تكميم الوزن block_n = 128.

يعمل التوازي الخبير على إصلاح ذلك عن طريق تقسيم أوزان الخبراء عبر مراتب التوازي الخبير بدلاً من مراتب التوازي الموتر، مما يحافظ على حدود كتل FP8. لهذا السبب تكون العلامة إلزامية لهذا البناء: مع --enable-expert-parallel، يصبح TP8 بمثابة TEP8 فعال. (وهي غير ضارة لبناء BF16، حيث لا توجد كتل FP8 للحفاظ عليها.) وصفة vLLM الرسمية صريحة بأن TP8 العادي غير متوافق مع كتل التكميم بعرض 128 الخاصة بنقطة التحقق، كما أن مشكلة vLLM المقدمة بعد يومين من إصدار الأوزان توثق الفشل نفسه على عقدة 8×L40s عند TP2 وTP4 وTP8. إذا فشل التحميل بخطأ يبدو متعلقًا بالشكل، فتحقق من العلامة قبل التحقق من التنزيل.

الأمر الدقيق

إليك استدعاء 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 — صورة qwen4_exp ليوم الإصدار. هذه ليست vLLM عامة؛ بل هي الصورة المخصصة للبنية المعمارية، والصور القياسية التي سبقت qwen4_exp لن تحمّل نقطة التحقق على الإطلاق.

• --trust-remote-code — يقوم بتحميل كود النمذجة qwen4_exp المرفق مع المستودع. بدونه يرفض المُحمِّل من حيث المبدأ.

• --max-model-len 262144 — يطابق نافذة السياق الأصلية. تريد تحديده صراحةً هنا بدلاً من تركه للقيمة الافتراضية.

• --enable-expert-parallel — مطلوب لإصدار FP8، للأسباب المذكورة في القسم أعلاه. وتشير البطاقة إلى أنه غير ضار لـ BF16.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — يُفعّل استدعاء الأدوات والدوال باستخدام تنسيق Qwen3-Coder XML. إذا تركتها معطّلة، سيظل النموذج يتحادث، لكن استخدام الأدوات الوكيلية سيكون متوقفًا.

• --tensor-parallel-size 8 — يفترض استدعاء البطاقة عقدة ذات 8 وحدات معالجة رسومية (8× من فئة Hopper). مع --enable-expert-parallel، يكون ذلك نشر TEP8.

بمجرد تشغيل الحاوية، ستكون نقطة النهاية متوافقة مع 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 — نفس متطلب التوازي على مستوى الخبراء، ونفس السبب؛ وTransformers مع pipeline("image-text-to-text", ...) على transformers 5.16+ إذا كنت تريد البرمجة النصية ضد النموذج بدلاً من تقديمه.

ما الذي ينجح فعلاً عند تقديمه

الأنماط في هذا القسم هي نتائج مجتمعية من أدلة تشغيل الممارسين وسلاسل المنتديات هذا الأسبوع، وليست إرشادات من البائعين. عندما تبلغ أكثر من بيئة إعداد عن نفس السلوك، فمن الجدير التعامل معها على أنها حقيقية:

• يعمل فك الترميز التخميني MTP. أضف --speculative-config '{"method":"mtp","num_speculative_tokens":3}' وسيستخدم vLLM رأس MTP المحفوظ. تشير عدة أدلة تشغيل (runbooks) إلى أن MTP هو السبب في بقاء فك ترميز هذا النموذج قابلاً للاستخدام رغم حجمه.

• OOM عند التحميل؟ أفرِغ جدول n-gram. إن تضمين n-gram لـ PLE ذي المعاملات 51B هو المفاجأة في استهلاك الذاكرة في هذه البنية. يعمل VLLM_PLE_CPU_OFFLOAD=1 على نقل الجدول إلى ذاكرة المضيف — خصص له ما لا يقل عن 51 جيجابايت تقريبًا هناك. تعتمد كل من الوصفة الرسمية وأدلة التشغيل متعددة العقد من المجتمع على هذا الخيار.

• الرؤية حقيقية، وليست أثرية.برج الرؤية والفيديو محفوظ بايتًا ببايت، لذلك يبقى هذا نموذج رؤية-لغة كاملًا. مرّر جزء محتوى image_url في إكمال محادثة، ويخدم نقطة النهاية نفسها فهم الصور؛ فحوصات OCR المجتمعية على هذا البناء تُظهر نجاحًا نظيفًا.

• الاستدلال مفعّل افتراضيًا — وهذا يغيّر صورة السلامة. قالب الدردشة يتيح التفكير ما لم تنص على خلاف ذلك. بدّل لكل طلب باستخدام chat_template_kwargs={"enable_thinking": true|false}، وأضِف محلّل استدلال إذا أردت فصل نص التفكير عن الإجابة. وبسبب هذا الوضع الافتراضي، فإنك تخدم نموذج التفكير المفعّل دائمًا تقريبًا ما لم تقم بإيقافه صراحةً.

• 262K أصلي، و1M مع تجاوز rope.السياق الأصلي هو 262,144 رمزًا. الوصول إلى 1M يتطلب تجاوزًا صريحًا لتوسيع نطاق rope بنمط YaRN بالإضافة إلى متغير بيئة يرفع سقف max-model-len في vLLM — ويجب عليك أولًا إجراء اختبارات انحدار على جودة السياق الأقصر، لأن التوسيع الأعمى بمقدار 4× هو الحالة التي تتدهور فيها جودة السياق الطويل عادةً.

ما تقوله أرقام البطاقة — وما لا تقوله

هذه قياسات البائع نفسه على تعديله الخاص، وهي منشورة في بطاقة النموذج، وقِيست على هذه الأوزان بالتحديد عبر تقديمها باستخدام vLLM مقابل النموذج الأساسي الرسمي، وبنفس النصوص البرمجية والإعدادات. انقلها كما هي: أرقام إرشادية فقط، وليست تدقيقًا مستقلًا.

العنوان الرئيسي هو انهيار الرفض عند إيقاف التفكير. في مجموعة اختبارات الطلبات الضارة على البطاقة (عدد الحالات من 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، ن=250) من 9.6% في النموذج الأساسي إلى 1.2% في هذا الإصدار مع إيقاف التفكير — وهذا تحسّن حقيقي، إذ إن النموذج الذي يرفض الاستفسارات غير المؤذية يمثّل نمط الفشل الأكثر هدوءًا. أما الاحتفاظ بالقدرات على MMLU / MMLU-Pro / GSM8K / CMMLU فيُظهر فروقًا مقدارها −2.0 و−1.2 و−1.3 و−0.6 نقطة على التوالي، وهو ما يتسق مع الادعاء بأن تعامد اتجاه واحد يكلف قدرة عامة شبه معدومة. كما أُبلغ عن أن استدعاء الأدوات، والرؤية/OCR، والاستدلال تعمل جميعها في هذا الإصدار.

ثمة تحفظان يخيمان على كل ما سبق. مقياس الرفض مستمد من مصنّف قائم على القواعد لعبارات الافتتاح، وهو ما تصفه البطاقة نفسها بأنه إرشادي وليس رقمًا صادرًا عن نموذج حكم أو بمستوى النشر — فلن تعيد لجنة بشرية أو نموذج تحكيم إنتاج هذه الأرقام بالضبط. كما أن عمود التحفظات مهم: في مجموعة اختبارات إيقاف التفكير، لا يزال ما يقرب من نصف إلى ثلاثة أرباع مخرجات هذا الإصدار يُفتتح ببيان إخلاء مسؤولية قصير قبل الامتثال. والنموذج نادرًا ما يرفض؛ بل يتحفظ. «غير المقيّد» هنا يعني أنه يجيب، لا أنه يجيب دون مقدمة.

قسم السلامة ليس مجرد إجراء شكلي

اقرأ هذا قبل رفع الأثقال، وليس بعده.

تمت إزالة مواءمة السلامة من هذا النموذج بشكل جوهري، والآلية محددة: {{1}}تم تقدير اتجاه رفض واحد في التدفق المتبقي وإزالته بتعامد من كل مصفوفة كتابة متبقية — 149 منها — محسوبة بصيغة float32{{/1}}. {{2}}النتيجة معلنة وليست عرضية{{/2}}. البطاقة صريحة في أن النموذج سيلبي الطلبات الضارة وغير الأخلاقية والمسيئة وغير القانونية التي كان النموذج الأساسي Qwen3.8-Flash-Next سيرفضها، وأنه لا يمتلك حواجز حماية مدمجة فعلية. {{3}}تم إصداره حصريًا للبحث المشروع — قابلية التفسير، ودراسة سلامة الذكاء الاصطناعي وآلية الرفض، والاختبار العدائي، وتقييم المتانة، والتجارب المضبوطة — ويتحمل المستخدم المسؤولية الكاملة والتبعات القانونية عمّا يولّده{{/3}}. {{4}}ترخيص Apache 2.0 يحدد ما يجوز لك فعله بالأوزان{{/4}}.

شيئان يجب ضبطهما بدقة، لأن هذا الإصدار يجعل من السهل الخطأ فيهما.

أولاً، اختبار كسر الحماية الذي “ينجح” ضد هذا النموذج ليس تقييمًا ناجحًا للسلامة. إنه السلوك المُعلن عنه. إذا كان ادعاء تقييمك هو “تم تجاوز سلامة هذا النموذج”، فأنت قد قست التصميم، لا ثغرة. ما سيشكل اكتشافًا فعليًا هو رفضٌ يصمد أمام عملية الإزالة، أو تراجع في القدرات — وأرقام بطاقة النموذج تشير إلى أن كلاهما نادر.

ثانيًا، سطح الهجوم المحفوظ أوسع من النص. برج الرؤية سليم بايتًا ببايت، واستدعاء الأدوات يعمل، لذا فإن إدخال الصور والاستخدام الوكيل كلاهما نشط. وخطة الفريق الأحمر التي تختبر فقط مطالبات النص تفوت الأنماط التي يكشفها هذا النموذج فعليًا. وأرقام الرفض أعلاه هي مصنّف قائم على قواعد على تعديل البائع نفسه — وهي ليست تدقيقًا مستقلاً لأي شيء، بما في ذلك السلامة.

لا تنشر هذا للمستخدمين النهائيين أو إلى بيئة الإنتاج دون إضافة طبقات الحماية والمراقبة ومنع الإساءة الخاصة بك. شروط المستودع تنص على ذلك بوضوح، وهي ليست نصًا نمطيًا: المخرجات لا تعكس آراء القائمين على الرفع أو آراء Qw​en / Ali​baba.

كيفية الحصول على خط أساس مبتور للمقارنة

إذا كان عملك هو البحث في آليات الرفض أو اختبار الاختراق (red-teaming)، فأنت شبه مؤكد تريد النسخة الخاضعة للرقابة من هذا النموذج جنبًا إلى جنب — نفس البنية بدون التعديل — لقياس الفرق. هذا الإصدار غير الخاضع للرقابة محلي فقط حسب التصميم: المستودع (repo) مقيد الوصول ولا يحتوي على نشر استدلال مستضاف، وهذا مقصود لضمان عدم مرور الحمولات الحساسة عبر واجهة برمجة تطبيقات تابعة لجهة خارجية.

بالنسبة لخط الأساس المُستضاف، يوجّه OrcaRouter خط Qwen بسعر القائمة لدى المزوّد دون أي هامش ربح — Qwen3.8-Flash بسعر 0.15 دولار لكل مليون رمز إدخال و0.47 دولار لكل مليون رمز إخراج، مع تمرير الأسعار كما هي، وتجاوز الفشل التلقائي ومفتاح واحد لأكثر من 200 نموذج. يظهر تغيير سعر المزوّد في اليوم نفسه. إذا كنت تزن ما إذا كان يجب تشغيل هذا الإصدار أصلًا، أو مقدار ما يمكن أن يتحمّله من مجموعتك التقنية، فهذه هي الطريقة الرخيصة لمقارنة النسخة الخاضعة للرقابة به دون عقد ثانٍ أو قاعدة أكواد ثانية.

ابدأ من هنا

ملخص القرار. تحتاج إلى: حساب على Hugging Face مع قبول شروط المستودع؛ عقدة من فئة Hopper أو أحدث — يستهدف أمر البطاقة 8 وحدات معالجة رسومية، وحوالي 265 جيجابايت من ذاكرة VRAM للبطاقات الرسومية وفقًا لتوجيهات الوصفة الرسمية لنقطة التحقق FP8 المطابقة؛ وصورة vLLM الخاصة بالإطلاق الأول وtransformers الإصدار 5.16 فما فوق؛ وحوالي 186 جيجابايت من مساحة القرص للأوزان.

ترتيب التشغيل: اقبل شروط المستودع ← نزّل الأوزان ← اسحب صورة اليوم 0 ← شغّل الخادم مع --enable-expert-parallel ← تحقق من خلال طلب إلى :8000/v1/chat/completions ← ثم ابدأ تقييماتك. إذا فشل التحميل بخطأ يبدو أنه يتعلق بالشكل، افحص الخيار قبل أن تفحص التنزيل.

وأبقِ الإطار. هذه أداة بحثية أُطلقت بهذا الشرط. أرقامها هي قياسات البائع الاسترشادية على نسخته الخاصة. سلوكها الآمن هو الهدف من التمرين، وليس عيبًا يجب التحايل عليه. شغّلها، وقِسها، وضع رقابتك الخاصة بينها وبين أي شيء بشري.

جميع إصدارات Flash-Next الخمسة — BF16 وGGUF وMLX وFP8 وNVFP4 — مجمعة في مجموعة Qwen3.8-Flash-Next-Uncensored على Hugging Face.

نموذج مختلف، وليس نسخة أخرى من هذا النموذج: Qwen3.8-27B-Uncensored هو نموذج مجرّد من قاعدة مختلفة وله مجموعته الخاصة ودفاتر تشغيله الخاصة.

هذه الأوزان محلية فقط بحكم التصميم. للحصول على خط أساس مستضاف لقياس البناء المُجرَّد من المحاذاة مقابلَه، Qwen3.8-Flash يُقدَّم على OrcaRouter بسعر قائمة المزود بدون أي هامش ربح — النموذج الأصلي مع محاذاة السلامة سليمة.