このプロジェクトについて

全国の賃貸物件情報を自動で収集・分析し、相場より割安な「お宝物件」を見つけられるWebサービス「賃貸自動運営システム」を個人で開発・運用しています。

公開サイト: https://chintai2.happy-life-design.net
対象: 47都道府県・掲載中の全物件

物件データの一部処理にLLM(Ollama)を使っており、日中13時〜21時の間、2時間おきに定期実行しています。この処理は物件情報をサイトへ反映する前段の下準備を担っており、想定時間を超えて長引くと、次の実行時刻と重なったり、サイトへの反映が遅れたりする可能性があります。

見つかった問題

この定期処理が、想定より1時間以上長くかかるようになっていることに気づきました。

調査①: 低速な処理方式へのフォールバック

システムのログを確認したところ、少し前に行ったLLMツールの自動更新のあと、システム再起動をきっかけに、GPUの認識処理がタイムアウトして失敗し、GPUを使わない低速な処理方式に切り替わったままになっていたと判明しました。LLMツールを再起動し、GPU認識を復旧させました。

それでも残った遅延

再起動後も処理時間は完全には元に戻りませんでした。GPUの温度を記録したログを確認し、熱による速度低下ではないことをまず確認しました。そのうえでリクエストごとの処理時間の内訳をさらに調べたところ、別の原因が見つかりました。

真因: 使っていない新機能の管理コスト

同じ自動更新で、同じ会話を何度もやり取りする場面を高速化するための新機能が入っていました。ところが、この処理は物件ごとに毎回まったく異なる内容を1回だけ問い合わせる使い方をしており、会話を使い回す場面がそもそも存在しません。そのため高速化の効果は一切ないまま、この機能の管理コストだけが毎回発生していました(実測で1リクエストあたり0.3秒)。

対応

この新機能を無効化する設定を、LLMツールの起動設定ファイルに1行追記しました(変更前の状態はファイルとして保存済み)。

# Before
[Service]
...(既存の起動設定)...

# After
[Service]
...(既存の起動設定)...
Environment="LLAMA_ARG_CACHE_RAM=0"  # 追加: 未使用機能を無効化

結果

対応前後の所要時間は、定期処理の開始・終了時刻をログから直接算出した値です。

指標	対応前	対応後
所要時間	83分(4999.5秒)	68分(4109.9秒)
短縮率	-	約18%

残る課題

今回の対応後も、5月時点の所要時間(推定57分)にはまだ届いておらず、そこからさらに約3割の差が残っています。熱による速度低下・電力の制限・GPUの競合はいずれも個別に計測して原因ではないと確認できましたが、残る差の原因はまだ特定できていません。このLLMは他の個人開発プロジェクトとも共有しているリソースのため、今回の設定変更による影響もあわせて確認しながら、引き続き調査を続けます。

まとめ

処理が遅いという症状は1つでも、原因は「GPU認識の失敗」と「使っていない新機能の管理コスト」という異なる2つが重なっていました。原因を1つ見つけて満足せず、対応後にもう一度数字で確認したことで、2つ目の原因に気づけたと思います。気になる点・ご質問があればコメントでお知らせください。