TensorRT-LLM v 0.11.0.dev2024051400 の動作確認

TensorRT-LLM v 0.11.0.dev2024051400 の動作確認
Photo by Timur Garifov / Unsplash

こんにちは、株式会社 Qualiteg プロダクト開発部です!

TensorRT-LLM は FasterTransformerの後継ともいえるNVIDIA製 推論エンジンで、当社ChatStreamの推論エンジンとしても選択可能です。

vLLMと同じく新しいモデル対応が早く、既存モデルも豊富にサポートされています。

昨日 大型コミットが入りましたので動作確認をしました。(マルチモーダルモデルNeva,Kosmos2に対応など。)

TensorRT-LLM のサポートしている、モデルアーキテクチャは以下のとおりです。

LLM

Baichuan, BART, BERT, Blip2, BLOOM, ChatGLM, DBRX, FairSeq NMT, Falcon, Flan-T5, Gemma, GPT, GPT-J, GPT-Nemo, GPT-NeoX, InternLM, LLaMA, LLaMA-v2, Mamba, mBART, Mistral, MPT, mT5, OPT, Phi-1.5/Phi-2, Qwen, Qwen-VL, Replit Code, RoBERTa, SantaCoder, Skywork, Smaug, StarCoder, T5, Whisper

マルチモーダル

BLIP2 w/ OPT-2.7B, BLIP2 w/ T5-XL, CogVLM, Deplot, Fuyu, Kosmos-2, LLaVA-v1.5-7B, NeVA, Nougat family Nougat-small, Nougat-base, VILA

動作確認

安定した推論環境提供のため常に TensorRT-LLM 最新ビルドの動確をしております。今回も専用 Docker コンテナを使用して最新版の動確をしました。

今日はまず手動確認をしてみましたので、ご紹介します

TensorRT-LLMコンテナ起動。
モデルファイル等は ホストUbuntu /home/mlu/TensorRT-LLM 側に配置されている前提。

docker run --rm -it --ipc=host --ulimit memlock=-1 --ulimit stack=67108864  \
                --gpus=all \
                --volume /home/mlu/TensorRT-LLM:/code/tensorrt_llm \
                --env "CCACHE_DIR=/code/tensorrt_llm/cpp/.ccache" \
                --env "CCACHE_BASEDIR=/code/tensorrt_llm" \
                --workdir /app/tensorrt_llm \
                --hostname LLM-Inf-Dev-release \
                --name tensorrt_llm-release-mlu \
                --tmpfs /tmp:exec \
                tensorrt_llm_qs_ready

TensorRT-LLM のクイックスタートでおなじみ llama2-chat サンプルディレクトリに移動

cd /code/tensorrt_llm/examples/llama/

推論実行
浅草のオススメスポットをきいてみましょう。

python3 ../run.py --engine_dir ./llama-2-7b-engine  \
--max_output_len 1024 \
--tokenizer_dir ./meta-llama/Llama-2-7b-chat-hf \
--input_text "What are the recommended tourist spots in Asakusa?"

実行結果は以下動画にて。


(株)QualitegのChatStreamは 推論エンジンとして Classic Transformer,vLLM,DeepSpeed,TensorRT-LLM をサポートしております。

高速LLMサービング、省GPUメモリ、分散推論、量子化の要求に応じて最適な推論エンジンを選択することができます。

LLMの推論環境、サービングに関するお悩み、ご相談くださいませ

Read more

Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

こんにちは! 本日は、自動フレーミング映像の安定化に関するアルゴリズム・ノウハウを解説いたします 第1章 問題の背景と目的 バストアップ映像を撮影する際、特にオンラインミーティングやYouTubeなどのトーク映像では、人物がうなずく、首を振るなどの自然な動作をした際に「首まわりや肩がフレーム内で上下に移動してしまう」という現象がしばしば起こります。これは、多くの場合カメラや撮影ソフトウェアが人物の「目や顔を画面中央に保とう」とする自動フレーミング機能の働きに起因します。 撮影対象の人物が頭を下げた際に、映像のフレーム全体が相対的に上方向へシフトし、その結果、本来動いていないはずの肩の部分が映像内で持ち上がっているように見えてしまう現象です。 本稿では、この問題を撮影後の後処理(ポストプロセッシング)のみを用いて、高速、高い精度かつロバストに解決する手法をご紹介します。 前半では、従来のCV(コンピュータービジョン)の手法を使い高速に処理する方法をご紹介します。後半では、AIを使用してより安定性の高い性能を実現する方法について考察します。 第2章 古典手法による肩の上下

