オンプレミス ウェーハ検査AI： フォルダから注釈付き結果まで数分で

大規模シリコン製造事業者

弊社のクライアントは日本の複数サイトを持つシリコンウェーハメーカーで、半導体業界向けに大規模な基板を製造しています。同社の製造プロセスはすべての段階で精度を求めており、表面検査は最も労働集約的なプロセスの一つです。キャリアスクラッチ、縦方向スクラッチ、クラック、チッピング、パーティクル汚染はすべて、影響を受けたウェーハが下流に進む前に特定される必要があります。下流では欠陥のコストが各ステップで乗数的に増加します。

検査作業はこれまで、自動スキャン機器からの画像フォルダをレビューする訓練された作業員に依存してきました。この施設が運営するボリュームでは、そのモデルは自重で崩壊し始めていました。

なぜ問題をこれ以上待てなかったか

半導体メーカーは構造的な緊張に直面しています。生産スループット目標は毎サイクル上昇しますが、検査ステップは本質的に画像集中型で判断が重く、人的レビュアーだけではスケールしません。クライアントはネットワーク上にGPUインフラを持ち、明確に定義された欠陥クラスセットと、明確で一貫した命名規則を持つ本番画像フォルダがありました。大規模に推論を実行するために必要なものはすべて揃っていました。足りなかったのは展開可能なシステムでした。

パイプラインを自動化する以前の試みは推論層で失敗していました。GPUサーバーへのバッチ呼び出しがメモリ不足エラーを引き起こし、低速なシングルショット処理へのフォールバックを強制しました。この不安定さにより自動化は十分に信頼できないものとなり、作業員はAIツールを副次的なもの（テストするものであって信頼するものではないもの）として扱い続けました。ビジネスには毎回初回から機能し、プロセスオーバーヘッドを追加することなく管理者に完全な可視性を提供するシステムが必要でした。

フロアでの実際の検査の状況

このエンゲージメント前、検査ワークフローは次のような状況でした:

• 01作業員はスキャン機器からスロット→ウェーハ→画像で整理された画像フォルダを受け取っていました。
• 02画像はアドホックスクリプトを使用してレビューされていました。標準UIなし、バリデーションなし、進捗追跡なしでした。
• 03推論呼び出しはシングルショットでした。1枚の画像、1つのリクエスト、1つの結果です。GPUバッチ処理はバッチサイズ32での繰り返しOOMエラーの後に試みられ、放棄されていました。
• 04オペレーターの責任追跡記録がありませんでした。誰がどのターミナルでいつ何をレビューしたかのログがありませんでした。
• 05108枚の画像（3枚のウェーハ）を含む1ロットは7分以上かかりました。これはGPUエラーによるリトライループのないクリーンな実行での話です。
• 066種の欠陥クラスをシングルパスで検出する必要がありました。手動レビューはシフトや作業員間での不一致を意味していました。

基礎となるGPUインフラ（ファブLAN上で動作するNVIDIAサーバー）は、設定ミスと安定した推論クライアントの欠如により未活用でした。CUDAメモリプールは調整されておらず、インスタンス数はワークロードに対して不適切でした。ハードウェアは対応可能でしたが、それを取り巻くソフトウェアスタックがそうではありませんでした。

アーリャ・グローバルが構築したものとその理由

クラウド依存なし、MES変更なし、ショップフロアでのデベロッパーツール不要の本番グレードのエンドツーエンド検査自動化システムを構築しました。アーキテクチャには2つの明確な役割があります。作業員向けのWindowsクライアントと推論用のLinux GPUホストで、ファブLAN上のgRPCで接続されています。

並列前処理パイプライン

すべてのウェーハ画像は、モデルに直接送信するには処理が遅く精度が低くなるほどのサイズです。OpenCvSharpを使用した10分割タイリングシステムを実装しました。各画像はオーバーラップするタイルに分割され、パディングされ、モデルが期待するCHW形式に正規化されます。これはParallel.Forを使用して利用可能なすべてのCPUコアで並列に実行され、標準的なマルチコアワークステーションでの逐次アプローチと比較して前処理が通常50〜70%高速化されます。

