【日本株分析プラットフォーム】実行時刻をずらしたローカルLLM処理は、約38分から約16分に縮んだ話(後半)(2026-10-03)

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

EDINET(有価証券報告書等)の開示データをもとに、日本株の財務指標・投資判断スコアを日次で算出・公開しているサービスです。

公開サイトはこちら → https://stocks.happy-life-design.net
前回の記事(2026-10-02公開・前半)はこちら → https://qiita.com/rightcross-ae86/items/25999d105ae8cd05af2b

この記事は2部構成の後半です

	内容	公開
前半	実行時刻をずらすと決めた過程	2026-10-02(上のリンク)
後半(この記事)	ずらした効果の検証結果	2026-10-03

前半の要点は次の3つです。

• ニュースの要約と、意味が近い記事を探すための数値への変換(埋め込み)に、自前のサーバーのGPU(メモリ16GB)でローカルLLMを動かしている
• 同じGPUで別システムもローカルLLMを動かしていて、両方のモデルを同時に載せると17.2GB(phi4(14B)が9.1GB、gemma3(12B)が8.1GB)になり、16GBを超える
• そこで、スケジュールで動くこちらの4つの実行枠を、相手の空き時間帯に収めた(実行回数は4回のまま)

前半の時点では、変更後の最初の実行は処理待ちが空で、約1分で終わっていました。重い処理で動くかどうかと、効果は未確認でした。この記事では、その続きを確認した結果を書きます。

先に結論

• 変更後の4回は全て成功し、所要時間は約15〜17分(平均約16分)でした。変更前に重なっていた枠は、約29〜44分(平均約38分)でした
• 要約が1回の上限(100件)に達する重い実行でも、新しい時刻で動きました
• Ollamaのログでは、変更前は、載っているモデルを追い出して載せ直す動きが、枠の最初の約13分間に十数回ありました(2026-09-29の例)。変更後の約10時間分では0件でした
• ただし、確認できたのは変更後の約10時間分(4回の実行)だけです。エラーが解消したと言い切れる期間ではありません

前半の表現を訂正します

前半(2026-10-02公開)に、「2つが同時に動くと、メモリが足りなくなってエラーが出ていた」と書きました。Ollamaのログを調べ直すと、こちらの処理では、エラーではなく遅延として現れていました。

	前半の書き方	調べ直してわかったこと
こちらの処理	メモリ不足のエラーが出ていた	失敗せず、応答は成功(HTTP 200)していた。ただし1回の応答に47秒〜1分23秒かかっていた(通常は数秒)
HTTP 500のエラー	(区別して書いていなかった)	同じ時間帯に出ていたが、送り元はこちらの処理ではなく、同じサーバー上の別のプロセスだった。別システムのものかどうかは、未確認

前半の「エラー」は、こちらの処理については「遅延」が正確です。

何を確認したか

前半の最後に未確認として残した点を、3つの場所で調べました。

確認項目	見た場所	知りたかったこと
所要時間と成否	Airflowの実行履歴	短くなったか、失敗していないか
処理した件数	処理待ちの列(キュー)	処理待ちが空の実行ではなく、実際に処理されたか
メモリ不足の動き・応答時間・エラー	Ollamaのログ	モデルの追い出しや、HTTP 500、応答の遅れが消えたか

結果1: 所要時間は、約38分から約16分になった

	回数	所要時間
変更前・相手と重なっていた枠	実績(前半と同じ)	約29〜44分(平均約38分)
変更前・その他の3枠	実績(前半と同じ)	約17〜22分
変更後・4つの枠(2026-10-02)	4回	約15〜17分(平均約16分)・全て成功

処理待ちの列では、4回とも実際に処理が進んでいました。1回あたり、要約は100件(1回の上限)、埋め込みは44〜200件が完了していました。前半で未確認だった「phi4を読み込む長い実行が、新しい時刻で動くか」は、この4回で動いたと確認できました。

変更前の枠の処理件数とは突き合わせていないため、所要時間の比較は、厳密なものではありません。

結果2: 変更前に起きていたのは「失敗」でなく「遅延」だった

変更前の、相手と重なっていた枠のOllamaのログには、次の1行が、枠の最初の約13分間に十数回出ていました(件数は2026-09-29の例)。下に引用するのは、2026-10-01の同じ枠の実際のログです(時刻は省略し、行の末尾は...で切っています)。

level=INFO source=sched.go:557 msg="llama-server model predicted to exceed available memory, evicting" predicted="9.0 GiB" predicted_num_ctx=4096 num_batch=512 available="6.4 GiB" gpu_free="6.4 GiB" ...

