最先端の質問応答技術の研究開発と迅速な実用化ーStudio Ousiaでの取り組みー

情報処理学会第255回自然言語処理研究会 での招待講演資料です。

Transcript

1. 山田 育矢 (Ikuya Yamada)
   Studio Ousia
   最先端の質問応答技術の研究開発と迅速な実用化
   ーStudio Ousiaでの取り組みー
   

   View Slide

2. 自己紹介
   山田 育矢 (@ikuyamada)
   Studio Ousia 共同創業者チーフサイエンティスト
   理化学研究所AIP 客員研究員（知識獲得チーム、言語情報アクセス技術チーム）
   ● 大学入学時に、ベンチャー企業を起業し売却（2000年〜2006年）
   ○ インターネットの基盤技術（Peer to Peer通信におけるNAT越え問題）の研究開発を推進
   ○ 売却先企業は株式上場
   ● Studio Ousiaを共同創業し、自然言語処理に取り組む（2007年〜）
   ○ 質問応答を中心とした自然言語処理の研究開発を推進
   ● プログラミングが好き
   ○ 最近よく使うライブラリ：PyTorch、PyTorch-lightning、transformers、Wikipedia2Vec
   ● コンペティション・シェアードタスクにいろいろ出場
   ○ 優勝したタスク：#Microposts @ WWW2015, W-NUT Task #1 @ ACL 2015, HCQA @ NAACL 2016,
   HCQA @ NIPS 2017, Semantic Web Challenge @ ISWC 2020
   2
   

   View Slide

3. 本日の講演の流れ
   質問応答の研究開発から製品化に至るまでの
   Studio Ousiaでの取り組みを紹介します
   ● オープンドメイン質問応答の研究開発
   ● 質問応答の実用化：アンサーロボ
   ● スタートアップでの研究開発のおはなし
   3
   

   View Slide

4. これまでの質問応答への取り組み
   (2017-2020)
   4
   

   View Slide

5. 早押しクイズコンペティション @ NIPS 2017
   5
   ● 開発した単語とエンティティの
   ベクトル表現（Wikipedia2Vec）を
   使った質問応答システムを実装
   ● クイズで使ったモデル構造と
   Wikipedia2Vecは、CoNLL 2019、
   EMNLP 2020 (demo)でそれぞれ発表
   NIPS2017で行われた早押しクイズのコンペティションに参加
   (NIPS 2017 Human-Computer Question Answering Competition)
   

   View Slide

6. 早押しクイズコンペティション @ NIPS 2017
   6
   ● 開発した単語とエンティティの
   ベクトル表現（Wikipedia2Vec）を
   使った質問応答システムを実装
   ● クイズで使ったモデル構造と
   Wikipedia2Vecは、CoNLL 2019、
   EMNLP 2020 (demo)でそれぞれ発表
   クイズ文中の単語とエンティティを入力する
   （エンティティリンキングでエンティティを抽出）
   NIPS2017で行われた早押しクイズのコンペティションに参加
   (NIPS 2017 Human-Computer Question Answering Competition)
   回答するエンティティを候補から選ぶ
   （Wikipediaから回答エンティティを選ぶ超多クラス分類）
   

   View Slide

7. 早押しクイズコンペティション @ NIPS 2017
   7
   NIPS 2017で行われたクイズ対戦で、
   全米クイズ王チームに勝利！
   ● コンペティションに投稿されたシステムで
   最も良いスコアを獲得
   ● 「ジェパディ！」の優勝者を含む
   全米クイズ王チーム6人と対戦し、
   465 対 200 の大差で勝利！
   https://www.itmedia.co.jp/news/articles/1802/28/news037.html
   

   View Slide

8. 抽出型質問応答（SQuAD v1.1）
   ● 訓練済言語モデル（RoBERTa）をベースに、Wikipediaを用いた追加の
   事前訓練を行ってエンティティエンべディングを学習
   ● 単語に加えてパッセージ中のエンティティを入力することで、タスクに
   有用な情報を増やして性能を改善
   8
   知識拡張型言語モデルLUKEで抽出型質問応答（SQuAD v1.1）でSOTAを獲得
   

   View Slide