推論後、タイルレベルの検出は全画像座標に再マッピングされてマージされるため、注釈付き出力は作業員が認識する元のウェーハ画像を反映します。

ネイティブC++推論層（TritonClientWrapper）

このエンゲージメントで最も重要なアーキテクチャ上の決定は、WindowsクライアントがTritonサーバーと通信する方法でした。ほとんどの実装はHTTP RESTを使用します。マネージドコードからの統合は容易ですが、リクエストごとに大きなオーバーヘッドが発生し、Tritonのネイティブな本番パスではありません。私たちはTriton自身のC++クライアントライブラリ経由のgRPCを選択しました。

私たちはTritonClientWrapperを開発しました。Triton SDK（grpc_client、gRPC++、protobuf、absl）に対して構築されたネイティブDLLです。バッチ推論リクエストを処理し、YOLOv8 ONNXの出力テンソルを解析し、結果をJSONとしてC#アプリケーション層にマーシャリングします。すべてコンパイルされたネイティブコードで行われます。UIのC#層はP/Invoke経由でこれを呼び出します。推論のホットパスはマネージドコードに入りません。

これが以前のバッチ試みが失敗した理由でした。問題はモデルやGPUではなく、未調整のメモリプールと複数のTritonインスタンスがGPUメモリを競合することによるCUDAメモリのフラグメンテーションでした。2GBのCUDAメモリプールを設定し、モデルごとにシングルインスタンスを構成し、ONNXをBFCArenaアロケーションに切り替えると、バッチ32は初回試行でクリーンに実行されました。

NVIDIA Triton推論サーバー

TritonはクライアントのオンプレミスLinuxホスト（RHEL/Ubuntu）上のDockerで動作します。YOLOv8モデルはダイナミックバッチングを有効にし、max_batch_sizeを32〜64に設定したONNX形式で提供されます。同じクライアントサーバースタックは、あらゆるCUDA対応GPU（RTX 3080クラスからH100/A100まで）で変更なしに動作します。モデルのアップグレードはTritonモデルリポジトリの新バージョンにクライアントを向けるだけで、アプリケーションの書き直しは不要です。

オペレーター優先WinFormsアプリケーション

私たちはUIの表面を意図的に最小限に抑えました。生産フロアの作業員は設定パネルや高度なオプションを必要としません。ジョブを開始して完了することを信頼できれば十分です。WinFormsアプリケーションはまさにそれを提供します:

• 01入出力フォルダの参照（使い慣れたWindowsファイルピッカー）
• 02接続テスト — 長いバッチを開始する前にTritonサーバーへの到達可能性を確認
• 03安全な実行中キャンセル付きの開始/停止
• 04ライブ進捗: 現在のウェーハ、現在の画像、経過時間 — 管理者が一目で確認可能
• 05エンジニアリングの介入なしで速度とGPU負荷を調整するための設定可能なバッチサイズ（1〜64）
• 06出力フォルダの表示 — QC準備完了の注釈付き画像、ワンクリック
• 07実行ごとにタスクIDを割り当て — すべてのバッチが分離され、監査可能で再現可能

アプリケーションは完全非同期オーケストレーションと事前バリデーションを備えた.NET 8で構築されました。DLL以外の追加ランタイム依存関係なしで標準のWindowsファブデスクトップPCで動作します。

欠陥カバレッジ

6種の欠陥クラスがシングル推論パスで検出されます:

信頼度閾値のデフォルトは0.7で、展開ごとに設定可能です。バウンディングボックスはパディングを考慮しているため、タイル配置に関わらず全解像度ウェーハ画像に正しく整列します。

展開アーキテクチャ