phi4(約9GiB)を載せようとしたところ、GPUの空きが6.4GiBしかなく、すでにGPUに載っている相手のgemma3(12B)を追い出して、載せ直していました。モデルの載せ直しのたびに、こちらのリクエストは待たされます。

OllamaのHTTPログでは、こちらの処理のリクエストは、成功(200)でも、次のように長くかかっていました(2026-10-01の例。送り元と時刻は省略)。

[GIN] 2026/10/01 - (時刻省略) | 200 | 47.753704735s | (送り元省略) | POST "/api/generate"

同じ時間帯には、こちらとは別のプロセスのリクエストが、ちょうど1分で失敗(HTTP 500)していました。次の形の行が、1分前後の間隔で連続して出ていました。

[GIN] 2026/10/01 - (時刻省略) | 500 | 1m0s | (送り元省略) | POST "/api/generate"

ログに残っているのは、「500」と「1m0s」だけです。500になった理由の本文は、この行にはありません。

この矢印は、ログと所要時間から見た見立てです。各段階の因果を、直接測ったわけではありません。

変更前と変更後を並べると、次のとおりです。

項目	変更前(2026-09-29の例)	変更後(2026-10-02の約10時間分)
「メモリ不足の予測→モデルを追い出す」ログ	枠の最初の約13分間に十数回	0件
こちらのリクエストの応答	全て成功(HTTP 200)・1回に47秒〜1分23秒	全て成功(HTTP 200)。応答時間は、まだ集計していない
同じサーバー上の、こちら以外のプロセスのHTTP 500	2026-09-29が10件、2026-09-30が10件、2026-10-01が22件	0件(相手の稼働時間帯の約1,000件が全て成功)

HTTP 500の送り元は、同じサーバー上の、こちらではないプロセスでした。時間帯は相手の稼働と一致していますが、相手のシステムのものだと確認したわけではありません。

結果3: 処理待ちの列の失敗431件の内訳

処理待ちの列には、失敗として残っている記録が431件あります。内訳は次のとおりです。

内容	件数	時期
接続拒否	400	2026-08-15以前
読み取りタイムアウト(要約23・埋め込み6)	29	最後の6件が、変更前の最終日(2026-10-01)
HTTP 500	2	2026-08-25、2026-08-27

今回の変更に関わりそうなのは、読み取りタイムアウトの29件です。最後の6件は変更前の最終日のもので、変更後の分は、2026-10-02の時点でありません。接続拒否の400件は、2026-08-15以前の別の問題で、今回の変更とは関係がありません。

確認できたことと、できていないこと

	内容
確認できた	変更後の4回は全て成功、所要時間は約15〜17分
確認できた	要約が上限100件の重い実行でも、新しい時刻で動いた
確認できた	変更後の約10時間分で、モデルの追い出しとHTTP 500は0件
できていない	期間が約10時間分(4回の実行)だけで、数日続けて重ならないかは未確認
できていない	別システム側の様子(GPUのエラーが再発していないか)は、未確認
できていない	変更前のHTTP 500の送り元が、別システムかどうかの特定
できていない	画面から実行するAI分析(gemma3(12B))が、GPUの競合に関わるかどうかは、未調査
できていない	他にOllamaを呼ぶ処理が2つあり、用途を見ていない

したがって、現時点で言えるのは、「実行時刻をずらしたあとの約10時間分では、所要時間が短くなり、メモリ不足の動きも出ていない」までです。

見つかった限界: エラーの本文が残らない

こちらの処理は、失敗したときに、例外メッセージの先頭500文字だけを保存しています。Ollamaが返したエラーの本文は、残りません。そのため、メモリ系のエラーかどうかは、こちらの記録からは見分けられず、Ollamaのログを見る必要がありました。

Ollamaのログは、2026-09-11以降の分しか残っていません。1日分を検索するだけで数分かかるため、見る時間帯を絞る必要があります。

エラーの本文を残す改善は、候補として挙げただけで、実施するかどうかは、まだ決めていません。

まとめ

• 実行時刻をずらした後の約10時間分では、所要時間は平均約38分から約16分になり、全て成功した
• 変更前にこちらの処理に起きていたのは、エラーではなく、モデルの追い出しと載せ直しによる遅延だった(前半の表現を訂正)
• 確認できたのは約10時間分だけで、別システム側の様子も未確認。解消したかどうかは、継続して確認する

気になる点・ご質問があればコメントでお知らせください。