ローカルAIを使っていると、用途ごとにアプリが増えていきます。
LLMを動かすならLM Studio、画像や動画を生成するならComfyUI、モデルを学習するならさらに別の環境……といった具合です。
そんな中で気になったのが、Unsloth Desktopです。
従来のUnslothには「LLMを高速・省メモリでFine-tuningするライブラリ」という印象がありましたが、現在のDesktop版はかなり方向性が広がっています。
ローカルLLMのチャットだけでなく、画像生成、動画生成、学習などを一つのアプリから扱えるようになっています。
そこで今回は、Windows 11+RTX 5070 Ti 16GBのPCへUnsloth Desktopを実際に導入し、
「LM StudioやComfyUIの代わりとして、どこまで使えるのか?」
という視点で検証してみました。

先に結論を書くと、今回使った範囲ではかなり好印象でした。
特に、
メジャーなローカルLLMをできるだけ簡単に使いながら、画像や動画生成まで一つのアプリで済ませたい
という人には、かなり有力な選択肢だと思います。
- 今回の検証環境
- Windowsへのインストールはかなり簡単
- UIはかなり分かりやすい
- RTX 5070 Ti 16GBも正常に認識
- LM Studioで使っていたGGUFをそのまま認識した
- Qwen3-14BをUnsloth Desktopで実行
- Auto設定がかなり便利
- LM StudioとQwen3-14Bの推論速度を比較
- VRAM使用量もほぼ同等
- 画像生成も同じアプリから行える
- FLUX.2 Klein Base 4BをUnslothで生成
- Recommendedにはかなり多くの画像モデルが並ぶ
- ComfyUIでも同じFLUX.2 Kleinを生成
- ComfyUIは自由だが、その自由度を使うには知識も必要
- Unslothは「画像を作ること」に集中しやすい
- 生成画像は自動保存される
- ComfyUIとのモデル資産共有はLM Studioほど単純ではなかった
- ではLM Studioは不要になるのか?
- 3つのツールを実際に使って感じた違い
- 私ならUnslothをメイン、LM StudioとComfyUIをサブにする
- まとめ
今回の検証環境
| 項目 | 環境 |
|---|---|
| OS | Windows 11 |
| GPU | NVIDIA GeForce RTX 5070 Ti |
| VRAM | 16GB |
| RAM | 約48GB |
| Unsloth Desktop | v0.1.808-beta |
| LM Studio | 0.4.24 |
| LLM | Qwen3-14B Q5_K_M |
| 画像モデル | FLUX.2 Klein Base 4B |
Unsloth Desktopは現在も更新頻度が高いため、今後UIや機能が変わる可能性があります。
Windowsへのインストールはかなり簡単
Windows版は通常のインストーラー形式で、今回の環境では特に複雑な操作は必要ありませんでした。

Desktopアプリ本体のインストール先はデフォルトのまま進めました。
その後Unsloth Desktopを起動し、「Get Started」から初回セットアップを進めると、そのままメイン画面まで進めます。

今回の環境では事前にHugging Faceの保存先を、
HF_HOME=F:\LocalAI\Cache\HuggingFace
へ設定していました。
Unsloth側でもこの環境変数が認識され、モデルの保存場所としてFドライブを利用できました。
大容量モデルを多数扱う場合、モデルキャッシュを容量に余裕のあるSSDへ置けるのは重要です。
UIはかなり分かりやすい
初回セットアップ後の画面は、機能数の割にかなりシンプルです。

ローカルLLMだけを使う場合も、モデルを選択してロードし、そのままチャットを開始するという分かりやすい流れです。
LM Studioを触ったことがある人なら、それほど迷わず使えると思います。
RTX 5070 Ti 16GBも正常に認識
設定画面を確認すると、RTX 5070 TiがCUDAデバイスとして正常に認識されていました。

