LM Studio「llama-server exited before becoming healthy. exitCode=1」でモデルがロードできない原因と解決策【Windowsの日本語ユーザー名】

この記事は Claude を用いて執筆しています。 ただし、実際の切り分け・検証・判断は手元の Windows 環境で行った結果に基づいており、内容は実体験ベースで整理しています。

LM Studio でどのモデルをロードしようとしても、以下のエラーが出て必ず失敗する状態になりました。

1
2
[LMSInternal][LMSAuthenticator][Client=LM Studio][Endpoint=multiplexedLoadModel] Error in channel handler:
Error: Engine protocol runtime llama-server for XXXXXXXX exited before becoming healthy. exitCode=1, signal=null

一見すると GPU (Vulkan) 周りやランタイムの破損に見えます。しかし、最終的な原因は Windows のユーザー名が日本語であるために %TEMP% のパスに日本語が含まれ、llama.cpp (llama-server) が --chat-template-file で渡された非 ASCII パスのファイルを開けなかったことでした。

この記事では、まず最初に 「何が起きていたのか」と「どう直したのか」 を簡潔にまとめ、その後で詳細な経緯と切り分けを書きます。急いでいる方は「トラブルの概要」と「解決策」だけ読めば十分です。

トラブルの概要

発生した症状

LM Studio 0.4.19 (Windows) でモデルをロードすると、100% 失敗する
モデルを変えても、量子化を変えても、コンテキスト長を変えても失敗する
GPU オフロードを 0 (CPU のみ) にしても失敗する
Vulkan ランタイムを CPU llama.cpp ランタイムに切り替えても失敗する
ランタイムパックの再インストールでも、LM Studio 本体の完全クリーン再インストールでも直らない

main.log に残るのは冒頭の exited before becoming healthy. exitCode=1 のみで、llama-server 側の本当のエラーは記録されません。

環境

Windows 11 (Entra ID 参加、キッティング段階から Entra 参加)
ユーザープロファイルが C:\Users\<日本語ユーザー名> (日本語を含む)
LM Studio 0.4.19 (Build 2)
llama.cpp ランタイム v2.24.0 (Vulkan / CPU どちらも同症状)
GPU: Intel Arc 140T (内蔵)

一見したときの誤解しやすいポイント

このエラーとログだけ見ると、次のように考えがちです。

Vulkan / GPU ドライバの問題 (ログに No live GPU info available が出るため)
ランタイムパックのダウンロード破損
モデルファイル (GGUF) の破損
LM Studio 本体のインストール破損
Defender や EDR によるブロック

実際、自分もこの順で全部疑いました。しかしどれも外れでした。

実際の原因

LM Studio はモデルロード時に、モデルのメタデータからチャットテンプレート (Jinja) を抽出し、一時ファイルとして書き出してから llama-server に渡します。

1
%LOCALAPPDATA%\Temp\lmstudio-llama-chat-template-XXXXXX\chat-template.jinja

このパスは %TEMP% を基準にしているため、ユーザー名が日本語だと

1
C:\Users\<日本語ユーザー名>\AppData\Local\Temp\lmstudio-llama-chat-template-XXXXXX\chat-template.jinja

という 非 ASCII を含むパス になります。

そして llama-server (llama.cpp) の --chat-template-file 引数の実装は、Windows 上で非 ASCII パスのファイルを開けません。引数パースの段階で failed to open file となり、exitCode=1 で即死します。

興味深いことに、同じバイナリでも --model に渡す GGUF のパスは日本語を含んでいても問題なく読めます。モデル読み込みとテンプレート読み込みでコード経路が異なり、テンプレート側だけ Unicode パス未対応というのが実態です。

つまり、

日本語ユーザー名 + LM Studio (llama.cpp ランタイム) の組み合わせで必ず発生する
モデルにも GPU にもインストール状態にも一切関係ない

というのが真相です。

