onwx'(onwx-dash)— Ryzen AI の GPU + NPU、USB4 で 2 台を 1 つに
日本語 | English
onwx'(オンダブルエックス・ダッシュ、中の名前は onwx-dash)は、AMD Ryzen AI の PC で大きな言語モデルを動かすアプリです。Ryzen AI Max(Strix Halo、Radeon 8060S / 8050S)と Ryzen AI 300(Radeon 890M / 880M)の Windows と Linux で動き、チャット画面、OpenAI 互換 API、タスクトレイのモデル管理がそろっています。
- GPU + NPU:モデル(GGUF)は内蔵の Radeon GPU が動かし、XDNA2 NPU がプロンプトの読み込みの一部を引き受けます。1 台でも、プロンプトの読み込みは GPU だけで llama.cpp の約 1.2〜2.7 倍、NPU が手伝うとさらに速くなります
- USB4 で 2 台を 1 つに(Linux):2 台の PC を USB4 ケーブルでつなぎ、1 つのモデルを半分ずつ持って同時に計算します。32 GB の PC 1 台には載らない 74B のモデルも動き、生成は 1 台の約 1.5〜1.8 倍です。つなぎ方は 2 通りあります
- TCP/IP:ケーブルを挿すだけ。アプリが相手の PC を見つけてアドレスを決めます
- 生転送(設定では「生接続」):専用のカーネルモジュール(onwxtp)で、TCP/IP を通さずに USB4 を直接使います。ボトルネックが少なく、ケーブル 2 本も束ねられ、生成がもう一段速くなります
- やり取りは計算の裏に隠す:llama.cpp の 2 台(RPC)は層を前と後ろで分けて交代で計算するので、片方がいつも待っていて、生成は 1 台より遅くなります。onwx' はどの層も 2 台で同時に計算し、途中の和のやり取りは専用のスレッドが受け持ちます。プロンプトでは次のまとまりを計算している裏でやり取りするので、つなぎ方による差がほとんど出ません
0.6.1 までは onwx-halo という名前でした。NPU だけで動かすアプリは onwx です。
すぐに使う
Windows(PowerShell):
irm https://huggingface.co/ryugyosoft/onwx-dash/resolve/main/install.ps1 | iex
Linux(Ubuntu 24.04 以降):
wget -qO- https://huggingface.co/ryugyosoft/onwx-dash/resolve/main/install.sh | bash
開いたウィンドウの「モデル」でモデルをダウンロードして「ロード」を押せば、http://localhost:8110/chat で話せます(API は http://localhost:8110/v1)。必要なものと詳しい手順は下の「必要なもの」「インストール」にあります。
2 台で動かす(USB4、1.0 から。Linux)
2 台の PC を USB4(Thunderbolt)のケーブルでつなぎ、1 つのモデルを半分ずつ持って動かします。それぞれの PC が GPU に置く重みは約半分になるので、1 台ではメモリが足りないモデルも動きます(Nemotron 3.5 Bolt 74B-A9B は 22 GB の GGUF で、各 PC に約 11 GB)。生成もプロンプトの読み込みも 1 台より速くなります。「メイン PC」はいつもどおりアプリ(サーバー、チャット、API)を動かし、「補助 PC」はエンジンだけを動かしてメイン PC に付いていきます。モデルはメイン PC にあれば動きます:読み込みのたびに、メイン PC が補助 PC の分(モデルの約半分)を USB4 で送ります(設定で、補助 PC に置いた同じ GGUF から読み込むこともできます)。答えは 1 台で動かしたときとほぼ同じです(足し算の順序が変わるので、まったく同じとは限りません)。
速さ(1.2.1 で測定)
| tok/s | onwx' 1 台 | onwx' 2 台・TCP/IP | onwx' 2 台・生転送 | llama.cpp 1 台 | llama.cpp 2 台(RPC) |
|---|---|---|---|---|---|
| Nemotron 3.5 Bolt 74B-A9B 生成 | 14.3 | 21.7 | 22.8 | 12.5 | 11.3 |
| Qwen3.6 35B-A3B 生成 | 25.2 | 36.9 | 38.6 | 24.4 | 22.1 |
| Qwen3.6 35B-A3B 生成(MTP の下書き) | 33.9 | 45.6 | 47.4 | - | - |
| Qwen3.8 27B 生成 | 4.3 | 7.7 | 7.9 | 4.5 | 4.4 |
| Nemotron プロンプト 8,000 トークン | 270 | 412 | 404 | 184 | 284 |
| Qwen3.6 プロンプト 2,000 / 8,000 トークン | 1,018 / 1,043 | 1,342 / 1,500 | 1,357 / 1,488 | 528 / 503 | 715 / 729 |
| Qwen3.8 27B プロンプト 2,000 トークン | 183 | 286 | 288 | 143 | 167 |
1 台 = Ryzen AI 9 HX 470(Radeon 890M、64 GB)、2 台 = HX 470 + Ryzen AI 9 HX PRO 370(Radeon 890M、32 GB)、Ubuntu 26.04、GPU のみ、貪欲。プロンプトは 2 回目(温まったあと)の値。TCP/IP はケーブル 1 本、生転送は 2 本。llama.cpp は b12211 の Vulkan 版(llama-bench)、2 台は RPC の既定(層で分ける)。32 GB の PC 1 台には Nemotron は載りません。
なぜ 2 台で速くなるか
- テンソル並列:アテンションのヘッド、Mamba / DeltaNet のグループ、エキスパートの FFN などを、どの層も 2 台で半分ずつ持ちます。2 台が同時に計算し、層の途中で部分和を足し合わせます。読む重みが半分になるので、メモリの帯域で決まる生成が速くなります
- やり取りを隠す:生成では 1 トークンに数十回、数 KB の和をやり取りします。専用のスレッドが待ち構え、GPU からじかに読み書きできるメモリを使うので、コピーと待ちがほとんどありません。プロンプトでは 2 つのまとまりを交互に計算し、片方の和を送っている間にもう片方を計算します(TCP/IP でも生転送でも同じ速さなのはこのため)
- 生転送:TCP/IP の代わりに、自作のカーネルモジュール onwxtp が USB4 の DMA リングを直接使います。1 回のやり取りが約 23 µs から約 14 µs に縮み、ケーブル 2 本を同時に使えて、生成が 3〜5 % 速くなります
使い方
- ケーブル:2 台を USB4 のケーブルでつなぎます。「つなぎ方」が「自動(USB4 ケーブル)」(1.2 からの既定)なら、IP アドレスの設定は要りません(アプリが相手の PC を見つけて 2 台のアドレスを決めます。画面に「USB4 の接続を設定」のボタンが出たら押してください)。LAN などでつなぐとき(「IP アドレスを指定」)だけ、ネットワークアダプターに同じサブネットの固定 IP を自分で付けます(例:192.168.2.1 と 192.168.2.2。
thunderbolt0が出ないときはsudo modprobe thunderbolt_net):sudo nmcli con add type ethernet ifname thunderbolt0 con-name usb4 ipv4.method manual ipv4.addresses 192.168.2.2/24 802-3-ethernet.mtu 9000 sudo nmcli con up usb4 - アプリ:両方の PC に同じ版の onwx-dash を入れます。モデル(GGUF)はメイン PC にだけあれば十分です
- 設定 → 2 台で動かす:両方の PC でオンにし、役割(メイン PC / 補助 PC)を選びます。「待ち受ける PC」と「つなぎ方」は両方の PC で同じ値にします(「IP アドレスを指定」のときは「待ち受ける PC の IP アドレス」とポート 50120 も)。生接続(1.2 から、オプション):「つなぎ方」で「生接続(USB4・TCP/IP なし)」を選び、両方の PC で「モジュールをインストール」を一度押すと、TCP/IP を通さずに USB4 を直接使います(生成が数 % 速くなり、ケーブル 2 本なら 2 本とも使います。管理者のパスワードを聞かれ、初回は数分かかることがあります。Secure Boot がオンの PC では、画面に出る手順で鍵の登録が要ります)
- 補助 PC を先に開始:補助 PC の「サーバー」の画面かトレイのメニューで「補助を開始」(コマンドなら
.venv/bin/python -m onwx tp-helper。--model(GGUF のパスかstream)--ip--port--listen/--connectで設定を上書き)。メイン PC でモデルを読み込むと、つながってから読み込みます(補助 PC はメイン PC が読み込みを始めてから 10 分以内に開始しても間に合います)。補助はメイン PC がモデルを閉じるとまた待つ状態に戻ります
制限:使えるモデルは Nemotron 3.5 Bolt 74B-A9B、Qwen3.6 35B-A3B、Qwen3.8 27B(GGUF)です。2 台とも Linux で使ってください(Windows では Windows の GPU ランタイムでやり取りが遅く、1 台より遅くなったため、1.1 から設定に出しません)。GPU だけで動かし、NPU の手伝い、画像、別ファイルの下書きモデル(DFlash2、Nemotron の LiLiCorr)はこのモードでは使えません(Qwen3.6 のモデル内蔵の MTP の下書きは使えます)。モデルが合わないときやつながらないときは、メイン PC の画面に「2-PC: …」で理由が出ます。
速さ(1 台、llama.cpp との比較)
同じ PC、同じ GGUF で llama.cpp(Vulkan 版と ROCm 版)と比べました。
Ryzen AI 300(Ryzen AI 9 HX 470、Radeon 890M)
プロンプトの読み込みは GPU だけで、Qwen3.6 は llama.cpp(速いほう)の約 2.0〜2.7 倍、Nemotron は約 1.2 倍です。NPU が手伝うと Qwen3.6 はさらに約 1.15 倍、Nemotron は約 1.5 倍になります。生成も llama.cpp より速く、Qwen3.6 は MTP を使うと約 32 tok/s です。
Ryzen AI Max(Ryzen AI Max+ 395)
プロンプトの読み込みは GPU だけで llama.cpp(速いほう)の約 1.6〜1.9 倍、NPU が手伝うと長いプロンプトでさらに速くなります。生成も llama.cpp より速く、MTP やドラフトを使うともう一段上がります。
概要
- エンジン:gufo(MIT ライセンス)をもとにした onwx-halo エンジン(
onwx/bin/halo/<GPU>/onwx_halo.dll)。HIP / rocBLAS / hipBLASLt は AMD TheRock の Windows 版ランタイムを同梱しています。GPU ごとに別のエンジンがあり(gfx1151 = Ryzen AI Max、gfx1150 = Ryzen AI 300)、インストールとアップデートではその PC の GPU の分だけをダウンロードします - トークナイザーとチャットテンプレートは GGUF の中の情報から作ります(llama.cpp と同じトークン列になることを確認済み)
- onwx と並べて入れられます:インストール先
%LOCALAPPDATA%\onwx-dash、設定%APPDATA%\onwx-dash、スタートメニュー「onwx-dash」、API の既定ポート 8110 - onwx-halo を使っていた場合:最初の起動で onwx-halo の設定を引き継ぎ、ダウンロード済みのモデルはそのままの場所(
%APPDATA%\onwx-halo\models)から使います
エンジンについて(gufo からの移植)
onwx' のエンジンは、Strix Halo 向けの C++20 / HIP 推論エンジン gufo(MIT ライセンス)の NPU 対応フォーク mikealanni/gufo を移植して、onwx' 用に手を入れたものです(Windows でのビルドは本家 gufo-org/gufo の仕組みを参考にしています)。
- Windows で動くようにしました:NPU の手伝い(プロンプトの行列計算の一部を XDNA2 NPU に任せる仕組み)はフォークにしかなく、Linux 専用でした(本家 gufo は Windows でもビルドできますが、NPU の仕組みはありません)。AMD TheRock の Windows 版 HIP ランタイムでビルドし、NPU の手伝いも Windows の NPU ドライバ(XRT)で動くようにしました。Linux 版もあります(0.7.1 から)
- GPU と NPU を同時に使うときのバグを直しました:
- ある行列を丸ごと NPU に任せると、GPU 側が 0 行で起動してメモリを壊し、生成で落ちていた
- NPU が計算した行の結果がずれていた(直したあと、GPU だけのときと同じトークンになることを確認)
- Linux で、ほかのプロセスが GPU を使うと、NPU と共有するバッファを GPU のドライバが動かしてしまい、NPU のページフォールトと間違った答えになっていた(NPU 側で確保したバッファを GPU に登録する形に変更。2 プロセス同時の連続試験で 0 件)
- そのほかの GPU 側の修正:2,048 トークン以上のまとまりで作業領域があふれてページフォールトになっていた、Linux の Strix Halo で 1024 スレッドのワークグループが 128 を超えるレジスタを使えずに失敗していた(ROCm/TheRock#9639 で報告)
- onwx' で足したもの:Q6_K を Q8_0 に作り直さずにそのまま読む MoE カーネル(約 0.8 GB 減)、IQ4 / IQ3 / IQ2 の GGUF、短いプロンプトもまとめて計算する MoE(続きの質問の読み込みが 5〜7 倍速い)、KV キャッシュを使う分だけ確保、など
動くモデル(Ryzen AI Max+ 395)
| モデル | ファイル(取得元) | 大きさ | プロンプト読み込み | 生成 |
|---|---|---|---|---|
| Qwen3.6 35B-A3B | Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf(MTP 付き版、unsloth/Qwen3.6-35B-A3B-MTP-GGUF) |
22.9 GB | 約 2,200〜3,000 tok/s | 約 57 tok/s、MTP 併用で 考える・要約 84〜93 tok/s、物語など 62〜69 tok/s |
| Qwen3.6 35B-A3B IQ4_XS | Qwen3.6-35B-A3B-UD-IQ4_XS.gguf(同じリポジトリ) |
18.2 GB | 約 2,100〜3,000 tok/s | 約 59 tok/s、MTP 併用で約 84 tok/s |
| Qwen3.6 35B-A3B IQ3_XXS | Qwen3.6-35B-A3B-UD-IQ3_XXS.gguf(同じリポジトリ) |
14.1 GB | 約 1,300 tok/s(GPU のみ) | 約 59 tok/s、MTP 併用で約 83 tok/s |
| Qwen3.6 35B-A3B IQ2_M | Qwen3.6-35B-A3B-UD-IQ2_M.gguf(同じリポジトリ) |
11.9 GB | 約 1,370 tok/s(GPU のみ) | 約 64 tok/s、MTP 併用で約 82 tok/s |
| Qwen3.8 27B | Qwen3.8-27B-UD-Q4_K_XL.gguf(unsloth/Qwen3.8-27B-GGUF)+ ドラフト Qwen3.8-27B-DFlash2-Q4_K_M.gguf(z-lab/Qwen3.8-27B-DFlash2-GGUF) |
17.6 GB + 1.1 GB | 約 590〜720 tok/s | 約 11 tok/s、ドラフト併用で コード 34〜36 tok/s、説明文 20 tok/s前後 |
| NVIDIA Nemotron 3.5 Bolt 74B-A9B | NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB.gguf(nvidia/NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB-GGUF) |
22.0 GB + ドラフト 0.95 GB | 約 1,000〜1,160 tok/s | 約 35 tok/s、ドラフト併用で 考える・要約 55〜89 tok/s、物語など 30〜35 tok/s |
| Ternary Bonsai 2 27B | Ternary-Bonsai-2-27B-PQ2_0.gguf(prism-ml/Ternary-Bonsai-2-27B-gguf)+ Qwen3.8 27B と同じドラフト |
7.2 GB + 1.1 GB | 約 520〜640 tok/s | 約 22〜25 tok/s、ドラフト併用で 約 30〜49 tok/s(当たりにくい文章では約 19) |
IQ4_XS / IQ3_XXS / IQ2_M(0.8.2 から)は同じモデルの小さい版で、メモリの少ない PC 向けです。IQ4_XS は UD-Q4_K_XL とほぼ同じ速さと質で約 4 GB 少なく、IQ3_XXS と IQ2_M はさらに小さいかわりに答えの質が落ちます(IQ2_M ははっきり)。MTP 併用の値は 3 つと UD-Q4_K_XL(同じ試験で約 73 tok/s)を同じ文章で比べたものです。
速度は Ryzen AI Max+ 395(128 GB)で測った値です(プロンプトは数千トークンのとき)。モデルは配布元のリポジトリからそのままダウンロードします(onwx' はモデルを再配布しません)。 同じ GGUF がすでに PC にあれば、モデル画面の「ほかの場所」→「追加…」でそのフォルダを登録すれば使えます。 使うときは各モデルのライセンス(Qwen・Ternary Bonsai:Apache-2.0、Nemotron:NVIDIA のライセンス)に従ってください。
Ryzen AI 300(Radeon 890M)での速さ
| モデル | PC | プロンプト読み込み(NPU 併用) | 生成 |
|---|---|---|---|
| Qwen3.6 35B-A3B | Ryzen AI 9 HX 470、メモリ 64 GB(DDR5-5600) | 2,000 トークン 約 930 tok/s、4,000〜8,000 トークン 約 1,110 tok/s(GPU だけなら 約 880〜970) | 約 24 tok/s、MTP 併用で 約 28〜32 tok/s |
| NVIDIA Nemotron 3.5 Bolt 74B-A9B | Ryzen AI 9 HX 470、メモリ 64 GB(DDR5-5600) | 2,000 トークン 約 250 tok/s、4,000〜8,000 トークン 約 380 tok/s(GPU だけなら 約 240〜260) | 約 14 tok/s、ドラフト併用で 説明文 約 20 tok/s |
| Ternary Bonsai 2 27B | Ryzen AI 9 HX 370、メモリ 32 GB(LPDDR5X) | 2,000 トークン 約 175 tok/s、4,000 トークン 約 250 tok/s(GPU だけなら 約 130) | 約 12 tok/s(HX 470 ではドラフト併用で 約 13〜21 tok/s) |
- Qwen3.6 は 22.9 GB あるので、メモリ 64 GB の PC が必要です(32 GB では GPU が使えるメモリに収まりません)。32 GB の PC では Ternary Bonsai 2 27B が使えます
- Radeon 890M でも、Ternary Bonsai 2 27B はドラフト(先読み)を使います(0.8.4 から。Ryzen AI 9 HX 470 で、ドラフトなし 約 9.8 tok/s → 4 つの文章の平均 約 14.6 tok/s。環境変数
ONWX_HALO_DRAFT=0で使いません)。Qwen3.6 の MTP は 1 トークンずつ先読みします(この GPU ではそれが一番速い) - Nemotron も 64 GB の HX 470 で動きます(0.8.2 で確認)。Qwen3.8 27B は Radeon 890M ではまだ試していません
使用メモリ(NPU とドラフトを使うとき、文脈 32K トークンまでの会話):Qwen3.6 約 24〜25 GB、Nemotron 約 24〜25 GB、Qwen3.8 27B 約 21〜23 GB、Ternary Bonsai 2 27B 約 14〜15 GB。 KV キャッシュは会話が伸びた分だけ確保するので、文脈の設定を長くしてもそれだけではメモリは増えません(設定の長さまで会話が伸びたときの量はモデル画面に出ます)。 設定「KV キャッシュを 8 ビットにしてメモリを減らす」をオンにすると、その KV キャッシュがほぼ半分になります(Qwen3.8 27B・Ternary Bonsai 2 27B・Qwen3.6。32K トークンの会話で 27B は約 1 GB 減)。
Ternary Bonsai 2 27B:PrismML の 3 値(-1 / 0 / +1)重みの 27B(Qwen3.8 27B と同じ構造)。重みは 7.2 GB で、メモリの少ない PC でも 27B が動きます。先読みには Qwen3.8 27B 用の DFlash-2 ドラフトをそのまま使います(モデルのダウンロードで一緒に入ります)。
ドラフトモデル(Nemotron):NVIDIA が配布している先読み用の小さなモデル(nvidia/NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB-LiLiCorr-GGUF)を本体と同じフォルダにダウンロードします。ドラフトが数トークン先を予想し、本体がまとめて確かめるので、予想が当たりやすい文章(考える過程、要約、決まった形の答え)ほど速くなります。サンプリング(温度など)をしても出てくる文章の確率は変わりません。当たりにくい文章では自動で普通の生成に戻ります。手元の GGUF を使う場合は、NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB-LiLiCorr.gguf を本体と同じフォルダに置けば使われます(環境変数 ONWX_HALO_DRAFT=0 で使わない)。
必要なもの
- AMD Ryzen AI Max(Strix Halo、Radeon 8060S / 8050S)か Ryzen AI 300(Radeon 890M / 880M)の PC。メモリ 64 GB 以上を推奨(Ternary Bonsai 2 27B なら 32 GB でも動きます)。GPU が使えるのは「専用 GPU メモリ(BIOS / AMD Software で割り当てた量)+ 残りの半分」までです
- Windows 11、AMD のグラフィックスドライバーと NPU ドライバー(Ryzen AI ソフトウェア)。または Ubuntu 24.04 以降(下の「Linux」)
- Python 3.10 以上(なければセットアップが winget で入れることを提案します)
- ディスク:アプリ約 0.3 GB + モデル 1 つあたり 7〜23 GB
インストール
PowerShell から:
irm https://huggingface.co/ryugyosoft/onwx-dash/resolve/main/install.ps1 | iex
%LOCALAPPDATA%\onwx-dash にダウンロードして(別の場所にするときは $env:ONWX_HALO_DIR を短いパスに:PowerShell 5.1 は 260 文字を超えるパスを扱えません) setup.bat を実行します。Python の環境を作り、スタートメニューに「onwx-dash」を追加し、タスクトレイで起動します。
開いた画面の「モデル」タブでモデルをダウンロードし、「ロード」を押してください。チャット画面は http://localhost:8110/chat 、API は http://localhost:8110/v1 です。
手動で入れる場合:このリポジトリを好きなフォルダにダウンロードして setup.bat を実行します。
Linux(Ubuntu 24.04 以降、0.7.1 から)
wget -qO- https://huggingface.co/ryugyosoft/onwx-dash/resolve/main/install.sh | bash
~/onwx-dash にその PC の GPU 用の Linux エンジン(約 0.65 GB。AMD TheRock の Linux 版ランタイムを同梱)をダウンロードし、setup.sh が Python の環境、アプリ一覧への登録、トップバーのアプリを用意します。
- GPU を使うには、ユーザーが
renderとvideoのグループに入っている必要があります(sudo usermod -aG render,video $USERのあとログインし直し)。AMD の GPU ドライバー(amdgpu)はカーネルに入っているもので動きます - NPU の手伝いは既定でオフです(設定でオンにできます)。オンにするには、次の 3 つが必要です。足りないものは
setup.shが直し方のコマンドを表示します。どれもシステムの設定なので、自動では変えません- AMD の NPU ドライバー(amdxdna):カーネル 6.14 以降に入っています。
/dev/accel/accel0があれば OK です - XRT(NPU のランタイム):Ubuntu では AMD の Lemonade PPA から入れます(Ubuntu 26.04 で動作の報告があります)
sudo add-apt-repository ppa:lemonade-team/stable && sudo apt update && sudo apt install libxrt-npu2 python3-xrt - ロックできるメモリの上限:既定の 8 MB(
ulimit -lが8192)のままだと、NPU の準備が失敗して GPU だけで動きます。次の 3 行で無制限にして、PC を再起動します(ログインし直すだけでは、トップバーから起動したアプリに反映されないことがあります)printf '* - memlock unlimited\n' | sudo tee /etc/security/limits.d/99-memlock.conf sudo mkdir -p /etc/systemd/system.conf.d /etc/systemd/user.conf.d printf '[Manager]\nDefaultLimitMEMLOCK=infinity\n' | sudo tee /etc/systemd/system.conf.d/memlock.conf /etc/systemd/user.conf.d/memlock.conf
- AMD の NPU ドライバー(amdxdna):カーネル 6.14 以降に入っています。
- 動作は Ryzen AI Max+ 395(Ubuntu 24.04 のコンテナ、カーネル 6.18)で確認しました。Ternary Bonsai 2 27B:生成 約 27 tok/s、6,000 トークンのプロンプト 約 460 tok/s(GPU だけ)。Ryzen AI 300(Radeon 890M)の Linux ではまだ試していません
設定
- NPU にもプロンプトの読み込みを手伝わせる(設定 → サーバーと API):Windows は既定でオン、Linux は既定でオフ(上の 3 つが必要)。オフにすると GPU だけで動きます。モデルを読み込み直すと反映されます
- NPU の取り分(同じ場所):プロンプトの行列計算のうち、どれだけを NPU に任せるか。既定は「自動」で、GPU とモデルごとに測って一番速かった分け方を使います(Radeon 890M の 27B のモデルはほぼ全部、ほかは一部)。自動を外すと 10〜100 % を選べます。GPU が強い PC ほど少なめ、弱い PC ほど多めが速くなる傾向です
- API からモデルを切り替える(設定 → サーバーと API):既定でオン。
/v1/modelsにこのパソコンのモデルが全部出て(文脈長context_length、最大出力max_output_tokensつき)、リクエストのmodelに別のモデルの ID を指定すると、今のモデルを閉じてそれを読み込みます(10〜20 秒ほど) - 文脈の長さ、API キー、LAN からの接続、生成の既定値などは onwx と同じです
アンインストール
インストール先の uninstall.bat を実行します(アプリ、設定、ダウンロードしたモデル、スタートメニューの項目を消します。追加したフォルダのモデルは消しません)。
ライセンス
- アプリ:Apache-2.0(
LICENSE) - エンジン:gufo(MIT)とその同梱ライブラリの表示は
onwx/bin/halo/licenses/gufo/ - AMD ROCm(TheRock)のランタイム:各コンポーネントのライセンスは
onwx/bin/halo/licenses/rocm/。詳しくはonwx/bin/halo/licenses/README.txt