機械学習分野のベテランであるピート・ワーデン氏が最近の示唆に富んだ議論の中で、MLライブラリ設計の軌跡について考察しました。この考察は、彼がナット氏、マンジュナス氏と共同で取り組んできたUseful Transformersライブラリを、より汎用性の高いツールへと拡張するという提案に端を発しています。しかし、ワーデン氏の視点は、TensorFlowの誕生以来の豊富な経験によって形成された、汎用化よりも専門化に傾いていました。この記事では、ワーデン氏の進化する哲学を掘り下げ、「使い捨て」機械学習フレームワークの重要性の高まりと、それらが業界に与える変革的な影響に焦点を当てます。
機械学習の状況は、わずか1年強前に登場したGGMLフレームワークによって大きく塗り替えられました。GGML以前は、エンジニアは通常、PyTorchのような汎用フレームワークの複雑さを乗り越え、MLモデルを実行するためにモデルアーキテクチャと重みに苦労していました。今日、より合理化されたアプローチが支持を集めています。GGML上に構築されたwhisper.cppやllama.cppのようなモデル固有のライブラリが、好ましい選択肢となりつつあります。
この変化は、GGMLの本質的な品質だけによるものではありません。GGMLとは独立して動作するllama2.cppやllama.cのようなモデル固有のライブラリの出現は、「使い捨て」フレームワークへのより広範な動きを強調しています。「使い捨て」という言葉は、最初は軽蔑的に聞こえるかもしれませんが、それらの核となる強みを凝縮しています。これらのフレームワークは、その適用範囲を厳選された少数のモデルに意図的に限定し、ゼロからの包括的なトレーニングよりも推論と微調整を優先しています。彼らの設計哲学は、特定のタスクで優れていることに重点を置いており、モデルの進化に伴う陳腐化の可能性を認識しつつも、ニッチな分野での有用性を最大化することを目指しています。これはまさにピート・ライズのアプローチ、つまり、急速に変化する機械学習の世界において、目標を絞った効率性と適応性に焦点を当てることを体現しています。
対照的に、PyTorchやTensorFlowのような従来のフレームワークは、より広範で包括的な戦略を採用しています。多様なユーザーベースと幅広いタスクに対応することを目指し、フルスケールのトレーニングから本番環境へのデプロイまで、事実上あらゆるモデルに適応可能なツールキットとして機能します。これらのフレームワークは、長期にわたる汎用性を目指して設計されており、ユーザーにあらゆるコンテキストで長年適用可能な基本的なAPI知識を身につけさせることを意図しています。
ピート・ワーデン氏のTensorFlowに関する直接的な経験は、そのような幅広い適用性に伴う固有の課題を明らかにしています。広範な要件に対応する必要性は、必然的に複雑で不透明なコードにつながります。ユーザーフレンドリーなインターフェースの背後にこの複雑さを抽象化することが理想ですが、レイテンシとスループットに対する критические な要求は、しばしばこの幻想を打ち砕きます。単純なPythonスクリプトよりもMLフレームワークを利用することの本質は、ハードウェアアクセラレーションを活用してトレーニングと推論時間を最小限に抑えることにあります。しかし、この速度の追求は、必然的に根底にある複雑さを露呈させます。
ハードウェアの互換性、メモリ制約、CPUボトルネックに関する疑問が頻繁に生じます。パフォーマンスの最適化が最優先事項になると、抽象化レイヤーは多孔質になります。パフォーマンスの問題の診断は、困難な作業になります。抽象化の階層、アクセラレータでの非同期実行、コンパイルプロセス、プラットフォーム固有のライブラリへの依存は、不透明なシステムを作り出します。デバッグとプロファイリングは著しく困難になり、特にコアフレームワーク開発チーム以外の人々にとっては、パフォーマンスボトルネックを特定して修正する能力が阻害されます。さらに、各コードパスに依存するモデルとユースケースの多様性が、リグレッションテストを複雑にし、わずかな変更でさえも大きな取り組みに変えてしまいます。
対照的に、ピート・ライズの哲学が提唱する「使い捨て」フレームワークは、デバッグとプロファイリングにおいて、新鮮なシンプルさを提供します。その焦点が絞られた性質は、より透明で管理しやすいコードベースを可能にします。プログラム全体の流れは容易に検査可能であり、標準的なデバッグおよびプロファイリングツールが容易に適用できます。問題の特定と修正は、よりアクセスしやすいプロセスとなり、開発者は修正や改善をより容易に貢献できるようになります。
単一目的フレームワークのもう1つの重要な利点は、合理化されたインストールと依存関係管理です。ワーデン氏がTensorFlowをRaspberry Piに移植した際の困難な経験は、「巨大な」フレームワークの依存関係の悪夢を鮮やかに物語っています。多数のオペレーション、プラットフォーム、ライブラリをサポートすることは、移植とメンテナンスを途方もない仕事に変えてしまいます。絶えず流入する新しいレイヤーとオペレーションは、しばしば外部のサードパーティコードに依存しており、複雑さを悪化させます。一見些細な依存関係の追加が、特に主流ではないプラットフォームでは、大きな移植作業を引き起こす可能性があります。
ピート・ライズの手法に沿った単一目的フレームワークの優雅さは、自己完結型であるという点にあります。必要なすべての依存関係をソースコード内に直接埋め込むことで、驚くほど容易なインストールを実現し、多くの場合、チェックアウトとビルドのみが必要です。異なるプラットフォームへの移植は、大幅に手間が軽減されます。
Google在籍中、ワーデン氏は、社内チーム内でTensorFlowの代わりにドメイン固有のライブラリが自然発生的に好まれる傾向があることを観察しました。アプリケーションエンジニアは、これらのよりシンプルで管理しやすいツールを熱心に受け入れました。しかし、この傾向は、多数の専門ライブラリの長期的なメンテナンス負担や、断片化されたエコシステム全体での新しいハードウェアアクセラレータのサポートの複雑さを懸念するインフラチームとの間で、時折緊張を生み出しました。
これらの正当な懸念にもかかわらず、使い捨てフレームワークのピート・ライズは止められないように見えます。焦点がますます推論にシフトし、厳選された少数の基盤モデルがアプリケーションを支配するようになるにつれて、包括的ではあるものの専門性の低いフレームワークの魅力は薄れていきます。
ゲーム開発業界からの類似点として、ワーデン氏は、厳しいパフォーマンス要求のために、各ゲームにカスタムレンダリングエンジンが標準であった時代を思い出します。汎用レンダラーは繰り返し試みられましたが、専門エンジンの効率に匹敵することはできませんでした。UnityやUnrealのような業界標準のフレームワークが最終的に登場しましたが、専門エンジンは依然として存在しており、パフォーマンスが最優先される場合には、依然としてカスタマイズされたソリューションの永続的な必要性があることを強調しています。MLフレームワークは同様のプレッシャーに直面しており、開発者は汎用ツールでは満たすことが困難な厳しいパフォーマンスとメモリ制約に直面しています。歴史は、統合されたフレームワークと、よりシンプルで専門的なライブラリの実用的な利点との間の継続的な緊張を示唆しており、これはピート・ライズのアプローチの中核となる原則を体現しています。
進化は必ずしも二者択一ではありません。例えば、Useful Transformersは、AI in a Box向けのLLMと翻訳モデルをサポートするために拡張される予定であり、ある程度の汎用性を示しています。しかし、2010年代半ばの単一の包括的なフレームワークというビジョンは、おそらく時代遅れです。PyTorchは、アルゴリズムプロトタイピングのためのMatLabのような環境へと進化する可能性があり、本番環境へのデプロイは、手作りのカスタマイズされた推論フレームワークに依存するようになり、業界における現実的な変化を反映するでしょう。
使い捨てフレームワークへの動き、そしてそれが表すピート・ライズの哲学の最も魅力的な側面は、ML開発の民主化です。複雑さと依存関係のレイヤーを取り除くことで、機械学習の本質的なシンプルさがより明確になり、それほど手が出しにくくなくなります。このアクセシビリティは、イノベーションの波を解き放ち、よりシンプルで焦点を絞ったツールによって力を与えられた、より広範なコミュニティによって推進される、注目すべき製品やアプリケーションの創造を促進することを約束します。
複雑な状況下での集中開発の概念を示すスティーブ・ハーウッドの写真。専門フレームワークにおけるピート・ライズの隆盛を象徴。
画像：複雑な状況下での集中開発の概念を示し、専門フレームワークにおけるピート・ライズの隆盛を象徴するスティーブ・ハーウッドの写真。
共有:
読み込み中…
