古いPCをAI開発サーバーに再利用する — 自宅ラボの役割と構成

古いPCをAI開発に使うというと、最新LLMを高速に動かす話になりがちです。しかし、数年前のPCへ大きなモデルを無理に載せても、遅さと電力消費に悩むだけかもしれません。自宅ラボで価値が出るのは、速い計算より「いつでも同じ場所で動く」役割です。

たとえば、夜間の文字起こし、文書インデックスの更新、小さなローカルLLM API、CI、監視は、開発用ノートPCを占有したくない処理です。この記事では、古いPCを常時サーバーへ再利用し、AI開発の裏方として使う構成と安全な始め方を整理します。

再利用前にハードウェアを棚卸しする

最初にOSを入れ替えるのではなく、現状を記録します。

確認項目	判断すること
CPUと命令セット	64bit OSとコンテナを動かせるか
メモリ	モデル、DB、OSを同時に置けるか
GPUとVRAM	対応ランタイムがあるか、推論を載せる価値があるか
ストレージ	健康状態、空き容量、交換可能性
有線LAN	大きなモデルやデータの転送に耐えるか
待機電力・騒音	常時運転してよいか

古いNVIDIA GPUがあっても、現在のCUDA、ドライバ、フレームワークが対応するとは限りません。NVIDIAの公式手順では、CUDA対応GPU、対応Linux、コンパイラが要件です[4]。型番を確認し、公式対応外ならCPUサーバーとして設計します。

ストレージにSMARTエラーがある、ファンが異音を出す、負荷時に停止する場合は、先に部品を交換します。重要データの唯一の保存先にはしません。

役割を「常時動く裏方」に限定する

古いPCへ向く役割は、最高速度を要求しないものです。

• 小さな量子化LLMのAPI
• 文書の分割、埋め込み、検索インデックス更新
• 音声ファイルの夜間書き起こし
• テスト、静的解析、定期ビルド
• モデル・データセットのキャッシュ
• 実験メトリクスとログの収集

反対に、大規模モデルの学習、短納期の動画処理、多人数が同時利用する本番APIは向きません。処理が遅くても翌朝までに終わればよい仕事を選びます。

ローカルLLMの利活用7選から用途を選び、「このPCが停止しても業務が止まらない」範囲で始めます。

最小構成を決める

扱いやすい構成は、次の4層です。

開発用PC
  └─ SSH / LAN
      └─ 再利用PC
          ├─ Linux
          ├─ Docker
          ├─ Ollamaなどのモデルサーバー
          └─ データ用Volume

Linuxを直接入れると、デスクトップUIに使うメモリを減らし、SSHで管理できます。既存Windowsを残す必要があるならWSL2も候補ですが、常時サーバーとしては再起動、ログイン、更新後の復帰まで確認します。

サービスをコンテナ化すると、構成をファイルで残しやすくなります。ただしGPUパススルーはCPUコンテナより複雑です。最初はCPUで疎通させ、GPUは対応を確認してから追加します。

OllamaをローカルAPIとして試す

OllamaのAPIは、インストール後に既定でhttp://localhost:11434/apiへ提供されます[2]。まず再利用PC自身から、モデル一覧と生成APIが応答することを確認します。

curl http://localhost:11434/api/tags

モデルを取得した後は、次のように最小の生成を試せます。

curl http://localhost:11434/api/generate \
  -d '{"model":"YOUR_MODEL","prompt":"3行で自己紹介してください","stream":false}'

YOUR_MODELは実際に取得したモデル名へ置き換えます。この記事では特定モデルの取得コマンドを固定しません。モデルの公開状況、ライセンス、必要メモリが変わるためです。

Ollamaのollama psでは、モデルがCPUメモリ、GPU、または両方のどこへ載ったかを確認できます[1]。応答速度だけでなく、メモリ使用量、温度、消費電力も記録します。

LAN公開は疎通より先に境界を決める

