330 億もの大規模なパラメータ モデルを単一のコンシューマ グレード GPU に「投入」し、パフォーマンスを犠牲にすることなく 15% 高速化
特定のタスクにおける事前トレーニングされた大規模言語モデル (LLM) のパフォーマンスは向上し続けています。その後、プロンプトの指示が適切であれば、より多くのタスクに汎用化することができます。多くの人がこの現象が原因であると考えられています。ただし、最近の傾向では、研究者はより小規模なモデルに注目しているものの、これらのモデルはより多くのデータでトレーニングされるため、推論が容易になります。
たとえば、パラメーター サイズ 7B の LLaMA は 1T トークンでトレーニングされました。平均パフォーマンスは GPT-3 よりわずかに低いものの、パラメーター サイズは GPT-3 の 1/25 です。 。それだけでなく、現在の圧縮テクノロジはこれらのモデルをさらに圧縮することができ、パフォーマンスを維持しながらメモリ要件を大幅に削減できます。このような改善により、優れたパフォーマンスのモデルをラップトップなどのエンドユーザー デバイスに展開できるようになります。
ただし、これは別の課題に直面しています。それは、生成品質を考慮しながら、これらのモデルをデバイスに適合するのに十分小さなサイズに圧縮する方法です。調査によると、圧縮モデルは許容可能な精度で応答を生成しますが、既存の 3 ~ 4 ビット量子化技術では依然として精度が低下します。 LLM の生成は順番に実行され、以前に生成されたトークンに依存するため、小さな相対エラーが蓄積し、深刻な出力の破損につながります。信頼性の高い品質を確保するには、16 ビット モデルと比較して予測パフォーマンスを低下させない、低ビット幅の量子化方法を設計することが重要です。
ただし、各パラメータを 3 ~ 4 ビットに量子化すると、多くの場合、中程度または高精度の損失が発生します。特に、エッジ展開に適した 1 ~ 10B の精度は、パラメータ範囲内のより小さいモデルに適しています。
精度の問題を解決するために、ワシントン大学、チューリッヒ工科大学、その他の機関の研究者は、新しい圧縮形式と量子化技術 SpQR (Sparse-Quantized Representation、スパース - 定量化) を提案しました。表現)、以前の方法と同様の圧縮レベルを達成しながら、モデル スケール全体での LLM のほぼ可逆圧縮を初めて達成しました。
SpQR は、特に大きな量子化エラーを引き起こす異常な重みを特定して分離し、他のすべての重みを圧縮しながら、それらをより高精度で保存することによって機能します。 LLaMA および Falcon LLM では精度の低下が発生します。これにより、33B パラメータの LLM を 15% 高速化しながら、パフォーマンスを低下させることなく単一の 24GB コンシューマ GPU で実行できるようになります。
SpQR アルゴリズムは効率的で、重みを他の形式にエンコードしたり、実行時に効率的にデコードしたりできます。具体的には、この研究は、4 倍を超えるメモリ圧縮ゲインを達成しながら、16 ビットのベースライン モデルよりも高速に推論を実行できる効率的な GPU 推論アルゴリズムを SpQR に提供します。
- #論文アドレス: https://arxiv.org/pdf/2306.03078.pdf
- #プロジェクトアドレス: https://github.com/Vahe1994/SpQR メソッド
具体的には、この研究ではプロセス全体を 2 つのステップに分割しました。最初のステップは外れ値の検出です。この研究では、まず外れ値の重みを分離し、その量子化が高い誤差につながることを実証しています。外れ値の重みは高精度で維持されますが、他の重みは低精度で (たとえば 3 ビット形式で) 保存されます。次に、この研究では、非常に小さなグループ サイズでグループ化された量子化の変形を実装し、量子化スケール自体を 3 ビット表現に量子化できることを示しました。
SpQR は、精度を犠牲にすることなく LLM のメモリ フットプリントを大幅に削減し、16 ビット推論と比較して LLM を 20% ~ 30% 高速に生成します。
さらに、この研究では、重み行列内の敏感な重みの位置がランダムではなく、特定の構造を持っていることがわかりました。定量化中にその構造を強調するために、研究では各重量の感度を計算し、LLaMA-65B モデルのこれらの重量感度を視覚化しました。以下の図 2 は、LLaMA-65B の最後のセルフ アテンション層の出力投影を示しています。
この研究では、定量化プロセスに 2 つの変更を加えました: 1 つは小さな敏感な重みグループをキャプチャするため、もう 1 つは個々の外れ値をキャプチャするために使用されます。以下の図 3 は、SpQR の全体的なアーキテクチャを示しています:
次の表は、SpQR 定量化アルゴリズムを示しています。左側はプロセス全体を説明し、右側のコード スニペットには二次定量化と外れ値の検出のためのサブルーチンが含まれています:
この研究では、SpQR を他の 2 つの量子化スキーム、GPTQ、RTN (最近似への丸め) と比較し、2 つのメトリクスを使用して量子化モデルのパフォーマンスを評価します。 1 つ目は、WikiText2、Penn Treebank、C4 などのデータセットを使用したパープレキシティの測定で、2 つ目は、WinoGrande、PiQA、HellaSwag、ARC-easy、ARC-challenge の 5 つのタスクにおけるゼロサンプル精度です。
主な結果。図 1 の結果は、同様のモデル サイズで、特に小規模なモデルで、SpQR が GPTQ (および対応する RTN) よりも大幅に優れたパフォーマンスを発揮することを示しています。この改善は、SpQR が損失の劣化を軽減しながら、より多くの圧縮を達成したことによるものです。
#表 1、表 2 結果は、4 ビット量子化の場合、16 ビット ベースラインに対する SpQR の誤差が半分になることを示しています。 GPTQに。
以上が330 億もの大規模なパラメータ モデルを単一のコンシューマ グレード GPU に「投入」し、パフォーマンスを犠牲にすることなく 15% 高速化の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









