Qwen3.8 一時デプロイ：Ollama未対応でも検証を続ける方法

症状：Qwen3.8の重みは取得できたのに、Ollamaや手元の変換処理で読み込めない。
最速解法：モデルサービスとアプリを切り離し、公式に認識できる一時ランタイムからOpenAI互換APIを公開して、同じテストを続けてください。

この方法は、Qwen3.8の正式対応を宣言するものではありません。2026年8月14日時点で、Qwen公式のHugging Face組織ページには「Qwen3.8-2.4T-A95B」と「Qwen3.8-2.4T-A95B-FP8」が掲載されていますが、Qwen3.8-27Bの掲載は確認できません。まずはモデル一覧、モデルカード、各ランタイムの公式リリースとマージ済みコードを突き合わせてください。(huggingface.co)

この手順が必要な人

Ollamaの対応を待つ間も、プロンプト、出力形式、基本能力を確認したい個人開発者向けです。

ツール呼び出し、多段の状態管理、構造化出力を含むAI Agentを継続検証したいチームにも向いています。共有用の隔離環境、アクセス制御、検証ログを整えたい運用担当者にも使える手順です。

重み、ランタイム、アプリは別々に判定する

「Hugging Faceに重みがある」「ランタイムがモデル名を表示する」「アプリから正常に呼び出せる」は、別の判定です。

確認すべき層は次の3つです。

• モデル層：重み、設定ファイル、トークナイザー、ライセンスが揃っているか。
• ランタイム層：そのアーキテクチャを正式に認識し、読み込み処理を持つか。
• アプリ層：ストリーミング、ツール呼び出し、構造化出力、エラー処理が契約どおりか。

旧版Qwen3向けの文書にあるコマンドは、Qwen3.8の直接対応を証明しません。Qwen公式のデプロイ文書も、記載されたモデルとランタイムの組み合わせを示す資料として扱い、世代をまたいだ互換性の根拠にはしないでください。(github.com)

この切り分けをしないと、次の隠れたコストが発生します。

• 変換ファイルの出所やハッシュを追えず、再現性が失われる。
• モデルは読み込めても、テンプレートや終了条件がずれて出力が壊れる。
• APIの外形だけ合っていて、思考内容、ツール引数、構造化出力の解釈が変わる。
• ローカル環境で失敗したのか、モデル自体の能力不足なのか判別できない。
• チーム内で異なるコミット、量子化形式、起動オプションを使い、結果を比較できなくなる。

注意：未マージのプルリクエスト、個人配布の変換ファイル、コミュニティの成功報告は、検証の手掛かりにはなりますが、正式対応の証拠ではありません。採用する場合も「暫定実験」と記録し、業務テストの基準環境とは分けてください。

一人の冒頭確認は、変更を増やさず隔離する

単に「ロードできるか」「短い対話が成立するか」「生成が最後まで終わるか」を見たいなら、Ollamaの設定を何度も書き換えるより、Qwen3.8を明示的に扱える環境を一回だけ作る方が安全です。

次の順番で確認します。

1. モデルの出所を固定する
   Qwen公式のモデルページ、Hugging Face上のリポジトリ名、コミットまたはファイルのハッシュを記録します。ミラーや再変換物を使う場合は、元ファイルとの関係を残します。

2. ライセンスと利用条件を確認する
   個人検証、社内共有、外部デモでは許可範囲が異なる場合があります。ライセンス欄を保存し、チームの利用目的と照合します。

3. ランタイムの対応根拠を確認する
   公式ドキュメント、リリースノート、マージ済みコードのいずれかを確認します。vLLM、SGLang、llama.cppの各プロジェクトは、リリース、対応モデル、プルリクエストの状態を別々に見てください。(github.com)

4. 依存関係を環境単位で固定する
   Python、推論フレームワーク、GPUドライバー、CUDA系ライブラリなどを一覧化します。バージョンは、起動した環境の出力をそのまま保存してください。