なお、以前使っていた PC ではローカルユーザー (半角英数) で作成してから Entra 参加していたためプロファイル名が ASCII で、この問題を踏みませんでした。今回の端末はキッティング段階から Entra 参加したため、プロファイル名が Entra の表示名 (日本語) 由来になっていました。同じ構成の企業端末では再現しやすいはずです。

解決策

結論

TEMP / TMP 環境変数を ASCII のみのパスに変更することで解決しました。

llama-server に渡る一時テンプレートのパスから日本語が消えれば、それだけで正常にロードできるようになります。モデルフォルダ (~\.lmstudio\models) は日本語パスのままでも問題ありません。

手順

まず、ASCII のみで構成された任意のフォルダを作ります。

1
New-Item -ItemType Directory -Path C:\UserProfileData\exampleuser\tmp -Force

場所と名前は好みで構いません。ただし パス全体が ASCII のみ であることが条件です。

次に、ユーザー環境変数を変更します。

「システムのプロパティ」→「環境変数」→ ユーザー環境変数で、

TEMP → C:\UserProfileData\exampleuser\tmp
TMP → C:\UserProfileData\exampleuser\tmp

に編集します。旧 Temp (AppData\Local\Temp) の中身のコピーは不要です。使い捨ての作業領域なので、移行を機にリセットされるだけです。旧 Temp フォルダ自体は削除せずそのまま残してください (環境変数を無視してこのパスを直接使うアプリが存在するため)。

環境変数は既存プロセスに反映されないので、サインアウト → サインイン します。

その後、確認します。

1
$env:TEMP

新しいパスが返ってくれば、あとは LM Studio を普通に起動してモデルをロードするだけです。自分の環境ではこれで完全に解決しました。

影響範囲を絞りたい場合

ユーザー全体の TEMP を変えたくない場合は、LM Studio 起動時だけ差し替える方法もあります。

1
2
3
$env:TEMP = 'C:\lmstudio-tmp'
$env:TMP  = 'C:\lmstudio-tmp'
& "C:\Program Files\LM Studio\LM Studio.exe"

これをショートカットやラッパースクリプトにしておけば、システムへの影響はゼロです。自分はまず一時的にこの方法で原因を確定させてから、環境変数の恒久変更に踏み切りました。

重要な注意点 (8.3 短縮名)

移行先のフォルダ名が 8 文字を超える場合 (UserProfileData など)、変更後に $env:TEMP が短縮名で見えることがあります。

1
2
PS> echo $env:TEMP
C:\USERPR~1\EXAMPL~1\tmp

これは Windows のログオン処理が、レガシーアプリ互換のために TEMP / TMP に限って 8.3 短縮名へ変換する 古い仕様によるものです。レジストリ (HKCU\Environment) にはフルネームで正しく格納されており、指す実体も同じなので 動作上の実害はありません。むしろ短縮名は完全 ASCII なので、今回のような非 ASCII パスに弱いプログラムへの保険としては機能します。

どうしても見た目を直したい場合は、対象フォルダの 8.3 名を剥がします。

1
fsutil 8dot3name strip /f /s /v C:\UserProfileData

ただし、TEMP として使用中のフォルダは常駐アプリがファイルを掴んでいて c0000022 アクセスが拒否されました で失敗しがちです。その場合は別のローカル管理者アカウントでサインインして (=自分のセッションの常駐が全部いない状態で) 実行すると通ります。急ぎでなければ後回しで問題ありません。

最短のまとめ

同じエラーに遭遇していて、次の条件に当てはまるなら、かなり高確率で同じ原因です。

LM Studio でどのモデルも exited before becoming healthy. exitCode=1 でロード失敗する
CPU ランタイムに切り替えても、再インストールしても直らない
Windows のユーザー名 (プロファイルフォルダ名) に日本語が含まれている

この場合は、TEMP / TMP を ASCII パスに変えてサインインし直してください。 それだけです。

経緯や切り分け

