Learn more about Search Results ALiBi - Page 2

BLOOMトレーニングの技術背後

近年、ますます大規模な言語モデルの訓練が一般的になってきました。これらのモデルがさらなる研究のために公開されていない問題は頻繁に議論されますが、そのようなモデルを訓練するための技術やエンジニアリングについての隠された知識は滅多に注目されません。本記事では、1760億パラメータの言語モデルBLOOMを例に、そのようなモデルの訓練の裏側にあるハードウェアとソフトウェアの技術とエンジニアリングについて、いくつかの光を当てることを目指しています。 しかし、まず、この素晴らしい1760億パラメータモデルの訓練を可能にするために貢献してくれた企業や主要な人物やグループに感謝したいと思います。 その後、ハードウェアのセットアップと主要な技術的な構成要素について説明します。 以下はプロジェクトの要約です： 人々 このプロジェクトは、Hugging Faceの共同創設者でありCSOのThomas Wolf氏が考案しました。彼は巨大な企業と競争し、単なる夢だったものを実現し、最終的な結果をすべての人にアクセス可能にすることで、最も多くの人々にとっては夢であったものを実現しました。 この記事では、モデルの訓練のエンジニアリング側に特化しています。BLOOMの背後にある技術の最も重要な部分は、私たちにコーディングと訓練の助けを提供してくれた専門家の人々と企業です。 感謝すべき6つの主要なグループがあります： HuggingFaceのBigScienceチームは、数人の専任の従業員を捧げ、訓練を始めから終わりまで行うための方法を見つけるために、Jean Zayの計算機を超えるすべてのインフラストラクチャを提供しました。 MicrosoftのDeepSpeedチームは、DeepSpeedを開発し、後にMegatron-LMと統合しました。彼らの開発者たちはプロジェクトのニーズに多くの時間を費やし、訓練前後に素晴らしい実践的なアドバイスを提供しました。 NVIDIAのMegatron-LMチームは、Megatron-LMを開発し、私たちの多くの質問に親切に答えてくれ、一流の実践的なアドバイスを提供しました。 ジャン・ゼイのスーパーコンピュータを管理しているIDRIS / GENCIチームは、計算リソースをプロジェクトに寄付し、優れたシステム管理のサポートを提供しました。 PyTorchチームは、このプロジェクトのために基礎となる非常に強力なフレームワークを作成し、訓練の準備中に私たちをサポートし、複数のバグを修正し、PyTorchコンポーネントの使いやすさを向上させました。 BigScience Engineeringワーキンググループのボランティア プロジェクトのエンジニアリング側に貢献してくれたすべての素晴らしい人々を全て挙げることは非常に困難なので、Hugging Face以外のいくつかの主要な人物を挙げます。彼らはこのプロジェクトのエンジニアリングの基盤となりました。 Olatunji Ruwase、Deepak…

最適化ストーリー：ブルーム推論