今回の環境ではVRAMは約15.9GiBとして認識され、LLM推論バックエンドにはllama.cpp CUDAが使用されていました。
PythonやPyTorchなどの情報もGUI上から確認できます。
LM Studioで使っていたGGUFをそのまま認識した
今回特に便利だったのが、すでにLM Studioで使用していたモデルをUnsloth Desktopからそのまま利用できたことです。
私の環境ではLM Studioのモデルを、
F:\LocalAI\Models\LMStudio
へ保存しています。
Unsloth Desktopでローカルモデルを確認すると、この保存先にあるモデルがLM Studioの既存モデルとして表示されました。

Qwen3-14B、Ministral 14B、Qwen3.8-27Bなど、すでに保存していた複数のGGUFが表示されました。
同じモデルをUnsloth用として再ダウンロードしたり、別フォルダへコピーしたりする必要はありません。
ローカルLLMではモデル一つで数GB~数十GBになるため、既存資産を共有できるのはかなり便利です。
Qwen3-14BをUnsloth Desktopで実行
まず、
Qwen3-14B-Q5_K_M.gguf
をロードして日本語チャットを試しました。

今回使用したRTX 5070 Ti 16GBでは、全レイヤーをGPUへ載せた状態で動作しました。
Auto設定がかなり便利
Unsloth Desktopでは、Context LengthなどをAutoに設定できます。

実際にQwen3-14Bをロードすると、その時点の状態によってContext Lengthが17,152や17,408などに調整されました。
PowerShellからllama-serverの起動引数を確認すると、あるロード時には、
-c 17408
-ngl -1
--parallel 4
--flash-attn on
となっていました。
-ngl -1 なので全レイヤーをGPUへ載せつつ、使用可能なVRAMに合わせてContext側を調整していることが分かります。
細かなVRAM計算を自分で行わなくても、まずAutoで試せるのはかなり使いやすい部分です。
LM StudioとQwen3-14Bの推論速度を比較
せっかく同じGGUFを両方から利用できたため、Unsloth DesktopとLM Studioで簡単な推論速度比較も行いました。
主な比較条件は以下です。
| 設定 | 内容 |
|---|---|
| モデル | Qwen3-14B Q5_K_M |
| Context Length | 16,384 |
| GPU Offload | 全レイヤー |
| KV Cache | F16 |
| Flash Attention | ON |
| Parallel | 4 |
| CPU Threads | 2 |
| Thinking | ON |
| Speculative Decoding | OFF |
同じ日本語プロンプトを新規チャットから3回実行しました。
| 1回目 | 2回目 | 3回目 | 平均 | |
|---|---|---|---|---|
| Unsloth Desktop | 66.6 tok/s | 68.7 tok/s | 69.0 tok/s | 68.1 tok/s |
| LM Studio | 56.71 tok/s | 65.82 tok/s | 64.69 tok/s | 62.4 tok/s |

今回の3回平均では、Unsloth Desktopが約68.1 tok/s、LM Studioが約62.4 tok/sとなり、Unsloth側が約9%高速でした。
ただし、これはUnslothが常にLM Studioより9%高速という意味ではありません。
両者ではllama.cppランタイムのバージョンやロード方式、内部設定に違いがあります。またThinkingモデルでは、同じ質問でも思考トークン量自体が毎回変わります。
そのため今回の結果については、
少なくとも今回の環境では、Unsloth DesktopのGGUF推論性能はLM Studioに見劣りしなかった
程度に見るのがよいと思います。
VRAM使用量もほぼ同等
同程度の条件でnvidia-smiから確認したVRAM使用量は、Unsloth Desktopが13,907MiB、LM Studioが14,002MiBでした。
| アプリ | VRAM使用量 |
|---|---|
| Unsloth Desktop | 13,907MiB |
| LM Studio | 14,002MiB |
差は95MiB程度で、実用上はほぼ同等と考えてよさそうです。
画像生成も同じアプリから行える
次にUnsloth Desktopの画像生成を試しました。
Create画面では、Prompt、Negative Prompt、Aspect Ratio、Resolution、Steps、Guidance、Batch Size、Runs、Seedなどを調整できます。
Advancedを開けばPrecision、Attention、Memory、CPU Offloadなどの設定もあります。
つまり、
普通に画像を作るために必要な設定は揃っているが、ComfyUIのように生成パイプラインそのものを組み立てる必要はない
という設計です。
FLUX.2 Klein Base 4BをUnslothで生成
今回は画像モデルとして、
FLUX.2-klein-base-4B-GGUF
を選択し、Q4_K_Mを使用しました。

