Qwen3.8-Flash-Next-Uncensored-FP8のサービング: block-FP8ビルド向けvLLMランブック

Qwen3.8-Flash-Next-Uncensored-FP8は、abliterated Flash-Nextのblock-FP8ビルドであり、データセンターのハードウェアでこのモデルをサービス提供するときに実際にダウンロードする成果物です。また、このコレクションの中で最後に専用のランブックが追加されたものです。それは、次の場所にあります：orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8（Hugging Face上）：QwenのQwen3.8-Flash-Nextから拒否方向を除去し、公式のQwen3.8-Flash-Next-FP8とまったく同じFP8スキームにオフラインで再量子化したもので、vLLMが同一のカーネルパスでサービス提供できるようにしています。これは、Hopperクラス以降のGPUでこのモデルを実行する誰もが手に取るビルドであり、サービングパスには、間違えやすく、間違えると診断が難しいフラグが1つあります。

まず、境界線について。読者はこの境界線を曖昧にし続けており、それが以下のすべてを左右するからだ。Qwen3.8-Flash-Next-Uncensored と Qwen3.8-27B-Uncensored は、1つのモデルの2つのビルドではなく、別々の2つのモデルである。基本となる重みが異なり（Qwen3.8-Flash-Next 対 Qwen3.8-27B）、アーキテクチャも、公開された重みも、Hugging Face のコレクションも異なる。共通しているのは、abliteration の手法とファミリー名だけであり、それだけである。27B のページに記載された数値は、このモデルには一切当てはまらない。27B の検索からこのページにたどり着いたとしても、27B 独自のローカル実行手順書は、別の判断事項を持つ別のページである。

このページはFlash-Next FP8サービング専用ページであり、それ以外の何物でもありません。GGUF/MLXランブックは、このモデルのアブリテレーション解説と、コンシューマー向けハードウェアの2系統のビルドラインをカバーしています。ファミリー全体の背後にある技術は、アブリテレーション入門書と、より広範なアンセンサードLLM解説書で説明されています。また、あなたが案内されたかもしれない姉妹モデルであるQwen3.8-27B-Uncensored-FP8には、専用のFP8ランブックがあります。ここでは1つの問いにのみ焦点を当てます：block-FP8ビルドをどうサーブするか、誤った方法で行うと何が壊れるか、そしてカード自体の数値が何を伝え、何を伝えないかです。

開始する前に: ゲートとランタイム

このリポジトリを左右する2つの要素があり、その両方ともが別の原因のように見える失敗を引き起こします。

最初はアクセスです。リポジトリはゲート付きです。ダウンロードが機能するには、Hugging Face にログインし、リポジトリの利用規約に同意している必要があります。モデルページ自体はアカウントなしでも読めます。カードの全文は公開されていますが、重みは非公開です。つまり、規約に同意したログインセッションがない場合、hf download も vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 も認証エラーで失敗します。「Agree をクリックしてください」といった親切なメッセージではなく。まず一度クリックスルーしてから、hf CLI で約186GBを取得するか、初回実行時に vLLM にリポジトリを解決させてください。

2つ目はランタイムです。チェックポイントはqwen4_expアーキテクチャ（Qwen4ExpForConditionalGeneration）として登録されており、標準のvLLMと標準のTransformersではロードできません。day-0 vLLMイメージとtransformers 5.16+が必要です。これは今週のコミュニティのrunbook全体で最も一般的な「ロードできない」という失敗です。原因は破損したダウンロードではなく、アーキテクチャより前のランタイムにあります。イメージは必須であり、それこそが解決の道です。

ハードウェア：何かに着手する前に計画を立てられるように。カードの呼び出しは8 GPUノードを対象としており、FP8チェックポイントに関する公式vLLMレシピのガイダンスは、ビルドがテンソル単位で一致しているため、ここでも適用されます — フルノード展開には約265 GBのGPU VRAMが必要で、TP2はGB300クラスでは最小構成として扱われ、TEP4/TEP8は検証済みのフルトレイ構成とされています。

FP8ビルドが存在する理由 — そして「identical kernel path」こそが核心