この記事では、bloomをパワーアップする効率的な推論サーバーの裏側について説明します。 数週間にわたり、レイテンシーを5倍削減し（スループットを50倍に増やしました）、このような速度向上を達成するために私たちが経験した苦労やエピックな勝利を共有したかったです。 さまざまな人々が多くの段階で関与していたため、ここではすべてをカバーすることはできません。また、最新のハードウェア機能やコンテンツが定期的に登場するため、一部の内容は古くなっているか、まったく間違っている可能性があることをご了承ください。 もし、お好みの最適化手法が議論されていなかったり、正しく表現されていなかったりした場合は、お詫び申し上げます。新しいことを試してみたり、間違いを修正するために、ぜひお知らせください。 言うまでもなく、まず大きなモデルが最初にアクセス可能でなければ、それを最適化する理由はありません。これは、多くの異なる人々によってリードされた信じられないほどの取り組みでした。 トレーニング中にGPUを最大限に活用するために、いくつかの解決策が検討され、結果としてMegatron-Deepspeedが最終的なモデルのトレーニングに選ばれました。これは、コードがそのままではtransformersライブラリと互換性がない可能性があることを意味します。 元のトレーニングコードのため、通常行っていることの1つである既存のモデルをtransformersに移植することに取り組みました。目標は、トレーニングコードから関連する部分を抽出し、transformers内に実装することでした。この取り組みには「Younes」が取り組みました。これは、1ヶ月近くかかり、200のコミットが必要でした。 後で戻ってくるいくつかの注意点があります: 小さなモデルbigscience/bigscience-small-testingとbigscience/bloom-560mを用意する必要があります。これは非常に重要です。なぜなら、それらと一緒に作業するとすべてが高速化されるからです。 まず、最後のログがバイトまで完全に同じになることを望むことをあきらめる必要があります。PyTorchのバージョンがカーネルを変更し、微妙な違いを導入する可能性があり、異なるハードウェアでは異なるアーキテクチャのため異なる結果が得られる場合があります（コストの理由から常にA100 GPUで開発したくはないでしょう）。 すべてのモデルにとって、良い厳格なテストスイートを作ることは非常に重要です 私たちが見つけた最高のテストは、固定された一連のプロンプトを持つことでした。プロンプトを知っており、決定論的な結果が得られる必要があります。2つの生成物が同じであれば、小さなログの違いは無視できます。ドリフトが見られるたびに調査する必要があります。それは、あなたのコードがやるべきことをしていないか、または実際にそのモデルがドメイン外であるためにノイズに対してより敏感であるかのいずれかです。いくつかのプロンプトと十分に長いプロンプトがあれば、すべてのプロンプトを誤ってトリガーする可能性は低くなります。プロンプトが多ければ多いほど良く、プロンプトが長ければ長いほど良いです。 最初のモデル（small-testing）は、bloomと同じようにbfloat16であり、すべてが非常に似ているはずですが、それほどトレーニングされていないか、うまく機能しないため、出力が大きく変動します。そのため、これらの生成テストに問題がありました。2番目のモデルはより安定していましたが、bfloat16ではなくfloat16でトレーニングおよび保存されていました。そのため、2つの間にはエラーの余地があります。 完全に公平を期すために言えば、bfloat16→float16への変換は推論モードでは問題なさそうです（bfloat16は主に大きな勾配を扱うために存在しません）。 このステップでは、重要なトレードオフが発見され、実装されました。bloomは分散環境でトレーニングされたため、一部のコードはLinearレイヤー上でテンソル並列処理を行っており、単一のGPU上で同じ操作を実行すると異なる結果が得られていました。これを特定するのにかなりの時間がかかり、100％の準拠を選択した場合、モデルの速度が遅くなりましたが、少しの差がある場合は実行が速く、コードがシンプルになりました。設定可能なフラグを選択しました。 注：この文脈でのパイプライン並列処理（PP）は、各GPUがいくつかのレイヤーを所有し、各GPUがデータの一部を処理してから次のGPUに渡すことを意味します。 これで、動作可能なtransformersのクリーンなバージョンがあり、これに取り組むことができます。 Bloomは352GB（176Bパラメーターのbf16）のモデルであり、それに合わせるために少なくともそれだけのGPU RAMが必要です。一時的に小さなマシンでCPUにオフロードすることを検討しましたが、推論速度が桁違いに遅くなるため、それを取り下げました。 次に、基本的にはパイプラインを使用したかったのです。つまり、ドッグフーディングであり、これがAPIが常に裏で使用しているものです。 ただし、pipelinesは分散意識がありません（それがその目的ではありません）。オプションを簡単に話し合った後、新しく作成されたdevice_map="auto"を使用してモデルのシャーディングを管理するためにaccelerateを使用することにしました。いくつかのバグを修正し、transformersのコードを修正してaccelerateが正しい仕事をするのを助ける必要がありました。 これは、transformersのさまざまなレイヤーを分割し、各GPUにモデルの一部を与えて動作させることで機能します。つまり、GPU0が作業を行い、次にGPU1に引き渡し、それ以降同様に行います。 最終的には、上に小さなHTTPサーバーを置くことで、bloom（大規模なモデル）を提供できるようになりました！…

