ChatStream

ChatStream🄬でLlama-3-Elyza-JP-8B を動かす

Qualiteg プロダクト開発部

2024年6月27日 — 3 min read

こんにちは、本日は Llama-3-Elyza-JP-8B を使ってみました。

昨日 2024年6月26日に発表(https://prtimes.jp/main/html/rd/p/000000046.000047565.html)された Llama-3-Elyza-JP-8B は 70B 版では「GPT-4」を上回る性能の日本語LLMといわれています。

今回、当社でも Playground 環境に Llama-3-Elyza-JP-8B を搭載して試してみましたのでご紹介します。

70B(700億パラメータ)版は GPT-4 を上回るとのことですので、8B(80億パラメータ）版はGPT-3.5 と比較してみることにいたしました。

（性能比較は https://note.com/elyza/n/n360b6084fdbd の記事に詳しく書いてあります。）

AWQ量子化版を使用してみる

今回は、A4000 というスモールGPUで推論サーバーを構築するため、AWQ により 4bit 量子化バージョンの https://huggingface.co/elyza/Llama-3-ELYZA-JP-8B-AWQ を使用いたしました。

もとが 8B(80億) パラメータ相当ですので、 4bit 量子化すると、モデルサイズは 2B(20億)パラメータ相当となります。

AWQ量子化版は、推論エンジンとして vLLM での動作が想定されていますので、今回は、 ChatStream の推論エンジンとして vLLM 0.4.2 を選択して推論環境を構築いたしました。

ChatStream.net (playground)デプロイする

ChatStream SDK を使って Llama-3-Elyza-JP-8B 用の A4000 GPU のサーバーノードを1つ作りました。

作業時間は15分程度です。

このサーバーノードを Playground である ChatStream.net のフロントサーバーに登録すれば出来上がりです。

疎通試験も含めてトータル30分程度で使えるようになりました。

このように、激早で構築することができます。

LLM負荷ツールで計測したところ同時20リクエスト/sまではパフォーマンス低下ほぼ無い安定したスループットを達成しています。

おそらく60リクエスト/s 程度までは問題ないレベルだと思われます。

それを超えるリクエストが想定される場合は、 ChatStream のモデル並列化機能を使って簡単に分散させることも可能です。

体験デモ

「Llama-3-Elyza-JP-8B」 vs 「GPT-3.5 」

以下URLで、実際に Llama-3-Elyza-JP-8B を体験することができます。

ChatStreamのマルチタスク機能を使って比較用に GPT-3.5 も表示しています。

（マルチタスク機能と入力Syncを使うことで、複数のLLMに同時に質問を投げかけることができます）

https://chatstream.net/?ws_name=chat_app&mult=1&ontp=1&isync=1&model_id=llama_3_elyza_jp_8b&model_id=openai_gpt_3_5_175b

「Llama-3-Elyza-JP-8B」 vs 「RakutenAI-7B-chat」 vs 「GPT-3.5」で三つ巴で比較

さらにクエリにmodel_id を追加することで、 RakutenAI-7B-chat も入れて三つ巴で比較するには以下のようにします。

https://chatstream.net/?ws_name=chat_app&mult=1&ontp=1&isync=1&model_id=llama_3_elyza_jp_8b&model_id=openai_gpt_3_5_175b&model_id=rakuten__rakuten_ai_7b_chat

構成

今回作った Llama-3-Elyza-JP-8B 用の構成は以下のようになります。

ChatStream SDK は、サーバー側はDocker 化されているため、
コンテナを動作させるGPUサーバーさえ準備できれば、モデルの準備から公開までトータル30分程度です。モデル並列などスケールアウトも数分～数十分程度で可能ですので、最新のモデルをすぐにお客様に届けることが可能です。

動画

一連の内容を動画にまとめました。

まとめ

最後までお読みいただき、誠にありがとうございます。私たちQualitegは、LLMをはじめとするAI技術、開発キット・SDKの提供、LLMサービス構築、AI新規事業の企画方法に関する研修およびコンサルティングを提供しております。

今回ご紹介したChatStream🄬 SDK を使うと、最新のオープンソースLLMや、最新の商用LLMをつかったチャットボットをはじめとした本格的商用LLMサービスを超短納期で構築することが可能です。

もしご興味をお持ちいただけた場合、また具体的なご要望がございましたら、どうぞお気軽にこちらのお問い合わせフォームまでご連絡くださいませ。

Contact

LLMスポットコンサルご好評です

また、LLMサービス開発、市場環境、GPUテクノロジーなどビジネス面・技術面について1時間からカジュアルに利用できるスポットコンサルも実施しておりますのでご活用くださいませ。

（繁忙期、ご相談内容によっては、お受けできない場合がございますので、あらかじめご了承ください）

LLM推論基盤プロビジョニング講座　第5回 GPUノード構成から負荷試験までの実践プロセス

こんにちは！これまでのLLM推論基盤プロビジョニング講座では、推論速度の定義、リクエスト数見積もり、メモリ消費量計算、推論エンジン選定について詳しく解説してきました。今回は、残りのステップである「GPUノード構成見積もり」「負荷試験」「トレードオフ検討」について一気に解説し、最後に実際のサーバー構成例をご紹介します。 STEP5：GPUノード構成見積もり GPUメモリから考える同時リクエスト処理能力 LLMサービスを構築する際、どのGPUを何台選ぶかは非常に重要な決断です。今回はLlama 8Bモデルを例に、GPUメモリ容量と同時リクエスト処理能力の関係を見ていきましょう。 GPUメモリの使われ方を理解するここは復習となりますが、 LLM推論においてGPUメモリは主に2つの用途で消費されます 1. モデル重みデータ: LLMモデル自体を格納するためのメモリ 2. KVキャッシュ: ユーザーとの対話コンテキストを保持するための一時メモリ Llama 8Bを16ビット精度で実行する場合、モデル重みデータは約16GBのメモリを占めます。これは固定的なメモリ消

発話音声からリアルなリップシンクを生成する技術第2回：AIを使ったドリフト補正

こんにちは！前回の記事では、当社のMotionVoxで使用している「リップシンク」技術について、wav2vecを用いた音声特徴量抽出の仕組みを解説しました。音声から正確な口の動きを予測するための基礎技術について理解いただけたかと思います。今回は、その続編として、リップシンク制作における重要な技術的課題である「累積ドリフト」に焦点を当てます。wav2vecで高精度な音素認識ができても、実際の動画制作では複数の音声セグメントを時系列に配置する際、わずかなタイミング誤差が蓄積して最終的に大きなずれとなる現象が発生します。本記事では、この累積ドリフトのメカニズムと、機械学習を活用した最新の補正技術について、実際の測定データを交えながら詳しく解説していきます。前回のwav2vecによる特徴抽出と今回のドリフト補正技術を組み合わせることで、MotionVoxがどのように高品質なリップシンクを実現しているのか、その全体像が見えてくるはずです。累積ドリフトとは何か基本概念累積ドリフトとは、個々の音声セグメントが持つ微小なタイミング誤差が、時間の経過とともに蓄積していく現象で

AIエージェント時代の新たな番人「ガーディアンエージェント」とは？

こんにちは！今日は先日ガートナーが発表したガーディアンエージェントについて解説しますガートナーの公式定義ハイプカーブで有名なガートナーは2025年6月に、ガーディアンエージェントに関する見解を発表しました。ガーディアン・エージェントとは、AIとの安全で信頼できるやりとりを支援するために設計されたAIベースのテクノロジです。ざっくりいうと、「AIエージェントが来るよ」と予言したガートナー社は、次は、「ガーディアンエージェントが来るよ」と予言しました。なぜガーディアンエージェントが来るのでしょうか？本稿では、そのあたりを考察していきたいと思います。なぜ今、AIの「監視役」が必要なのか 2025年、私たちは本格的なAIエージェント時代の入り口に立っています。AIが単なるツールから、自律的に判断し行動する「エージェント」へと進化する中で、新たな課題が浮上しています。従来のAIとエージェント型AIの違いさて、ガーディアンエージェントが必要になる理由として、生成AI（以後AIと呼びます）の急速な進化があげられます。従来のAIとエージェント型AIの違いを思い出

LLM推論基盤プロビジョニング講座　第4回推論エンジンの選定

こんにちは！前回までの講座では、LLMサービス構築に必要なリクエスト数の見積もりや、使用モデルの推論時消費メモリ計算について詳しく解説してきました。今回は7ステッププロセスの4番目、「推論エンジンの選定」について詳しく掘り下げていきます。推論エンジンとは何か推論エンジンとは、GPU上でLLMモデルの推論計算（テキスト生成）を効率的に行うために設計された専用のソフトウェアプログラムです。一般的なディープラーニングフレームワーク（PyTorch、TensorFlowなど）でも推論は可能ですが、実運用環境では専用の推論エンジンを使用することで、大幅なパフォーマンス向上とリソース効率化が期待できます。推論エンジンは単なる実行環境ではなく、様々な最適化技術を実装しています。特定のモデルアーキテクチャに特化した最適化機能を実装したものや、推論速度の高速化に特化したもの、前回解説したKVキャッシュのメモリ効率化機能を備えたものなど、それぞれ特徴が異なります。そのため、自社で採用したLLMモデルや運用環境、要件に合致した推論エンジンを選定することが重要です。推論エンジン選定のアプロ