アブリテーション済みBF16ウェイトが{{1}}正本{{/1}}です。このリポジトリは、そのモデルをオフラインで再量子化したもので、{{2}}公式のQwen3.8-Flash-Next-FP8レシピを意図的に再現しています{{/2}}。量子化器が触れるのは、512個のルーティングエキスパート射影 — experts.{e}.down/gate/up_proj — のみで、{{3}}それらをBF16ビルドの3Dレイアウトから融合解除し、各要素を128×128ブロックのfloat8_e4m3fnウェイトとBF16のweight_scale_invスケールとして格納します{{/3}}。アクティベーションは{{4}}トークン単位の動的FP8{{/4}}で、キャリブレーションセットはありません。その他はすべてBF16のままです：{{5}}アテンションとlinear_attn、共有エキスパート、MoEルーター（mlp.gate）、Hyper-Connectionミキサー、エンベディング、lm_head、MTP投機的デコーディングヘッド、そしてビジョンタワー全体{{/5}}。

「identical kernel path」という記述は単なるマーケティングではなく、一文を割く価値がある。このビルドは公式FP8チェックポイントに対して検証されており、ブロックスケールは正確に再現され（scale_relerr = 0）、FP8コードはsub-ULPレベルの丸め精度で一致する。だからこそvLLMは、公式リリースと同じブロックスケールFP8カーネルと同一のMTP投機的復号を用いてこれを実行できるのだ。テンソルは実質的に同じテンソルであり、単に拒否方向（refusal direction）を除いたものにすぎない。

具体的には、131シャードにわたって約186GB（152,089個のテンソルのうち75,264個がFP8）、262,144トークンのネイティブコンテキスト、バイト単位で保存されたビジョン＋ビデオタワー（333個のvisual.*テンソル）、そして無傷のMTPヘッドが得られます。重みはまずアブリテレーションが施されました——Arditi et al.（2024）に従い、単一の拒否方向をレイヤー24で推定し、float32で149個の残差書き込みテンソルから直交化して除去する手法です——MTPヘッドの残差書き込みも一貫して編集されているため、投機的デコードは引き続き機能します。この最後の細部は自明ではなく、デコードを高速化するヘッドと、黙って劣化させるヘッドとの違いを分ける点です。

ロードの成否を決める唯一のフラグ

このビルドを --enable-expert-parallel なしでサービングすると、形状のバグのように見える障害が発生しますが、実際は設定ミスではありません。これはこのチェックポイントで最も報告されているサービング障害であり、完全に決定論的です。

以下がその計算です。ルーティングされるエキスパートの融合された gate+up 投影の中間サイズは 640 です。Block-FP8 は 128 幅のブロックで量子化します。単純なテンソル並列では、その 640 はランク間で分割されます — 640 ÷ TP — そして一般的な TP 度(2, 4, 8)では、ランクあたりのスライスは 128 で割り切れません: TP8 では 80、TP4 では 160、TP2 では 320 になります。すると vLLM はウェイトの読み込みを拒否し、形状不一致のようなエラーを出します: 「The output_size of gate's and up's weight = 80 is not divisible by weight quantization block_n = 128。」

エキスパート並列は、エキスパート重みをテンソル並列ランクではなくエキスパート並列ランク間でシャーディングすることでこの問題を修正し、FP8ブロック境界を維持します。そのため、このビルドではフラグが必須です: --enable-expert-parallel を使用すると、TP8は動作するTEP8になります。(保存すべきFP8ブロックが存在しないBF16ビルドでは無害です。) 公式のvLLMレシピは、プレーンなTP8がチェックポイントの128幅量子化ブロックと互換性がないことを明示しており、重みが公開された2日後に提出されたvLLMのissueは、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 のデイ0イメージです。これは汎用の 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 GPUノード（8× Hopper クラス）を前提としています。--enable-expert-parallel を使用すると、これは TEP8 デプロイメントになります。

コンテナが起動すると、エンドポイントは:8000/v1でOpenAI互換になります。--served-model-nameはクライアントが期待する名前に設定してください。カードはQwen3.8-Flash-Next-Uncensoredを使用します。

代替案（すべてカードに記載されているか、今週の実践者によって裏付けられたもの）：HF セッションが認証されたら、vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 を直接実行する；lmsysorg/sglang:qwen38flashnext イメージ経由の SGLang を --tp 8 --ep 8 付きで使用する — 同じエキスパート並列要件、同じ理由；そして、モデルをサーブするのではなくスクリプトで利用したい場合は、transformers 5.16+ で Transformers の pipeline("image-text-to-text", ...) を使用する。

実際に提供してみて効果のあるもの

このセクションのパターンは、今週の実践者のランブックやフォーラムスレッドで見つかったコミュニティの知見であり、ベンダーのガイダンスではありません。複数のセットアップが同じ挙動を報告している場合、それは現実のものとして扱う価値があります：