MPT-30B：モザイクMLは新しいLLMを使用して、NLPの限界を em>GPT-3を凌駕します

MosaicMLのLLMにおける画期的な進歩について、MPTシリーズで学びましょうMPT-30Bおよびその微調整された派生モデル、MPT-30B-InstructとMPT-30B-Chatが他のモデルを凌駕する方法を探索してください

MosaicMLは、彼らのMPT-30BをApache 2.0の下でリリースしました

MosaicML-7Bの大成功の後、MosaicMLは再び以前に設定した基準を上回りました。新しい画期的なリリースでは、MosaicML-30Bを発表しました。 MosaicMLは非常に正確で強力な事前学習済みトランスフォーマーです。MosaicMLは、MosaicML-30BがChatGPT3よりもさらに優れていると主張しています。 MosaicML-30Bの発売前、MosaicML-7BはAI界を席巻しました。MPT-7B Base-instruct、base-chat、およびストーリーライティングは大成功でした。同社は、これらのモデルが世界中で300万回以上ダウンロードされたと主張しています。以前にリリースしたモデルへのコミュニティの熱狂がさらに優れたエンジンを求める最大の理由であり、Mosaic MLはMPT-30Bでそれを実現しました。 コミュニティがこれらのMPTエンジンを適応し、より調整されたものを構築して具体的なユースケースに役立てる姿は信じられないほどでした。興味深いケースの一部はLLaVA-MPTです。LLaVa-MPTは、事前学習済みMPT-7Bにビジョン理解を追加します。 同様に、GGMLはMPTエンジンをApple SiliconとCPUでより良く実行できるように最適化します。GPT4ALLは、MPTを基にしたGPT4のようなチャットオプションを実行できる別のユースケースです。 よく見ると、MosaicMLがより優れており、大企業に対して強力な競争力を持ち、比較的簡単な統合でさまざまなユースケースにモデルを適応させることができるというのは、彼らが提供する競争力のある機能のリストとモデルの適応性のおかげです。 このリリースでは、Mosaic MLはまた、ChatGPTが使用するパラメータのおよそ三分の一のMPT-30Bが、既存の生成ソリューションと比較して非常に軽量なモデルであると主張しています。 MosaicMLの既存のMPT-7Bよりも優れており、このMPT-30Bは商業ライセンスの下で即座に商業利用が可能です。 それだけでなく、MPT-30BにはMPT-30B-InstructとMPT-30B-Chatの2つの事前学習済みモデルも付属しており、1つの単一指示に影響を受けることができ、より長い時間のマルチターン会話を追うことができます。 その優れた点は続きます。MosaicMLはMPT-30Bをボトムアップのアプローチでより良く、より効率的に設計しました。MPT-30Bは8kトークンのコンテキストウィンドウでトレーニングされています。ALiBiを介してより長いコンテキストをサポートしています。 FlashAttentionの助けを借りて、トレーニングと推論のパフォーマンスを改善しました。MPT-30Bは、データの多様性によるより強力なコーディング能力を備えています。このモデルはNvidiaのH100上で8Kコンテキストウィンドウに拡張されました。同社は、これがH100で訓練された最初のLLMモデルであり、お客様にすぐに利用可能であると主張しています。 MosaicMLはまた、モデルを軽量に保ち、新興企業が運用コストを低く抑えるのに役立てています。 MPT-30Bのサイズも、単一のGPU上で簡単に展開できるように特別に選ばれました。1つのA100-80GB（16ビット精度）または1つのA100-40GB（8ビット精度）でシステムを実行できます。Falcon-40Bなどの他の比較可能なLLMは、より大きなパラメータ数を持ち、単一のデータセンターGPUではサービスできません（現在）。これには2つ以上のGPUが必要であり、最小の推論システムコストが増加します。

Find the right Blockchain Investment for you

Web 3.0 is coming, whether buy Coins, NFTs or just Coding, everyone can participate.

Advertising with us