ここからは、実際にどう切り分けていったかを詳しく書きます。結論だけ知りたい方はここから先を飛ばして構いません。今回は誤読による回り道も含めて、時系列そのままに書きます。

1. main.log の確認と初期切り分け

まず LM Studio のログ (%APPDATA%\LM Studio\logs\main.log) を確認しました。ロード失敗のたびに次のパターンが繰り返されています。

1
2
3
4
[error] [LM Studio] Live GPU memory info:
No live GPU info available
[error] [LMSInternal]...[Endpoint=multiplexedLoadModel] Error in channel handler:
Error: Engine protocol runtime llama-server for XXXXXXXX exited before becoming healthy. exitCode=1, signal=null

ここで重要だったのは、ログをよく見ると GPU オフロード 0 (Num Offload Layers: 0、つまり CPU のみ) でも同じ exitCode=1 で失敗している 記録があったことです。この時点で Vulkan / GPU ドライバ起因の線はかなり薄くなりました。

また、ログには DownloadsManager のタイムアウトや File size mismatch も多発しており、ランタイムパックの破損も候補に残っていました。

2. 定番の対処を一通り実施 → すべて空振り

CPU llama.cpp ランタイムへの切り替え → 同症状
Vulkan ランタイムパックのアンインストール / 再インストール → 同症状
ネットワーク到達性の確認 → 問題なし

3. llama-server.exe を直接起動 → 正常起動

ランタイムのフォルダから llama-server を引数なしで直接叩いてみました。

1
2
cd $env:USERPROFILE\.lmstudio\extensions\backends\llama.cpp-win-x86_64-vulkan-avx2-2.24.0
.\llama-server.exe

1
0.00.041.175 I srv  llama_server: listening on http://127.0.0.1:8080

普通に起動しました。 つまりバイナリ・DLL 群・実行環境 (AVX、Vulkan ドライバ等) は壊れていません。LM Studio がロード時に渡している「何か」が原因、と絞り込めました。

4. lms log stream で llama-server の本当のエラーを取得

main.log には親プロセス (LM Studio) 側の「子が死んだ」という記録しかなく、llama-server 自身が標準エラーに吐いた内容は握り潰されています。これを見るには LM Studio CLI が使えます。

1
lms log stream --source server

これを張った状態でロードを試すと、初めて本当のエラーが見えました。

1
2
[DEBUG] error while handling argument "--chat-template-file": error: failed to open file
'C:\Users\<日本語ユーザー名>\AppData\Local\Temp\lmstudio-llama-chat-template-uqxVV1\chat-template.jinja'

llama-server は、LM Studio が Temp に書き出したはずのチャットテンプレートを開けずに死んでいました。3 回リトライされ、毎回別のランダムフォルダ名で同じ失敗をしていたため、特定モデルの問題ではなく毎回再現する環境問題だと分かります。

5. 外部要因の除外

「書き出したはずのファイルが無い」ので、まず外部要因を疑いました。

Temp への書き込み権限 → New-Item で正常に作成できる。問題なし
Windows セキュリティの保護の履歴 (検疫) → 該当なし
Storage Sense / Temp クリーナー → 素の Windows 11 で該当ツールなし
Procmon で Path contains lmstudio-llama-chat-template をフィルタして監視 → 何も引っかからない

Procmon に何も映らないのは不可解でした (後から分かりますが、これはフィルタの問題ではなく本質的なヒントでした)。

6. OneDrive / Intune の疑いも検討 → 対象外

この端末は Entra ID + Intune 管理なので、OneDrive の既知フォルダー移動 (KFM) が Temp を巻き込んでいないかも調べました。しかし KFM の対象は Desktop / Documents / Pictures のみで、AppData\Local\Temp は対象外。タイミング的にも (作成直後・数百 ms 後の失敗)、Files On-Demand の仕組みとは一致しません。この線は消えました。

7. 完全クリーン再インストール → それでも再発