従来のコンピューティングを超える能力を備えているだけでなく、より低コストでより効率的なパフォーマンスを実現する人工知能モデルを想像してみてください。これは SF ではありません。世界で最も強力なオープンソース MoE モデルである DeepSeek-V2[1] が登場しました。 DeepSeek-V2 は、経済的なトレーニングと効率的な推論の特徴を備えた強力な専門家混合 (MoE) 言語モデルです。これは 236B のパラメータで構成されており、そのうち 21B は各マーカーをアクティブにするために使用されます。 DeepSeek67B と比較して、DeepSeek-V2 はパフォーマンスが優れていると同時に、トレーニング コストを 42.5% 節約し、KV キャッシュを 93.3% 削減し、最大生成スループットを 5.76 倍に高めます。 DeepSeek は一般的な人工知能を研究する会社です

今月初め、MIT やその他の機関の研究者らは、MLP に代わる非常に有望な代替案である KAN を提案しました。 KAN は、精度と解釈可能性の点で MLP よりも優れています。また、非常に少数のパラメーターを使用して、多数のパラメーターを使用して実行する MLP よりも優れたパフォーマンスを発揮できます。たとえば、著者らは、KAN を使用して、より小規模なネットワークと高度な自動化で DeepMind の結果を再現したと述べています。具体的には、DeepMind の MLP には約 300,000 個のパラメーターがありますが、KAN には約 200 個のパラメーターしかありません。 KAN は、MLP が普遍近似定理に基づいているのに対し、KAN はコルモゴロフ-アーノルド表現定理に基づいているのと同様に、強力な数学的基礎を持っています。以下の図に示すように、KAN は

テスラのロボット「オプティマス」の最新映像が公開され、すでに工場内で稼働可能となっている。通常の速度では、バッテリー(テスラの4680バッテリー)を次のように分類します:公式は、20倍の速度でどのように見えるかも公開しました - 小さな「ワークステーション」上で、ピッキング、ピッキング、ピッキング:今回は、それがリリースされたハイライトの1つビデオの内容は、オプティマスが工場内でこの作業を完全に自律的に行い、プロセス全体を通じて人間の介入なしに完了するというものです。そして、オプティマスの観点から見ると、自動エラー修正に重点を置いて、曲がったバッテリーを拾い上げたり配置したりすることもできます。オプティマスのハンドについては、NVIDIA の科学者ジム ファン氏が高く評価しました。オプティマスのハンドは、世界の 5 本指ロボットの 1 つです。最も器用。その手は触覚だけではありません