5. 起動ログを確認する
   モデル名だけでなく、認識されたアーキテクチャ、データ型、コンテキスト設定、読み込み完了、警告、終了理由を確認します。

6. 最小の対話を実行する
   短い質問を送り、空レスポンス、無限生成、途中停止、文字化け、終了理由の欠落がないか確認します。

7. 環境を捨てずに記録する
   起動方法、依存関係、モデルの出所、ログ、失敗した入力を保存します。あとでOllamaへ戻す際に、比較基準として使えます。

ここでは、正式なQwen3.8対応が確認できないまま、旧版のQwen3用コマンドを提示しません。起動パラメーターは、対象ランタイムの当該バージョン文書か、あなたが保存した実行ログと一致するものだけを使ってください。

アプリ回帰は、先にAPI契約を固定する

アプリ側の回帰試験では、モデルの起動方法よりもサービス契約の固定を優先します。コード内にOllamaのURLや固有モデル名が残っていると、ランタイムを切り替えるたびに修正範囲が広がります。

設定層へ次の項目を移してください。

• base_url
• モデル識別子
• APIキーまたは認証方式
• 接続タイムアウト
• 生成タイムアウト
• ストリーミングの有無
• 最大入力長と最大出力長
• 思考内容を受け取るかどうか

OpenAI互換インターフェースを使えば、アプリ側は原則としてベースURLとモデル識別子を変更するだけで接続できます。ただし、「互換」はリクエストとレスポンスの外形を指すことが多く、拡張パラメーターの意味まで一致するとは限りません。

最低限、次のテストを固定データで実施します。

• 通常応答が返るか。
• ストリーミングの各チャンクを正しく結合できるか。
• finish_reason相当の終了情報を受け取れるか。
• コンテキストをまたいだ会話が崩れないか。
• 4xx、5xx、タイムアウトを既存の再試行処理が扱えるか。
• JSONやスキーマ指定が、期待する形式で返るか。

AI Agentの呼び出し部分は、モデル名ではなく設定プロファイルを参照させます。これで、臨時ランタイム、確認済みのホスト型API、Ollamaを同じテストハーネスから選べます。

AI Agentの連携では、チャットよりツール呼び出しを優先する

Agent連携で普通の質問に答えられても、実運用の検証が完了したとは言えません。重要なのは、ツール選択、引数の構造、ツール結果の再投入、最終回答までの一連の状態です。

次の記録を分けて保存してください。

1. モデルがツールを選択したか。
2. ツール名が期待した値か。
3. 引数が有効なJSONになっているか。
4. 必須フィールドや型が維持されているか。
5. ツールの結果を次のターンへ正しく戻せたか。
6. 最終回答に内部用フィールドが漏れていないか。
7. ツール失敗時に、再試行または説明へ正しく分岐したか。

Qwenの公式ドキュメントや各ランタイムのツール呼び出し文書を照合し、思考内容のフィールド、ツール呼び出しの表現、構造化出力の扱いを確認します。SGLangの公式文書でも、思考内容の解析やツール呼び出しの解析は個別の設定として説明され、すべてがOpenAI互換になるわけではないとされています。(github.com)

ここで差異が出ても、すぐに「Qwen3.8の能力不足」と判断しないでください。パーサーやアダプター層の差なら、次のいずれかで吸収できます。

• ツール引数をJSONとして再検証する。
• 思考内容と本文を別フィールドへ分離する。
• 不正な引数だけを検出して再試行する。
• ランタイム固有の拡張パラメーターを設定層に閉じ込める。
• 同じ入力、ツール定義、サンプリング設定で再現試験する。

チーム共有は、性能より再現性を優先する

複数人が並行して確認する場合や、手元のMacでモデル規模に対して余裕がない場合は、短期間の隔離算力環境を使う選択肢があります。目的は本番基盤を先に作ることではなく、統一したテスト入口を用意することです。

共有環境では、次の順で管理します。