モデルをダウンロードするとそのままロードされ、すぐ画像生成へ進めました。
ComfyUIのようにText EncoderやVAEを個別に指定する必要はありません。
1024×1024の画像もRTX 5070 Ti 16GBで問題なく生成できました。

Recommendedにはかなり多くの画像モデルが並ぶ
Unsloth Desktopの画像モデル選択画面で「Recommended」を開くと、かなり多くのモデルが表示されます。

今回確認できた中には、Z-Image、Qwen-Image、FLUX.1、Krea 2、Lumina、Hunyuan、HiDream、Ideogram、SDXL、FLUX.2 Klein、ERNIE Imageなどがありました。
この一覧にある対応モデルは、モデルを選択して必要なファイルを取得すれば、Unsloth側が生成環境をまとめて扱ってくれます。
一方で、Hugging Faceから任意の画像checkpointをダウンロードし、safetensorsを配置すれば何でも自動的に利用できる、という意味ではありません。
例えばKrea 2自体は一覧から利用できますが、Krea 2をベースにした特殊な派生checkpointを手動で配置した場合、それをUnslothが正しく認識できるとは限りません。
こうした派生モデルや特殊な構成を自由に組み合わせたい場合は、ComfyUIの方が向いています。
ComfyUIでも同じFLUX.2 Kleinを生成
比較のため、ComfyUIでもFLUX.2 Klein Base 4Bを使用しました。

