目次 — 知りたいところから読む

自宅サーバーの省電力を考えるなら、瞬間の最大Wだけでなく、何もしていない時間と、同じ仕事を終えるまでのWhを見る。ここではコンセント型電力計のログを集計する方法を示す。実サーバーの測定は未実施で、添付の40 Wデータは計算確認用の合成値である。

測定の境界を固定する

電力計に接続した範囲を決める。サーバー単体なのか、UPSの損失を含むのか、外付けストレージやネットワーク機器も含むのかで結果は変わる。定格範囲内で使える電力計を用い、PC内部の配線を加工する必要はない。

読むのは有効電力Wと電力量Whである。電圧Vと電流Aの積は皮相電力VAであり、交流負荷では力率が関係する。単にV×Aをサーバーの消費Wとして扱わない。横河の電力測定の基礎で、有効電力・皮相電力・力率の関係を確認できる。表示分解能、精度、記録周期、低負荷時の測定範囲も電力計の説明書から記録する。

図1 · ボタンで表示を切り替え
測定境界、アイドル、固定仕事、積分の手順

アイドルを一つの状態にする

起動直後の更新やインデックス作成を避け、サービス、CPU設定、GPU常駐モデル、ディスクの回転状態、画面、ファン、室温を記録する。「アイドル」はCPU使用率だけで決めず、バックグラウンド処理が落ち着いた区間を選ぶ。たとえば10分を観測窓に決めても、周期処理が30分ごとなら見逃す。最初は長めのログで周期を調べる。

ストレージを停止した構成と回転した構成は別条件とする。停止による省電力と、アクセス開始時の待ち時間・起動回数は別の評価軸になる。

AIとストレージの仕事を固定する

AI推論はモデル・量子化・入力・出力上限・並列数・キャッシュ条件をそろえる。ローカルLLMの測定で時間と生成数を記録し、その開始・完了を電力ログへ対応させる。最初のモデル読込を含む試験と、常駐後の試験を分ける。

ストレージはファイル数・総量・読み書き・キャッシュの状態を固定し、演習専用データで行う。書込処理の終了がアプリの返答なのか、同期完了なのかも定義する。ページキャッシュに当たった読み出しを、ディスクそのものの性能や電力として解釈しない。

Wを時間で積分する

時刻tを秒、電力PをWとし、隣り合う標本間を直線で結ぶ台形則を使う。

E_{\mathrm{Wh}}=\frac{1}{3600}\sum_i\frac{P_i+P_{i+1}}{2}(t_{i+1}-t_i)

平均WはWhを測定時間[h]で割ればよい。電力が一定40 Wで600 sなら6.667 Whとなる。40 Wが24時間30日ずっと続く仮定なら28.8 kWhである。これは算術例であり、このサイトのサーバーの実績や料金予測ではない。

CSV集計を試す

power_log.py合成CSVを同じフォルダへ保存する。Python 3.12.3の標準ライブラリで実行を確認した。

python3 power_log.py server-power-synthetic.csv

期待結果はduration_s=600、mean_W=40、energy_Wh=6.666666…、samples=601である。検証結果も掲載した。CSVはtime_s,power_Wの2列で、1ファイルを一つの連続した測定区間にする。重複時刻、非有限値、負の電力、2 sを超える欠測間隔を拒否する。既定は1 Hz記録を想定しており、違う周期なら--max-gapを明示する。

標本の最大値はpeak_sampled_Wであって、標本間の瞬間ピークを保証しない。電力計が区間平均を出す場合は、その出力定義に合った積分方法を選ぶ必要がある。

比較結果の読み方

全体のWhと、アイドル平均W×処理時間を引いた増分Whを分けて報告する。差し引きは「その間ずっと同じアイドル状態だった」という仮定を含み、CPU・GPU・ディスクの厳密な内訳測定にはならない。一条件だけ変えた比較でも、ファンや電源効率などが一緒に変わる可能性を残す。

同じ仕事を短時間で終えれば、高いWでもWhが小さくなる場合がある。反対に、短い処理の省電力化より長いアイドル時間の削減が効くこともある。実測表には境界、環境、観測周期、反復数、所要時間、平均W、Wh、処理量をそろえ、性能と電力量を一緒に読む。

次に読む

同じ処理を比較するため、入力と生成量をそろえる。ローカルLLMの速さをどう測るか前提を確認する自宅サーバーのバックアップから復元まで — 小さなデータで復元演習する同じ分野を別の観点から読むDockerのデータはどこにあるのか