• MTP投機的デコードは機能します。--speculative-config '{"method":"mtp","num_speculative_tokens":3}' を追加すると、vLLMは保存されたMTPヘッドを使用します。複数のランブックが、このモデルのデコードがそのサイズにもかかわらず使用可能な状態を維持できる理由としてMTPを挙げています。

• ロード時にOOM？ n-gramテーブルをオフロードしましょう。このアーキテクチャのメモリ事情で意外なのは、51BパラメータのPLE n-gram埋め込みです。VLLM_PLE_CPU_OFFLOAD=1 を設定すると、それがホストRAMに移動されます。そこには少なくとも約51GBを確保してください。公式レシピとコミュニティのマルチノード実行手順書の両方がこのフラグを使用しています。

• ビジョンは実在するものであり、痕跡的なものではありません。 ビジョン+ビデオタワーはバイト単位でそのまま保持されるため、これは完全なビジョン言語モデルのままです。チャット補完でimage_urlコンテンツ部分を渡すと、同じエンドポイントが画像理解を提供します。このビルドでのコミュニティOCRプローブはクリーンな合格を報告しています。

• 推論はデフォルトでオンになっており、安全性の見方が変わります。 チャットテンプレートは、特に指定がない限り思考を有効にします。リクエストごとに chat_template_kwargs={"enable_thinking": true|false} で切り替え、思考テキストを回答から分離したい場合は推論パーサーを追加してください。このデフォルト設定のため、明示的にオフにしない限り、ほとんどの場合、思考オン（thinking-on）のモデルを提供することになります。

• ネイティブ262K、ロープオーバーライドで1M。 ネイティブコンテキストは262,144トークンです。1Mへ押し上げるには、明示的なYaRNロープスケーリングオーバーライドに加えて、vLLMのmax-model-len上限を引き上げる環境変数が必要です。また、先に短いコンテキストの品質を回帰テストすべきです。盲目的な4倍拡張は、長いコンテキストの品質が通常低下するところだからです。

カードの数字が語ること — そして語らないこと

これらは、ベンダー自身による自社編集版に対する測定結果であり、モデルカードに公開されているもので、同一のスクリプトと設定の下でvLLMで提供されたこれらの正確な重みを公式ベースと比較して測定されたものです。これらはその性質を正確に伝えてください：参考値であり、独立した監査ではありません。

見出しは、思考オフでの拒否崩壊です。モデルカードの有害プロンプトスイート（ベンチマークごとに 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%を記録しているが、それはベースがすでに削減した数値から、さらにわずかな数値を削り取っているにすぎない。思考オフの数値だけを引用すれば、それは物語の都合の良い半分を示すことになり、まさに安全性評価が依存すべきではない半分なのだ。

{{1}}無害なプロンプトに対する過剰拒否（XSTest-safe、n=250）は、ベースモデルの9.6%から、思考オフのこのビルドでは1.2%に低下します——これは真の改善です。無害なプロンプトを拒否するモデルこそが、より目立たない失敗モードだからです。{{/1}}{{2}}MMLU / MMLU-Pro / GSM8K / CMMLUにおける能力維持は、それぞれ−2.0、−1.2、−1.3、−0.6ポイントの差分を示しており、1つの方向を直交化しても汎用能力へのコストがほぼゼロであるという主張と一致しています。{{/2}}{{3}}ツール呼び出し、ビジョン/OCR、推論はすべてこのビルドで動作すると報告されています。{{/3}}

上記のすべてに2つの留保事項がつきまとう。拒否指標はルールベースの冒頭フレーズ分類器に基づくものであり、カード自体もこれを、LLM判定や公表に耐えうる数値ではなく「参考値」と位置づけている。人間のパネルでも判定モデルでも、この正確な数値が再現されることはないだろう。そして、この注記の列が重要なのだ。thinking-offスイートでは、このビルドの出力のおよそ半数から4分の3が、いまだ回答の前に短い免責事項を挟んでいる。このモデルが拒否することはまれで、むしろ言葉を濁す。ここで「無修正」と呼ばれるのは、回答をするという意味であり、前置きなしに回答するという意味ではない。

安全セクションは形だけのものではない

ウェイトを引く前にこれを読んでください。後ではなく。

このモデルはセーフティアライメントが大幅に除去されており、その仕組みは明確である：単一の拒否方向が残差ストリーム内で推定され、すべての残差書き込み行列（計149個）それぞれから直交化によって除去された。計算はfloat32で行われた。この結果は明示的に宣伝されており、偶発的なものではない。モデルカードは率直であり、このモデルはベースのQwen3.8-Flash-Nextが拒否するであろう有害・非倫理的・不快・違法なリクエストに応じる一方、実質的な組み込みガードレールを持たないと述べている。これは厳密に正当な研究——解釈可能性、AI安全性および拒否メカニズムの研究、レッドチーミング、堅牢性評価、統制実験——のために公開されており、ユーザーはそれが生成するものに対して全責任と法的責任を負う。重みの取り扱いについてはApache 2.0が規定する。