9. 抽出型質問応答（SQuAD v1.1）
   9
   SQuAD v1.1での評価結果
   リーダーボードで一位を獲得
   

   View Slide

10. オープンドメイン質問応答への取り組み
    (2020-)
    10
    

    View Slide

11. オープンドメイン質問応答とは？
    ● 知識ソース（Wikipedia等）を参照して解答を生成
    ● BERT等の事前訓練モデルの台頭で実用的な性能で解けるようになった
    11
    質問応答システム
    「吾輩は猫である」の
    作者は誰？
    夏目漱石
    知識ソース
    

    View Slide

12. NeurIPS EfficientQAコンペティション
    ● Google等に所属する研究者が開催
    ● システムの精度と計算効率の双方にフォーカス
    ● モデルやデータを全て含んだDockerイメージのサイズを制約
    ● 4つのトラックのうち、無制限トラックと6GB以内トラックに参加
    ○ 無制限
    ○ 6GB以内
    ○ 500MB以内
    ○ 25％以上の性能を出した最小のシステム 12
    NeurIPS 2020で行われたオープンドメイン質問応答のコンペティションに参加
    

    View Slide

13. コンペティションの背景
    ● 近年の質問応答システムでstate of the artスコアを出すには
    大規模な計算資源が必要
    ○ 例：Natural Questionsデータセットで当時のSOTAだったFusion-in-Decoderは
    64枚のTesla V100 GPU 32GBで訓練されている
    ● 性能を上げるためには、大きいニューラルネットワークを大きい
    メモリを積んだ複数枚のGPUで分散訓練するのが有利
    ● 研究予算の大きい大手企業が有利になりがち
    13
    システムの容量を制約して計算資源が少ないチームでも戦いやすくする
    

    View Slide

14. Natural Questionsデータセットの例
    Q: who is under the mask of darth vader
    A: Anakin Skywalker
    Q: who has the most gold medals in the winter olympics of all time
    A: Norway
    Q: how many episodes are there in dragon ball z
    A: 291
    Q: who has the most followers in the world on instagram
    A: Instagram
    Q: ok google who was the second president of the united states
    A: John Adams
    14
    Googleで検索された質問とその解答で構成されるデータセット
    

    View Slide

15. 15
    東北大学との合同チームで出場
    

    View Slide

16. 16
    2位
    6GB制約トラック
    

    View Slide

17. 順位 名前 スコア
    1 Microsoft Research 54.00
    2 Facebook AI 53.89
    3 Studio Ousia & Tohoku Univ. 52.78
    4 Brno Univ. of Technology 50.33
    5 Huawei Noah’s Ark Lab 48.06
    6 Salesforce 46.83
    17
    3位
    無制約トラック
    

    View Slide

18. 18
    オープンドメイン質問応答の技術
    

    View Slide

19. Retriever-readerアプローチ
    ● Retriever: 大量のパッセージから高速に候補パッセージを探す軽いモデル
    ● Reader: パッセージを詳しく読む重たいモデル
    19
    Retriever Reader
    我が輩は猫である
    を書いた作家は？
    夏目漱石
    上位k件の該当性の
    高いパッセージ
    知識ソース (Wikipedia等)
    Retrieverが知識ソースから少量の候補パッセージを選択し、
    Readerが候補パッセージを詳しく読んで解答
    

    View Slide

20. 20
    ReaderではなくRetrieverに注力する理由：
    1. Readerの訓練には解答文字列のデータが必要
    ○ 実世界の問題ではアノテーションのコストが高く入手が困難なことが多い
    ○ ファクトイド型の質問しかうまく扱えない
    2. “超”大規模言語モデル（ChatGPT等）との組み合わせの相性が良い
    （retrieval-augmented LM）
    ニューラルネットを用いたRetrieverに重点を置いて開発しています
    技術開発の方針
    

    View Slide

21. Retrieverに関連する主な研究テーマ
    ● 軽量化
    ○ 推論の軽量化
    ○ 訓練の軽量化
    ● 精度向上
    ○ 性能の良いモデルの開発
    ○ 大きなモデルからの蒸留
    21
    ● ドメイン外への転移性能の向上
    ○ プロンプト・チューニング
    ○ 転移に強いモデルの開発
    ● 遠距離学習
    ○ 訓練データのウェブからの獲得
    （日本語、多言語）
    ○ 擬似クエリ・パッセージ生成
    様々な手法を気軽に試してうまくいった方法を論文化しています
    

    View Slide

