AIBR プレミアム
拓海先生、今朝の会議で部下に「エッジでDNNを動かして遅延を減らせば現場が助かる」と言われまして、しかし実際にはどう変わるのか見えなくて困っています。要点を教えていただけますか。
素晴らしい着眼点ですね！端的に言うと、本論文はエッジサーバー側で来るリクエストを賢く並べ替え、まとめて処理することで「待ち時間を大幅に減らす」手法を示しています。大丈夫、一緒に分解していけば必ず理解できますよ。
並べ替えるといっても、現場での導入コストや投資対効果が気になります。既存のサーバーを触らずに速くなるものなのでしょうか。
良い質問ですね。結論から言うと、特殊な高価ハードは前提にせず汎用サーバー（commodity hardware）で効果を出しています。重要なポイントは三つで、1) リクエストの『まとめ処理（バッチング）』を意図的に作ること、2) 同じDNNを使うリクエストを揃えるスケジューリング、3) 共有できる中間処理を活用すること、です。
これって要するに、現場から来る処理をまとめて順番を調整すれば、今ある設備でも処理が速くなるということですか。
まさにその通りです。例えるなら、工場のラインで同じ部品をまとめて流すと効率が上がるように、似た処理をまとめるとDNNの処理効率が上がるんです。安心してください、先ずは小さな負荷で実証し、効果が見えたら段階的に拡大する進め方が現実的ですよ。
実際の効果はどの程度か、数字で示してくれますか。現場には説得材料が必要でして。
論文では、最適化したサーバーのみの戦略に比べて処理能力が約67%改善したと報告されています。数字は環境依存ですが、重要なのは相対的な改善幅です。投資対効果を見極めるために、まずは既存サーバー上で小規模なA/B検証を勧めます。
A/B検証なら取り組めそうです。もう一つ聞きたいのですが、複数の異なる処理が混ざるときはどう調整するのですか。
良い観点ですね。論文は異なるDNNが共有する「共通の処理部分」を見つけ、その段階でまとめて処理できるようスケジュールを作り直します。要点は三つで、1) 個別DNNごとの最適スケジュールを作る、2) 共有できるレイヤーを見つけて同時処理を行う、3) 新しいリクエスト到着に応じて柔軟に再計算する、です。
実装は複雑じゃないですか。うちのIT担当はクラウドもうまく触れない状態でして、運用が増えるのは困ります。
お任せください、運用負荷を下げる設計が鍵です。まずはサーバー側でスケジューラを小さく実装し、既存の運用手順を変えずに試行し、効果が出た段階で自動化を進めるやり方が現実的ですよ。一歩ずつ行けば必ずできます。
分かりました。ではまず小さい検証から始めて、効果が出たら段階的に広げるという理解で進めます。要点を自分の言葉で整理すると、エッジのリクエストを賢くまとめて順番を変えることで、追加投資を抑えつつレスポンスを速められる、ということですね。