By Qualiteg 研究部
LLM推論基盤プロビジョニング講座 第1回 基本概念と推論速度

LLM推論基盤プロビジョニング講座 第1回 基本概念と推論速度

こんにちは! 本日は LLMサービスの自社構築する際の推論基盤プロビジョニング、GPUプロビジョニングについて数回にわけて解説いたします。 はじめに LLMの進化に伴い、ChatGPTやClaudeといったパブリックなLLMの活用は企業においても急速に広がってきました。しかし先進的な企業はこれらの汎用LLMに加えて、「領域特化型」「ドメイン特化型」といった専用LLMの構築へと歩みを進めています。こうした動きの背景には、企業固有の専門知識への対応力強化と情報セキュリティの確保という二つの重要なニーズがあります。 一般的なパブリックLLMでは対応できない企業固有の専門知識や機密情報の取り扱いが必要なケースが増えているため、自社LLMの構築や自社サーバーでの運用を検討する企業が急増しています。特に金融、医療、製造、法務といった専門性の高い領域では、業界特化型の独自LLMが競争優位性をもたらすと認識されています。 しかし、業界特化型のLLMを自社で運用することは簡単ではありません。自社運用を決断した場合、まず最初に取り組むべきは適切な推論環境の整備です。オンプレミス環境を構築するに

By Qualiteg コンサルティング
Startup JAPAN 2025 に出展いたしました

Startup JAPAN 2025 に出展いたしました

こんにちは! 2025年5月8日(木)-5月9日(金)に東京ビッグサイトで開催された Startup JAPAN 2025 に出展いたしましたので、簡単にレポートいたします😊 開催概要 出展概要 今回は当社が開発するアバター動画生成AI「MotionVox™」を中心に出展させていただきました! 展示会について簡単にふりかえってみたいとおもいます 当社ブース 当社ブースはこんなかんじです。 今回は、ブースというか、このイーゼルのような雰囲気の木枠にポスターをくっつけるというスタイルでの展示方式でした。 こういう方式ははじめてなので斬新でした。おそらくこの方式で相当なコストダウンを図れておりスタートアップにはうれしいですね。セットアップも数分で終わりました。 会場 今回の会場はビッグサイトの南ホールでした。南ホールは、ビッグサイト入口からすぐそこなので駅から会場までたいして歩かず、疲れずに行くことができアクセスがとても良いです。 ホールは広めですが、ところせましと400社の出展会社がひしめきあっておりスタートアップの勢いのある会場となっており

By Qualiteg ビジネス開発本部 | マーケティング部
GPUサービスで「Segmentation Fault 」に出会ったら~分析から解決までの実践アプローチ~

GPUサービスで「Segmentation Fault 」に出会ったら~分析から解決までの実践アプローチ~

こんにちは! 今日は仮想環境+GPUなサービスにおける「Segmentation Fault」について、分析と対処法について書いてみたいと思います。 Segmentation Faultの本質と特徴 Segmentation Faultは、プログラムが保護されたメモリ領域にアクセスしようとした際にOSが発生させる例外です。 今回は複数のGPUサービス(つまりGPUを使うプロセス)が動作していて、そのうちの1つを再起動したときに発生しました。 毎回発生するわけではありません。むしろ数百回の起動に1回程度ですが、1回でも発生すると絶望的な結果につながります。というのも、1つのGPUサービスの停止が SPOF となってサービス全体に影響が発生します。かつ、1回でも「Segmentation Fault」が発生してしまうと、その原因となったプロセスが二度と起動しなくなる、というやっかいな現象でした。 このように「普段は正常に動作しているのに突然動かなくなる」というのがデバッグを非常に難しくします。 とくにGPU+仮想化の組み合わせで従来のC++アプリよりも発生確率がぐっとあがる印象

By Qualiteg プロダクト開発部