生成された画像はUnsloth版とは完全に同一ではありませんが、同じプロンプトに含まれる人物、ティーセット、森、巨大なキノコといった主要要素はどちらもきちんと反映されました。
どちらも普通に利用できるクオリティです。
当初はSeed、Steps、Guidanceなどを完全に揃え、細かな画質差まで比較することも考えました。
しかし実際に両方を使ってみると、画像の微妙な優劣よりも操作性と設計思想の違いの方がはるかに分かりやすい差でした。
ComfyUIは自由だが、その自由度を使うには知識も必要
ComfyUIの最大の特徴は自由度です。
Sampler、Scheduler、Text Encoder、VAE、LoRA、ControlNet、後処理などをノードとして組み合わせ、自分専用の生成ワークフローを構築できます。
一方で、初心者がゼロからワークフローを組むのは簡単ではありません。
実際には既存テンプレートを利用することが多いと思います。
テンプレートを使えば生成自体は簡単になりますが、少し構成を変更しようとすると、
どのノードを変更してよいのか?
このモデルにはどのText Encoderが必要なのか?
VAEは何を使うのか?
といった知識が必要になります。
今回も、別モデル用テンプレートでDiffusion ModelだけをFLUX.2 Kleinへ変更したところエラーになりました。
FLUX.2 Klein用の正しいText EncoderとVAEを組み合わせた公式テンプレートへ変更すると正常に生成できました。
これはComfyUIの欠点というより、自由度が高い代わりに利用者側も生成パイプラインを理解できるように作られているという特徴です。
Unslothは「画像を作ること」に集中しやすい
Unslothはかなり方向性が違います。
対応モデルを選択したら、あとはPrompt、Seed、Steps、Guidance、Resolutionなどを調整して生成します。
内部のText EncoderやVAEを毎回意識する必要はありません。
今回両方を触った感覚では、
画像を生成したい人 → Unsloth
画像生成の仕組みそのものを構築したい人 → ComfyUI
という違いがかなり分かりやすいです。
生成画像は自動保存される
Unslothで生成した画像は、今回のWindows環境では、
C:\Users\ユーザー名\.unsloth\studio\images
へ保存されていました。
アプリを終了しても消えません。
生成履歴の画像メニューからDeleteを選ぶと削除でき、Archiveは削除ではなく整理用の機能でした。
これは特にデメリットというものではなく、画像管理上知っておけばよい仕様です。
ComfyUIとのモデル資産共有はLM Studioほど単純ではなかった
今回、UnslothへComfyUIの既存モデルフォルダも指定してみました。
D:\ComfyUI_windows_portable\ComfyUI\models
しかし、今回使用していたComfyUI側の画像モデルはUnslothのOn Device一覧には表示されませんでした。
LM StudioのGGUFはそのまま認識されたため、ここは扱いが異なります。
ただし、これはUnsloth単体で利用する場合の問題ではありません。
すでにComfyUI環境を持っていて両方を併用したい人にとって、既存画像モデルの資産共有はLM StudioのGGUFほど単純ではなかった、という程度の違いです。
ではLM Studioは不要になるのか?
今回Unsloth Desktopを使ってみて、個人的にはかなり「普段はUnslothでよいのでは?」と感じました。
LLMチャットではLM Studioで保存済みのGGUFをそのまま利用できました。
推論性能も今回の環境では同等以上です。
さらに同じアプリから画像、動画、学習へ移動できます。
そのため、単純なローカルLLMチャット用途では、LM Studioを起動する機会はかなり減りそうです。
ただし、LM Studioには別の強みがあります。
現在のLM Studioは単なるローカルLLMチャットアプリというより、
ローカルLLM専用ツール兼LLMサーバー
という側面がかなり強くなっています。
自作アプリなどからOpenAI互換API経由でローカルLLMを呼び出したり、モデルのロード・アンロードを管理したり、LLMサーバーとして常用したりする用途では、依然として非常に使いやすいアプリです。
そのため「UnslothがあるからLM Studioは完全に不要」というより、用途が少し違ってきます。
3つのツールを実際に使って感じた違い
| 用途 | Unsloth Desktop | LM Studio | ComfyUI |
|---|---|---|---|
| ローカルLLMチャット | ◎ | ◎ | △ |
| LLMサーバー用途 | ○ | ◎ | △ |
| 画像生成 | ◎ | - | ◎ |
| 動画生成 | ◎ | - | ◎ |
| Fine-tuning | ◎ | - | △ |
| 初心者の分かりやすさ | ◎ | ◎ | △~○ |
| 画像生成の自由度 | ○ | - | ◎ |
| 独自ワークフロー構築 | △ | - | ◎ |
| 一つのアプリで幅広く使う | ◎ | △ | ○ |
ここでの評価は製品そのものの絶対評価というより、今回実際に使ってみた範囲での使い分けです。
私ならUnslothをメイン、LM StudioとComfyUIをサブにする
今回の検証後、私自身の使い方として一番しっくりきたのは、
普段のLLMチャット、簡単な画像・動画生成:
Unsloth Desktop
ローカルLLMサーバーとして細かく運用したい:
LM Studio
複雑な画像生成や独自ワークフローを作りたい:
ComfyUI
という使い分けです。
特にUnslothはLM Studioの既存GGUFをそのまま利用できたため、両方インストールしておいても同じLLMモデルを二重に保存する必要はありませんでした。
そのためLM StudioやComfyUIを削除してしまうのではなく、
まずUnslothを使い、必要になったときだけLM StudioやComfyUIを使う
という運用が現実的だと思います。
まとめ
Unsloth Desktopを触る前は、Unslothには「Fine-tuning用ライブラリ」という印象がかなり強くありました。
しかしDesktop版を実際に使ってみると、印象はかなり変わりました。
ローカルLLM、画像、動画、学習などをまとめた、ローカルAI総合アプリに近い存在です。
RTX 5070 Ti 16GBで試した今回の環境では、Qwen3-14BのLLMチャットも快適で、FLUX.2 Kleinによる1024×1024画像生成も問題なく利用できました。
そして一番印象に残ったのは、
「ローカルAIだから難しい」という部分をかなり隠してくれている
ことです。
ComfyUIほど画像生成ワークフローを自由に構築できるわけではありません。
LM StudioほどLLMサーバー用途に特化しているわけでもありません。
しかし、
ローカルLLMも画像生成も動画生成もやってみたい。でも複数の環境を細かく使い分けるのは面倒
という人には、かなり相性の良いアプリだと思います。
私自身、今回実際に使った後では、普段のローカルAI用途ではUnsloth Desktopをメインにしてもよいと感じています。


コメント