Proxmox VE と PBS：中小規模 On-prem 基盤の設計とバックアップ戦略

Mon, 26 Oct 2026 00:00:00 +0800

2023 年から、Operator として Proxmox VE、Proxmox Backup Server（PBS）、GPU server、On-prem infrastructure の設計と運用を担当しています。この環境では internal services と AI runtime workload を動かしており、全体の backup strategy も私の担当です。

この記事はインストール手順ではありません。中小規模のオンプレミス環境で私が重視している設計原則と、実際に遭遇して blog に記録した問題をまとめたものです（リンク先の記事は繁体字中国語です）。ホスト名、IP アドレス、ネットワーク構成、セキュリティの詳細は含めていません。設定に関する内容は一般的な指針であり、正確な情報は Proxmox の公式ドキュメントを参照してください。

背景と要件

オンプレミスの要件はたいてい現実的です。internal services を長期間安定して動かし、AI workload には GPU が必要で、データはバックアップでき、復元できなければなりません。予算も人手も限られているため、少人数で保守できるプラットフォームであることが重要です。

Proxmox VE はこうした状況に合っています。VM と LXC container を同じ画面で管理でき、クラスタ、ストレージ、バックアップにも標準の仕組みがあり、PBS を組み合わせれば incremental かつ deduplicated なバックアップが取れます。私にとって大事なのは機能の多さではなく、障害時にすばやく調査し、復旧できるかどうかです。

この領域での主な担当業務は次のとおりです。

Proxmox VE cluster、virtualization、storage、VM lifecycle の設計と運用。
Proxmox Backup Server の構築と、backup、restore、disaster recovery のプロセス設計。
NVIDIA GPU server、driver / runtime、inference environment の管理とシステムチューニング。
Dell、HP、Supermicro の server hardware と GPU server の仕様を評価し、調達・運用できる技術仕様にまとめること。
社内外のデータセンター、site-to-site backup、high availability の経路設計と、LibreNMS による network / server monitoring。

設計のポイント：クラスタ、ストレージ、ネットワーク

クラスタ

クラスタには集中管理と VM 移動というメリットがありますが、quorum の問題もついてきます。Proxmox VE 公式ドキュメントによると、High Availability を使うには信頼できる quorum のために最低 3 ノードが必要です。2 ノード構成の場合は QDevice で 3 票目を補えます。

Speech AI と GPU Runtime：Kaldi・Whisper のデプロイと運用ノート

Mon, 26 Oct 2026 00:00:00 +0800

2022 年から、私は Kaldi や Whisper といった speech recognition 技術と GPU runtime を実際のシステムに組み込む仕事をしています。範囲は model inference、system deployment、そしてその後の performance maintenance です。

この記事は特定プロジェクトの詳細な事例紹介ではなく、社内のアーキテクチャ、データ、性能数値は含みません。まとめたいのは、この種の仕事への向き合い方です。Kaldi と Whisper の違いをどう捉えているか、なぜ GPU runtime を先に安定させるのか、デプロイ後に何を確認しているのかを書きます。技術的な説明は公式ドキュメントに基づき、トラブル対応の経験は blog.clarence.tw（中国語）で公開してきた記事から引いています。

プロダクトにおける Speech AI の位置づけ

私の仕事の進め方でも書いたように、LLM や Speech AI の仕事は model API を呼ぶだけでは終わりません。batch processing、local model、GPU runtime、既存の backend workflow とつなげる必要があります。

音声認識は、多くの場合プロダクト全体の流れの一部です。一般的には、認識の前に音声の取得、形式変換、分割があり、認識の後にはテキストの後処理、保存、検索、他サービスへの受け渡しがあります。そのため Speech AI のコンポーネントを評価するときは、認識結果そのものだけでなく、次の点も一緒に見ます。

入力音声の形式と品質はそろっているか。前処理はどのレイヤーが担当するか。
ストリーミング認識か batch 処理か。失敗時にどう retry するか。
モデル出力をどう検証し、どの場合に人の確認が必要か。
この runtime を別のマシンで再構築できるか。

同じツールでも内容によって結果が大きく変わることは、早い段階で実感しました。2019 年に Amazon Transcribe が簡体字中国語に対応したとき、試してみた感想を記事にしました。歌では結果が良くなかった一方、会話中心の動画ではかなり良くなりました。managed service でも自前でデプロイするモデルでも、実際の利用シーンに近い音声で判断する必要があります。

Kaldi と Whisper の特性とトレードオフ

私の仕事では Kaldi と Whisper の両方を使います。どちらかがもう一方を置き換えるものではなく、設計思想が大きく異なる二つのツールだと考えています。