【要約】文字起こしが数時間終わらない。GPUは挿さっているのに「GPU未検出」だった [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
音声文字起こしツールを自作した開発者が、GPUを搭載しているにもかかわらず、処理が極端に遅いという問題に直面した。原因は、GPUの有無を判定するコードが、あらゆるエラーを「GPUなし」として一括りにしていたことにある。具体的には以下の課題があった。
- ・
except Exceptionによる例外の握り潰し。 - ・「GPUが見えない」と「検出に失敗した」の区別が不能。
- ・CPUとGPUの速度差（約7.6倍）により、数時間の待ち時間が発生。
- ・異常終了やタイムアウトが、正常な「GPUなし」として処理される。
// Approach
開発者は、GPU検出の戻り値を単なるリストから、状態を持つデータクラスへと変更することで、エラーの可視化を図った。具体的には以下のステップで実装を刷新した。
- ・ステータスを
ok、absent、errorの3値に定義。 - ・
FileNotFoundErrorやTimeoutExpired等の例外ごとに、具体的なエラー内容を保持。 - ・「GPUがない（absent）」と「検出に失敗した（error）」を明確に分離。
- ・
error状態のときは、処理を開始せずにエラーを投げる事前チェックを導入。
// Result
検出ロジックの改善により、環境に起因する問題の特定が容易になった。これにより、以下の成果が得られた。
- ・PATH不足、権限不足、ドライバ不整合などの原因が、具体的なメッセージとして表示される。
- ・「GPUがない環境でのCPU動作」と「環境トラブルによる検出失敗」を区別できる。
- ・メモリ量解析失敗（
[N/A]）が原因でCPUに落ちるような、過剰なエラー判定も解消された。 - ・異常な環境で処理を開始する前に、エラーとして停止させることが可能になった。
Senior Engineer Insight
> 外部プロセスに依存するハードウェア検出において、例外の握り潰しは致命的なデバッグ遅延を招く。単なる「成功/失敗」ではなく、状態を多値化してコンテキストを保持する設計が、運用フェーズでのMTTR（平均復旧時間）を劇的に改善する。また、検出成功が「ライブラリのロード成功」を保証しない点にも注意が必要だ。検出器が通ったからといって、実際の推論（DLLのロード）が成功するとは限らない。階層的なチェック設計が実戦では求められる。