PagedAttentionを用いた大規模言語モデルサービングの効率的なメモリ管理
PagedAttentionとvLLMは、LLMのサービスにおける重要な課題、特に推論にGPUメモリを使用する際の高いコストと非効率性を解決する。
シリーズ全体を読む
- OpenAIのChatGPT
- GPT-4.0と大規模言語モデルの秘密を解き明かす
- 2024年のトップLLM：価値あるもののみ
- 大規模言語モデルと検索
- ファルコン180B大型言語モデル（LLM）の紹介
- OpenAIウィスパー高度なAIで音声をテキストに変換する
- OpenAI CLIPを探る：マルチモーダルAI学習の未来
- プライベートLLMとは？大規模言語モデルをプライベートで実行 - privateGPTとその先へ
- LLM-Eval：LLMの会話を評価するための合理的なアプローチ
- CohereのRerankerを使いこなし、AIのパフォーマンスを向上させる
- PagedAttentionを用いた大規模言語モデルサービングの効率的なメモリ管理
- LoRAの説明LLMを微調整するための低ランク適応
- 知識の蒸留：妥当性を犠牲にすることなく、大規模で計算量の多いLLMから小規模なLLMへ知識を移行する
- RouteLLM: LLM展開におけるコストと品質のトレードオフをナビゲートするオープンソースフレームワーク
- 検証者-検証者ゲームがLLM出力の可読性を向上させる
- 金魚のように、暗記をするな！ジェネレーティブLLMで暗記を軽減する
- LLMにおけるメニーショット・インコンテキスト学習のパワーを解き放つ
- 双眼鏡でLLMを発見：機械生成テキストのゼロショット検出
大規模言語モデル(LLMs)は、様々な分野の数多くの問題を解決できる強力で多用途なAIシステムである。その開発は非常に速いペースで進んでおり、新しいモデルが頻繁にリリースされている。一般的に、新しいLLMは様々なタスクに対処する上でより優れた性能を発揮する。Mistral](https://zilliz.com/blog/optimize-multi-agent-system-with-mistral-large-mistral-nemo-and-llama-agents)、Llama、OPT、Qwenなど、これらのモデルの一部はオープンソース化されており、社内データや商用目的で利用することができます。
しかし、これらのオープンソースLLMを実装する際の大きな課題の一つは、LLMを提供する段階で生じる。LLMのホスティングは、複数のGPUが必要なため、運用コストの面で著しく高価です。したがって、この段階でメモリを効率的に管理するソリューションを実装することが極めて重要です。可能性のある解決策の1つは、PagedAttentionと呼ばれるアルゴリズムの実装です。
LLM 推論の問題点
その核心は、LLMはTransformerデコーダの巨大なスタックで構成されている。ご存知のように、Transformerデコーダベースのアーキテクチャは、テキストを逐次的に生成することで動作する。これは、生成されるテキストが長ければ長いほど、これらのLLMを実行するためにより多くのGPUメモリが必要になることを意味する。
例えば、 GPT-4の価格を見ると、8kのコンテキスト・ウィンドウを持つモデルは、128kのコンテキスト・ウィンドウを持つモデルよりも安価です。この価格差は単に、より多くのテキストを出力するためのコストを反映しているだけです。さらに、モデルのサイズも考慮しなければなりません。下の画像に示すように、NVIDIA A100 で 13B のパラメー タを持つ LLM をホストする場合、GPU メモリの 65%がモデルの重みの格納に、 30%がキー・バリュー（KV）キャッシュ（またはコンテキスト・ウィ ンドウ）に、残りがモデルの活性化に割り当てられます。
図：13Bのパラメータを持つLLMを処理するときのGPUメモリ割り当て](https://assets.zilliz.com/Figure_GPU_memory_allocation_when_serving_an_LLM_with_13_B_parameters_67c69554ab.png)
オープンソースのLLMをホストサービスとして実行するのは非常に高価で、複数のGPUを必要とすることはよく知られています。したがって、スループットを向上させ、リクエストあたりのコストを削減することは非常に重要です。では、どうすればこれを達成できるのでしょうか？GPUのメモリ消費の観点からは、モデルの重みは固定されており、それについてはあまり手を打つことができません。一方、活性化は GPU メモリのごく一部しか占めません。**従って、KVキャッシュ内のメモリ管理を最適化することが、スループット向上の主な焦点となるはずです。
しかし、KVキャッシュを最適化する主な課題は、LLM出力生成の性質にあります。前述したように、Transformer-decoderはテキスト出力を逐次的に生成するため、推論プロセス中にGPUが十分に活用されない可能性があります。
GPUメモリ使用率とスループットの明らかな改善は、バッチ化されたリクエストを実行する能力です。しかし、LLMでバッチ要求を実装することは、2つの理由から困難です：
リクエストは異なる時間に到着する可能性がある。素朴なバッチ化戦略では、先に到着したリクエストを後に到着したリクエストのために待たせるか、先に到着したリクエストが終了するまで到着するリクエストを遅らせることになり、キュー遅延につながります。
以下のShareGPTとAlpacaデータセットのトークン分布に示されるように、 リクエストの入力と出力の長さが異なるかもしれない。簡単な解決策は、各リクエストが同じような長さになるようにパディングを 実装することであるが、これはメモリを浪費する。
図：ShareGPTとAlpacaデータセットの入出力長分布](https://assets.zilliz.com/Figure_Input_output_length_distributions_of_Share_GPT_and_Alpaca_datasets_34636e51a8.png)
これらの問題に対処するために、セルラーバッチングと反復レベルスケジューリングと呼ばれる方法が実装されている。これらの方法は、リクエストレベルではなく、イテレーションレベルで動作する。バッチ全体を待つ代わりに、イテレーションが終わるとすぐに 新しいリクエストを処理することができる。
セルラーバッチングとイテレーションレベルのスケジューリングは、GPUメモリ使用率に関連する問題を解決しますが、バッチで処理できるリクエストの数は、依然としてGPUメモリ容量によって制約されます。幸いなことに、KVキャッシュの動作の性質上、改善の余地が残されています。その実装では、KV キャッシュは GPU メモリを消費する上でユニークな特性を 持っています。すなわち、モデルが新しいトークンを生成するにつれて、動的に増 加したり縮小したりすることができ、その長さは事前にはわかりません。
図：一般的な手法におけるKVキャッシュのメモリ管理](https://assets.zilliz.com/Figure_KV_cache_memory_management_in_common_methods_7dfe1af574.png)
推論にLLMを使う場合、通常、生成されるトークンの最大数を設定する必要があります（1000、2048など）。次にGPUは、この最大長に従って連続したメモリチャンクを割り当てます。ほとんどのシナリオでは、生成されるトークンは最大長よりもはるかに短いため、このアプローチは潜在的にメモリを浪費します。
以下に示すように、プロファイリングの結果、KV キャッシュメモリの 20.4%～38.4%だけが、トークンの格納に実際に使用されています。
図：異なるLLMサービング・システムにおけるメモリ浪費の平均割合](https://assets.zilliz.com/Figure_The_average_percentage_of_memory_wastes_in_different_LLM_serving_systems_70409fe8ff.png)
つ目の改善の可能性は、KVキャッシュのメモリ共有に関するものである。LLMは1つのプロンプトに対して、1回のリクエストで複数のバ ージョンの出力を生成できる。GPUのメモリ消費を最適化するために、KVキャッシュを複数のバージョンの出力間で共有できれば有益です。しかし、リクエストごとの KV キャッシュは別々の連続したスペースに保存されるため、現在のところメモリ共有は不可能です。
これらの問題に対処するために、PagedAttention と呼ばれるメソッドが導入されました。
PagedAttentionとvLLMの仕組み
**PagedAttentionは、連続したキーと値のペアを、連続しないメモリ空間に保存 することを可能にするメソッドである："4スコアと7年前、我々の父祖は_を生んだ。"
図：PagedAttentionアルゴリズムの視覚化](https://assets.zilliz.com/Figure_Paged_Attention_algorithm_visualization_d6a8fb7248.png)
PagedAttentionメソッドは、最初にこのリクエストのKVキャッシュをKVブロックに分割する。各KVブロックは、固定数のトークンのKVベクトルを含む。
上に示したように、PagedAttentionは、プロンプトを物理メモリ内の3つの非連続な KVブロックに分割する。計算中、このメソッドは各KVブロックを個別に識別してフェッチし、前のトークンに対する次の可能性のあるトークンのアテンションを計算する。
このPagedAttentionメソッドは、vLLMと呼ばれるLLMサービングエンジン内に実装されている。
vLLMには、分散GPUワーカーの実行を調整する集中型スケジューラとKVキャッシュマネージャが含まれています。KVキャッシュ・マネージャの主な目標は、ページング方式でKVキャッシュを効率的に管理することです。このマネージャの実装はオペレーティングシステム（OS）にヒントを得ており、OSはメモリを固定サイズのページに分割し、論理ページから物理ページへのユーザープログラムのマッピングを作成します。
この実装の利点は、連続する論理ページが連続しない物理ページに対応できることだ。つまり、従来のKVキャッシュ・システムのように物理メモリを事前に確保する必要がないため、GPU利用におけるメモリの無駄を省くことができる。
各リクエストで論理ページを物理ページにマッピングするために、KVキャッシュ・マネージャーはブロック・テーブルを利用する。ブロック・テーブルには、論理ページと物理ページの両方における各KVブロックの位置と、埋まっている位置と埋まっていない位置の数が記録されています。
リクエストごとの単一サンプルのvLLMデコードワークフロー](https://assets.zilliz.com/v_LLM_decoding_workflow_of_a_single_sample_per_request_4bfb5852ee.png)
PagedAttentionとvLLMによるデコードプロセス
このサブセクションで、PagedAttentionとvLLMが一つのリクエストに対してどの ように働くかを詳しく調べます。
上のビジュアライゼーションにあるように、7つのトークンを含むプロンプト を持つリクエストをするとしよう。この場合、vLLMは最初にプロンプトのKVを格納するために2つの論理ブロックを割り当てる。
テキスト生成処理中、論理ブロック1の最後のスロットはまだ使用可能であるため、vLLMは新しく生成されたトークンをそこに格納する。次に、可視化のステップ2に示すように、ブロックテーブルの#filledレコードが更新される。
2回目の反復で、論理ブロックのすべてのスロットが埋まると、vLLMは新しい論理ブロックを割り当てる。次に、新しいトークンをそこに格納し、新しい物理ブロックを割り 当て(可視化ではブロック3)、このマッピングをブロックテーブルに記録する。リクエストが完了すると、対応するKVブロックは他のリクエストで使用する ために解放できる。
この方法によって、より多くのリクエストを GPU メモリに収めることができ、GPU メモリが無駄にならないようになります。複数の要求がある場合、異なる要求の論理ブロックは、下の可視化図に示され ているように、異なる物理ブロックにマッピングされます。
図：2つの異なるリクエストのvLLMデコードワークフロー](https://assets.zilliz.com/Figure_v_LLM_decoding_workflow_of_two_different_requests_01613e2155.png)
並列サンプリング
vLLMとPagedAttentionは、パラレル・サンプリングのような、他の多くの高度なデコード・シナリオも扱うことができる。
LLM に複数のバージョンの出力を出力させたい場合、vLLM はプロンプト用の 1 つの KV キャッシュを共有して複数の出力を生成できる効率的なソリューションを提供します。主なアイデアは、1つの物理ブロックを複数の論理ブロックにマッピングできることであり、そのためvLLMは参照カウントと呼ばれる変数を導入している。
並列サンプリングのvLLMデコードワークフロー](https://assets.zilliz.com/v_LLM_decoding_workflow_of_parallel_sampling_d36fd17262.png)
参照カウントは、特定の物理ブロックにいくつの論理ブロックがマッピングされているかを表す。LLMにAとBの2つのバージョンの出力を生成させたい場合、特定の物理ブロックの参照カウントは2になる。
テキスト生成フェーズで、サンプルAが論理ブロックの最後のスロットに書き込む必要がある場合、vLLMは対応する物理ブロックの参照カウントをチェックする。参照カウントが1より大きい場合、vLLMはそのブロックのコピーを新しい物理ブロックに作成し、参照カウントを1に減らします。その後、サンプルBがその最後の論理ブロックに書き込む必要がある場合、参照カウントが1になったため、新しいKVキャッシュを元の物理ブロック内に格納できます。
パラレル・サンプリングの概念は、システム・プロンプトを作成するシナリオでも有益である。システム・プロンプトは、LLMに入力として提供する命令とタスクのセットであり、このシステム・プロンプトは数回のリクエストの間変更されない可能性がある。この場合、vLLMはシステム・プロンプトのKVキャッシュを格納する物理ブロックを確保し、上で説明した手順と同様のテキスト生成を複数回実行することができる。
vLLMの並列サンプリング実装では、プロンプトブロックだけでなく、異なるサンプル間で他のブロックを共有することもサポートしている。これは、テキスト生成プロセスにおいて、すべての反復で上位k個の候補を保持したいようなビームサーチシナリオで特に有用である。
スケジューリングと先取り
推論のためにLLMをホストするとき、トラフィック要求がシステムの容量を超える場面に遭遇することがある。このような場合、vLLMはFCFS(first-come-first-served)スケジュー リングを実装し、最も早いリクエストが最初に処理されるようにする。
しかし、このスケジューリングの実装は、潜在的に問題を引き起こす可能性がある。例えば、vLLM が、あるリクエストの新しく作成された KV キャッシュを格納する GPU の物理ブロックを使い果たすという状況に遭遇するかもしれません。この場合の解決策は、物理ブロックをいくつか破棄してスペースを空け ることです。これを達成するために、vLLMは、シーケンスに属するすべての物理ブロックを一度に破棄する方法を実装しています。
この方法には重要な疑問がある：廃棄されたブロックが将来必要になったらどうするのか？vLLMはこの問題に対処するために2つのアプローチを実装している：
1.スワッピング：vLLMのアーキテクチャにはCPUアロケータが含まれています。ブロックがGPUメモリから破棄されると、vLLMは将来使用するためにブロックをこのCPUメモリにコピーします。
2.再計算：必要に応じて、vLLMは要求されたシーケンスのKVキャッシュを単純に再計算することができます。
vLLMシステム概要](https://assets.zilliz.com/v_LLM_system_overview_25e30c4437.png)
ベンチマークデータセットにおけるvLLMの性能
他のLLM提供手法に対するvLLMの性能を評価するために、異なるLLMとデータセットを用いていくつかのテストを行った。
テストでは2種類のLLMが使用された：13B、66B、175Bのパラメータを持つOPTモデルと、13Bのパラメータを持つLLAMAである。使用したデータセットは、ChatGPTでユーザが共有した会話を含むShareGPTデータセットと、GPT-3.5-instructで生成されたデータを含むAlpacaデータセットである。
この論文でvLLMと比較された手法は、FasterTransformerと自己実装のOrcaであり、セットアップが異なる：
1.Orca（Oracle）：システムはリクエストで生成されたトークンの数を知っていると仮定する。
2.オルカ(Pow2): システムが、実際に生成されたトークンの最大2倍のスペースメモリーを過剰に予約していると仮定する。
3.オルカ（Max）：システムが、あらかじめ定義された生成トークンの最大長（たとえば2048トークン）だけスペース・メモリを確保すると仮定する。
OPT 175B モデルを使用した基本的なサンプリング（つまり、リクエストごとに 1 サンプルを出力）では、ShareGPT データセットで vLLM は Orca (Oracle) よりも 1.7 倍～2.7 倍、Orca (Max) よりも 2.7 倍～8 倍高いスループットを維持できることが以下の可視化で示されています。同じデータセットにおいて、vLLMはFasterTransformerよりもはるかに優れており、22倍のスループットを維持しています。
図：ShareGPTおよびAlpacaデータセットにおけるOPTモデルによる単一サンプル生成](https://assets.zilliz.com/Figure_Single_sample_generation_with_OPT_models_on_the_Share_GPT_and_Alpaca_dataset_3d9cddf998.png)
Alpacaデータセットでも同様の現象が起こる。しかし、このデータセットでvLLMを使用する利点は、ShareGPTデータセットほど明らかではありません。OPT175BモデルはKVキャッシュを格納するために大きなGPUメモリを必要とするが、このデータセットの平均シーケンス長はShareGPTよりもはるかに短いからである。
並列サンプリングとビームサーチの場合、サンプリングに必要なシーケンスが増えるほど、vLLMの方が大きな性能向上効果が得られます。例えば、AlpacaデータセットでvLLMを使用した場合の改善効果は、下の可視化に示すように、基本サンプリングで1.3倍からビームサーチ（幅6）で2.3倍に増加します：
図：AlpacaデータセットにおけるOPTモデルによる並列生成とビーム探索](https://assets.zilliz.com/Figure_Parallel_generation_and_beam_search_with_OPT_model_on_the_Alpaca_dataset_1eb2f24722.png)
vLLMは、並列サンプリングとビーム探索におけるGPUメモリの節約という点で、他の手法よりも優れた性能を示しました。その結果、並列サンプリングでは6.1%～9.8%、ビーム探索では最大55.2%のメモリ節約になりました。
図：AlpacaデータセットにおけるOPT 13BによるKVブロック共有の平均メモリ節約](https://assets.zilliz.com/Figure_Average_memory_saving_from_sharing_KV_blocks_with_OPT_13_B_on_the_Alpaca_dataset_2f718293c0.png)
vLLMを実装する際に微調整できるパラメータがある：ブロックサイズであり、ブロックサイズに適切な値を選択することが重要である。ブロックサイズが小さすぎると、vLLMはGPUの並列性を十分に活用できないかもしれません。一方、大きすぎると内部の断片化が増えます。ShareGPTデータセットとAlpacaデータセットの観察から、vLLMの強力な性能を十分に活用するためには、ブロックサイズ16が良い目安になると結論づけることができます。したがって、vLLMのデフォルトのブロックサイズは16に設定されている。
vLLM の実装
このセクションでは、vLLMを使った簡単なユースケースを簡単に実装する。具体的には、入力プロンプトに基づいてオフライン推論を実行する。vLLMを使い始める最も簡単な方法は、pip installでインストールすることである。
pip install vllm
必要なライブラリをインストールし、入力プロンプトのリストを定義する：
from vllm import LLM, SamplingParams
prompts = "こんにちは、私の名前は"
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
上記の SamplingParams クラスの内部では、LLMの温度、top p、top k、出力配列の数など、テキスト出力を生成するために使用するサンプリングパラメータを定義することができる。このクラス内で変更できるパラメータの完全なリストは このドキュメントで見ることができます。
次に、LLMを初期化し、与えられたプロンプトで出力を生成しましょう。ここでは1.5Bのパラメータを持つMicrosoft Phiモデルを実装します。vLLMがサポートしているモデルのリストは このドキュメントで確認できます。
llm = LLM(model="facebook/opt-125m")
outputs = llm.generate(prompts, sampling_params)
# 出力を印刷する
prompt = output.prompt
generated_text = output.outputs[0].text
print(f "Prompt: {prompt!r}, Generated text: {generated_text!r}")
vLLM と Milvus の統合
vLLMの基本的な実装がわかったところで、vLLMとMilvusを使って簡単なRAG(Retrieval Augmented Generation)を構築してみましょう。Milvusはベクトルデータベースで、数百万のベクトルを保存し、数秒でベクトル検索を実行することができます。
Milvusを使い始める最も簡単な方法は、Milvus Liteをインストールすることです：
pip install -U pymilvus
pymilvus[model] をインストールします。
では、コレクションを作成し、そこにデータを挿入してみよう。以下の例では、まずテキストデータをベクトル埋め込みに変換することで、3つのテキストデータをMilvusデータベースに挿入します。次に、ベクトル埋め込みデータを件名や原文などのメタデータと一緒にMilvusに格納します。
from pymilvus import MilvusClient
from pymilvus import モデル
クライアント = MilvusClient("milvus_demo.db")
# コレクションを作成する
if client.has_collection(collection_name="rag_vllm")：
client.drop_collection(collection_name="rag_vllm")
client.create_collection(
コレクション名="rag_vllm"、
dimension=768, # このデモで使用するベクトルは768次元です。
)
# 埋め込みモデルの定義
embedding_fn = model.DefaultEmbeddingFunction()
# 検索元のテキストデータ
docs = [
"人工知能は1956年に学問分野として創設された"、
「アラン・チューリングは人工知能の実質的な研究を行った最初の人物である、
「チューリングはロンドンのマイダベールで生まれ、イングランド南部で育った、
]
# テキストデータをエンベッディングに変換する
vectors = embedding_fn.encode_documents(docs)
データ = [
{"id": i, "vector": vectors[i], "text": docs[i], "subject"："履歴"}。
for i in range(len(vectors))
]
# 埋め込みをMilvusに挿入する。
res = client.insert(コレクション名="rag_vllm", データ=data)
この段階で、我々はMilvusの中にデータを持っています。次に、クエリに従ってMilvusデータベース内の最も関連性の高いデータを取得します。
例えば、"アラン・チューリングの業績は？"のような質問があるとすると、ベクトル検索を実行することで最も関連性の高いテキストを得ることができる。しかし、その前に、データベース内のテキストを変換するのに使ったのと同じ埋め込みモデルを使って、クエリを埋め込みに変換する必要があります。
SAMPLE_QUESTION = "アラン・チューリングの業績は？"
query_vectors = embedding_fn.encode_queries([SAMPLE_QUESTION])
res = client.search(
コレクション名="demo_collection"、
data=query_vectors、
limit=1、
output_fields=["text"]、
)
コンテキスト = res[0][0]["entity"]["text"] )
これで、クエリに従って最も関連性の高いデータが得られた。RAGアプリケーションでは、LLMがクエリに対する文脈化された回答を生成するために使用するコンテキストとして、最も関連性の高いデータを使用する。LLMに関連するコンテキストを提供することで、LLMによる幻覚のリスクを減らすことができる。
それでは、LLMに送る完全なプロンプトを作成しよう。RAGアプリケーションでは、プロンプトは高レベルのタスクや命令、元のクエリ、そして上で実装したベクトル検索から取得したコンテキストの組み合わせで構成される。
SYSTEM_PROMPT = f"""提供されたコンテキストを使用して質問に答えてください。
明確、簡潔、適切であること。
コンテキスト{コンテキスト}。
ユーザーの質問{sample_question}
"""
プロンプト = [SYSTEM_PROMPT］
そして最後に、前節の実装でも使用したMicrosoft Phi 1.5BモデルでRAGを実行することができる。
from vllm import LLM, SamplingParams
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
llm = LLM(model="microsoft/phi-1_5")
outputs = llm.generate(prompts, sampling_params)
# 出力を印刷する
prompt = output.prompt
generated_text = output.outputs[0].text
print(f "Prompt: {prompt!r}, Generated text: {generated_text!r}")
"""
出力：
質問"アラン・チューリングの功績は？"
生成されたテキスト"答えアラン・チューリングのAIにおける功績は、その概念を発展させた先駆的な仕事である"
"""
これで完了だ！これで、Milvus、vLLM、Microsoft Phiを使った簡単なRAGが成功しました。MilvusとvLLMの統合についてもっと詳しく知りたい方は、ドキュメントページをご覧ください。
まとめ
今回は、PagedAttentionとvLLMについて紹介した論文について解説しました。PagedAttentionとvLLMは、LLMのサービスにおける重要な課題、特に推論にGPUメモリを使用する際の高いコストと非効率性を解決します。PagedAttentionはKVキャッシュを非連続メモリブロックに格納することでGPUメモリ消費を最適化し、vLLMは高度なメモリ管理技術でこの方法を実装しています。
ベンチマーク・テストでは、FasterTransformerやOrca実装のような代替と比較して、vLLMの優れた性能が実証されています。vLLMを使用する利点は、並列サンプリングやビーム探索のシナリオなど、より多くのシーケンスを生成する必要がある場合に、より明らかになります。
その他のリソース
PagedAttentionに関する2023年のvLLM論文](https://arxiv.org/pdf/2309.06180)
vLLM GitHubリポジトリ](https://github.com/vllm-project/vllm%20and%20model%20page)
Milvus、vLLM、Llama 3.1によるRAGの構築](https://zilliz.com/blog/building-rag-milvus-vllm-llama-3-1)
Zilliz Cloud + vLLM: 高性能RAGシステム](https://zilliz.com/product/integrations/vllm)
Milvus、vLLM、Llama 3.1によるRAGの構築｜Milvusドキュメント](https://milvus.io/docs/milvus_rag_with_vllm.md)
Ray Summitでの2023 vLLMプレゼンテーション](https://www.youtube.com/watch?v=80bIUggRJf4)
vLLM blog: vLLM: PagedAttentionによる簡単、高速、安価なLLMサービング](https://blog.vllm.ai/2023/06/20/vllm.html)
RAGとは](https://zilliz.com/learn/Retrieval-Augmented-Generation)
ベクター・データベースとは何ですか？
読み続けて
ファルコン180B大型言語モデル（LLM）の紹介
Falcon 180Bは、3.5兆のトークンで学習された180Bのパラメータを持つオープンソースの大規模言語モデル（LLM）です。 このブログでそのアーキテクチャと利点を学んでください。
プライベートLLMとは？大規模言語モデルをプライベートで実行 - privateGPTとその先へ
プライベートLLMは、組織のポリシーやプライバシーのニーズに合わせてカスタマイズすることで、データ管理を強化し、法令遵守を保証し、データ漏洩などのリスクを最小限に抑えます。セキュアな環境で運用することにより、第三者からのアクセスを減らし、機密データを不正な暴露から保護します。プライベートLLMは、組織の既存のシステム、ネットワーク、データベースとシームレスに統合できるように設計することができる。組織は、機密情報を保護するために、プライベートLLMに独自のセキュリティ対策を導入することができます。
CohereのRerankerを使いこなし、AIのパフォーマンスを向上させる
Cohere の rerank エンドポイントは、検索および推薦システムを強化するためのシンプルかつ強力なソリューションを提供します。その方法をご覧ください！