1. 接続元のIP、VPN、認証ユーザーを限定する。
2. モデルファイルの保存先と読み取り権限を分ける。
3. 実行環境のイメージまたは依存関係を固定する。
4. 起動ログとモデル読み込みログを保存する。
5. テストバッチごとに入力、モデル識別子、ランタイムのコミットまたはリリースを記録する。
6. 使い終わった認証情報と公開ポートを無効化する。

クラウドやリモート環境で動いたことは、手元のOllamaが対応したことを意味しません。モデルサービスとクライアントを分離した結果、別のランタイムで検証できただけです。この境界を記録に明記してください。

チームで運用する場合は、MacHTMLのコンソールや利用時のヘルプも確認し、接続方法、アクセス権、環境の破棄手順を先に決めておくと、検証後の片付け漏れを減らせます。

よくある判断を先に整理する

Qwen3.8をOllamaで使えないときの代替

最初の選択肢は、Qwen3.8を正式に認識できる別ランタイムです。vLLMやSGLangを候補にできますが、公式文書に対象モデルがない場合は、旧世代の手順をそのまま実行しないでください。確認済みのホスト型APIを使う方法もあります。

Agentコードを変更せずに切り替える方法

アプリが設定層のbase_url、モデル識別子、認証情報を参照していれば、接続先の変更で切り替えられます。Ollama固有のAPI拡張や独自レスポンスを業務ロジックへ直接書いている場合は、完全な無変更切り替えはできません。先にアダプターを置いてください。

一時サービスの合格条件

通常のチャットだけで合格にしないでください。ストリーミング、終了理由、タイムアウト、構造化出力、ツール選択、引数の妥当性、複数ターンの状態復元を、固定した入力で確認します。

Ollama対応後の切り戻し

Ollamaの公式リリース、モデルタグ、読み込み成功の3点を確認してから切り替えます。テストデータ、プロンプト、ツール定義、サンプリング設定を変えずに比較し、差分が残るなら一時サービスを退避先として保持します。

臨時環境とOllamaを切り替える判断表

Ollamaの公式リリースページでは、モデル対応が追加されたリリースに変更内容が記載されます。リリース番号だけでなく、対象モデル名やアーキテクチャの記述を確認してください。(github.com)

Ollamaへ戻す前に、同じ試験をもう一度行う

正式対応が確認できたら、次の条件をすべて満たした時点で切り戻します。

• 公式リリースまたは公式モデルタグで対象が確認できる。
• 目的のファイルを実際に読み込める。
• 基本対話が最後まで完了する。
• ストリーミングと終了理由が既存契約に合う。
• ツール呼び出しの名前と引数が期待どおりである。
• 構造化出力とエラー処理が許容範囲に収まる。
• 重要なAgentシナリオが一時環境と同じ結果になる。

比較時は、プロンプト、温度、最大出力、ツール定義、テストデータを変えません。出力の文章が少し違うことより、JSONの構造、ツール選択、停止条件、エラーの扱いを優先して比較します。

差異が残った場合は、臨時サービスをすぐに削除しないでください。回帰テストの退避先として短期間保持し、差異がモデル、テンプレート、パーサー、サンプリングのどこから出たかを切り分けます。

現在の構成がローカルOllamaだけに依存していると、対応待ち、手元のメモリ制限、共有設定のばらつきが重なり、AI Agentの検証日程を動かしにくくなります。一方、MacHTMLで短期の隔離算力環境を用意すれば、モデル規模、検証期間、同時利用者数、ツール呼び出しの試験範囲を分けて設計できます。長期の常時負荷や物理デバイス接続が必要なら自前環境が適しますが、Ollamaの対応待ちを越えて一時的に検証を進める用途では、記録付きのレンタル環境の方が切り替えと撤去を管理しやすいでしょう。利用前にはMacHTMLの料金案内で条件を確認し、モデルの出所、実行期間、並行利用、ツール試験の項目を整理してから環境を確保してください。