Ollamaは既定で127.0.0.1へバインドされ、設定によりネットワーク公開できます[1]。しかし、0.0.0.0へ変えるだけでは認証付きサービスになりません。

安全に試す順序は次の通りです。

1. 再利用PC自身のlocalhostだけで動かす
2. SSHポートフォワーディングで開発PCから接続する
3. 必要ならLAN内の特定端末だけをファイアウォールで許可する
4. 複数人利用ではリバースプロキシ、TLS、認証、利用ログを追加する
5. インターネットへ直接公開しない

SSHポートフォワーディングなら、開発PC側で次のようにローカルポートへ転送できます。

ssh -N -L 11434:127.0.0.1:11434 [email protected]

この状態では、開発PCのhttp://localhost:11434へのアクセスが再利用PCへ届きます。ホスト名とユーザー名は自分の環境へ置き換えます。

データをコンテナの外へ出す

コンテナを削除したときにモデルやインデックスまで消える構成は、更新のたびに大きな再ダウンロードを生みます。Docker Volumeは、コンテナのライフサイクル外でデータを永続化する仕組みです[3]。

少なくとも次を分けます。

• アプリ設定: Gitで管理できるテキスト
• モデル: 再取得可能だが容量が大きいキャッシュ
• 原本データ: バックアップ対象
• 検索インデックス: 原本から再生成できる派生データ
• ログ: 保存期間を決めてローテーション

原本と派生データを同じディレクトリへ混ぜないことが重要です。ディスクが足りなくなったとき、モデルキャッシュと検索インデックスは消して再生成できますが、原本は消せません。

バッチ処理を夜間へ逃がす

常時サーバーの利点は、対話速度よりスケジュール実行です。たとえば、監視対象ディレクトリに置かれた音声を夜間に書き起こし、終了後に結果とステータスを保存します。

バッチには次の状態を持たせます。

状態	意味
pending	未処理
running	実行中
succeeded	成果物を保存済み
failed	エラーと再実行回数を保存

ファイル名だけで処理済みを判断すると、上書きや同名ファイルで崩れます。入力のハッシュ、処理プログラムの版、モデル名を記録すると再現しやすくなります。Whisperの書き起こしパイプラインも、常時サーバーへ移しやすい処理です。

監視するのはAI精度だけではない

古いPCでは、温度、ディスク、メモリ不足が先に問題になります。最低限、次を確認します。

• ディスク残量とSMART状態
• CPU・GPU温度
• メモリとスワップ
• サービスの生存確認
• バッチの成功・失敗件数
• 再起動後の自動復帰

ログを無期限に残すと、監視自身がディスクを埋めます。保存日数と最大サイズを決めます。停電後に自動起動しない機種なら、外出先から使う前提にしない方が安全です。

再利用をやめる基準も決める

古いPCを使い続けること自体が目的になると、保守時間と電力が新品より高くつきます。次の条件では撤退を検討します。

• 必要なOSやドライバのセキュリティ更新を受けられない
• アイドル時の消費電力が用途に対して大きい
• メモリ不足で常にスワップし、処理が実用時間に収まらない
• ストレージやファンの交換が繰り返し必要
• 騒音や発熱で設置場所を維持できない

重い学習だけが不足しているなら、サーバー全体を捨てず、クラウドGPUとのハイブリッドに切り替えます。再利用PCはデータ準備とジョブ投入、クラウドは計算という分担ができます。

まとめ

• 古いPCは高速学習機ではなく、常時動くAI開発の裏方として使う
• 最初にメモリ、GPU対応、ストレージ状態、電力、騒音を測る
• 小さなLLM API、RAG更新、音声処理、CI、監視が向いている
• LAN公開前にSSH転送、ファイアウォール、認証の境界を設計する
• 原本、モデルキャッシュ、派生インデックス、ログを分離する
• セキュリティ更新、電力、保守時間が見合わなくなったら撤退する

まずは1つの夜間バッチだけを移し、1週間動かしてください。安定して自動復帰し、失敗を検知できてから、次の役割を追加するのが安全です。