このビルドは間違えやすいので、正確にやるべきことが2つあります。

まず、このモデルに対して「成功する」脱獄プローブは、安全性評価に合格したことを示すものではない。それは宣伝どおりの動作である。評価の主張が「このモデルの安全性は回避された」というものなら、それは脆弱性ではなく、設計を測定したにすぎない。実際に「発見」となるのは、アブリテレーションを生き残る拒否、あるいは能力の後退である——そしてカードの数値は、その両方が稀であることを示唆している。

第二に、保持された攻撃対象領域はテキストよりも広い。ビジョンタワーはバイト単位でそのまま無傷であり、ツール呼び出しも機能するため、画像入力とエージェント利用の両方が有効だ。テキストプロンプトのみを調査するレッドチーム計画では、このモデルが実際に公開しているモダリティを見逃すことになる。そして、上記の拒否件数はベンダー自身の編集に対するルールベースの分類器によるものであり、安全性を含め、何の独立した監査でもない。

独自の安全性、モデレーション、および悪用防止レイヤーを追加せずに、これをエンドユーザーまたは本番環境にデプロイしないでください。リポジトリの利用規約には明確に記載されており、これは定型文ではありません：出力はアップロード者やQw​en / Ali​babaの見解を反映するものではありません。

比較用の打ち切りベースラインを取得する方法

拒否メカニズムの研究やレッドチーミングに携わっているなら、ほぼ間違いなく、このモデルの検閲版——編集を加えていない同一アーキテクチャのモデル——を並べて用意し、その差分を測定したいと思うでしょう。この検閲なしビルドは、設計上ローカルのみで動作します。リポジトリはアクセス制限付きで、ホスト型の推論デプロイメントは用意されていません。これは意図的な設計であり、センシティブなペイロードが第三者のAPIを経由することが決してないようにするためです。

ホステッドベースラインでは、OrcaRouterがQwenシリーズをプロバイダー定価のまま、マークアップなしでルーティングします。Qwen3.8-Flashは入力トークン100万件あたり0.15ドル、出力100万件あたり0.47ドルで、そのまま透過的に提供され、自動フェイルオーバーと200以上のモデルに対応する単一のAPIキーを備えています。ベンダーの価格変更は当日に反映されます。このビルドをそもそも実行すべきか、あるいはスタックのどの程度を任せられるかを検討しているなら、それは、追加の契約や追加のコードベースなしに、検閲版と比較するための安価な方法です。

ここから始める

決定の概要。必要なもの：リポジトリの利用規約に同意済みのHugging Faceアカウント、Hopper世代以降のノード（カードのコマンドは8基のGPUを対象としており、対応するFP8チェックポイントに関する公式レシピのガイダンスでは約265 GBのGPU VRAM）、デイ0のvLLMイメージとtransformers 5.16以上、そして重み用に約186 GBのディスク容量。

実行順序: リポジトリの規約に同意する → 重みをダウンロードする → day-0 イメージをプルする → --enable-expert-parallel でサーブする → :8000/v1/chat/completions へのリクエストで検証する → その後 evals を開始する。ロードが shape のようなエラーで失敗した場合は、ダウンロードを確認する前にフラグを確認してください。

そしてフレームを維持してください。これは研究用の機器であり、その条件で公開されています。その数値は、ベンダー自身の編集による独自の参考測定値です。その安全性の挙動はこの演習の要点であり、回避すべきバグではありません。それを提供し、測定し、そしてそれとあらゆる人間的なものとの間に、ご自身のモデレーションを置いてください。

5つのFlash-Nextビルド（BF16、GGUF、MLX、FP8、およびNVFP4）がすべて収集されているのはQwen3.8-Flash-Next-Uncensoredコレクション（Hugging Face上）です。

これは別のモデルであり、このモデルの別ビルドではありません：Qwen3.8-27B-Uncensoredは、異なるベースからアブリテーションされており、独自のコレクションと独自のランブックを備えています。

これらのウェイトは設計上ローカルのみです。アブリテーション済みビルドを比較評価するためのホスト型ベースラインとして、Qwen3.8-Flash は OrcaRouter 上でプロバイダー定価・マークアップ0%で提供されています——安全アライメントを維持した標準モデルです。