環境残骸の可能性を潰すため、通常のアンインストールに加えて以下を全削除し、インストーラも新規ダウンロードして入れ直しました。

1
2
3
4
5
Remove-Item "$env:ProgramFiles\LM Studio" -Recurse -Force
Remove-Item "$env:LOCALAPPDATA\Programs\LM Studio" -Recurse -Force
Remove-Item "$env:APPDATA\LM Studio" -Recurse -Force
Remove-Item "$env:USERPROFILE\.lmstudio" -Recurse -Force
Remove-Item "$env:USERPROFILE\.cache\lm-studio" -Recurse -Force

(モデルは事前に別フォルダへ退避)

その後、まっさらな状態で lmstudio-community/Llama-3.2-1B-Instruct-GGUF を新規ダウンロードしてロード。寸分違わず同じエラーで失敗しました。 これで「環境残骸・キャッシュ破損・特定モデルの不備」は全部消えました。

8. Procmon のフィルタを緩めて再取得 → ファイルは実在していた

前回 Procmon に何も映らなかったのはフィルタの取りこぼしを疑い、条件を緩めて再取得しました。すると今度は全部映りました。

LM Studio が lmstudio-llama-chat-template-XXXXXX フォルダを作成 → SUCCESS
chat-template.jinja (346 バイト) を書き込み → SUCCESS
直後の QueryDirectory でもファイルの存在を確認できる
MsMpEng.exe (Defender) が同ファイルをスキャンのためロック (FILE LOCKED WITH ONLY READERS)
その後 LM Studio が同フォルダを削除しようとして NOT EMPTY で一度失敗 → 中身を先に消して削除成功
次のフォルダを作り、また同じサイクル (計 3 回)

ファイルは書けている。 ここで一度、「LM Studio が llama-server の起動前後に自分でファイルを消してしまうレースコンディションで、Defender のスキャンロックが引き金では」という仮説を立てました。

9. Defender 除外を投入 → 効果なし (仮説が崩れる)

パスとプロセスの除外を入れて検証しました。

1
2
Add-MpPreference -ExclusionPath "$env:LOCALAPPDATA\Temp\lmstudio-llama-chat-template-*"
Add-MpPreference -ExclusionProcess "llama-server.exe"

結果は 変化なし。再取得した Procmon ログには MsMpEng が一切登場しなくなったので除外自体は効いています。それでも失敗する。Defender は無関係でした (除外は後で削除しました)。

10. コマンドライン全体の取得と、タイミング仮説の崩壊

2 回目の Procmon キャプチャには Process Create イベントも含まれており、LM Studio が llama-server に渡している完全なコマンドラインが取れました。

1
2
3
4
llama-server.exe --model C:\Users\<日本語ユーザー名>\.lmstudio\models\lmstudio-community\Llama-3.2-1B-Instruct-GGUF\Llama-3.2-1B-Instruct-Q8_0.gguf
  --host 127.0.0.1 --port 59086 --no-webui --jinja
  --chat-template-file C:\Users\<日本語ユーザー名>\AppData\Local\Temp\lmstudio-llama-chat-template-2hlloJ\chat-template.jinja
  --ctx-size 8192 --n-gpu-layers 999999 ...

タイムスタンプを整理すると、テンプレート書き込み → llama-server 起動 → 約 160ms 後に LM Studio がフォルダを削除、という順序です。当初は「起動 0.16 秒後に消すのが早すぎる」と読んだのですが、これは誤読でした。

lms log stream のエラーは error while handling argument — つまり 引数パース段階、プロセス起動から数ミリ秒の時点での失敗です。モデルロード (GGUF 読み込み) にすら到達していません。つまり llama-server は起動直後に即死しており、160ms 後の削除は 死んだ子プロセスの後片付けとして正常な動作 でした。だからロード設定を軽くして起動を速める対症療法 (mlock オフ等) も効かなかったわけです。

