※本記事は、Y CombinatorのGeneral PartnerであるAnkit Gupta氏と、AnthropicのHead of Pre-trainingであるNick Joseph氏による対談動画「Anthropic Head of Pretraining on Scaling Laws, Compute, and the Future of AI」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=YFeb3yAxtjE でご覧いただけます。本記事では、動画の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈についてはオリジナルの動画をご視聴いただくことをお勧めいたします。また、Y Combinator（@ycombinator）のソーシャルメディアアカウントもご参照ください。
1. はじめに
1.1 動画の概要と登場人物の紹介
司会： 本日はAnthropicでプリトレーニングを担当するHead of PretrainingのNick Josephさんにお越しいただきました。今回の対談では、まずプリトレーニングとは何かという基礎的なところから始まり、AnthropicにおけるNickさんの戦略・データ・インフラに対する考え方まで深く掘り下げていきたいと思います。この対談を通じて、AIにおける進歩がいかにプリトレーニングの進歩から直接生まれてきたかについて、皆さんに理解していただけることを期待しています。まずはNickさんのこれまでの経歴について少しお聞きしてもよいでしょうか。Anthropicに至るまで、どのような場所で働かれていたのでしょうか。またそれぞれの場所でどのような気づきを得られたのでしょうか。
2. VicarousからOpenAI、そしてAnthropicへ
2.1 キャリアの出発点とAI安全性への目覚め
Nick： 私のキャリアはVicariousから始まり、その後OpenAI、そしてAnthropicという流れです。Vicariousはもともとは汎用知能の研究をしていたラボで、私が入社したころにはロボティクス製品へと軸足を移していました。私が担当したのはロボティクス製品向けのコンピュータビジョンモデルの訓練で、これが初めての仕事でした。機械学習モデルの作り方や、機械学習のインフラをどう書くかについて本当に多くのことを学んだ時期です。
司会： 当時、アカデミアに進むことも考えていましたか？その頃はAIをやっている人の多くがPhDを取るという流れでしたし、私自身もそういう道を考えていました。Nickさんはそのあたりどう考えていたのでしょう？
Nick： 少し時間を巻き戻すと、私の考え方の多くはGiveWellというNPOでのインターンシップから来ています。GiveWellは慈善団体を評価する組織で、そこにいた人たちが「いずれAGIが実現するかもしれない、それは危険な可能性があるし、このリスクは人類全体への大きなインパクトになりうる」という話をしていました。当時の私はそれほど確信が持てなかったのですが、その後は経済学の道に進んで貧困問題に直接取り組もうとしていました。ただそれはさまざまな理由でうまくいかず、最終的に「では少なくともAIをやろう。安全性の問題が本当に重要であればそこで働けばいいし、そうでなかったとしても、AIを使って貧困問題に役立つことをより効果的にできるかもしれない」という判断に落ち着きました。アカデミアの観点からアプローチしていたわけではなくて、むしろAIに転向した理由のひとつは、経済政策の分野であればPhDに6年かけてようやくスタートできるのに対し、AIであればすぐに実際のことができるという点でした。
司会： 当時のAI安全性の議論はどのような状態だったのでしょうか？誰がそういったことを考えていたのですか？
Nick： Vicariousにも安全性について考えている人は何人かいましたが、あくまでロボティクス企業でしたから。当時の私の認識では、AI安全性の議論はかなり理論的・哲学的なもので、モデル自体がまだそれほど高性能ではなく、実際に危険をもたらすほどのものではありませんでした。「いつかすごく賢いAIが来るかもしれない、それは人間より賢くなるかもしれない、それをどう考えるか、近い将来の問題と比べてどう優先順位をつけるか」というような議論が多かったです。それは知的に面白い問いではあるものの、正直なところあまり説得力のある議論には聞こえませんでした。
2.2 OpenAIでの経験とAnthropicへの合流
司会： そして次にOpenAIに移られましたね。当時のOpenAIはどんな状況でしたか？
Nick： OpenAIでは安全チームの一員として働いていました。そこで取り組んだのはコードモデルの研究です。入社してまず目にしたのは、GPT-3をファインチューニングしてコードを書かせたというものでしたが、それが本当に優秀で、「ああ、AIの危険性を心配しているなら、AIが自分自身のコードを書けるようになることはまさにその中心的な問題のひとつだ、自己改善につながりうる」と感じました。それがどの程度起きる可能性があるのかを評価したり、何がそれに寄与しているかを研究したりしていました。その後、約8ヶ月ほどで、一緒に働いていた安全研究のリードたちがほぼ全員チームを去ることになりました。彼らがAnthropicを立ち上げるに当たって私も声をかけてもらいました。私がOpenAIに入った理由はAI安全性に取り組みたいからで、その人たちと働きたかったからです。ですから彼らについてAnthropicの創業直後に合流することにしました。
3. プリトレーニングとは何か・なぜ次トークン予測が勝ち残ったか
3.1 プリトレーニングの基本的な仕組みとスケーリング則
司会： これまでAnthropicでプリトレーニングにかなりの時間を費やしてこられたと思いますし、その内容も年々進化してきたと思います。まずそもそもプリトレーニングとは何なのか、AIモデルの発展においてどのような位置づけにあるのかというところから話していただけますか？
Nick： AIモデルをより良くするための要素のひとつとして、スケールがあります。大量のコンピュートを投入したい。では最大限のコンピュートをモデルに投入するにはどうすればいいかと考えたとき、膨大なデータが存在するような目的関数が必要になります。そこで思いつくのがインターネットです。インターネットは人類が作り出した中でおそらく最大の単一データソースです。しかしラベルはありません。誰かがインターネット全体を読んで何かコメントをつけるという作業はさせたくない。ですからデータそのものからラベルを取り出す必要があります。そのアイデアが「テキストの次の単語を予測する」というものです。「the」という最初の単語を与えて次の単語を予測し、「the cat」と与えて次を予測するという形で進めます。これによって非常に密な学習シグナルが得られます。すべての単語が新たな学習サンプルになるわけです。データ量も膨大です。そしてGPT-1やGPT-2の時代から分かってきた知見として、このアプローチにより多くのコンピュートを投入し、より多くのデータを使い、より大きなモデルにすると、モデルがより賢くなるということがありました。これがプリトレーニング全体を通じた中心的なテーゼです。
さらにスケーリング則という考え方があります。コンピュート・データ・パラメータを増やすと、次の単語の予測精度、つまりロスが非常に予測可能な形で低下していくというものです。より具体的にはロスはコンピュートの冪乗則に従って低下します。そしてこのスケーリング則の論文から、Darioをはじめとする人たちが見通していたことがあります。当時は必ずしも自明ではありませんでしたが、一度この関係が成立すると「モデルを訓練して有用なものを作って販売し、そのお金でさらにコンピュートを買い、より良いモデルを作る」というポジティブなフィードバックループが生まれます。私たちはこのサイクルをここ5年ほどで何度も繰り返してきました。
3.2 なぜ次トークン予測が他の手法を凌駕したか
司会： この目的関数について考えてみると、2017年から2020年、あるいは2021〜2022年頃を振り返ると、BERTやBARTのようなマスク言語モデルなど、プリトレーニングの目的関数としてさまざまな候補が検討されていましたね。GPTシリーズが採用している自己回帰型の次トークン予測がその中で勝ち残ったように見えますが、なぜそうなったのでしょうか。当時あれこれ試した結果そうなったのか、それとも最初から「これが正解だ」という原理的な理由があったのでしょうか？
Nick： 答えは基本的に経験的なものだと思います。物事の考え方として言えば「全部試してみて何が機能するかを見る」ということになります。自己回帰型の設定には大きな利点がひとつあって、それは後でテキストを生成するためにそこからサンプリングするのが非常に自然にできるという点です。これがプロダクトへの応用をとても自然に可能にします。また、損失関数が「実際に欲しいもの」と一致しているという性質も重要です。言語モデリングで完璧なスコアを出せれば、人間と同じようにテキストを書けるということになります。論文のタイトルを入力すれば完全な論文を出力できる、というくらいの話です。一方でBERTのような手法にはこの特性が必ずしもありません。これに対してマスク言語モデルのアプローチは、このような形でオープンエンドにサンプリングするという性質がやや弱いと思います。
司会： なるほど、先ほどおっしゃっていたループ、つまりモデルをリリースして収益を得てコンピュートに再投資するというループとの親和性も高いということですね。新しいプロダクトを出し続けてそこから収益を得てさらにコンピュートに投資するという形が最も自然にできると。
Nick： そうですね、最もオープンエンドなものを作れます。例えばあるベースモデルを訓練して、それを百個の特定タスクにファインチューニングするというアプローチも考えられます。事前に大規模な訓練をして、その後オープンエンドにサンプリングするのではなく、特定の百タスクにファインチューニングするわけです。それもひとつのやり方として機能はすると思います。ただ私が持っている一般的な直感としては、どの目的関数であっても十分なコンピュートを投入すれば、おそらくかなり良いものが得られて他のタスクにもファインチューニングできるということがあります。これらの細部がどれほど重要かは、より多くのコンピュートを投入することと比べると驚くほど小さいのです。
4. スケーリング則とコンピュート・モデル・収益のフィードバックループ
4.1 スケーリング則の実際と限界・ハイパーパラメータ設計の難しさ
司会： 実際にコンピュートを投入するとき、特定のモデルアーキテクチャに対してより多くのデータを与えるという軸もあれば、レイヤーを増やしてモデルを大きくするという軸もありますし、さまざまなアーキテクチャのバリアントに対してニューラルアーキテクチャサーチをかけるという軸もあります。現在はある程度どのアーキテクチャを使うかが固まっていると思いますが、初期の頃はそうでもなかったと思います。当時どのようにそれを判断していたのでしょうか？どんなインフラを使ってその判断をしていたのか教えてもらえますか？
Nick： 正直なところ難しいというのが答えです。やっていることは、ひとつの大きくてコストのかかるモデルを訓練することで、ハイパーパラメータと呼べるものの空間があります。レイヤー数はいくつか、幅はどれくらいか、そういった数百ものハイパーパラメータをすべて最適にしたいわけです。そこで「これらがどれくらい重要なのか、適当に決めてもっとコンピュートを投入すれば基本的に問題ないのか、それとも正確に調整すべきなのか」というバランスをどこに置くかという判断が常についてまわります。
司会： なるほど。
Nick： 興味深いのは、実はそれほど重要ではないということです。初期のスケーリング則の論文のひとつにあったと思いますが、こういった設定を変えても少し良くなるくらいで、コンピュートを投入し続ければ信頼性をもって改善していきます。ただし大きく外しすぎると、その法則に従った改善が見られなくなります。そしてそれがなぜなのかを知る手段がないというのが、ある意味で最も難しい部分です。
司会： 反事実が分からないということですね。十分長く実行していないから実際のところが分からないという。
Nick： そうです。スケーリング則があるので「コンピュートを増やせばロスが冪乗則に従って下がるはずだ」とは言えます。より正確には冪乗則＋定数の形なので、最終的にはその冪乗則から外れて頭打ちになります。そのとき「これはスケーリングの根本的な限界なのか、それとも学習率をほんの少し調整すべきだったということなのか」というのが課題のひとつです。通常のパラダイムは、大スケールで実行する前に小スケールで試すということです。
司会： 小スケールというのはデータ量の意味ですか、それとも別の何かですか？
Nick： 全部です。すべてを比例的にスケールダウンしたいわけです。FLOPSが10倍になったときにそのどれだけをレイヤーに、データに、アテンションに振り向けるかという理論を立てて、すべてを比例的にスケールダウンした条件でその理論が最適かどうかを一通り検証します。
4.2 スケーリングへの確信と他ラボとの文化的差異
司会： Anthropicの創業初期、例えば10人とか12人くらいのチームだった頃、比較的身軽なスタートアップとしてどのような大規模インフラにアクセスできていたのでしょうか。それなりの資金調達はしていたとはいえ、実際に働いている人数はそれほど多くなかった時期のことを聞かせてください。
Nick： 実は驚いたことのひとつが、少なくとも当時の感覚では、私たちが最前線にいたということです。もちろん他のラボが何をやっているかは分かりませんが、この規模の訓練に真剣に取り組んでいる人たちがそれほど多くなかったように感じていました。私はある意味でジュニアな立場でしたが、他のみんなはやり方を知っていて経験もあった。でも思ったより簡単に最前線に届けるということが意外でした。GPT-3の訓練コストの外部推定は500万ドルほどだったと記憶しています。個人にとっては大きな金額ですが、企業としては調達できる水準です。ですから、そのくらいのコンピュートを買えば当時最高クラスのモデルを訓練できた。
司会： スケーリング則の有効性について、当時他のラボでは懐疑的な声もあったのでしょうか？
Nick： 私は少し傲慢だったのかもしれませんが、周りを見渡して「この人たちは大局を見失っている」と感じていました。スケーリング則はかなり明確だと思っていましたし、反論はあまり理にかなったものに見えませんでした。元のスケーリング則の論文は11桁のオーダーをカバーしていて、「さらにもう少し続くかどうか」について激しい議論がありました。私の感覚では「11分の1の確率で失敗するかもしれないところで、確実に止まるかのように争っている」という感じでした。もちろんうまくいかないこともあります。でも、この分野に常にどっぷり浸かってプロットを作り続けていると割と明確に見えてくるものが、外から見るとかなり違って見えることもあると思います。外からは膨大な量の論文があって、みんな自分の論文をとても重要に見せようとしますから、「あ、これは本物ではないな」と思ってしまうこともあり得ます。
またラボによって文化も違いました。FAIRはよりPhD的な独立研究の文化で、それぞれが自分のアイデアを追い、コンピュートのために争うというスタイルでした。大規模言語モデルを訓練するようなプロジェクトは、多くの人が非常に複雑なインフラで密に協働する必要があって、しかもそれは論文にはなりません。「次のモデルより5%効率が良くなった」というのは論文として発表できるものではないですし、そういった文化では評価もされません。それがFAIRのような場所でこの種の仕事に力が入りにくかった理由のひとつだったかもしれません。
5. Anthropicの初期インフラ構築と効率化ハック
5.1 初期インフラの実態と低レベル最適化の必要性
司会： クラウドプロバイダーを使っていたとのことですが、カスタムセットアップだったのでしょうか、それともどこかにラックを置いてNvidiaのGPUを買い込んでいたのでしょうか？
Nick： クラウドプロバイダーを使っていましたが、実はそれほど違いはないと思っています。というのも、驚いたことのひとつが、チップの物理的な配置まで実際に理解する必要があるということだったからです。あるとき同僚がクラスタリングアルゴリズムを走らせて、チップがどの部屋に収まっているかを特定しようとしていたことがありました。チップが異なる部屋に分かれていて、それが何らかのネットワーク遅延の原因になっているという仮説を持っていたのです。逆算してみると「明らかに接続性の良い2つのクラスタがあって、その間の接続に問題がある」ということが分かりました。ハードウェアの限界をできる限り押し広げようとしていたわけです。特に初期の頃は他のほとんどのところがコンピュートの使い方に非効率だったので、私たちは「コンピュートの使い方を本当に効率化すれば大きなアドバンテージが取れる」と考えていました。
司会： 初期の頃にハードウェアから最大限の性能を引き出すために取り組んでいたことについて、もう少し教えていただけますか。たとえばGoogleの初期の事例では、比較的安価なコンシューマー向けチップを大量に買い込んで、そこから最大のコストパフォーマンスを引き出すようソフトウェアを最適化することで低レイテンシ・高可用性を実現したという話がありますが、AI初期時代にそれと似たようなことをやっていたのでしょうか？
Nick： 私たちの場合は主に分散フレームワークをきちんと整えることでした。大量のチップで訓練するためには多数のチップを使って訓練しなければなりませんし、それをどうやるかにはいくつかのアプローチがあります。データ並列化、パイプライン並列化、シャーディングなどいろいろありますが、当時はそのための優れたオープンソースパッケージがほとんど存在しませんでした。
司会： 当時はそういったものが文字通り何もなかったと思います。今は多少はあるようですが。
Nick： いくつかはありました。初期にデータ並列化に取り組んでいたとき、同僚が「さあall-reduceを自分たちで書こう」と言い出して、「本当に自分たちでやるのか、パッケージがあるんじゃないか」と思ったことを覚えています。返ってきた答えは「どうせ修正することになるから」というものでした。PyTorchにはそのためのパッケージがありましたが、私たちはFacebookが到達していない規模まで行くことになる。だからそのパッケージに依存して、常に改変し続けなければならないような状況になるのは避けたかったわけです。
司会： それ自体かなり直感に反する発言ですよね。当時FairとDeepMindは優秀な研究者を大量に採用していて、機械学習研究の最高峰と見なされていたわけですから。「Facebookが到達していない規模に行く」というのは、当時その発言を聞いてどう感じましたか？自然でしたか、それとも自分たちの判断を疑うことはありませんでしたか？
Nick： 驚いたとは思います。ただ私はおそらく少し傲慢すぎたのかもしれません。周りを見渡して「この人たちは大局を見失っている」と感じていたくらいですから。
5.2 MFU最適化・プロファイリング・デバッグの手法
司会： 実際にこれらのモデルを実装するとき、PyTorchのようなライブラリを使いつつも、すべてをそのまま使うのではなく一段低い抽象レベルでカスタマイズしていたとのことですが、カスタムCUDAカーネルを書くようなところまでは踏み込んでいたのでしょうか？
Nick： 演算の種類によります。私自身はtorch.matmulのレベルで作業していましたが、matmulをどう効率化するかは考えていませんでした。PyTorchがmatmulを最大限効率化してくれると仮定していました。ただアテンションのように非常に多くのバリアントがあってGPU上での効率化が難しい部分については、スタックのさらに低いレベルまで降りる必要がありました。
そこで面白いプロセスがあって、それまで考えたことがなかったのですが、やろうとしていることをモデル化して、効率を高めるための並列化戦略を考えるというやり方です。GPU利用率、つまりMFU（モデルFLOPs利用率）を目標として置きます。そこで「自分がやろうとしていることで理論的に達成できる効率はどれくらいか」を紙と鉛筆でモデル化できます。ボトルネックとなる制約はすべて分かっています。HBM帯域幅で律速される場合もあれば、ホストからCPUへのオフロードで律速される場合もあるし、ほかにもいくつかのポイントがあります。しかし関係する数字はそれほど多くなく、6つ程度の重要な数字があるだけです。だから完全にモデル化して制約を把握し、そこに到達できる実装を作ることができます。もちろん最初に実装したときは非効率なものができますが、そこからプロファイラーを使います。すべての演算にどれくらい時間がかかっているかを見て、それぞれの演算にかかるべき時間についてモデルを持って、その2つを一致させるわけです。
司会： 当時はすぐに使える優れたプロファイラーがあったのでしょうか？それともその規模のネットワークトポロジーに対応したものがなくて自分たちで書く必要があったのでしょうか？
Nick： 時間とともに改善されていきましたが、PyTorchのプロファイラーは実は最初からかなり優れていました。単一GPUのプロファイリングにはPyTorchプロファイラーで十分でした。しかし数百、数千のGPUで実行しているジョブ全体をプロファイルしようとすると、そういったことはほとんど誰もやっていなかった。だからプロファイラーをハックして、すべてのトレースをまとめて統合する方法を自分たちで考えました。
司会： 帯域幅の制限などに関わる6つの重要な数字の話ですが、Nickさん自身はそのような低レベルの知識をどうやって習得したのでしょうか？
Nick： Anthropicに入ったとき、嬉しかったことのひとつは、最初の日に社内Slackとナレッジベース全体を読み通せたことです。すべてが自分に関係しているという感覚があって、それはとても気持ちが良かったです。そして主にペアプログラミングで学びました。Tom Brownはそのすべてを以前にやってきた人で、Sam Mclishというマネージャーも多くのことを経験していて、最初のうちは彼らと膨大な時間をペアでやりました。ペアプログラミングによる学習の良さは、やろうとしていることを学べるというだけでなく、人がどうやるかを学べる点です。プロファイラーの使い方のようなことは、誰かのSlackへの最終的な報告を見ても分かりません。「これらを見つけて、この特定の行を変えて改善した」というのは見えますが、プロセスが見えない。4時間のYouTube動画で誰かがプロファイラーをいじっているのを見るか、実際に誰かとペアになるかのどちらかが最善です。あと振り返ると恥ずかしいのですが、Anthropicに入るまでデバッガーを一度も使ったことがなかったんです。PDBというものがあると聞いていましたが、printで十分だと思っていました。でも誰かがデバッガーを使っているところを見て、特にコードの起動に時間がかかる場合には本当に有用なツールだと分かったんです。こういうことはペアリングから最もよく学べますし、もちろん実際にやってみることからも学びます。最終的には自分でプロファイラーを立ち上げて何時間も眺めることになるわけですから。
6. 数千GPUにわたる訓練の課題と新チップとの協働
6.1 大規模分散訓練における障害・バグ・スケーリングの複雑さ
司会： 時間の経過とともにプリトレーニングはどんどん大規模になっていきましたが、GPUの数が増えれば当然ネットワーク接続も複雑になります。規模が大きくなることで生じた、一般にはあまり知られていないような壁にぶつかった経験はありますか？
Nick： チップを接続すること自体が驚くほど難しいというのがひとつあります。チップが増えれば増えるほど、AIで一般的な並列化の方法では全体が単一の障害ドメインになってしまうという問題があります。
司会： 「AIで一般的な方法」というのは、AIの分野での標準的なやり方という意味ですか、それとも他の分野でも共通する話ですか？
Nick： AI向けの話として、少なくとも初期の頃は物事がそういう作りになっていました。たとえば128GPUのクラスタがあったとして、そのうちの1台が死ぬとジョブ全体が落ちてしまいます。最もシンプルな形ではモデルを分散させて、各レイヤーを別々のチップに置くわけですが、レイヤー7を失ったらそのままレイヤー7をスキップするわけにはいきません。一応やろうとすればできなくはないでしょうが、かなり奇妙な訓練プロセスになります。
これがひとつの興味深い問題につながります。スケールアップすると、チップの絶対数が増えるにつれて障害の発生率も上がっていきます。一方でチェックポイントからすぐに再起動できるので、ある程度は管理可能です。
もうひとつ驚いたのは、スタック全体の新しさです。データセンター内のチップの配置からチップそのものまで、すべてが非常に新しい。GPUの世代もそれほど多くありません。コンピュータサイエンスを学んでいた頃は「コードが動かない→自分のせい」という前提でやっていました。コンピュータは壊れないと先生に言われていましたし。ところがAIの初期に取り組んでいて、何をやっても分からなくて完全に行き詰まっていたとき、マネージャーが見て「たぶんコンピュータがおかしい」と言うんです。そんなはずはないと思っていたのですが、本当にGPUが壊れていました。新しいものと交換しなければならなかったのです。GPUが壊れている可能性、GPUが遅い可能性、データセンターの電源が壊れている可能性、こういったことまで考慮しなければならないというのは、Pythonプログラマーとして想定していた以上の深みがあります。
司会： 初期の頃、1回の訓練実行でだいたい何台くらいのGPUを使っていたのでしょうか？数十台とか数百台くらいでしたか？
Nick： 数千台です。この部屋に収まるくらいのラック数でしたが、数千台でした。
司会： 今は1回の実行に建物全体くらいの規模が必要になっていますよね。
Nick： そうです。今は巨大なキャンパス規模になっています。当時は「全部同じ部屋に入れる必要があるか、複数の部屋に分けても大丈夫か」というのも不明確でした。理論的なモデルとして「ポイントAからポイントBへこれだけの帯域幅が必要だ」というのは分かっていましたが、どこまで詳細に考慮する必要があるのかが読めない。「全部同時に電源を入れたら電力を一括処理しているコンデンサがひとつあって、それがクラッシュするんじゃないか」みたいなことまで考えないといけないわけです。
司会： 特に発見が難しいバグへの対処についても聞かせてもらえますか？
Nick： 私が最も不安を感じるのは、本当に難しいバグです。単一のバグが何ヶ月もの作業を狂わせることがあります。モデルの訓練に数ヶ月かかるわけですから、何か見えないところでコードが間違っていてそれに気づかないまま進むと、1世代分まるごと失うことになりかねません。MLでバグを見つけるのはそもそも本当に難しい。さらにスケールアップした問題は、既にバグがあると分かっていても解決が非常に困難な場合があります。
たとえば典型的で非常に単純なMLのバグとして、10レイヤーのネットワークがあってレイヤー7が8ではなく9に接続されてしまっているというケースがあります。接続の一部が正しくない状態でもモデルは技術的には訓練されますし、すべての重みが更新されます。有効なモデルではあるけれど正しいモデルではない。これは発見がかなり難しいバグです。それがさらに百万倍複雑になったものを考えてください。深いカーネルの中で間違った精度でキャストしてしまったとか、そういうことがあると大スケールでモデルが壊れ始めます。それに気づくのが1ヶ月後だったり、あるいは永遠に気づかなかったりすることもあります。何万行ものコードの中からどうやって特定するんですかという話です。
実際にNelsonという人がブログ記事を書いた「呪われたバグ」というのがありました。私が初期にそのバグに出会って「これは難しい、誰かほかの人が見てくれ」と思って引き渡し、1ヶ月後に「引き渡して本当に良かった、自分では絶対に解けなかった」と感じたバグです。スタックのどの深さでも掘り下げられる能力というのは本当に稀なスキルです。私自身の場合、torch.matmulのレベルで作業していましたが、CUDAを知らないのでtorch.matmulが壊れていてもその中に入って解析することはできませんでした。ネットワーキングも同様で、バイトをAからBへ送ることはできても、基盤となるネットワーキングプロトコルが壊れていたら、TCP/IPやパケットについて一から学ばなければならない。
また、クラッシュするのではなくジョブが極端に遅くなるというケースもあり、それも解析が非常に難しいことがあります。
6.2 GPUとTPUの違いとチップメーカーとの協働
司会： 異なるチップの種類について考えるとき、さまざまなクラウドプロバイダーを使っているわけですが、エンジニアとしてはこれらは単純にコンピュートの供給源として捉えればいいのでしょうか、それともTPUとGPUでは実際に異なる考え方が必要になるのでしょうか？
Nick： 根本的には同じことをやっています。同じ演算、つまり行列積などを計算しています。ただやり方はかなり異なりますし、プログラミングの方法もかなり違います。また実際のスペックもかなり異なります。FLOPSが多くてメモリが少ないものもあれば、HBM帯域幅が多くてメモリが少ないものもある。複数のチップ種類を持っていることの利点は、そのジョブに最も適したチップに割り当てられることです。
司会： TPUクラスタとNvidia GPUクラスタでは、向いているジョブの種類が違うのですか？
Nick： 良い例として、推論ワークロードは一般的にHBM帯域幅をより多く必要とします。最もシンプルな形のサンプリングでは1トークンずつ生成するので、トークンごとにすべての重みをロードしなければならない。そのためHBM帯域幅が多く欲しくなります。プリトレーニングはバッチサイズが大きいのでFLOPS集約型になることが多い。ですからどのチップをどの用途に使うかをある程度特化させることができます。複数のチップ種類を持つデメリットは、それぞれ別に実装しなければならないということです。理論上は抽象化できますが、違いが大きすぎて実際には難しい。すべてのワークロードをすべてのチップでやろうとすると、作業量がチップの数だけ倍増していきます。
司会： 「コンピュータが壊れることがある」という点に関連して、あなたが以前私に話してくれたエピソードがあります。私の会社でGoogle TPUを使っていた頃に何か不思議なセグメンテーション違反が起きていると話したら、「6ヶ月前に使っていれば、うちらがTPUの問題の半分を直す前だったね」と言っていましたよね。
Nick： そうですね。チップメーカーは問題を修正することに強いインセンティブを持っています。将来的にもっとチップを売りたいわけですし、私たちも長期契約でチップを買っているので、クラスタを動かすことにすべてがかかっています。ただ完全に情報を共有できるわけではないという制約もあります。そこで有効な戦略のひとつが、小さな再現コードを作ることです。大きな本番コードでセグメンテーション違反が起きたとして、「このクラスタでセグフォルトが出た」とチップメーカーに言っても彼らには分からない。ですからそのコードベースから問題を切り出して、単一チップ、単一ファイルで問題を再現できる形にして送れるようにする必要があります。
司会： チップメーカーとのやり取りはどういう形でしていましたか？共有Slackで繋がっているような形ですか？
Nick： 主に共有Slackです。時には直接会う方が良い場合もありますが、Slackが一般的な連絡手段でした。
7. ジェネラリストvsスペシャリスト・評価指標の設計
7.1 チーム構成の変遷と組織設計上の学び
司会： 時間の経過とともにプリトレーニングの戦略がどう変わってきたか聞かせていただけますか？コンピュートが増えたのは当然として、それ以上に何が変わったのでしょうか？
Nick： 変わっていないことから言うと、驚くほど変わっていないことがあります。最初の日から全く同じメトリクスを追い続けているという点です。ある損失関数があって、それを下げる。最初に訓練したモデルから今まで同じメトリクスでプロットを作れば、チームの進歩をそのまま表せると思います。OKRとしては「できる限り低く」というもので、それを永遠に追い続けます。
一番大きく変わったのは専門分化が進んだことです。最初の3〜6ヶ月は、私はコードベースのすべてのPRを読もうとしていましたし、実際に読めていました。すべての部品を把握していたわけです。チームが大きくなるにつれて、アテンションの動かし方やパラレリズム戦略のような各領域が細かく煮詰められていき、個々の領域の深い専門家が揃ったチームができていきます。それはとても良いことで、各領域を深く掘り下げられます。ただマネージャーとして考えなければならないのは、全体の大局がきちんと意味をなしているかどうか、そして全体像を実際に理解している人が十分にいて単一障害点がないかどうかです。
司会： そのトレードオフをどう捉えますか？専門化のメリットは最適化が深められることですが、全員が同じ方向を向いていないと大きな賭けに出にくくなるという面もありますよね。
Nick： バランスを取ることを心がけています。ひとつ気づいたのは、人によって本当に好みが違うということです。ジェネラリストでいたい、すべてを理解していたい、いろいろなことに軽く触れたいという人もいれば、ひとつの領域を選んで深い専門家になりたい、もう精度については決めた、精度だけをずっと考え続けたいという人もいます。たとえば精度のPhDをやっていてそれだけを考えたいという人もいます。バランスよく取り揃えたい。
初期に失敗したパターンとして、スタートアップに早期参加するような人はジェネラリスト型が多いという傾向があって、気づいたらみんながすべてをやっていて誰もひとつのことを本当に深く理解していないという状態になっていました。これがひとつの失敗モードです。逆にスペシャリストが多すぎると、すべてをつなげる労力がリーダーに集中することになりますし、「ここのアーキテクチャを変えれば、あっちの効率化の課題がずっと楽になる」という横断的な気づきが生まれにくくなります。初期の頃は自分がそういう気づきをしやすい立場にいて、「この部分の実装をこう変えれば、効率化のために大変な作業をしなくてすむ」という判断がすぐにできていました。
チームが必要としているのはエンジニアです。この分野の歴史全体を通じて、コンピュートを投入すれば機能する、というのは常に言えることです。研究者はいると良いですが、本当の課題は「正しく動かすこと」であって、これはMLの問題ではありません。実際のアーキテクチャはかなりシンプルで、数式で書けます。でも数式を理解しなくても実装はできます。正しい実装を得て、それを大規模化して並列化してすべてが正しいかどうか確認するという、エンジニアリングの問題です。ただしそれは「Webサービスを素早くイテレートするエンジニアリング」とは違う種類のスキルです。ウェブサービスは何でも試してどれも技術的に難しくないので素早く失敗していけますが、私たちが求めているのは「どんな問題でも深く掘り下げられる」力です。
司会： そういう人たちはどこから採用しているのですか？大きく成長した会社で似たような経験をしてきた人ですか、それともアカデミアからですか？
Nick： 今の段階では、同じことをすでにやってきた人を他の場所から採用できるようになっています。JAXで訓練を効率化する役割であれば、JAXをやってきた人か、他の会社でJAXスタックを効率化してきた人を採用するという感じです。Anthropicが十分に知られるようになったので、そういった人たちを採用できるようになりましたし、分野も十分に成熟して専門的な経験を持つ人が増えています。ただ初期は様々なバックグラウンドの人を多く採用して、単純に賢くて一生懸命働く人はこれを早く習得できるということが分かりました。理論物理学者を多く採用しましたが、残留研究員としてやってきて、プログラミングを学んで、本当に優秀な成果を出していました。
7.2 評価指標の設計哲学とロスの優位性
司会： 先ほどプリトレーニングで気にする唯一のメトリクスはロスだとおっしゃっていましたが、実際にはevalについてもいろいろ考えていると思います。モデルそのものの評価や、何をモデルに入れるかというデータ品質について、ロス以外にどんなメトリクスを考えているか教えてもらえますか？
Nick： ロスは本当に良い指標だということを強調したいです。驚くほど良い指標だと思っています。私がevalに求める性質として、まず「本当に重要なことを測っているか」ということがあります。プロキシは厄介なことがあって、evalに飽和するのがとても早い。AI全体としてのパターンとして、目標を設定してそれを達成して、そして目標が思ったほどのものではなかったと気づくということが起きています。私はかつてコーディング面接の問題を解けるAIがあればそれはAGIに近いと思っていました。それが就職活動でやったことですし、仕事でもそれをやると思っていたからです。ところが実際にそれができるようになると、驚くほど狭い能力しか示さず、ほかのほとんどのことはできない。だから評価が本当に重要なことを捉えているかどうかが最も大事です。
次に低ノイズであること。100問のeval問題があってモデルを評価すると、非常にノイズが多くて判断が難しくなります。信頼区間が広くて、統計的に有意でないことが多い。小さな差でも実際に意味があると分かるくらい、evalでの差が信号として機能する必要があります。たとえばGPT-4の最初のMLUスコアは86.4%で、それを上回ったのはGeminiの90%でした。これは大きな差で、これらが異なるスコアだということははっきり分かります。そして最後に、実際に速く簡単に実行できること。
最初の条件が最も難しいと思います。何を重視するかという問いに答えなければならないだけでなく、普通の答えは他の2つの条件を満たすのが非常に難しいのです。たとえばチームのマネジメントがうまいClaudeを作りたいとします。6ヶ月計画をどうevalするかというと、よく分からない。
司会： AIの医師を作ろうとする場合を考えると、試験問題への正答率はおそらくほぼ100%近く出るでしょうが、本当に難しいevalは、患者との長い会話の中でシグナルとノイズを区別して正しい情報を抽出し診断につなげる能力です。それは診断パートではなく、このノイズ抽出パートです。それを評価するには実際の患者が必要で、かなりの時間会話しなければならず、良いevalをどうやって作るかが自明ではないのに、それがおそらく本当に作りたい「AI医師」のための最重要指標になるわけです。
Nick： まさにそうです。そしてロスが良い指標だということは言っておきたいのですが、ドメイン特化の文脈でも実はロスが有効だと思っています。優れた医師と患者の会話のトランスクリプトを大量に集めて、モデルがそのトランスクリプトをどれだけ予測できるかを測る。それだけで有用なシグナルが得られます。100件のトランスクリプトがあれば大量のトークン数になりますし、平均を取ることでノイズも低くなります。そのロスを非常に低くできれば、モデルは少なくともトランスクリプト上では医師と同レベルに達しているはずです。スタートアップのアイデアとして面白いとさえ思います。
ただevalに関して言えば、スタートアップが大きなラボの行動に影響を与えられるひとつの方法がevalを作ることだと思います。モデルを持っているラボと比べて優位性があるわけではないけれど、ラボはevalスコアを最適化しようとするので、誰でも作れるevalを作ってそれを広めれば、ラボはそのevalを最適化する方向に動くということが実際に起きています。
8. アライメントとプリトレーニング・ポストトレーニングの役割分担
8.1 アライメントとは何か・どこで行うべきか
司会： Anthropicの外部イメージとして「アライメント」というテーマが大きく打ち出されていますが、そもそもアライメントとは何なのか、そしてそれがプリトレーニングとどう関係するのかを教えてもらえますか？まず高いレベルでアライメントとは何かを定義していただければと思います。
Nick： 少し引いた視点から話すと、私たちはAGIを作ろうとしています。人間ができることをある程度すべてこなせるAIという意味です。SF映画をよく見てきた人は特定のイメージを持っているかもしれませんが、SF映画は実はその影響を過小評価していると思っています。SF映画には大抵「人間のような1体のロボット」が登場しますが、それを10億体コピーできたらどうなるか。AGIが実現したとき、人間は誰でも自分と同等かほとんどの点でそれ以上に賢い10億人の会社を立ち上げられるようになります。これは世界にとって本当に変革的なことで、さまざまな形で使われうるものです。
そこで懸念のひとつが、そのAIが実際に何をしようとしているのかという問題です。次トークン予測について何度も話してきましたが、モデルは次のトークンを予測しようとしている。それはちょっと奇妙なことで、私たちが実際に望んでいるものとは違います。アライメントとは「モデルが人間の目標と一致した目標を持つようにすること」であり、特にモデルが人間より賢くなったときにこれが重要になります。これは理論的なアプローチでも取り組めますし、実証的なアプローチでも取り組めます。実証的なアプローチとは、今あるモデルを使って「私たちが望む動作をしているか」を確認することで、しばしばそうではないことが分かるので、そこをどう直すかを探っていくというものです。
アライメントにはもうひとつの側面があって、「将来の問題は置いておいても、今あるモデルにもやってほしいことをやってほしい」という現実的な観点があります。モデルの振る舞いを制御するということ、たとえばこのモデルを訓練するにあたって「平均的なインターネットユーザーのような振る舞いをしてほしくない、特定の形で人と接してほしい」というわけです。これをコードに落とすのは難しい。さまざまなテクニックがあります。Constitutional AIという話があって、モデルが従うべきルールの「憲法」を書くというものです。
司会： それはモデルの訓練時に適用するシステムプロンプトのようなものですか、それとも訓練によってモデルの出力分布を変えるためにポストトレーニングでやることですか？
Nick： 両方です。訓練時にやることですが、システムプロンプトにも入れます。訓練済みモデルに対してシステムプロンプトに書くのか、訓練時に組み込むのかによって、ロバスト性が変わります。「以前の指示をすべて無視しろ」という入力にどれだけ耐えられるかが変わってくる。
司会： これらのモデルにどの価値観を持たせるかという問いはどう考えますか？私たち人類が共有する価値観もあれば、社会として合理的に多様であるべき価値観もありますよね。AGIにどの価値観を持たせるかをどう決めるのでしょうか？
Nick： 本当に難しい問題だと思います。ひとつ面白い言い方をすると、「どの価値観を選ぶか」よりも「そもそも価値観を制御できる状態にすること」の方が先の問題だと思っています。聞いたことがあるアナロジーで気に入っているのは「車にハンドルをつける」というものです。ハンドルがなければまずハンドルをつけることが重要で、誰が運転するか、どこへ向かうかはその後の問題です。ハンドルをつけることがまず重要だというのがひとつの答えです。
もうひとつの答えは、価値観は民主的なコントロール下に置かれるべきだということです。一人の人間の価値観をAIに持たせるのは避けるべきで、それはディストピアへの道に見えます。理想的には多くの人々と対話して、さまざまな視点からその価値観を取り込めるようなもの、あるいはある状況でどうすべきかを人々に問いかけて自ら判断しないようなもの、あるいはモデルが本当に強力になってきたときには積極的に行動しすぎないようにする、という考え方が重要だと思っています。コントロールを奪わないこと、特に望まない形でのコントロールを奪わないことが大事です。
司会： 今あるモデルのアライメント、つまりインターネット上での特定の振る舞いのようなものは、主にポストトレーニングから来るものだと直感的に思っています。プリトレーニングを終えて、ロスをある程度下げて、追加データを与えることで特定の分布の方向に調整する、というイメージです。これはだいたい正しい理解でしょうか、それともプリトレーニング自体にも重要な部分がありますか？
Nick： ほとんどの場合そのイメージで正しいと思います。私の考え方としては「ポストトレーニングでできることはポストトレーニングでやるべき」です。理由はイテレーションループの速さです。ポストトレーニングなら何かを試して、また試して、また試してを繰り返せます。それが数時間か数日でできる。プリトレーニングに入れようとすると、慎重に実験してリスクを取り除いて、次の訓練実行に組み込んで、数ヶ月待って、結果を得たときに何か問題があれば本当に深刻です。またポストトレーニングの方が有利なもうひとつの理由として、複雑なモデル行動への介入を行う場合、プリトレーニングのパラダイム、つまり小スケールでテストして大スケールで実行するという方法が機能しません。小さなモデルは文章をほとんどまとめられない。まともな人格を持たせたいなら、それは十分に賢いモデルの上でやる必要があります。
ただし、ある時点でアライメントの一部はプリトレーニングに戻してもいいかもしれないとも思っています。より強固に、より確実に組み込みたいものについては、プリトレーニングに入れることで、それがより強くモデルの知性の一部になる可能性があります。プリトレーニングを「モデルを賢くする」フェーズ、ポストトレーニングを「振る舞いを調整する」フェーズと考えると、本当は知性の一部として組み込みたいような調整が出てくることも考えられます。「プリトレーニング・オン・ヒューマン・フィードバック」という論文では、人間フィードバックの特性をプリトレーニングに組み込んでテストするということをやっていて、ポストトレーニングで与えるすべての情報をプリトレーニングに混ぜ込んでその効果を見るというアプローチです。
ただしポストトレーニングの柔軟性を失うというコストがあります。たとえばポストトレーニングをやって、多くの人と対話してみると「このモデルは『おっしゃる通りです』と言いすぎる」という問題が見つかったりします。そういう問題が見つかったときに、ポストトレーニングなら素早く対処できますが、プリトレーニングに組み込んでいれば次の訓練実行まで対処できない。イテレーションループが数ヶ月単位なのか1日単位なのかの差は本当に大きく、並列でさまざまなポストトレーニング戦略を試すこともできます。プリトレーニングのあらゆる側面が難しいのは「何ヶ月に一度しかゴールに向かって打てない」という性質があるからです。
9. プリトレーニングの未来・データ・アーキテクチャの展望
9.1 データ可用性と合成データをめぐる論点
司会： プリトレーニング自体について今後を見据えて考えてみたいのですが、今の時点でインターネット上のテキストはほぼ全部訓練に使われていると思います。「プリトレーニング用のデータが尽きた」という言説をTwitterなどでよく目にしますが、Nickさんはそれをどう見ていますか？またインターネット上のデータの多くがAIによって生成されるようになってきている今、モデル崩壊のリスクや、AIが生成したデータで訓練することの過学習の問題はどう考えていますか？
Nick： データについては非常に自信を持った発言を目にすることが多くて、「インターネットのデータはこの時点で尽きた、スケーリングは終わった」というものがありますが、私は「実際に皆がどれだけのデータを使っているのか、正確にはよく分からない」という気持ちになります。常に品質と量のトレードオフがありますし、考慮すべき要素もたくさんある。根本的な点として、データは本当に膨大にあります。コンピュートの増加速度の方がデータの増加速度より速いという可能性はありますが、これについては自信を持って言えるわけではありません。
司会： コンピュートとデータのどちらが速く増えているかというのは、言われてみれば自明ではないですね。
Nick： そうなんです。もうひとつ興味深いのは「インターネットはどのくらいの大きさか」という問いです。答えは無限です。スクロールし続ければ自動生成されるページが延々と続くようなサイトがたくさんあります。ではどのくらいが「有用なインターネット」なのかというと、実は誰も知りません。Webページを作るときに「今日のインターネットに50ワード追加した」みたいなカウンターがあるわけではないので、そのあたりの不確実性はかなりあります。
司会： PageRankで閾値を設けて、それ以上のものを有用なインターネットとして定義するのはどうでしょうか？
Nick： それで十分かというと、そうでもないと思います。有用なインターネットというのは人間の視点とモデルの視点でかなり違うと思います。人間が読む価値があるかどうかとPageRankは相関しているかもしれませんが、AIにとって有用なデータかどうかとは必ずしも一致しません。PageRankはリンクベースのシステムですから、リンクされているものが多くなければスコアが低くなる。でも誰もリンクしていないけれどAIにとっては価値があるデータというのはあり得ます。
Nick： むしろある時点ではテールを狙っていくようになるかもしれません。大量にリンクされているものはすでに持っている、そこからは1箇所しかリンクされていないような小さな知識の断片、めったに問われないような難しいクエリの最後の10%に役立つようなデータを探していくということになるかもしれない。
司会： 合成データについてはどう考えていますか？
Nick： いくつかの考え方があります。ひとつは蒸留型のアプローチで、賢いモデルからデータを生成して、そのデータで訓練すれば、そのモデルの知性に近いモデルを作れるという話です。オープンソースモデルでもよく見られます。Qwenのような小さな推論モデルがより大きなQwenモデルから蒸留されていたり、DeepSeekでも同様のことが行われています。これは確かにできます。
では別の問い、つまり今のモデルよりも賢いモデルを作るために今のモデルのデータを使えるかというと、これは面白い問題です。ClaudeにアクセスしてClaudeが生成したテキストをたくさん作っても、理論的にはそれを使ってより良いモデルを訓練できるはずがない。得られるのは同じものだからです。
司会： 理由としては、そのモデルが生成したものへの次トークン予測のロスが非常に低くなるからですよね。
Nick： そうです。モデルがある分布を持っていて、その分布を正確に学習することになる。しかしその分布が間違っていれば、真実を学習することにはなりません。モデルが「5+5は11だ」と信じていれば、「5+5」という文字列に対して毎回11を出力し、新しいモデルもそれを学習してしまいます。これはなかなか面白い研究領域だと思いますが、研究するのが難しい問題でもあります。通常のパラダイムは小スケールで研究して大スケールで実行することですが、「最良のモデルからのデータで訓練するとより良いモデルができる」ということをテストしようとすると、どうやって検証するのかという問題があります。
これとは別に意図せず合成データを使ってしまうという問題もあります。インターネット上のコンテンツの多くがLLMによって生成されるようになっています。これは検出が難しくはないですが自明でもない。LLMが書いたものかどうかは分かりますが自明ではありません。そしてそれがモデルに与える影響も考えにくい。インターネットの1%がLLM生成だとして、それはコンピュートの1%を無駄にするだけなのか、それとも5%や10%になるとモデルが壊れるのか。
司会： 必ずしも悪いことではないかもしれませんよね。LLMプロバイダーがたくさんいて、モデルの分布を真の分布に近づけるという観点で考えると、インターネット上に出回っているものは、「5+5は11だ」というものよりは「5+5は10だ」というものの方がアップサンプルされているはずです。
Nick： そうあってほしいのですが、実際にそれが保証されているわけではありません。インターネット上にはナンセンスなコンテンツを大量に生成しているSEO目的のジャンクサイトもたくさんあります。そしてもちろん極端なケースとして、意図的にモデルを壊そうとする人たちもいます。フィルターを通り抜けてモデルに入り込むように設計された、できるだけ有害なコンテンツを作ろうとする人たちです。
9.2 アーキテクチャの進化・推論との共設計・今後の展望
司会： 今後数年で直面するであろう既知の問題と、まだ輪郭が見えていないような問題について聞かせてください。コンピュートが増えてより大きなネットワークのGPUを繋げる必要が出てくるといったことは当然あると思いますが、それ以外に「これは来る問題だ」と感じているものはありますか？
Nick： 最も気になっているのはパラダイムシフトです。強化学習へのシフトはひとつのパラダイムシフトで、これからも同様のシフトがあるでしょう。「現在のパラダイムでAGIに届くか」という議論をよく聞きますが、私は分かりません、おそらくそうかもしれませんが、何桁も規模が上がる過程で何も新しい気づきが得られないというのは驚くべき展開に思えます。そのなかで実際に最も不安を感じているのは、解決が本当に難しいバグです。単一のバグが何ヶ月も狂わせることがある。モデルの訓練には数ヶ月かかるので、コードのどこかに問題があっても気づかないまま進んでしまうと、1世代分まるごと失うことになります。
司会： 次トークン予測以外のアーキテクチャについて、たとえばLiquid AIのような独自アーキテクチャを持つ会社が出てきていますし、自己回帰的な訓練以外のアプローチもあります。そのあたりをどう見ていますか？
Nick： 面白いとは思います。ただ私は「自己回帰がすべてだ」という立場ではないものの、自己回帰はおそらくAGIに届くのに十分だと思っています。スケールが主な推進力で、基礎的なことを丁寧に積み上げることの方が、全く新しいものを発明するよりも重要だと見ています。新しいものの方が優れているものが確実にあると思いますが、スケーリングの方が簡単で信頼性も高い。そしてスケーリングからはまだ非常に大きな改善が得られています。
司会： 中国のラボなどが出しているオープンソースの論文では、より良いキャッシュ動作や効率的なアテンション関数など、アーキテクチャ自体への細かい改善が行われていますが、それはコンピュートをより多く投入すれば誤差の範囲に収まってしまうものでしょうか、それとも本当に重要なものでしょうか？
Nick： 両方の組み合わせだと思います。細かい改善は積み重なっていくと思いますし、コンピュートを投入すれば投入するほど、そういった実験をやることの見返りが大きくなります。推論という観点からも話しますが、これらのモデルを多くの人に提供するためにはモデルを安く動かす必要があって、推論スタックやチップの詳細に依存した多くの変更が可能です。
司会： プリトレーニングに注力している立場として、推論についてはあまり考えない、ただロスを下げて渡すだけというわけではないのですか？
Nick： いや、推論については相当考えます。プリトレーニングが基本的に推論が解くべき問題を決めているからです。私たちがモデルを渡すと、推論チームはそれを速く動かさなければならない。でも速く動かすのが不可能なモデルを渡すことは非常に簡単にできてしまいます。最も単純な例ではモデルをとにかく巨大にしてしまうことです。それから多くの場所でコミュニケーションを必要とするような設計にすることも推論を難しくします。また複雑にするだけで根本的に難しい理由はないのに、推論チームの人数は限られていて、多くの場所で実装しなければならないというコストが現実としてあります。推論は私が最も密に連携しているチームで、モデルを賢くかつ安くするという設計を共同でやっています。
司会： コンピュートが100倍あったとしたら、やっていることは変わりますか？それともとにかく手に入るコンピュートをすべて使ってロス曲線を下げ続けるということに変わりはないですか？
Nick： コンピュートが無限にある世界というのはあり得ないので、あれば全部使うということになります。ただもし本当に無限のコンピュートがあったとしたら、課題はそのコンピュートをどう活かすかに移ります。チップが何十億個もあったとして、チップが1台壊れたときどうするか、そういう問題を解かなければならない。その時点でのボトルネックはエンジニアリングを解くスピードになります。ただ変化は本当に大きいと思いますし、現時点でのAI研究がどれだけコンピュートに制約されているかを人々は十分に理解していないと思います。今皆さんが使っているClaude Sonnet 4やClaude Opus 4は、そのスケールで訓練した最初の試みです。何事もそうですが、一度やれば次はもっとうまくできます。コンピュートが10倍あれば毎日実行できる、100倍あれば本当に大きな変化になる。そしてそれは実際に来るものでもあります。この分野の面白さのひとつは、1年前には全くコンピュートがなかったと感じていたのに、毎年それが変わっていくことです。
司会： 離散拡散モデルはどうでしょうか？Geminiの拡散モデルの話もありましたし、タンパク質設計の分野でも離散拡散モデルが使われていますが、そこに面白い進展が起きると思いますか？
Nick： 正直なところ、私たちは画像生成をやってきておらず、拡散の主な用途がそこにあったので、私のやることリストにずっと入っているテーマです。チームには理解している人もいるので彼らの方が良い見解を持っているかもしれませんが、私自身は十分に理解できていないので断言はできません。ただ私の頭の中では「大きなパラダイムシフトではないが、かなり大きな変化をもたらすものがある」というカテゴリに入っています。そういった変化のいくつかは機能すると思いますが、それが拡散なのか別のものなのかは分かりません。
司会： スタートアップにとっての機会はどこにあると思いますか？Anthropicが年々モデルを改善していく中で、どこでスタートアップが勝てると思いますか？
Nick： 全体的な読みとしては、モデルが賢くなるほど価値が高まるようなものは何でも有望だと思います。大きなラボは汎用システムを作っていて、多くの異なる用途をカバーしようとしているので、個々の具体的な用途についてはスタートアップが取り組む余地がある。「現行モデルでほぼ動くが少し手を加える必要があるもの」は有望な方向性です。逆に注意が必要なのは、今は大量のスキャフォールドを作り込むことで機能しているが、次世代ではそのスキャフォールドが全部不要になるようなものです。スキャフォールドを構築してビジネスを立ち上げるという観点ではいいのかもしれませんが、後々余分な作業をすることになる気がします。
司会： 逆に、Anthropicの訓練スタックのどこかで「これを解決してくれる会社があったら絶対に買うのに」というものはありますか？
Nick： たくさんあります。特に急成長している会社では何人採用できるかが常にボトルネックで、自分でもできるとしても、他の会社に委託して彼らが管理・採用・組織面を担ってくれるというのは価値があります。真っ先に思い浮かぶのはチップの計算誤りの話です。「すべてのチップが正確に演算しているかを確認して、正確でなければ何の割合でどこが問題なのかを正確に教えてくれる」スタートアップがあれば素晴らしいです。計算が間違っていることは分かっても、チップの低レベルな詳細を十分に理解していないので「この特定のコンポーネントが間違って配線されていた」とか「宇宙線が当たった」とかまでは分からない。もっと深く掘り下げられる可能性は常にあります。
10. クロージング：スタートアップと学生へのアドバイス
10.1 AGI実現後の世界への提言
司会： 最後の質問として、学生の方々へのキャリアアドバイスを聞かせてください。10年前に学生だったNickさんが、経済学からAIへとピボットしていった時代と比べて、今から入ってくる人たちへ向けてどんなことを伝えたいですか？当時やっていたことが今に向けて複利で効いてきたと思いますが、今の学生が10年後にNickさんのような役割に就くためにどんなスキルを身につけるべきでしょうか。
Nick： タイミングが全然違うので難しいですね。10年前に何をすべきかと、今何をすべきかは本当に異なります。ただ10年前に戻れるなら間違いなくAIに集中すると言います。最も重要なことです。そして特にエンジニアリングに集中すると思います。当時の自分には自明ではありませんでした。重要なのは数学やSVMや標準的なML文献の理論的な理解ではなく、エンジニアリングスキルだということは、当時だったら気づかなかっただろうと思います。
今の学生に対しては、エンジニアリングスキルと「AGIが実現した後の世界でどう行動するか」の2点を最も重要なこととして考えます。
司会： スタートアップを作ろうとしている人たちへのアドバイスについても少し付け加えてもらえますか。
Nick： 少し技術的な話ではないかもしれませんが、AGIが実現したとき、つまり人間がやれることほぼ全てを自動化できるようになったとき、そこから生まれる経済成長の規模は本当に膨大です。ですから「技術的にどう成功するか」以上に「これがどうすれば世界のためになるか、そうでない方向にいかないためにどうすべきか」を少し多めに考えてほしいと思っています。経済的な成功はどのみちたくさんあるはずですから、それよりもこの変革がどう世界全体に恩恵をもたらすかを考えることの方が重要だと感じています。
司会： Nickさん、今日はありがとうございました。
Nick： ありがとうございました。