22. Retrieverに関連する主な研究テーマ
    ● 軽量化
    ○ 推論の軽量化
    ○ 訓練の軽量化
    ● 精度向上
    ○ 性能の良いモデルの開発
    ○ 大きなモデルからの蒸留
    22
    ● ドメイン外への転移性能の向上
    ○ プロンプト・チューニング
    ○ 転移に強いモデルの開発
    ● 遠距離学習
    ○ 訓練データのウェブからの獲得
    （日本語、多言語）
    ○ 擬似クエリ・パッセージ生成
    様々な手法を気軽に試してうまくいった方法を論文化しています
    本講演では、研究の取り組みの例として、推論の軽量化に関する研究を紹介します
    

    View Slide

23. 23
    ハッシングによる
    Dense Passage Retrieverの軽量化
    

    View Slide

24. Dense Passage Retriever (DPR): 概要
    24
    ● 質問用とパッセージ用の2つのBERTを使って
    質問とパッセージをベクトルにエンコード
    ○ BERTの[CLS]トークンの出力表現を用いる
    ● 質問とパッセージの”近さ”をそれぞれの
    ベクトル表現の内積で表現
    DPR: 最もよく使われている単純なRetriever
    q: 質問 p: パッセージ
    E
    Q
    (･): 質問エンコーダ
    E
    P
    (･): パッセージエンコーダ
    Karpukhin et al. 2020 Dense Passage Retrieval for Open-Domain Question Answering. EMNLP.
    パッセージ
    エンコーダ
    質問
    エンコーダ
    パッセージ 質問
    スコア
    内積
    [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd
    

    View Slide

25. DPR: 推論の仕組み
    ● 知識ソースに含まれる全てのパッセージを予めベクトルに変換し、
    パッセージのベクトルインデクスを作成する
    インデクス：[パッセージ数×ベクトルの次元] の巨大な行列
    ● 質問のベクトルをクエリとした近傍探索として解く
    ○ 高速に動作する実装がある（Faiss, ScaNN等）
    ○ HNSW等の近似近傍探索を適用することで推論速度を高速化できる
    25
    

    View Slide

26. DPR: メモリコストの問題
    26
    各パッセージベクトルのサイズ:
    4 バイト * 768 次元 ≒ 3072 バイト
    (float32) (BERT出力次元)
    3072 バイト * 21,000,000 ≒ 65GB
    英語Wikipediaパッセージ（21M）のインデクスに必要なサイズ：
    インデクスは基本的に物理メモリに置く必要がある
    

    View Slide

27. 27
    インデクスを小さくして
    普通のマシンでも動くようにしたい...
    

    View Slide

28. Binary Passage Retriever (BPR)
    ● 実数ベクトルからバイナリベクトルに変換を行うハッシュ関数を
    エンドツーエンドで学習 (learning-to-hash)
    ● 候補生成とリランキングの二つのステージでタスクを解く
    28
    ハッシングという技法を使ってDPRを拡張し
    パッセージを実数ではなくバイナリのベクトルとして表現する
    EfficientQAのシステムで使用した後にACL 2021で発表
    （ワシントン大学の浅井明里さんとHannaneh Hajishirzi先生との共同研究）
    

    View Slide

29. DPRとBPRの構造の違い
    29
    パッセージ
    エンコーダ
    質問
    エンコーダ
    パッセージ 質問
    スコア
    内積
    [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd
    DPR:
    

    View Slide

30. DPRとBPRの構造の違い
    30
    パッセージ
    エンコーダ
    質問
    エンコーダ
    パッセージ 質問
    スコア
    内積
    [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd
    パッセージ
    エンコーダ
    質問
    エンコーダ
    パッセージ 質問
    リランキング
    内積
    [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd
    ハッシュ
    レイヤー
    ハッシュ
    レイヤー
    [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d
    ハミング距離
    候補生成
    DPR: BPR:
    

    View Slide

31. DPRとBPRの構造の違い
    31
    パッセージ
    エンコーダ
    質問
    エンコーダ
    パッセージ 質問
    スコア
    内積
    [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd
    パッセージ
    エンコーダ
    質問
    エンコーダ
    パッセージ 質問
    リランキング
    内積
    [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd
    ハッシュ
    レイヤー
    ハッシュ
    レイヤー
    [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d
    ハミング距離
    候補生成
    DPR: BPR:
    

    View Slide

32. BPR: ハッシュレイヤー
    32
    パッセージ
    エンコーダ
    質問
    エンコーダ
    パッセージ 質問
    リランキング
    内積
    [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd
    ハッシュ
    レイヤー
    ハッシュ
    レイヤー
    [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d
    ハミング距離
    候補生成
    エンコーダの上にハッシュレイヤーを追加
    エンコーダによって計算された実数ベクトルを
    バイナリベクトルに変換
    ハッシュレイヤーは符号関数を用いて実装
    

    View Slide

33. BPR: 符号関数をスケールされたtanh関数で近似
    33
    問題:
    符号関数は不連続で誤差逆伝播と
    相性が悪い
    解決策:
    訓練時に符号関数をスケールされた
    tanh関数で近似する (Cao et al. 2017)
    βを訓練ステップ毎に徐々に増やす
    green: sign(x) blue: tanh(βx)
    training step: 0 (β=1, γ=0.1)
    

    View Slide

34. BPR: 符号関数をスケールされたtanh関数で近似
    34
    問題:
    符号関数は不連続で誤差逆伝播と
    相性が悪い
    解決策:
    訓練時に符号関数をスケールされた
    tanh関数で近似する (Cao et al. 2017)
    βを訓練ステップ毎に徐々に増やす
    green: sign(x) blue: tanh(βx)
    training step: 240 (β=5, γ=0.1)
    

    View Slide

35. BPR: 符号関数をスケールされたtanh関数で近似
    35
    問題:
    符号関数は不連続で誤差逆伝播と
    相性が悪い
    解決策:
    訓練時に符号関数をスケールされた
    tanh関数で近似する (Cao et al. 2017)
    βを訓練ステップ毎に徐々に増やす
    green: sign(x) blue: tanh(βx)
    training step: 990 (β=10, γ=0.1)
    

    View Slide

36. BPR: 符号関数をスケールされたtanh関数で近似
    36
    問題:
    符号関数は不連続で誤差逆伝播と
    相性が悪い
    解決策:
    訓練時に符号関数をスケールされた
    tanh関数で近似する (Cao et al. 2017)
    βを訓練ステップ毎に徐々に増やす
    green: sign(x) blue: tanh(βx)
    training step: 8990 (β=30, γ=0.1)
    

    View Slide

37. BPR: 候補生成とリランキングの二段階アプローチ
    37
    パッセージ
    エンコーダ
    質問
    エンコーダ
    パッセージ 質問
    リランキング
    内積
    [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd
    ハッシュ
    レイヤー
    ハッシュ
    レイヤー
    [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d
    ハミング距離
    候補生成
    候補生成:
    ● 少数のパッセージ候補を計算効率の高い
    ハミング距離を使って取得する
    ○ 質問: バイナリベクトル
    ○ パッセージ: バイナリベクトル
    

    View Slide

38. BPR: 候補生成とリランキングの二段階アプローチ
    38
    パッセージ
    エンコーダ
    質問
    エンコーダ
    パッセージ 質問
    リランキング
    内積
    [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd
    ハッシュ
    レイヤー
    ハッシュ
    レイヤー
    [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d
    ハミング距離
    候補生成
    候補生成:
    ● 少数のパッセージ候補を計算効率の高い
    ハミング距離を使って取得する
    ○ 質問: バイナリベクトル
    ○ パッセージ: バイナリベクトル
    リランキング:
    ● パッセージ候補を表現力の高い内積を
    用いてリランキングする
    ○ 質問: 実数ベクトル
    ○ パッセージ: バイナリベクトル
    表現力が高い
    

    View Slide

39. BPR: マルチタスク訓練
    候補生成用のランキング損失関数:
    リランキング用の交差エントロピー損失関数:
    最終的な損失関数:
    39
    二つの異なる損失関数を使ったマルチタスク訓練
    

    View Slide

40. BPR: DPRとの比較
    40
    ● 評価するパッセージ数kが20個以上での再現率でDPRと同様かDPR以上の性能
    ● DPRの計算量を飛躍的に削減
    → インデクスサイズ: 65GB -> 2GB
    → クエリ時間: 457ms -> 38ms
    Natural Questionsでの
    top-kでの再現率
    TriviaQAでの
    top-kでの再現率
    質問応答においては通常は20個以上のパッセージを
    読み込むので、20個以下の性能は重要でない
    

    View Slide

41. BPR: エンドツーエンドの質問応答性能
    41
    モデル NQ TQA
    BPR+抽出型リーダ 41.6 56.8
    DPR+抽出型リーダ 41.5 56.8
    ● DPRと同様の性能を飛躍的に小さい計算効率で実現
    Natural QuestionsとTriviaQAでの正解率（exact match）
    同じBERTをベースにした
    抽出型リーダを使用
    

    View Slide

42. EfficientQA 6GB制約トラック
    42
    モデル トラック 順位 リトリーバ リーダ 知識ソース 自動評価 手動評価
    Facebook
    System
    6GB 1位 DPR+GAR Fusion-in-
    Decoder
    Wikipediaテキスト、リ
    スト
    53.33% 65.18%
    Ousia-Tohoku
    Soseki
    6GB 2位 BPR 抽出型
    (ELECTRA)
    Wikipediaテキスト 50.17% 62.01%
    BPRと抽出型リーダを組み合わせてEfficientQAに投稿し
    6GB制約トラックでFacebookAIについで二位
    ● Facebook AIも独自のリトリーバの軽量化（post-hocな量子化、次元削減）を実施
    ● Facebook AIとの性能差の要因
    ○ リーダの性能差（生成型（Fusion-in-decoder） v.s. 抽出型）
    ○ 知識ソースの差（Wikipediaのリスト）
    ○ リトリーバの拡張（GAR）
    

    View Slide

43. EfficientQA 6GB制約トラック
    43
    モデル トラック 順位 リトリーバ リーダ 知識ソース 自動評価 手動評価
    Facebook
    System
    6GB 1位 DPR+GAR Fusion-in-
    Decoder
    Wikipediaテキスト、リ
    スト
    53.33% 65.18%
    Ousia-Tohoku
    Soseki
    6GB 2位 BPR 抽出型
    (ELECTRA)
    Wikipediaテキスト 50.17% 62.01%
    BPRと抽出型リーダを組み合わせてEfficientQAに投稿し
    6GB制約トラックでFacebookAIについで二位
    ● Facebook AIも独自のリトリーバの軽量化（post-hocな量子化、次元削減）を実施
    ● Facebook AIとの性能差の要因
    ○ リーダの性能差（生成型（Fusion-in-decoder） v.s. 抽出型）
    ○ 知識ソースの差（Wikipediaのリスト）
    ○ リトリーバの拡張（GAR）
    我々もFusion-in-Decoderを実装したものの、当時は性能を再現できず
    

    View Slide

44. EfficientQA 6GB制約トラックでの6GBの容量の割合
    ● システムの動作に必要なリソースを6GB以内におさめる必要がある
    ○ 知識ソース（Passage corpus）
    ○ 検索インデックス
    ○ モデルのパラメータ
    ○ OS、コード、依存ライブラリ
    ● 特に知識ソースとインデックスが容量が大きい
    ○ DPRが使用している英語Wikipediaのテキストデータは約16GB
    ○ DPRのパッセージインデックスは60GB超(!)
    44
    Min et al. 2020 NeurIPS 2020 EfficientQA Competition: Systems, Analyses and Lessons Learned. ArXiv.
    6GB制約トラックにおける上位エントリのストレージの使い方
    

    View Slide

45. BPR: ベクトル検索のオープンソース実装で採用
    45
    WeaviateがBPRを公式にサポート
    vespa.ai (Yahoo検索のOSS) が
    BPRを使った大規模検索を紹介
    

    View Slide

46. 実用化：アンサーロボ
    46
    

    View Slide

47. アンサーロボ
    47
    ● 独自に大規模な日本語／多言語での質問応答データセットを収集し
    リトリーバを訓練
    ● zero-shotで企業の実データにおいて高い性能を発揮
    ● クラウド（AWS）上でのSaaSとして展開
    zero-shot型の企業向け質問応答システム
    https://answerrobot.ai
    

    View Slide

48. 30分でAIボットを作成できるアンサーロボ
    適切なFAQの抽出を高精度の訓練済AIで行うから
    すぐに・手間なく導入できる
    既存FAQを
    そのまま
    登録するだけ
    辞書登録
    学習データ登録
    不要
    シナリオ登録
    不要
    Copyright © Studio Ousia｜All Rights Reserved. 4
    

    View Slide

49. スタートアップでの研究開発
    49
    

    View Slide

50. 研究をする上で気をつけていること
    50
    ● 実世界での実用的なニーズを満たすテーマを選ぶ
    ○ 論文でのみ通用する問題設定を避ける
    ○ 実用化から遠い基礎的な内容を避ける
    

    View Slide

51. 研究をする上で気をつけていること
    51
    ● 実世界での実用的なニーズを満たすテーマを選ぶ
    ○ 論文でのみ通用する問題設定を避ける
    ○ 実用化から遠い基礎的な内容を避ける
    ● 論文にも製品にもならない中途半端な状態に陥らないようにする
    ○ 研究の各段階で目的意識を明確にして無理に続けずに早期に撤退する
    ○ なるべくインパクトのある論文として対外的に発表できるように努力する
    

    View Slide

52. 研究をする上で気をつけていること
    52
    ● 実世界での実用的なニーズを満たすテーマを選ぶ
    ○ 論文でのみ通用する問題設定を避ける
    ○ 実用化から遠い基礎的な内容を避ける
    ● 論文にも製品にもならない中途半端な状態に陥らないようにする
    ○ 研究の各段階で目的意識を明確にして無理に続けずに早期に撤退する
    ○ なるべくインパクトのある論文として対外的に発表できるように努力する
    ● 良い性能を出すことにこだわる
    ○ 性能は実用上のメリットと論文の説得力を両立する近道
    ○ ベンチマークでの性能に関するインサイトはビジネスでも有用であることが多い
    

    View Slide

53. 研究をする上で気をつけていること
    53
    ● 実世界での実用的なニーズを満たすテーマを選ぶ
    ○ 論文でのみ通用する問題設定を避ける
    ○ 実用化から遠い基礎的な内容を避ける
    ● 論文にも製品にもならない中途半端な状態に陥らないようにする
    ○ 研究の各段階で目的意識を明確にして無理に続けずに早期に撤退する
    ○ なるべくインパクトのある論文として対外的に発表できるように努力する
    ● 良い性能を出すことにこだわる
    ○ 性能は実用上のメリットと論文の説得力を両立する近道
    ○ ベンチマークでの性能に関するインサイトはビジネスでも有用であることが多い
    ● 研究用のコードと割り切らない
    ○ 研究フェーズでなるべく綺麗なコードを書いておく
    ○ そのまま拡張していけば製品に使える状態になるように努力する
    

    View Slide

54. GPU計算資源の安価な確保
    開発用GPUマシンを組み立て
    ● パーツをeBayやAmazon等で安価に調達
    ● 外排気型GPU 4枚構成のLambda Deep Learning DevBoxを
    Corsair Air 540 + pcpartpicker.comのパーツリストから自前で再現
    ● RTX 3090 4枚構成のマシン（1500W以上の電力を消費）を
    PC電源を2台載せられるPCケース（Lian Li O11 Dynamic）を使って作成
    安価なGPUクラウドの活用
    ● Vast.ai
    ● Lambda Cloud
    54
    自作GPUワークステーションとGPUクラウドを効果的に利用
    Lian Li O11 Dynamic
    Corsair Air 540
    

    View Slide

55. 55
    ikuya@ousia.jp @ikuyamada
    質問やコメント等は下記の連絡先までご連絡ください！
    ありがとうございました！
    

    View Slide