11. 決定的な違和感: llama-server がファイルに一度も触れていない

ここで 2 回目の Procmon ログを見直して、決定的な事実に気づきました。キャプチャには llama-server.exe のイベントが 1 万件以上あるのに、chat-template.jinja への llama-server からのアクセスが 1 件も存在しない のです。

ファイルは実在する (LM Studio の書き込みと QueryDirectory で確認済み)
llama-server はパスを引数で受け取っている (コマンドラインで確認済み)
なのに llama-server はそのファイルを 開こうとすらしていない (CreateFile が発行されていない) のに failed to open file と言っている

ファイルオープンの試行が OS に届く前に失敗している。これが起きる典型は、パス文字列のエンコーディング変換の失敗 です。C/C++ の fopen 系で Windows の UTF-8 / UTF-16 / ANSI (CP932) 変換に不整合があると、Win32 API に到達する前に NULL が返り、Procmon には何も映りません。最初の Procmon (厳しいフィルタ) で何も映らなかったのも、実は同じ理由でした。

そして問題のパスには C:\Users\<日本語ユーザー名>\... と 非 ASCII 文字が含まれています。前の PC (ローカルユーザー作成 → ASCII プロファイル) では動いていて、キッティング段階から Entra 参加した今回の端末 (日本語プロファイル) で発生する、という状況証拠とも完全に一致します。

12. 検証: 同一ファイルを ASCII パスと日本語パスに置いて比較

仮説を最小構成で検証しました。同じ内容の Jinja ファイルを 2 か所に置き、llama-server に直接読ませます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
New-Item -ItemType Directory -Path C:\lmtest -Force
Set-Content -Path C:\lmtest\t.jinja -Value '{{ messages }}' -NoNewline
Copy-Item C:\lmtest\t.jinja "$env:LOCALAPPDATA\Temp\t.jinja"

cd $env:USERPROFILE\.lmstudio\extensions\backends\llama.cpp-win-x86_64-vulkan-avx2-2.24.0

# テスト1: ASCII パス
.\llama-server.exe --jinja --chat-template-file C:\lmtest\t.jinja

# テスト2: 日本語を含むパス
.\llama-server.exe --jinja --chat-template-file $env:LOCALAPPDATA\Temp\t.jinja

結果:

1
2
3
4
5
6
# テスト1 (ASCII): 正常起動
0.00.089.970 I srv  llama_server: listening on http://127.0.0.1:8080

# テスト2 (日本語パス): 失敗
error while handling argument "--chat-template-file": error: failed to open file
'C:\Users\<日本語ユーザー名>\AppData\Local\Temp\t.jinja'

同一ファイル・同一バイナリで、パスの文字種だけで結果が変わりました。 原因確定です。

13. 追加検証: –model は日本語パスでも読める

モデル本体も ~\.lmstudio\models (日本語パス配下) にあるため、そちらも死ぬのか確認しました。

1
.\llama-server.exe --model "$env:USERPROFILE\.lmstudio\models\lmstudio-community\Llama-3.2-1B-Instruct-GGUF\Llama-3.2-1B-Instruct-Q8_0.gguf" --chat-template-file C:\lmtest\t.jinja --jinja

1
2
3
0.00.084.791 I srv    load_model: loading model 'C:\Users\<日本語ユーザー名>\.lmstudio\models\...\Llama-3.2-1B-Instruct-Q8_0.gguf'
0.04.201.940 I srv  llama_server: model loaded
0.04.201.945 I srv  llama_server: listening on http://127.0.0.1:8080

モデルは日本語パスでも読めます。 GGUF 読み込み側は Unicode パス対応済みで、--chat-template-file 側だけ未対応、というコード経路の差です。同時に「モデルフォルダの移動は不要、直すべきは TEMP だけ」と確定しました。

14. TEMP 差し替えで LM Studio ごと検証 → 解決

LM Studio を完全終了してから、そのプロセスにだけ ASCII の TEMP を見せて起動しました。