システムはファブネットワーク内に完全に展開されます。クラウドエンドポイントなし、ライセンスサーバーなし、外部SLA依存なしです:

導入前と導入後 — 同じワークロードで測定

パフォーマンスはサーバー調整と本番展開の前後に同じ108枚画像ロット（3枚のウェーハ）で測定されました:

運用上の変化

• 01作業員はすべてのシフトで同じモデルと同じルールを実行します。人やターミナルによって異なるアドホックスクリプトではありません。
• 02バッチ32推論は失敗した実験ではなく、今や標準パスになりました。GPU利用率はもはや管理すべき問題ではありません。
• 03すべてのバッチが生成するもの: 注釈付きJPEG、画像ごとのクラスと信頼度データを含むdetections.csv、プレーンテキストサマリー、gRPC実行ログ。QCチームは手動抽出なしに構造化された出力を受け取ります。
• 04管理者は作業員を中断したり別のツールを開いたりすることなく、ライブジョブステータス（ウェーハ番号、画像数、経過時間）を確認できます。
• 05予期しなかった恩恵として、タスクIDシステムが自然な監査証跡を作り出し、チームがその後のコンプライアンスレビューで活用しました。これは当初要件として指定されていませんでした。

“

「システムはすべてのシフトで同じモデル、同じルールを実行します。管理者はリアルタイムでステータスを確認でき、すべてのバッチが監査可能です — 誰かが追いかけて確認する必要はありません。」

“

「バッチ32は今では初回から動作します。何ヶ月もの間、ハードウェアの制約だと思っていましたが、実際は設定の問題でした。適切に修正すると、スループットの数値はすぐに変わりました。」

一回限りのプロジェクトではなくプラットフォーム

アーキテクチャは単一の検査ラインを超えてスケールするように設計されています。同じパターン（Windowsクライアント、Linux Tritonホスト、C++ gRPCブリッジ、大画像タイリング）は、任意の解像度でのあらゆるフォルダベースの検査ワークフローに適用されます。2番目の検査ラインへの展開は、新しいクライアントを同じTritonホストに向けてフォルダパスを設定するだけです。新しいファブサイトへの展開は、同じDockerコンテナを実行してクライアントバイナリを配布するだけです。

クライアントはアーリャ・グローバルと、隣接する生産ラインの第2の検査カテゴリへのシステム拡張について積極的に協議中です。モデル更新パス（Tritonリポジトリへの新ONNXファイルの投入）により、欠陥クラス定義が進化してもアプリケーションの変更は不要です。

成果を生み出した決定

3つの選択がこのエンゲージメントの成果を定義しました:

• 01マネージドよりネイティブ。推論パスにはマネージドHTTPではなくネイティブC++を使用しました。これが安定したバッチ32推論を実現した唯一の決定であり、パフォーマンス改善の他のすべてはここから続きました。
• 02非侵襲型統合。MESには触れず、既存の生産ワークフローも変更しませんでした。システムはフォルダの受け渡しのみで動作します。これはファブがすでに画像移動に使用していた同じメカニズムです。既存システムを置き換えた後ではなく、その傍らで稼働開始しました。
• 03デモのデフォルトではなく本番設定。デモレベルの設定を受け入れるのではなく、GPUスタックを本番向けに調整しました。この特定のワークロードに対するCUDAメモリプールの動作、BFCArenaアロケーション、シングルインスタンスTriton設定を理解することが、機能するシステムと失敗した実験の違いをもたらしました。

同様の課題に直面している場合

GPU推論を使用した高解像度画像検査、オンプレミスのデータ主権要件、デベロッパーツールを使用できない作業員集団は、特定のサービスが不足している問題です。私たちはこのための本番パターンを構築しました。

貴社が同様の環境で検査ボトルネック、アイドルGPUインフラ、または失敗した自動化の試みに対処している場合、私たちのアプローチとどのような同じモデルが貴社の状況に適用されるかを喜んでご共有いたします。