大規模言語モデル (LLM) を人間の価値観や意図に合わせるには、人間のフィードバックを学習して、それが有用で、正直で、無害であることを確認することが重要です。 LLM を調整するという点では、ヒューマン フィードバックに基づく強化学習 (RLHF) が効果的な方法です。 RLHF 法の結果は優れていますが、最適化にはいくつかの課題があります。これには、報酬モデルをトレーニングし、その報酬を最大化するためにポリシー モデルを最適化することが含まれます。最近、一部の研究者はより単純なオフライン アルゴリズムを研究しており、その 1 つが直接優先最適化 (DPO) です。 DPO は、RLHF の報酬関数をパラメータ化することで、選好データに基づいてポリシー モデルを直接学習するため、明示的な報酬モデルの必要性がなくなります。この方法は簡単で安定しています

ソフトウェア テクノロジの最前線に立つ UIUC Zhang Lingming のグループは、BigCode 組織の研究者とともに、最近 StarCoder2-15B-Instruct 大規模コード モデルを発表しました。この革新的な成果により、コード生成タスクにおいて大きな進歩が達成され、CodeLlama-70B-Instruct を上回り、コード生成パフォーマンス リストのトップに到達しました。 StarCoder2-15B-Instruct のユニークな特徴は、その純粋な自己調整戦略であり、トレーニング プロセス全体がオープンで透過的で、完全に自律的で制御可能です。このモデルは、高価な手動アノテーションに頼ることなく、StarCoder-15B 基本モデルの微調整に応じて、StarCoder2-15B を介して数千の命令を生成します。

上記と著者の個人的な理解: この論文は、自動運転アプリケーションにおける現在のマルチモーダル大規模言語モデル (MLLM) の主要な課題、つまり MLLM を 2D 理解から 3D 空間に拡張する問題の解決に特化しています。自動運転車 (AV) は 3D 環境について正確な決定を下す必要があるため、この拡張は特に重要です。 3D 空間の理解は、情報に基づいて意思決定を行い、将来の状態を予測し、環境と安全に対話する車両の能力に直接影響を与えるため、AV にとって重要です。現在のマルチモーダル大規模言語モデル (LLaVA-1.5 など) は、ビジュアル エンコーダーの解像度制限や LLM シーケンス長の制限により、低解像度の画像入力しか処理できないことがよくあります。ただし、自動運転アプリケーションには次の要件が必要です。

さまざまな Java フレームワークのパフォーマンス比較: REST API リクエスト処理: Vert.x が最高で、リクエスト レートは SpringBoot の 2 倍、Dropwizard の 3 倍です。データベース クエリ: SpringBoot の HibernateORM は Vert.x や Dropwizard の ORM よりも優れています。キャッシュ操作: Vert.x の Hazelcast クライアントは、SpringBoot や Dropwizard のキャッシュ メカニズムよりも優れています。適切なフレームワーク: アプリケーションの要件に応じて選択します。Vert.x は高パフォーマンスの Web サービスに適しており、SpringBoot はデータ集約型のアプリケーションに適しており、Dropwizard はマイクロサービス アーキテクチャに適しています。

1. はじめに ここ数年、YOLO は、計算コストと検出パフォーマンスの効果的なバランスにより、リアルタイム物体検出の分野で主流のパラダイムとなっています。研究者たちは、YOLO のアーキテクチャ設計、最適化目標、データ拡張戦略などを調査し、大きな進歩を遂げました。同時に、後処理に非最大抑制 (NMS) に依存すると、YOLO のエンドツーエンドの展開が妨げられ、推論レイテンシに悪影響を及ぼします。 YOLO では、さまざまなコンポーネントの設計に包括的かつ徹底的な検査が欠けており、その結果、大幅な計算冗長性が生じ、モデルの機能が制限されます。効率は最適ではありませんが、パフォーマンス向上の可能性は比較的大きくなります。この作業の目標は、後処理とモデル アーキテクチャの両方から YOLO のパフォーマンス効率の境界をさらに改善することです。この目的を達成するために