1
2
3
4
New-Item -ItemType Directory -Path C:\lmtest\tmp -Force
$env:TEMP = 'C:\lmtest\tmp'
$env:TMP  = 'C:\lmtest\tmp'
& "C:\Program Files\LM Studio\LM Studio.exe"

この状態でモデルをロードすると 正常にロードできました。あとはユーザー環境変数の TEMP / TMP を恒久的に ASCII パスへ変更してサインインし直し、完全解決です。

15. 今回の結論

事象の表面

exited before becoming healthy. exitCode=1 という汎用的なエラーしか出ない
ログに GPU 関連の error 行が並ぶため、Vulkan / GPU 起因に見える
再インストールで直りそうに見えて、直らない

実際の原因

LM Studio がチャットテンプレートを %TEMP% 配下に書き出して --chat-template-file で llama-server に渡す設計
llama.cpp の --chat-template-file の実装が Windows の非 ASCII パスを開けない
日本語ユーザー名 → %TEMP% に日本語が含まれる → 100% 失敗

実務的な見立て

LM Studio / llama.cpp の一般不具合というより、非 ASCII ユーザー名環境でのみ顕在化するアップストリームのバグ
日本語・中国語・韓国語などのユーザー名は、Entra ID 参加端末 (表示名がそのままプロファイル名になる) で特に発生しやすい
エラーメッセージからは絶対に辿り着けない部類。lms log stream --source server で llama-server の生エラーを見るのが突破口だった
Procmon で「アクセスの失敗」ではなく「アクセスの不在」に気づけるかが分水嶺だった

16. 同じエラーに遭遇した人向けの確認ポイント

まず確認したいこと

自分のプロファイルパスに非 ASCII が含まれるか。

1
$env:USERPROFILE

C:\Users\ の後に日本語等が含まれていれば、この記事のケースの可能性が高いです。

次にやること

llama-server の生エラーを見ます。

1
lms log stream --source server

これを張った状態でモデルをロードし、--chat-template-file ... failed to open file が出れば確定です。あとは解決策の通り TEMP / TMP を ASCII パスへ。

いきなり遠回りしなくてよいもの

今回のケースに限れば、次の作業は全部遠回りでした。

ランタイムパックの再インストール
LM Studio の完全クリーン再インストール
モデルの再ダウンロード
GPU ドライバの更新
Defender の除外設定

exitCode=1 の中身を見ずにこれらを繰り返しても直りません。まず lms log stream です。

まとめ

今回のトラブルは、表面上は llama-server の起動失敗 (exitCode=1) にしか見えないものの、実際には 日本語ユーザー名によって %TEMP% が非 ASCII パスになり、llama.cpp の --chat-template-file がそのファイルを開けなかった ことが原因でした。

解決策は、TEMP / TMP 環境変数を ASCII のみのパスに変更してサインインし直すこと。モデルフォルダの移動は不要です。

同一バイナリで --model は非 ASCII パスを読めるのに --chat-template-file は読めない、という綺麗な最小再現まで取れました。同じ構成 (Entra 参加 + 日本語表示名) の端末は今後も増えるはずなので、同じエラーで困っている方の参考になれば幸いです。

余談（人間執筆。）

昔っから、フォルダに全角パスが含まれるのはどうにもいけ好かなくて嫌いな人間ではあるのですが、やはりまた似たような症状が出てしまったか、、、、という思いです。

個人で作成する部分は極力、マルチバイト文字を使わないようにしているのですが、システムで勝手に作られる部分はどうしたものかなぁと思っています。

初回のタイミングで早めに気が付ければ今回の手順のように環境変数を片っ端から修正しておくということができるのですが、しばらく使っているPCだとそんなの面倒くさくってしょうがないですよね。

ちなみにわれらが天下のMS様はこんな回答がありまして。

Entraid

learn.microsoft.com

当分望み薄っぽいですね。ちゃんちゃん。