Three Building Blocks for Creating AI Virtual Assistants for Customer Service with an NVIDIA AI Blueprint

In today’s fast-paced business environment, providing exceptional customer service is no longer just a nice-to-have—it’s a necessity. Whether addressing technical issues, resolving billing questions, or providing service updates, customers expect quick, accurate, and personalized responses at their convenience. However, achieving this level of service comes with significant challenges.
Legacy approaches, such as static scripts or manual processes, often fall short when it comes to delivering personalized and real-time support. Additionally, many customer service operations rely on sensitive and fragmented data, which is subject to strict data governance and privacy regulations. With the rise of generative AI, companies aim to revolutionize customer service by enhancing operational efficiency, cutting costs, and maximizing ROI.
Integrating AI into existing systems presents challenges related to transparency, accuracy, and security, which can impede adoption and disrupt workflows. To overcome these hurdles, companies are leveraging generative AI-powered virtual assistants to manage a wide range of tasks, ultimately improving response times and freeing up resources.
This post outlines how developers can use the
NVIDIA AI Blueprint for AI virtual assistants
to scale operations with generative AI. By leveraging this information, including sample code, businesses can meet the growing demands for exceptional customer service while ensuring data integrity and governance. Whether improving existing systems or creating new ones, this blueprint empowers teams to meet customer needs with efficient and meaningful interactions.
Smarter AI virtual assistants with an AI query engine using retrieval-augmented generation
When building an AI virtual assistant, it’s important to align with the unique use case requirements, institutional knowledge, and needs of the organization. Traditional bots, however, often rely on rigid frameworks and outdated methods that struggle to meet the evolving demands of today’s customer service landscape.
Across every industry, AI-based assistants can be transformational. For example, telecommunications companies, and the majority of retail and service providers, can use AI virtual assistants to enhance customer experience by offering support 24 hours a day, 7 days a week while handling a wide range of customer queries in multiple languages and providing dynamic, personalized interactions that streamline troubleshooting and account management. This helps reduce wait times and ensures consistent service across diverse customer needs.
Another example is within the healthcare insurance payor industry, where ensuring a positive member experience is critical. Virtual assistants enhance this experience by providing personalized support to members, addressing their claims, coverage inquiries, benefits, and payment issues, all while ensuring compliance with healthcare regulations. This also helps reduce the administrative burden on healthcare workers.
With the NVIDIA AI platform, organizations can create an AI query engine that uses
retrieval-augmented generation (RAG)
to connect AI applications to enterprise data. The AI virtual assistant blueprint enables developers to quickly get started building solutions that provide enhanced customer experiences. It is built using the following
NVIDIA NIM
microservices:
NVIDIA NIM for LLM:
Brings the power of state-of-the-art large language models (LLMs) to applications, providing unmatched natural language processing with remarkable efficiency.
Llama 3.1 70B Instruct NIM
:
Powers complex conversations with superior contextual understanding, reasoning, and text generation.
NVIDIA NeMo
Retriever NIM:
This collection provides easy access to state-of-the-art models that serve as foundational building blocks for RAG pipelines. These pipelines, when integrated into virtual assistant solutions, enable seamless access to enterprise data, unlocking institutional knowledge via fast, accurate, and scalable answers.
NeMo
Retriever Embedding NIM
:
Boosts text question-answering retrieval performance, providing high-quality embeddings for the downstream virtual assistant.
NeMo
Retriever Reranking NIM
:
Enhances the retrieval performance further with a fine-tuned reranker, finding the most relevant passages to provide as context when querying an LLM.
The blueprint is designed to integrate seamlessly with existing customer service applications without breaking information security mandates. Thanks to the portability of NVIDIA NIM, organizations can integrate data wherever it resides. By bringing generative AI to the data, this architecture enables AI virtual assistants to provide more personalized experiences tailored to each customer by leveraging their unique profiles, user interaction histories, and other relevant data.
A blueprint is a starting point that can be customized for an enterprise’s unique use case.  For example, integrate other NIM microservices, such as the
Nemotron 4 Hindi 4B Instruct
, to enable an AI virtual assistant to communicate in the local language. Other microservices can enable additional capabilities such as synthetic data generation and model fine-tuning to better align with your specific use case requirements. Give the AI virtual assistant a humanlike interface when connected to the digital human AI Blueprint.
With the implementation of a RAG backend with proprietary data (both company and user profile and their specific data), the AI virtual assistant can engage in highly contextual conversations, addressing the specifics of each customer’s needs in real-time. Additionally, the solution operates securely within your existing governance frameworks, ensuring compliance with privacy and security protocols especially when working with sensitive data.
Three building blocks for creating your own AI virtual assistant
As a developer, you can build your own AI virtual assistant that retrieves the most relevant and up-to-date information, in real time, with ever-improving humanlike responses. Figure 1 shows the AI virtual assistant architecture diagram which includes three functional components.
Figure 1. The NVIDIA AI Blueprint for AI virtual assistants
1. Data ingestion and retrieval pipeline
Pipeline administrators use the ingestion pipeline to load structured and unstructured data into the databases. Examples of structured data include customer profiles, order history, and order status. Unstructured data includes product manuals, the product catalog, and supporting material such as FAQ documents.
2. AI agent
The AI virtual assistant is the second functional component. Users interact with the virtual assistant through a user interface. An AI agent, implemented in the LangGraph agentic LLM programming framework, plans how to handle complex customer queries and solves recursively. The LangGraph agent uses the tool calling feature of the
Llama 3.1 70B Instruct NIM
to retrieve information from both the unstructured and structured data sources, then generates an accurate response.
The AI agent also uses short-term and long-term memory functions to enable multi-turn conversation history. The active conversation queries and responses are embedded so they can be retrieved later in the conversation as additional context. This allows more human-like interactions and eliminates the need for customers to repeat information they’ve already shared with the agent.
Finally, at the end of the conversation, the AI agent summarizes the discussion along with a sentiment determination and stores the conversation history in the structured database. Subsequent interactions from the same user can be retrieved as additional context in future conversations. Call summarization and conversation history retrieval can reduce call time and improve customer experience. Sentiment determination can provide valuable insights to the customer service administrator regarding the agent’s effectiveness.
3. Operations pipeline
The customer operations pipeline is the third functional component of the overall solution. This pipeline provides important information and insight to the customer service operators. Administrators can use the operations pipeline to review chat history, user feedback, sentiment analysis data, and call summaries. The analytics microservice, which leverages the Llama 3.1 70B Instruct NIM, can be used to generate analytics such as average call time, time to resolution, and customer satisfaction. The analytics are also leveraged as user feedback to retrain the LLM models to improve accuracy.
You can find the complete example of how to get started with this Blueprint on the
NVIDIA AI Blueprint GitHub repository.
Get to production with NVIDIA partners
NVIDIA consulting partners are helping enterprises adopt world-class AI virtual assistants built using NVIDIA accelerated computing and
NVIDIA AI Enterprise software
, which includes NeMo, NIM microservices, and AI Blueprints.
Accenture
The Accenture AI Refinery
built on
NVIDIA AI Foundry
helps design autonomous, intent-driven customer interactions, enabling businesses to tailor the journey to the individual through innovative channels such as digital humans or interaction agents. Specific use cases can be tailored to meet the needs of each industry, for example, telco call centers, insurance policy advisors, pharmaceutical interactive agents or automotive dealer network agents.
Deloitte
Deloitte Frontline AI enhances the customer service experience with digital avatars and LLM agents built with NVIDIA AI Blueprints that are accelerated by NVIDIA technologies such as NVIDIA ACE, NVIDIA Omniverse, NVIDIA Riva, and NIM.
Wipro
Wipro Enterprise Generative AI (WeGA) Studio accelerates industry-specific use cases including contact center agents across healthcare, financial services, retail, and more.
Tech Mahindra
Tech Mahindra is leveraging the NVIDIA AI Blueprint for digital humans to build solutions for customer service. Using RAG and NVIDIA NeMo, the solution provides the ability for a trainee to stop an agent during a conversation by raising a hand to ask clarifying questions. The system is designed to connect with microservices on the backend with a refined learning management system) which can be deployed across many industry use cases.
Infosys
Infosys Cortex
, part of
Infosys Topaz
, is an AI-driven customer engagement platform that integrates NVIDIA AI Blueprints and the NVIDIA NeMo, Riva, and ACE technologies for generative AI, speech AI, and digital human capabilities to deliver specialized and individualized, proactive, and on-demand assistance to every member of a customer service organization, consequently playing a pivotal role in enhancing customer experience, improving operational efficiency, and reducing costs.
Tata Consultancy Services
The Tata Consultancy Services (TCS) virtual agent, powered by NVIDIA NIM, and integrated with ServiceNow’s IT Virtual Agent is designed to optimize IT and HR support. This solution uses prompt-tuning and RAG to improve response times, accuracy, and provide multi-turn conversational capabilities. Benefits include reduced service desk costs, fewer support tickets, enhanced knowledge utilization, faster deployment, and a better overall employee and customer experience.
Quantiphi
Quantiphi
is integrating NVIDIA AI Blueprints into its conversational AI solutions to enhance customer service with lifelike digital avatars. These state-of-the-art avatars, powered by NVIDIA Tokkio and ACE technologies,
NVIDIA NIM microservices
and
NVIDIA NeMo
, seamlessly integrate with existing enterprise applications, enhancing operations and customer experiences with increased realism. Fine-tuned NIM deployments for digital avatar workflows have proven to be highly cost-effective, reducing enterprise spending on tokens.
SoftServe
SoftServe Digital Concierge
, accelerated by NVIDIA AI Blueprints and NVIDIA NIM microservices, uses NVIDIA ACE, NVIDIA Riva, and the NVIDIA Audio2Face NIM microservice to deliver a highly realistic virtual assistant. Thanks to the Character Creator tool, it delivers speech and facial expressions with remarkable accuracy and lifelike detail.
With RAG capabilities from NVIDIA NeMo Retriever, SoftServe Digital Concierge can intelligently respond to customer queries by referencing context and delivering specific, up-to-date information. It simplifies complex queries into clear, concise answers and can also provide detailed explanations when needed.
EXL
EXL’s Smart Agent Assist offering is a contact center AI solution leveraging NVIDIA Riva, NVIDIA NeMo, and NVIDIA NIM microservices. EXL plans to augment their solution using the NVIDIA AI Blueprint for AI virtual agents.
This week at
NVIDIA AI Summit India
, NVIDIA consulting partners announced a collaboration with NVIDIA to transform India into a Front Office for AI. Using NVIDIA technologies, these consulting giants can help customers tailor the customer service agent blueprint to build unique virtual assistants using their preferred AI model—including sovereign LLMs from India-based model makers—and run it in production efficiently on the infrastructure of their choice.
Get started
To try the blueprint for free, and to see system requirements, navigate to the
Blueprint Card
.
To start building applications using those microservices, visit the
NVIDIA API catalog
. To
sign in
, you’ll be prompted to enter a personal or business email address to access different options for building with NIM. For more information, see the
NVIDIA NIM FAQ
.
This post was originally published on 10/23/2024.

NVIDIA AI Blueprint でカスタマー サービス向けの AI バーチャル アシスタントを作成する 3 つの構成要素

Reading Time:
2
minutes
今日のめまぐるしいビジネス環境では、優れたカスタマー サービスを提供することは、もはや単に「あれば良いこと」ではなく、「必要不可欠なこと」です。技術的な問題への対応、請求に関する質問の解決、サービスの最新情報の提供など、顧客は、迅速かつ正確で、顧客の都合にカスタマイズされた対応を期待しています。しかし、このレベルのサービスを実現するには、大きな課題が伴います。
パーソナライズされたリアルタイムのサポートを提供するには、多くの場合、静的なスクリプトや手作業によるプロセスといった従来のアプローチでは不十分です。さらに、多くのカスタマー サービス業務では、機密性が高くかつ断片的なデータを取り扱うことになり、厳しいデータ管理とプライバシー規制の対象となります。生成 AI の台頭により、企業は運用効率の向上、コスト削減、ROI の最大化によってカスタマー サービスに革命を起こすことを目指しています。
AI を既存のシステムに組み込む際には、透明性、精度、セキュリティに関する課題に直面し、導入を妨げ、ワークフローを中断させることもあるかもしれません。こうしたハードルを克服するために、企業は生成 AI を活用したバーチャル アシスタントを利用して幅広いタスクを管理し、最終的に応答時間を短縮して、リソースを解放しています。
この投稿では、開発者が、
AI バーチャル アシスタントに NVIDIA AI Blueprint
を使用して、生成 AI で業務を拡張する方法について説明します。サンプル コードを含むこの情報を活用することで、企業は、データの整合性とデータ ガバナンスを確保しながら、優れたカスタマー サービスへの高まる要求に応えることができます。既存のシステムの改善または新しいシステムの構築にかかわらず、この Blueprint によってチームは効率的で意味のあるやりとりを通じて顧客のニーズに対応することができます。
検索拡張生成 (RAG) を使用した AI クエリ エンジンによるスマートな AI バーチャル アシスタント
AI バーチャル アシスタントを構築する場合、独自のユース ケース要件および組織の知識やニーズに合わせて調整することが重要です。従来のボットでは、多くの場合、柔軟性の乏しいフレームワークと時代遅れのメソッドを利用しており、今日のカスタマー サービスのような常に変化し続ける要求に対応できません。
あらゆる業界で、AI ベースのアシスタントが革新的な存在となり得ます。たとえば、通信会社や小売、サービス プロバイダーの大多数は、AI バーチャル アシスタントを使用して、24 時間 365 日稼働するサポートを提供しながら、多言語で幅広い顧客の問い合わせに対応し、トラブルシューティングやアカウント管理を合理化する、ダイナミックでパーソナライズされたやりとりを提供することで、顧客体験を向上させことができます。これにより、待ち時間を短縮し、さまざまな顧客ニーズに対して一貫したサービスを提供することができます。
もうひとつの例として、医療保険の支払業界では、加入者にとって満足度の高い体験を確実に提供することが重要です。バーチャル アシスタントは、医療規制の遵守を確保しながら、加入者にパーソナライズされたサポートを提供し、請求、補償に関する問い合わせ、給付金、支払いに関する問題に対処することで、こうした体験を向上しています。これにより、医療従事者の管理上の負担を軽減することもできます。
NVIDIA AI プラットフォームを使用することで、企業は、
検索拡張生成 (RAG)
を使用する AI クエリ エンジンを作成し、AI アプリケーションを企業データに接続することができます。AI バーチャル アシスタントの Blueprint により、開発者は、より洗練された顧客体験を提供するソリューションを迅速に構築し開始することができます。この Blueprint は、以下の
NVIDIA NIM
マイクロサービスを使用して構築されます。
LLM 向け NVIDIA NIM:
最先端の大規模言語モデル (LLM) のパワーをアプリケーションに取り入れ、大幅に効率化して、卓越した自然言語処理を提供します。
Llama 3.1 70B Instruct NIM
:
優れた文脈理解、推論、テキスト生成で複雑な会話が可能です。
NVIDIA NeMo
Retriever NIM:
RAG パイプラインの基礎となる構成要素である最先端モデルに簡単にアクセスできます。この RAG パイプラインによって、バーチャル アシスタントは企業データへのシームレスなアクセスが可能になり、迅速かつ正確でスケーラブルな回答で、組織の知識を活用できます。
NeMo
Retriever Embedding NIM
:
テキストの QA 検索タスクに特化されており、バーチャル アシスタントはこの高品質のテキスト埋め込みを利用します。
NeMo
Retriever Reranking NIM
:
ファインチューニングされたリランキング モデルであり、埋め込みモデルと併用することで検索性能をさらに向上させることができます。入力文に最も関連性の高い文章を見付け出し、LLM に文脈として渡します。
この Blueprint は、情報セキュリティに関する義務に反することなく、既存のカスタマー サービス アプリケーションとシームレスに統合できるように設計されています。NVIDIA NIM の移植性のおかげで、企業は、データがどこにあっても統合することができます。生成 AI をデータに取り入れることで、AI バーチャル アシスタントは、顧客固有のプロファイル、ユーザーとの対話履歴、その他の関連データなどを活用して、各顧客に合わせたよりパーソナライズされた体験を提供できるようになります。
Blueprint は、企業独自のユース ケースに合わせてカスタマイズが可能な ”土台” のようなものです。たとえば、
Nemotron 4 Hindi 4B Instruct
など他の NIM マイクロサービスを統合すれば、AI バーチャル アシスタントが現地の言語でコミュニケーションできるようになります。その他のマイクロサービスにより、合成データの生成やモデルのファインチューニングなどの追加機能が可能になり、特定のユース ケース要件に適合させることができます。また、デジタル ヒューマン AI Blueprint に接続すると、AI バーチャル アシスタントに人間のようなインターフェイスが提供されます。
独自のデータ (企業やユーザーのプロファイル、特定のデータ) を備えた RAG バックエンドを実装することで、AI バーチャル アシスタントは、文脈に沿った対話を行い、リアルタイムで各顧客のニーズの特定事項に対応することができます。さらに、このソリューションはすでに運用しているガバナンス フレームワーク内で安全に運用され、特に機密データを扱う際には、プライバシーとセキュリティ プロトコルの遵守を保証します。
独自の AI バーチャル アシスタントを構築する 3 つの構成要素
開発者として、最も関連性の高い最新の情報をリアルタイムで取得し、常に人間のような応答ができるよう日々進化する独自の AI バーチャル アシスタントを構築できます。図 1 は、3 つの機能コンポーネントを含む AI バーチャル アシスタントのアーキテクチャ図です。
図 1. AI バーチャル アシスタント向けの NVIDIA AI Blueprint
1. データの取り込みと検索パイプライン
パイプライン管理者は、取り込み (Ingest) パイプラインを使用して、構造化データや非構造化データをデータベースに読み込むことができます。構造化データの例として、顧客プロファイル、注文履歴、発送状況などがあります。非構造化データには、製品マニュアル、製品カタログ、FAQ ドキュメントなどのサポート資料が含まれます。
2. AI エージェント
2 つ目の機能コンポーネントは AI バーチャル アシスタント です。ユーザーは、ユーザー インターフェイスを介してバーチャル アシスタントと対話します。エージェント型 LLM プログラミング フレームワークである LangGraph で実装された AI エージェントが、顧客からの複雑な問い合わせに対応する方法を計画し、その問い合わせを再帰的に解決します。LangGraph エージェントは
Llama3.1 70B Instruct NIM
のツール呼び出し機能を使用して、非構造化データと構造化データの両方から情報を取得し、正確な応答を生成します。
また AI エージェントにより、短期メモリと長期メモリの機能を使用してマルチターンの対話履歴を実現できます。アクティブな会話に対する問い合わせや応答が埋め込まれているため、会話の後半で追加の文脈として検索し利用できます。これにより、より人間に近いやりとりが可能になり、顧客がすでにエージェントと共有した情報を繰り返す提供する必要がなくなります。
最終的に、会話の最後に AI エージェントが感情の判定とともに議論を要約し、構造化データベースに会話履歴を保存します。ユーザーとの対話は、今後の会話で追加の文脈として検索できます。通話の要約と会話履歴を検索することで、通話時間を短縮し、顧客体験を向上させることができます。感情判定によって、エージェントの有効性に関する貴重な洞察をカスタマー サービス管理者に提供できます。
3. 運用パイプライン
顧客運用パイプラインは、ソリューション全体の 3 つ目の構成要素です。このパイプラインは、カスタマー サービス オペレーターに重要な情報と洞察を提供します。管理者は、運用パイプラインを使用して、チャット履歴、ユーザーのフィードバック、感情分析データ、通話の要約を確認することができます。Llama 3.1 70B Instruct NIM を活用した分析マイクロサービスを使用して、平均通話時間、解決までの時間、顧客満足度などの分析を生成できます。また分析結果は、ユーザー フィードバックとしても活用され、LLM モデルを再トレーニングして精度を向上します。
NVIDIA パートナーと本番環境に着手
NVIDIA のコンサルティング パートナーは、各企業が、NVIDIA アクセラレーテッド コンピューティングと、NeMo、NIM マイクロサービス、AI Blueprint を含む
NVIDIA AI Enterprise ソフトウェア
で構築された世界水準の AI バーチャル アシスタントを導入できるように支援しています。
Accenture
NVIDIA AI Foundry
上に構築された
Accenture AI Refinery
は、自律的で顧客の意図に沿った対話を設計し、企業がデジタル ヒューマンやインタラクション エージェントなどの革新的なチャネルを通じて、個人に合わせてカスタマイズできるようにします。特定のユース ケースは、通信会社のコール センター、保険契約のアドバイザー、医薬品のインタラクティブ エージェント、自動車ディーラーのネットワーク エージェントなど、各業界のニーズに合わせてカスタマイズできます。
Deloitte
Deloitte Frontline AI は、NVIDIA ACE、NVIDIA Omniverse、NVIDIA Riva、NIM などの NVIDIA のテクノロジによって加速された NVIDIA AI Blueprint を利用して構築されたデジタル アバターや LLM エージェントでカスタマー サービス体験を向上しています。
Wipro
Wipro Enterprise Generative AI (WeGA) Studio は、ヘルスケア、金融サービス、小売などのコンタクト センターのエージェントを含む業界固有のユース ケースを加速しています。
Tech Mahindra
Tech Mahindra は、デジタル ヒューマン向けの NVIDIA AI Blueprint を活用して、カスタマー サービス向けのソリューションを構築しています。RAG と NVIDIA NeMo を使用したこのソリューションは、トレーニング受講者が、会話中に手を挙げて明確な質問をすることで、エージェントを止める機能を提供します。このシステムは、多くの業界のユース ケースでデプロイできる洗練された学習管理システムで、バックエンドのマイクロサービスと接続するように設計されています。
Infosys
Infosys Topaz
の一部である
Infosys Cortex
は、AI を活用した顧客エンゲージメント プラットフォームであり、生成 AI、スピーチ AI、デジタル ヒューマン機能を実現する NVIDIA AI Blueprint と NVIDIA NeMo、Riva、ACE 技術を統合し、カスタマー サービス組織のあらゆるメンバーに専門的で個人に合わせたプロアクティブかつオンデマンドの支援を提供することで、顧客体験の向上、運用効率の改善、コスト削減に重要な役割を果たします。
Tata Consultancy Services
NVIDIA NIM を搭載し ServiceNow の IT 仮想エージェントと統合された Tata Consultancy Services (TCS) の仮想エージェントは、IT と HR のサポートを最適化するように設計されています。このソリューションは、プロンプト チューニングと RAG を使用して、応答時間、精度を向上させ、マルチターンの会話機能を提供します。サービス デスクのコスト削減、サポート チケットの減少、ナレッジ活用の強化、より迅速なデプロイ、そして従業員と顧客の全体的な体験の向上などのメリットがあります。
Quantiphi
Quantiphi
は、NVIDIA AI Blueprint を対話型 AI ソリューションに統合し、リアルなデジタル アバターでカスタマー サービスを強化しています。NVIDIA Tokkio と ACE、
NVIDIA NIM マイクロサービス
、
NVIDIA NeMo
を搭載した最先端のアバターが、既存のエンタープライズ アプリケーションとシームレスに統合し、リアリティを高めながら運用と顧客体験を向上させます。デジタル アバター ワークフローにファインチューニングされた NIM のデプロイは、費用対効果が高く、企業のトークンに対する支出を削減することが実証されています。
SoftServe
SoftServe Digital Concierge
は、NVIDIA AI Blueprint と NVIDIA NIM マイクロサービスによって加速されており、NVIDIA ACE、NVIDIA Riva、NVIDIA Audio2Face NIM マイクロサービスを使用して、非常にリアルなバーチャル アシスタントを提供します。Character Creator ツールを使用することで、音声や顔の表情を驚くほど正確かつリアルに詳細を再現できます。
NVIDIA NeMo Retriever の RAG 機能により、SoftServe Digital Concierge は、文脈を参照し、特定の最新情報を提供することで、顧客からの問い合わせにインテリジェントに対応できます。複雑な問い合わせを簡素化し、明確で簡潔な回答にまとめ、必要に応じて詳細な説明を提供することもできます。
EXL
EXL の Smart Agent Assist 製品は、NVIDIA Riva、NVIDIA NeMo、NVIDIA NIM マイクロサービスを活用したコンタクト センター AI ソリューションです。EXL は、AI 仮想エージェント向けの NVIDIA AI Blueprint を使用して、ソリューションを強化する予定です。
NVIDIA AI Summit India
で、NVIDIA コンサルティング パートナーが、インドを AI のフロント オフィスに変革するために、NVIDIA とのコラボレーションを発表しました。NVIDIA テクノロジを使用することで、これらのコンサルティング大手は、顧客がカスタマー サービス エージェントの Blueprint をカスタマイズし、好みの AI モデル (インドに拠点を置くモデル メーカーが提供するソブリン LLM を含む) を使用して独自のバーチャル アシスタントを構築し、希望のインフラで効率的に本番稼動できるようにします。
今すぐ始める
Blueprint を無料で試したり、システム要件を確認するには、
Blueprint カード
をご参照ください。これらのマイクロサービスを使用してアプリケーションの構築を始めるには、
NVIDIA API カタログ
にアクセスしてください。
サインイン
するには、NIM で構築するさまざまなオプションにアクセスするため、個人用またはビジネス用のメール アドレスを入力する必要があります。詳細については、
NVIDIA NIM FAQ
をご覧ください。
関連情報
GTC セッション:
金融部門向けの安全で効率的なバーチャル アシスタント
GTC セッション:
生成 AI の課題への対応と可能性の活用: NVIDIA のエンタープライズ デプロイから得られた洞察
NGC コンテナー:
retail-shopping-advisor-chatbot-service
NGC コンテナー:
retail-shopping-advisor-frontend-service
ウェビナー:
金融サービス コンタクト センター向けの AI 音声対応バーチャル アシスタントの構築と導入方法
ウェビナー:
通信企業が対話型 AI で顧客体験を変革する方法


Hymba Hybrid-Head Architecture Boosts Small Language Model Performance

Transformers, with their attention-based architecture, have become the dominant choice for language models (LMs) due to their strong performance, parallelization capabilities, and long-term recall through key-value (KV) caches. However, their quadratic computational cost and high memory demands pose efficiency challenges. In contrast, state space models (SSMs) like Mamba and Mamba-2 offer constant complexity and efficient hardware optimization but struggle with memory recall tasks, affecting their performance on general benchmarks.
NVIDIA researchers recently proposed
Hymba
, a family of small language models (SLMs) featuring a hybrid-head parallel architecture that integrates transformer attention mechanisms with SSMs to achieve both enhanced efficiency and improved performance. In Hymba, attention heads provide high-resolution recall, while SSM heads enable efficient context summarization.
The novel architecture of Hymba reveals several insights:
Overhead in attention:
Over 50% of attention computation can be replaced by cheaper SSM computation.
Local attention dominance:
Most global attention can be replaced by local attention without sacrificing performance on general and recall-intensive tasks, thanks to the global information summarized by SSM heads.
KV cache redundancy:
Key-value cache is highly correlated across heads and layers, so it can be shared across heads (group query attention) and layers (cross-layer KV cache sharing).
Softmax attention limitation:
Attention mechanisms are constrained to sum to one, limiting sparsity, and flexibility. We introduce learnable meta-tokens that are prepended to prompts, storing critical information and alleviating the “forced-to-attend” burden associated with attention mechanisms.
This post shows that Hymba 1.5B performs favorably against state-of-the-art open-source models of similar size, including Llama 3.2 1B, OpenELM 1B, Phi 1.5, SmolLM2 1.7B, Danube2 1.8B, and Qwen2.5 1.5B. Compared to Transformer models of similar size, Hymba also achieves higher throughput and requires 10x less memory to store cache.
Hymba 1.5B is released to the
Hugging Face
collection and
GitHub
.
Hymba 1.5B performance
Figure 1 compares Hymba 1.5B against sub-2B models (Llama 3.2 1B, OpenELM 1B, Phi 1.5, SmolLM2 1.7B, Danube2 1.8B, Qwen2.5 1.5B) in terms of average task accuracy, cache size (MB) relative to sequence length, and throughput (tok/sec).
Figure 1. Performance comparison of Hymba 1.5B Base against sub-2B models
In this set of experiments, the tasks include MMLU, ARC-C, ARC-E, PIQA, Hellaswag, Winogrande, and SQuAD-C. The throughput is measured on an NVIDIA A100 GPU with a sequence length of 8K and a batch size of 128 using PyTorch. For models encountering out of memory (OOM) issues during throughput measurement, the batch size was halved until the OOM is resolved to measure the maximal achievable throughput without OOM.
Hymba model design
SSMs such as Mamba were introduced to address the quadratic complexity and large inference-time KV cache issues of transformers. However, due to their low-resolution memory, SSMs struggle with memory recall and performance. To overcome these limitations, we propose a road map for developing efficient and high-performing small LMs in Table 1.
Configuration
Commonsense reasoning (%) ↑
Recall (%) ↑
Throughput (token/sec) ↑
Cache size (MB) ↓
Design reason
Ablations on 300M model size and 100B training tokens
Transformer (Llama)
44.08
39.98
721.1
414.7
Accurate recall while inefficient
State-space models (Mamba)
42.98
19.23
4720.8
1.9
Efficient while inaccurate recall
A. + Attention heads (sequential)
44.07
45.16
776.3
156.3
Enhance recall capabilities
B. + Multi-head heads (parallel)
45.19
49.90
876.7
148.2
Better balance of two modules
C. + Local / global attention
44.56
48.79
2399.7
41.2
Boost compute/cache efficiency
D. + KV cache sharing
45.16
48.04
2756.5
39.4
Cache efficiency
E. + Meta-tokens
45.59
51.79
2695.8
40.0
Learned memory initialization
Scaling to 1.5B model size and 1.5T training tokens
F. + Size / data
60.56
64.15
664.1
78.6
Further boost task performance
G. + Extended context length (2K→8K)
60.64
68.79
664.1
78.6
Improve multishot and recall tasks
Table 1. Design road map of the Hymba model
Fused hybrid modules
Fusing attention and SSM heads in parallel within a hybrid-head module outperforms sequential stacking, according to the ablation study. Hymba fuses attention and SSM heads in parallel within a hybrid head module, enabling both heads to process the same information simultaneously. This architecture improves reasoning and recall accuracy.
Figure 2. The hybrid-head module in Hymba
Efficiency and KV cache optimization
While attention heads improve task performance, they increase KV cache requirements and reduce throughput. To mitigate this, Hymba optimizes the hybrid-head module by combining local and global attention and employing cross-layer KV cache sharing. This improves throughput by 3x and reduces cache by almost 4x without sacrificing performance.
Figure 3. Hymba model architecture
Meta-tokens
A set of 128 pretrained embeddings prepended to inputs, functioning as learned cache initialization to enhance focus on relevant information. These tokens serve a dual purpose:
Mitigating attention drain by acting as backstop tokens, redistributing attention effectively
Encapsulating compressed world knowledge
Figure 4. Interpretation of Hymba from the memory aspect
Model analysis
This section presents an apples-to-apples comparison across different architectures under the same training settings. We then visualize the attention maps of SSM and Attention in different pretrained models. Finally, we perform head importance analysis for Hymba through pruning. All the analyses in this section help to illustrate how and why the design choices for Hymba are effective.
Apples-to-apples comparison
We performed an apples-to-apples comparison of Hymba, pure Mamba2, Mamba2 with FFN, Llama3 style, and Samba style (Mamba-FFN-Attn-FFN) architectures. All models have 1 billion parameters and are trained from scratch for 100 billion tokens from SmolLM-Corpus with exactly the same training recipe. All results are obtained through lm-evaluation-harness using a zero-shot setting on Hugging Face models. Hymba performs the best on commonsense reasoning as well as question answering and recall-intensive tasks.
Table 2 compares various model architectures on language modeling and recall-intensive and commonsense reasoning tasks, with Hymba achieving strong performance across metrics. Hymba demonstrates the lowest perplexity in language tasks (18.62 for Wiki and 10.38 for LMB) and solid results in recall-intensive tasks, particularly in SWDE (54.29) and SQuAD-C (44.71), leading to the highest average score in this category (49.50).
Model
Language (PPL) ↓
Recall intensive (%) ↑
Commonsense reasoning (%) ↑
Mamba2
15.88
43.34
52.52
Mamba2 w/ FFN
17.43
28.92
51.14
Llama3
16.19
47.33
52.82
Samba
16.28
36.17
52.83
Hymba
14.5
49.5
54.57
Table 2. Comparison of architectures trained on 100 billion tokens under the same settings
In commonsense reasoning and question answering, Hymba outperforms other models in most tasks, such as SIQA (31.76) and TruthfulQA (31.64), with an average score of 54.57, slightly above Llama3 and Mamba2. Overall, Hymba stands out as a balanced model, excelling in both efficiency and task performance across diverse categories.
Attention map visualization
We further categorized elements in the attention map into four types:
Meta:
Attention scores from all real tokens to meta-tokens. This category reflects the model’s preference for attending to meta-tokens. In attention maps, they are usually located in the first few columns (for example, 128 for Hymba) if a model has meta-tokens.
BOS:
Attention scores from all real tokens to the beginning-of-sequence token. In the attention map, they are usually located in the first column right after the meta-tokens.
Self:
Attention scores from all real tokens to themselves. In the attention map, they are usually located in the diagonal line.
Cross:
Attention scores from all real tokens to other real tokens. In the attention map, they are usually located in the off-diagonal area.
The attention pattern of Hymba is significantly different from that of vanilla Transformers. In vanilla Transformers, attention scores are more concentrated on BOS, which is consistent with the findings in Attention Sink. In addition, vanilla Transformers also have a higher proportion of Self attention scores. In Hymba, meta-tokens, attention heads, and SSM heads work complementary to each other, leading to a more balanced distribution of attention scores across different types of tokens.
Specifically, meta-tokens offload the attention scores from BOS, enabling the model to focus more on the real tokens. SSM heads summarize the global context, which focuses more on current tokens (Self attention scores). Attention heads, on the other hand, pay less attention to Self and BOS tokens, and more attention to other tokens (that is, Cross attention scores). This suggests that the hybrid-head design of Hymba can effectively balance the attention distribution across different types of tokens, potentially leading to better performance.
Figure 5. Schematics of the attention map of Hymba as a combination of meta-tokens, sliding window attention, and Mamba contributions
Figure 6. Sum of the attention score from different categories in Llama 3.2 3B and Hymba 1.5B
Heads importance analysis
We analyzed the relative importance of attention and SSM heads in each layer by removing them and recording the final accuracy. Our analysis reveals the following:
The relative importance of attention/SSM heads in the same layer is input-adaptive and varies across tasks, suggesting that they can serve different roles when handling various inputs.
The SSM head in the first layer is critical for language modeling, and removing it causes a substantial accuracy drop to random guess levels.
Generally, removing one attention/SSM head results in an average accuracy drop of 0.24%/1.1% on Hellaswag, respectively.
Figure 7. The achieved accuracy, measured using 1K samples from Hellaswag, after removing the Attention or SSM heads in each layer
Model architecture and training best practices
This section outlines key architectural decisions and training methodologies for Hymba 1.5B Base and Hymba 1.5B Instruct.
Model architecture
Hybrid architecture:
Mamba is great at summarization and usually closer focuses on the current token, while attention is more precise and acts as snapshot memory. Combining them in parallel merges these benefits, but standard sequential fusion does not. We chose a 5:1 parameter ratio between SSM and attention heads.
Sliding window attention:
Full attention heads are preserved in three layers (first, last, and middle), with sliding window attention heads used in the remaining 90% layers.
Cross-layer KV cache sharing:
Implemented between every two consecutive attention layers. It is done in addition to GQA KV cache sharing between heads.
Meta-tokens:
These 128 tokens are learnable with no supervision, helping to avoid entropy collapse problems in large language models (LLMs) and mitigate the attention sink phenomenon. Additionally, the model stores general knowledge in these tokens.
Training best practices
Pretraining:
We opted for two-stage base model training. Stage 1 maintained a constant large learning rate and used less filtered large corpus data. Continuous learning rate decay was then performed to 1e-5 using high-quality data. This approach enables continuous training and resuming of Stage 1.
Instruction fine-tuning:
Instruct model tuning is performed in three stages. First, SFT-1 provides the model with strong reasoning abilities by training on code, math, function calling, role play, and other task-specific data. Second, SFT-2 teaches the model to follow human instructions. Finally, DPO is leveraged to align the model with human preferences and improve the model’s safety.
Figure 8. Training pipeline adapted for the Hymba model family
Performance and efficiency evaluation
With only 1.5T pretraining tokens, the Hymba 1.5B model performs the best among all small LMs and achieves better throughput and cache efficiency than all transformer-based LMs.
For example, when benchmarking against the strongest baseline, Qwen2.5, which is pretrained on 13x more tokens, Hymba 1.5B achieves a 1.55% average accuracy improvement, 1.41x throughput, and 2.90x cache efficiency. Compared to the strongest small LM trained on fewer than 2T tokens, namely h2o-danube2, our method achieves a 5.41% average accuracy improvement, 2.45x throughput, and 6.23x cache efficiency.
Model
# Para-ms
Train tokens
Token
per sec
Cache
(MB)
MMLU  5-
shot
ARC-E 0-shot
ARC-C 0-shot
PIQA 0-shot
Wino.  0-shot
Hella. 0-shot
SQuAD -C
1-shot
Avg
Open
ELM-1
1.1B
1.5T
246
346
27.06
62.37
19.54
74.76
61.8
48.37
45.38
48.57
Rene
v0.1
1.3B
1.5T
800
113
32.94
67.05
31.06
76.49
62.75
51.16
48.36
52.83
Phi
1.5
1.3B
0.15T
241
1573
42.56
76.18
44.71
76.56
72.85
48
30.09
55.85
Smol
LM
1.7B
1T
238
1573
27.06
76.47
43.43
75.79
60.93
49.58
45.81
54.15
Cosmo
1.8B
.2T
244
1573
26.1
62.42
32.94
71.76
55.8
42.9
38.51
47.2
h20
dan-ube2
1.8B
2T
271
492
40.05
70.66
33.19
76.01
66.93
53.7
49.03
55.65
Llama 3.2 1B
1.2B
9T
535
262
32.12
65.53
31.39
74.43
60.69
47.72
40.18
50.29
Qwen
2.5
1.5B
18T
469
229
60.92
75.51
41.21
75.79
63.38
50.2
49.53
59.51
AMD
OLMo
1.2B
1.3T
387
1049
26.93
65.91
31.57
74.92
61.64
47.3
33.71
48.85
Smol
LM2
1.7B
11T
238
1573
50.29
77.78
44.71
77.09
66.38
53.55
50.5
60.04
Llama
3.2 3B
3.0B
9T
191
918
56.03
74.54
42.32
76.66
69.85
55.29
43.46
59.74
Hymba
1.5B
1.5T
664
79
51.19
76.94
45.9
77.31
66.61
53.55
55.93
61.06
Table 2. Hymba 1.5B Base model results
Instructed models
The Hymba 1.5B Instruct model achieves the highest performance on an average of all tasks, outperforming the previous state-of-the-art model, Qwen 2.5 Instruct, by around 2%. Specifically, Hymba 1.5B surpasses all other models in GSM8K/GPQA/BFCLv2 with a score of 58.76/31.03/46.40, respectively. These results indicate the superiority of Hymba 1.5B, particularly in areas requiring complex reasoning capabilities.
Model
# Params
MMLU ↑
IFEval ↑
GSM8K ↑
GPQA ↑
BFCLv2 ↑
Avg. ↑
SmolLM
1.7B
27.80
25.16
1.36
25.67
-*
20.00
OpenELM
1.1B
25.65
6.25
56.03
21.62
-*
27.39
Llama 3.2
1.2B
44.41
58.92
42.99
24.11
20.27
38.14
Qwen2.5
1.5B
59.73
46.78
56.03
30.13
43.85
47.30
SmolLM2
1.7B
49.11
55.06
47.68
29.24
22.83
40.78
Hymba 1.5B
1.5B
52.79
57.14
58.76
31.03
46.40
49.22
Table 3. Hymba 1.5B Instruct model results
Conclusion
The new Hymba family of small LMs features a hybrid-head architecture that combines the high-resolution recall capabilities of attention heads with the efficient context summarization of SSM heads. To further optimize the performance of Hymba, learnable meta-tokens are introduced to act as a learned cache for both attention and SSM heads, enhancing the model’s focus on salient information. Through the road map of Hymba, comprehensive evaluations, and ablation studies, Hymba sets new state-of-the-art performance across a wide range of tasks, achieving superior results in both accuracy and efficiency. Additionally, this work provides valuable insights into the advantages of hybrid-head architectures, offering a promising direction for future research in efficient LMs.
Learn more about
Hybma 1.5B Base
and
Hymba 1.5B Instruct
.
Acknowledgments
This work would not have been possible without contributions from many people at NVIDIA, including Wonmin Byeon, Zijia Chen, Ameya Sunil Mahabaleshwarkar, Shih-Yang Liu, Matthijs Van Keirsbilck, Min-Hung Chen, Yoshi Suhara, Nikolaus Binder, Hanah Zhang, Maksim Khadkevich, Yingyan Celine Lin, Jan Kautz, Pavlo Molchanov, and Nathan Horrocks.

Hymba ハイブリッド ヘッド アーキテクチャが小規模言語モデルのパフォーマンスを向上

Reading Time:
4
minutes
Transformer は、その Attention ベースのアーキテクチャによる、強力なパフォーマンス、並列化能力、および KV (Key-Value) キャッシュを通じた長期記憶のおかげで、言語モデル (LM) の主流となっています。しかし、二次計算コストと高いメモリ要求により、効率性に課題が生じています。これに対し、Mamba や Mamba-2 のような状態空間モデル (SSMs) は、複雑さを一定にして効率的なハードウェア最適化を提供しますが、メモリ想起タスクが苦手でそれは一般的なベンチマークでのパフォーマンスに影響を与えています。
NVIDIA の研究者は最近、効率性とパフォーマンスの両方を向上させるために、Transformer の Attention メカニズムを SSM と統合したハイブリッド ヘッド並列アーキテクチャを特徴とする小規模言語モデル (SLM) ファミリである
Hymba
を提案しました。Hymba では、Attention ヘッドが高解像度の記憶能力を提供し、SSM ヘッドが効率的なコンテキストの要約を可能にします。
Hymba の新たなアーキテクチャは、いくつかの洞察を明らかにしています。
Attention のオーバーヘッド:
Attention 計算の 50% 以上を、より安価な SSM 計算に置き換えることができます。
ローカル Attention の優位性:
SSM ヘッドにより要約されたグローバル情報のおかげで、一般的なタスクやメモリ想起に集中するタスクのパフォーマンスを犠牲にすることなく、ほとんどのグローバル Attention をローカル Attention に置き換えることができます。
KV キャッシュ冗長性:
Key-value キャッシュは、ヘッド間とレイヤー間で高い相関性があるため、ヘッド間 (GQA: Group Query Attention) およびレイヤー間 (Cross-layer KV キャッシュ共有) で共有できます。
Softmax の Attention の制限:
Attention メカニズムは、合計が 1 になるように制限されており、疎性と柔軟性に制限があります。NVIDIA は、プロンプトの先頭に学習可能なメタトークンを導入し、重要な情報を格納し、Attention メカニズムに関連する「強制的に Attention を行う」負担を軽減します。
この記事では、Hymba 1.5B が同様の規模である最先端のオープンソース モデル、Llama 3.2 1B、OpenELM 1B、Phi 1.5、SmolLM2 1.7B、Danube2 1.8B、Qwen2.5 1.5B などと比較して、良好なパフォーマンスを発揮することが示されています。同等のサイズの Transformer モデルと比較すると、Hymba はより高いスループットを発揮し、キャッシュを保存するために必要なメモリが 10 分の 1 で済みます。
Hymba 1.5B は
Hugging Face
コレクションと
GitHub
で公開されています。
Hymba 1.5B のパフォーマンス
図 1 は、Hymba 1.5B と 2B 未満のモデル (Llama 3.2 1B、OpenELM 1B、Phi 1.5、SmolLM2 1.7B、Danube2 1.8B、Qwen2.5 1.5B) を、平均タスク精度、シーケンス長に対するキャッシュ サイズ (MB)、スループット (tok/sec) で比較したものです。
図 1. Hymba 1.5B Base と 2B 未満のモデルのパフォーマンス比較
この一連の実験には、MMLU、ARC-C、ARC-E、PIQA、Hellaswag、Winogrande、SQuAD-C などのタスクが含まれています。スループットは、シーケンス長 8K、バッチ サイズ 128 で PyTorch を使用して NVIDIA A100 GPU で測定します。スループット測定中にメモリ不足 (OOM: Out of Memory) 問題が発生したモデルでは、OOM が解決されるまでバッチ サイズを半分にして、OOM なしで達成可能な最大スループットを測定しました。
Hymba モデルのデザイン
Mamba のような SSM は、Transformer の二次的な複雑性と推論時の KV キャッシュが大きい問題に対処するために導入されました。しかし、メモリ解像度が低いために、SSM は記憶想起とパフォーマンスの点で苦戦しています。これらの制限を克服するために、表 1 で効率的で高性能な小規模言語モデルを開発するためのロードマップを提案します。
構成
常識推論 (%) ↑
リコール (%) ↑
スループット (token/sec) ↑
キャッシュ サイズ (MB) ↓
設計理由
300M モデル サイズと 100B トレーニング トークンのアブレーション
Transformer (Llama)
44.08
39.98
721.1
414.7
非効率的ながら正確な記憶
状態空間モデル (Mamba)
42.98
19.23
4720.8
1.9
効率的だが不正確な記憶
A. + Attention ヘッド (連続)
44.07
45.16
776.3
156.3
記憶能力を強化
B. + 複数ヘッド (並列)
45.19
49.90
876.7
148.2
2 つのモジュールのバランスの改善
C. + ローカル / グローバル Attention
44.56
48.79
2399.7
41.2
演算 / キャッシュの効率を向上
D. + KV キャッシュ共有
45.16
48.04
2756.5
39.4
キャッシュ効率化
E. + メタトークン
45.59
51.79
2695.8
40.0
学習した記憶の初期化
1.5B モデル サイズと 1.5T トレーニング トークンへのスケーリング
F. + サイズ / データ
60.56
64.15
664.1
78.6
タスク パフォーマンスのさらなる向上
G. + コンテキスト長の拡張 (2K→8K)
60.64
68.79
664.1
78.6
マルチショットとリコール タスクの改善
表 1. Hymba モデルのデザイン ロードマップ
融合型ハイブリッド モジュール
アブレーション研究によると、ハイブリッド ヘッド モジュール内で Attention と SSM ヘッドを並列にして融合するほうが、シーケンシャルにスタッキングするより優れていることが分かっています。Hymba は、ハイブリッド ヘッド モジュール内で Attention と SSM ヘッドを並列に融合させ、両ヘッドが同時に同じ情報を処理できるようにします。このアーキテクチャは、推論と記憶の正確さを高めます。
図 2. Hymba のハイブリッド ヘッド モジュール
効率性と KV キャッシュの最適化
Attention ヘッドはタスクのパフォーマンスを向上させますが、KV キャッシュの要求を増大させ、スループットを低下させます。これを緩和するために、Hymba はローカルおよびグローバルの Attention を組み合わせ、 Cross-layer KV キャッシュ共有を採用することで、ハイブリッド ヘッド モジュールを最適化します。これにより、パフォーマンスを犠牲にすることなくスループットが 3 倍向上し、キャッシュがほぼ 4 分の 1 に削減されます。
図 3. Hymba モデルのアーキテクチャ
メタトークン
入力の先頭に置かれる 128 の事前学習済みの埋め込みのセットであり、学習済みキャッシュの初期化として機能し、関連情報への注意を強化します。このようなトークンには 2 つの目的があります。
バックストップ トークンとして機能し、Attention を効果的に再分配することで Attention の流出を軽減する
圧縮された世界知識をカプセル化する
図 4. メモリの側面から見た Hymba の解釈
モデル解析
このセクションでは、同一のトレーニング設定における異なるアーキテクチャを比較する方法を紹介します。それから、SSM と Attention の Attention マップを異なる学習済みモデルで可視化し、最後に、剪定 (pruning) を通じて Hymba のヘッド重要度分析を行います。このセクションのすべての分析は、Hymba のデザインにおける選択の仕組みと、それが効果的な理由を説明するのに役立ちます。
同一条件での比較
Hymba、純粋な Mamba2、Mamba2 と FFN、Llama3 スタイル、Samba スタイル (Mamba-FFN-Attn-FFN) のアーキテクチャを同一条件で比較しました。すべてのモデルが 10 億のパラメーターで、まったく同じトレーニング レシピで SmolLM-Corpus から 1,000 億トークンをゼロから学習しています。すべての結果は、Hugging Face モデルでゼロショット設定を使用して lm-evaluation-harness を通じて取得されています。Hymba は、常識推論だけでなく、質問応答タスクや記憶想起タスクでも最高のパフォーマンスを発揮します。
表 2 は、言語モデリングタスクと記憶想起タスクおよび常識推論タスクに関するさまざまなモデル アーキテクチャを比較しており、Hymba はすべての評価基準で卓越したパフォーマンスを達成しています。Hymba は、言語モデリングタスクで最も低い Perplexity を示し (Wiki で 18.62、LMB で 10.38)、特に SWDE (54.29) と SQuAD-C (44.71) の記憶想起タスクにおいて堅実な結果を示し、このカテゴリで最高の平均スコア (49.50) を達成しました。
モデル
言語モデリング (PPL) ↓
記憶想起型 (%) ↑
常識推論 (%) ↑
Mamba2
15.88
43.34
52.52
Mamba2 と FFN
17.43
28.92
51.14
Llama3
16.19
47.33
52.82
Samba
16.28
36.17
52.83
Hymba
14.5
49.5
54.57
表 2. 同じ設定で 1,000 億トークンで学習されたアーキテクチャの比較
常識推論と質問応答において、Hymba は平均スコア 54.57 で、 SIQA (31.76) や TruthfulQA (31.64) などのほとんどのタスクで、Llama3 や Mamba2 をやや上回っています。全体的に、Hymba はバランスの取れたモデルとして際立っており、多様なカテゴリで効率性とタスク パフォーマンスの両方で優れています。
Attention マップの可視化
さらに、Attention マップの要素を 4 つのタイプに分類しました。
Meta:
すべての実トークンからメタトークンへの Attention スコア。このカテゴリは、モデルがメタトークンに Attention を向ける傾向を反映するものです。Attention マップでは、通常、モデルにメタトークンがある場合、最初の数列 (例えば Hymba の場合は 128) に位置しています。
BOS:
すべての実トークンからセンテンスの開始トークンまでの Attention スコア。Attention マップでは、通常、メタトークンの直後の最初の列に位置します。
Self:
すべての実トークンからそれ自身への Attention スコア。Attention マップでは、通常、対角線上に位置しています。
Cross:
すべての実トークンから他の実トークンへの Attention スコア。Attention マップでは、通常、対角線外の領域に位置しています。
Hymba の Attention パターンは、vanilla (加工されていない) Transformer のそれとは大きく異なります。vanilla Transformer の Attention スコアは BOS に集中しており、Attention Sink の結果と一致しています。さらに、vanilla Transformer は、Self-Attention スコアの比率も高くなっています。Hymba では、メタトークン、Attention ヘッド、SSM ヘッドが互いに補完し合うように機能し、異なるタイプのトークン間で、よりバランスの取れた Attention スコアの分布を実現しています。
具体的には、メタトークンが BOS からの Attention スコアをオフロードすることで、モデルがより実際のトークンに集中できるようになります。SSM ヘッドはグローバルなコンテキストを要約し、現在のトークン (Self-Attention スコア) により重点を置きます。一方、Attention ヘッドは、Self と BOS トークンに対する注意が低く、他のトークン (すなわち、Cross Attention スコア) への注意が高くなります。これは、Hymba のハイブリッド ヘッド デザインが、異なるタイプのトークン間の Attention 分布のバランスを効果的に取ることができ、パフォーマンスの向上につながる可能性があることを示唆しています。
図 5. メタトークン、Sliding Window Attention、Mamba 貢献の組み合わせによる Hymba の Attention マップの概略図
図 6. Llama 3.2 3B と Hymba 1.5B の異なるカテゴリからの Attention スコアの合計
ヘッド重要度分析
各レイヤーのAttention と SSM ヘッドの相対的な重要性を分析するために、それぞれを削除して最終的な精度を記録しました。分析の結果、以下のことが明らかになりました。
同じレイヤーの  Attention / SSM ヘッドの相対的な重要性は入力適応であり、タスクによって異なります。これは、さまざまな入力の処理において、異なる役割を果たす可能性があることを示唆しています。
最初のレイヤーの SSM ヘッドは言語モデリングタスクに不可欠で、これを削除すると、ランダム推測レベルにまで大幅に精度が低下します。
一般的に、Attention / SSM ヘッドを 1 つ削除すると、Hellaswag ではそれぞれ平均 0.24%/1.1% 精度が低下します。
図 7. Hellaswag の 1K サンプルを使用して測定した、各レイヤーの Attention または SSM ヘッドを削除した後の達成精度
モデル アーキテクチャと学習のベスト プラクティス
このセクションでは、Hymba 1.5B Base と Hymba 1.5B Instruct の主要アーキテクチャ上の決定事項と学習方法の概要について説明します。
モデル アーキテクチャ
ハイブリッド アーキテクチャ:
Mamba は要約に優れ、通常は現在のトークンにより重点を置きます。Attention はより正確でスナップショット メモリとして機能します。標準的なシーケンシャル融合ではなく、並列に組み合わせることで利点を統合することができます。SSM と Attention ヘッド間のパラメーター比は 5:1 を選択しました。
Sliding Window Attention:
完全な Attention ヘッドは 3 つのレイヤー (最初、最後、中間) に維持され、残りの 90% のレイヤーで Sliding Window Attention ヘッドが使用されます。
Cross-layer KV キャッシュ共有:
連続する 2 つの Attention レイヤー間に実装されます。これは、ヘッド間の GQA KV キャッシュ共有に加えて行われます。
メタトークン:
これらの 128 トークンは教師なし学習が可能であり、大規模言語モデル (LLM) におけるエントロピー崩壊の問題を回避し、Attention Sink 現象を緩和するのに役立ちます。さらに、モデルはこれらのトークンに一般的な知識を格納します。
学習のベスト プラクティス
事前学習:
2 段階のベースモデル学習を選択しました。ステージ 1 では、一定の高い学習率を維持し、フィルタリングされていない大規模なコーパス データの使用しました。続いて、高品質のデータを用いて 1e-5 まで継続的に学習率を減衰させました。このアプローチにより、ステージ 1 の継続的な学習と再開が可能になります。
指示ファインチューニング:
指示モデルの調整は 3 つの段階で行われます。まず、SFT-1 は、コード、数学、関数呼び出し、ロール プレイ、その他のタスク固有のデータで学習を実施し、強力な推論能力をモデルに付与します。次に、SFT-2 はモデルに人間の指示に従うことを教えます。最後に、DPO を活用して、モデルを人間の好みに合わせ、モデルの安全性を高めます。
図 8. Hymba モデル ファミリに適応した学習パイプライン
パフォーマンスと効率性の評価
1.5T の事前学習トークンだけで、Hymba 1.5B モデルはすべての小規模言語モデルの中で最高の性能を発揮し、Transformer ベースの LM よりも優れたスループットとキャッシュ効率を実現します。
例えば、13 倍以上のトークン数で事前学習された最も強力なベースラインである Qwen2.5 に対してベンチマークした場合、Hymba 1.5B は平均精度が 1.55%、スループットが 1.41 倍、キャッシュ効率が 2.90 倍に向上します。2T 未満のトークンで学習された最も強力な小規模言語モデル、すなわち h2o-danube2 と比較すると、この方法は平均精度が 5.41%、スループットが 2.45 倍、キャッシュ効率が 6.23 倍に向上しています。
モデル
パラメーター数
学習トークン
トークン
(1 秒あたり)
キャッシュ
(MB)
MMLU 5-
shot
ARC-E 0-shot
ARC-C 0-shot
PIQA 0-shot
Wino. 0-shot
Hella. 0-shot
SQuAD -C
1-shot
平均
OpenELM-1
1.1B
1.5T
246
346
27.06
62.37
19.54
74.76
61.8
48.37
45.38
48.57
Renev0.1
1.3B
1.5T
800
113
32.94
67.05
31.06
76.49
62.75
51.16
48.36
52.83
Phi1.5
1.3B
0.15T
241
1573
42.56
76.18
44.71
76.56
72.85
48
30.09
55.85
SmolLM
1.7B
1T
238
1573
27.06
76.47
43.43
75.79
60.93
49.58
45.81
54.15
Cosmo
1.8B
.2T
244
1573
26.1
62.42
32.94
71.76
55.8
42.9
38.51
47.2
h20dan-ube2
1.8B
2T
271
492
40.05
70.66
33.19
76.01
66.93
53.7
49.03
55.65
Llama 3.2 1B
1.2B
9T
535
262
32.12
65.53
31.39
74.43
60.69
47.72
40.18
50.29
Qwen2.5
1.5B
18T
469
229
60.92
75.51
41.21
75.79
63.38
50.2
49.53
59.51
AMDOLMo
1.2B
1.3T
387
1049
26.93
65.91
31.57
74.92
61.64
47.3
33.71
48.85
SmolLM2
1.7B
11T
238
1573
50.29
77.78
44.71
77.09
66.38
53.55
50.5
60.04
Llama3.2 3B
3.0B
9T
191
918
56.03
74.54
42.32
76.66
69.85
55.29
43.46
59.74
Hymba
1.5B
1.5T
664
79
51.19
76.94
45.9
77.31
66.61
53.55
55.93
61.06
表 2. Hymba 1.5B ベース モデルの結果
指示モデル
Hymba 1.5B Instruct モデルは、全タスク平均で最高のパフォーマンスを達成し、直近の最高性能モデルである Qwen 2.5 Instruct を約 2% 上回りました。特に、Hymba 1.5B は GSM8K/GPQA/BFCLv2 で、それぞれ 58.76/31.03/46.40 のスコアで他のすべてのモデルを上回っています。これらの結果は、特に複雑な推論能力を必要とする分野において、Hymba 1.5B の優位性を示しています。
モデル
パラメーター数
MMLU ↑
IFEval ↑
GSM8K ↑
GPQA ↑
BFCLv2 ↑
平均↑
SmolLM
1.7B
27.80
25.16
1.36
25.67
-*
20.00
OpenELM
1.1B
25.65
6.25
56.03
21.62
-*
27.39
Llama 3.2
1.2B
44.41
58.92
42.99
24.11
20.27
38.14
Qwen2.5
1.5B
59.73
46.78
56.03
30.13
43.85
47.30
SmolLM2
1.7B
49.11
55.06
47.68
29.24
22.83
40.78
Hymba 1.5B
1.5B
52.79
57.14
58.76
31.03
46.40
49.22
表 3. Hymba 1.5B Instruct モデルの結果
まとめ
新しい Hymba ファミリの小規模言語モデルは、ハイブリッド ヘッド アーキテクチャを採用し、Attention ヘッドの高解像な記憶能力と SSM ヘッドの効率的なコンテキストの要約を組み合わせています。Hymba のパフォーマンスをさらに最適化するために、学習可能なメタトークンが導入され、Attention ヘッドと SSM ヘッドの両方で学習済みキャッシュとして機能し、顕著な情報に注目するモデルの精度を強化しました。Hymba のロードマップ、包括的な評価、アブレーション研究を通じて、Hymba は幅広いタスクにわたって新たな最先端のパフォーマンスを確立し、正確さと効率性の両面で優れた結果を達成しました。さらに、この研究は、ハイブリッド ヘッド アーキテクチャの利点に関する貴重な洞察をもたらし、効率的な言語モデルの今後の研究に有望な方向性を示しています。
Hybma 1.5B Base
と
Hymba 1.5B Instruct
の詳細はこちらをご覧ください。
謝辞
この成果は、Wonmin Byeon、Zijia Chen、Ameya Sunil Mahabaleshwarkar、Shih-Yang Liu、Matthijs Van Keirsbilck、Min-Hung Chen、Yoshi Suhara、Nikolaus Binder、Hanah Zhang、Maksim Khadkevich、Yingyan Celine Lin、Jan Kautz、Pavlo Molchanov、Nathan Horrocks など、NVIDIA の多くのメンバーの貢献なくしては実現しませんでした。
関連情報
GTC セッション:
Optimizing Large Language Models: An Experimental Approach to Pruning and Fine-Tuning LLama2 7B (大規模言語モデルの最適化: LLama2 7B の剪定とファインチューニングの実験的アプローチ)
GTC セッション:
Accelerating End-to-End Large Language Models System using a Unified Inference Architecture and FP8 (統一推論アーキテクチャと FP8 を用いたエンドツーエンドの大規模言語モデル システムの高速化)
NGC コンテナー:
Llama-3.1-Nemotron-70B-Ins
truct
NGC コンテナー:
Llama-3-Swallow-70B-Instruct-v0.1
SDK:
NeMo Megatron


Deploying Fine-Tuned AI Models with NVIDIA NIM

For organizations adapting AI foundation models with domain-specific data, the ability to rapidly create and deploy fine-tuned models is key to efficiently delivering value with enterprise generative AI applications.
NVIDIA NIM
offers prebuilt, performance-optimized inference microservices for the latest AI foundation models, including
seamless deployment
of models customized using parameter-efficient fine-tuning (PEFT).
In some cases, it’s ideal to use methods like continual pretraining, DPO, supervised fine-tuning (SFT), or model merging, where the underlying model weights are adjusted directly in the training or customization process, unlike PEFT with low-rank adaptation (LoRA). In these cases, inference software configuration for the model must be updated for optimal performance given the new weights.
Rather than burden you with this often lengthy process, NIM can automatically build a
TensorRT-LLM
inference engine performance optimized for the adjusted model and GPUs in your local environment, and then load it for running inference as part of a single-step model deployment process.
In this post, we explore how to rapidly deploy NIM microservices for models that have been customized through SFT by using locally built, performance-optimized TensorRT-LLM inference engines. We include all the necessary commands as well as some helpful options, so you can try it out on your own today.
Prerequisites
To run this tutorial, you need an NVIDIA-accelerated compute environment with access to 80 GB of GPU memory and which has
git-lfs
installed.
Before you can pull and deploy a NIM microservice in an NVIDIA-accelerated compute environment, you also need an NGC API key.
Navigate to the
Meta Llama 3 8B Instruct
model listing in the NVIDIA API Catalog.
Choose
Login
at the top right and follow the instructions.
When you’re logged in, choose
Build with this NIM
on the
model page
.
Choose
Self-Hosted API
and follow either option to access NIM microservices access:
NVIDIA Developer Program membership with free access to NIM for research, development, and testing only.
The 90-day NVIDIA AI Enterprise license, which includes access to NVIDIA Enterprise Support.
After you provide the necessary details for your selected access method, copy your NGC API key and be ready to move forward with NIM. For more information, see
Launch NVIDIA NIM for LLMs
.
Getting started with NIM microservices
Provide your NGC CLI API key as an environment variable in your compute environment:
export NGC_API_KEY=<<YOUR API KEY HERE>>
You also must point to, create, and modify permissions for a directory to be used as a cache during the optimization process:
export NIM_CACHE_PATH=/tmp/nim/.cache
mkdir -p $NIM_CACHE_PATH
chmod -R 777 $NIM_CACHE_PATH
To demonstrate locally built, optimized TensorRT-LLM inference engines for deploying fine-tuned models with NIM, you need a model that has undergone customization through SFT. For this tutorial, use the
NVIDIA OpenMath2-Llama3.1-8B
model, which is a customization of
Meta’s Llama-3.1-8B
using the
OpenMathInstruct-2
dataset.
The base model must be available as a downloadable NIM for LLMs. For more information about downloadable NIM microservices, see the
NIM Type: Run Anywhere filter
in the NVIDIA API Catalog.
All you need is the weights to this model, which can be obtained in several ways. For this post, clone the model repository using the following commands:
git lfs install
git clone https://huggingface.co/nvidia/OpenMath2-Llama3.1-8B
export MODEL_WEIGHT_PARENT_DIRECTORY=$PWD
Now that you have the model weights collected, move on to the next step: firing up the microservice.
Selecting from available performance profiles
Based on your selected model and hardware configuration, the most applicable inference performance profile available is automatically selected. There are two available performance profiles for local inference engine generation:
Latency:
Focused on delivering a NIM microservice that is optimized for latency.
Throughput:
Focused on delivering a NIM microservice that is optimized for batched throughput.
For more information about supported features, including available precision, see the
Support Matrix
topic in the NVIDIA NIM documentation.
Example using an SFT model
Create a locally built TensorRT-LLM inference engine for OpenMath2-Llama3.1-8B by running the following commands:
docker run -it --rm --gpus all \
--user $(id -u):$(id -g)\
	--network=host \
	--shm-size=32GB \
	-e NGC_API_KEY \
	-e NIM_FT_MODEL=/opt/weights/hf/OpenMath2-Llama3.1-8B \
	-e NIM_SERVED_MODEL_NAME=OpenMath2-Llama3.1-8B \
-v $NIM_CACHE_PATH:/opt/nim/.cache \
-v $MODEL_WEIGHT_PARENT_DIRECTORY:/opt/weights/hf \
nvcr.io/nim/meta/llama-3.1-8b-instruct:1.3.0
The command is nearly identical to the typical command you’d use to deploy a NIM microservice. In this case, you’ve added the extra
NIM_FT_MODEL
parameter, which points to the OpenMath2-Llama3.1-8B model.
With that, NIM builds an optimized inference engine locally. To perform inference using this new NIM microservice, run the following Python code example:
from openai import OpenAI

client = OpenAI(
  base_url = "http://localhost:8000/v1",
  api_key = "none"
)

completion = client.chat.completions.create(
  model="OpenMath2-Llama3.1-8B",
  messages=[{"role":"user","content":"What is your name?"}],
  temperature=0.2,
  top_p=0.7,
  max_tokens=100,
  stream=True
)

for chunk in completion:
  if chunk.choices[0].delta.content is not None:
    print(chunk.choices[0].delta.content, end="")
Video 1. How to Deploy Fine-Tuned AI Models
Building an optimized TensorRT-LLM engine with a custom performance profile
On
supported GPUs
, you can use a similar command to spin up your NIM microservice. Follow the
Model Profile
instructions to launch your microservice and determine which profiles are accessible for it.
export IMG_NAME="nvcr.io/nim/meta/llama-3.1-8b-instruct:1.3.0"
docker run --rm --gpus=all -e NGC_API_KEY=$NGC_API_KEY $IMG_NAME list-model-profiles
Assuming you’re in an environment with two (or more) H100 GPUs, you should see the following profiles available:
tensorrt_llm-h100-bf16-tp2–pp1-throughput
tensorrt_llm-h100-bf16-tp2-pp1-latency
Re-run the command and provide an additional environment variable to specify the desired profile:
docker run --rm --gpus=all \
  -e NGC_API_KEY \
  -e NIM_FT_MODEL=/opt/weights/hf/OpenMath2-Llama3.1-8B \
  -e NIM_SERVED_MODEL_NAME=OpenMath2-Llama3.1-8B \
  -e NIM_MODEL_PROFILE=tensorrt_llm-h100-bf16-tp2-pp1-latency \
  -v $NIM_CACHE_PATH:/opt/nim/.cache \
  -v $MODEL_WEIGHT_PARENT_DIRECTORY:/opt/weights/hf \
  $IMG_NAME
Now that you’ve relaunched your NIM microservice with the desired profile, use Python to interact with the model:
from openai import OpenAI

client = OpenAI(
  base_url = "http://localhost:8000/v1",
  api_key = "none"
)

completion = client.chat.completions.create(
  model="llama-3.1-8b-instruct",
  messages=[{"role":"user","content":"What is your name?"}],
  temperature=0.2,
  top_p=0.7,
  max_tokens=100,
  stream=True
)

for chunk in completion:
  if chunk.choices[0].delta.content is not None:
    print(chunk.choices[0].delta.content, end="")
Conclusion
Whether you’re using
PEFT
or SFT methods for model customization, NIM accelerates customized model deployment for high-performance inferencing in a few simple steps. With optimized TensorRT-LLM inference engines built automatically in your local environment, NIM is unlocking new possibilities for rapidly deploying accelerated AI inferencing anywhere.
Learn more and get started today by visiting the NVIDIA
API catalog
and checking out the
documentation
. To engage with NVIDIA and the NIM microservices community, see the NVIDIA
NIM developer forum
.

NVIDIA NIM でファインチューニングされた AI モデルのデプロイ

Reading Time:
2
minutes
ドメイン固有のデータで AI 基盤モデルを適応させている企業にとって、ファインチューニングされたモデルを迅速に作成し、デプロイする能力は、企業の生成 AI アプリケーションで効率的に価値を提供するための鍵となります。
NVIDIA NIM
は、Parapeter-efficient Fine-tuning (PEFT) を用いてカスタマイズしたモデルの
シームレスなデプロイ
など、最新の AI 基盤モデル向けにビルドされたパフォーマンスを最適化した推論マイクロサービスを提供します。
場合によっては、Low-rank Adaptation (LoRA) を使用した PEFT とは異なり、継続事前学習、DPO、教師ありファインチューニング (SFT: Supervised Fine-tuning)、モデル マージなどの手法を利用し、基礎となるモデルの重みをトレーニングやカスタマイズの過程で直接調整するのが理想的です。このような場合、新しい重みを考慮した最適なパフォーマンスを実現するには、モデルの推論ソフトウェア構成を更新する必要があります。
この長時間を要するプロセスに負担を割くのではなく、NIM は、調整されたモデルと GPU に合わせて最適化した
TensorRT-LLM
推論エンジンをローカル環境でビルドし、ロードし、それを単一ステップのモデル デプロイ プロセスの一環として推論を実行できます。
この投稿では、パフォーマンスを最適化した TensorRT-LLM 推論エンジンをローカルでビルドして、SFT でカスタマイズされたモデルに対する NIM マイクロサービスを迅速にデプロイする方法を説明します。必要なコマンドと便利なオプションもご紹介しますので、是非今すぐお試しください。
前提条件
このチュートリアルを実行するには、80 GB の GPU メモリを持つ NVIDIA アクセラレーテッド コンピューティング環境と
git-lfs
のインストールが必要です。
NVIDIA アクセラレーテッド コンピューティング環境で、NIM マイクロサービスを pull してデプロイするには、NGC API キーも必要です。
NVIDIA API カタログのモデル一覧から
Meta Llama 3 8B Instruct
に移動します。
右上の
[Login]
を選択し、指示に従ってください。
ログインしたら、
モデル ページ
で
[Build with this NIM]
を選択します。
[Self-Hosted API]
を選択し、いずれかのオプションに従って、NIM マイクロサービスへアクセスします。
NVIDIA 開発者プログラムのメンバーであれば、研究、開発、テストに限り NIM に無料でアクセスすることができます。
90 日間の NVIDIA AI Enterprise ライセンスには、NVIDIA Enterprise サポートへのアクセスが含まれています。
選択したアクセス方法に必要な詳細情報を提供したら、NGC API キーをコピーして、NIM を進める準備をします。詳細については、
Launch NVIDIA NIM for LLMs
を参照してください。
NIM マイクロサービスをはじめる
利用中のコンピューティング環境の環境変数として、NGC API キーを提供します。
export NGC_API_KEY=<<YOUR API KEY HERE>>
また、最適化処理中にキャッシュとして使用するディレクトリを作成して、パーミッションを変更して、指定する必要があります。
export NIM_CACHE_PATH=/tmp/nim/.cache
mkdir -p $NIM_CACHE_PATH
chmod -R 777 $NIM_CACHE_PATH
NIM でファインチューニングされたモデルをデプロイするために、最適な TensorRT-LLM 推論エンジンをローカルでビルドする実証には、SFT によってカスタマイズしたモデルが必要です。このチュートリアルでは、
OpenMathInstruct-2
データセットを使用して、
Meta の Llama-3.1-8B
をカスタマイズした
NVIDIA OpenMath2-Llama3.1-8B
モデルを使用します。
ベース モデルは、ダウンロード可能な NIM for LLMs として利用可能でなければなりません。ダウンロード可能な NIM マイクロサービスの詳細については、NVIDIA API カタログの「
NIM Type: Run Anywhere filter
」を参照してください。
必要なのはこのモデルの重みだけで、これはさまざまな方法があります。この投稿では、以下のコマンドを使用してモデル リポジトリをクローンします。
git lfs install
git clone https://huggingface.co/nvidia/OpenMath2-Llama3.1-8B
export MODEL_WEIGHT_PARENT_DIRECTORY=$PWD
これでモデルの重みが収集できたので、次のステップのマイクロサービスの起動に進みます。
利用可能なパフォーマンス プロファイルから選択する
選択したモデルとハードウェアの構成に基づいて、利用可能なものの中から最も適切な推論パフォーマンス プロファイルが自動的に選択されます。ローカル推論エンジンの生成には、以下の 2 つのパフォーマンス プロファイルが利用できます。
レイテンシ:
レイテンシに最適化された NIM マイクロサービスの提供に重点を置きます。
スループット:
バッチ スループットに最適化された NIM マイクロサービスの提供に重点を置きます。
利用可能な精度など、サポート機能の詳細については、NVIDIA NIM ドキュメントの
サポート情報
のトピックを参照してください。
SFT モデルを使用した例
以下のコマンドを実行して、ローカル環境でビルドした OpenMath2-Llama3.1-8B 用の TensorRT-LLM 推論エンジンを作成します。
docker run -it --rm --gpus all \
    --user $(id -u):$(id -g)\
    --network=host \
    --shm-size=32GB \
    -e NGC_API_KEY \
    -e NIM_FT_MODEL=/opt/weights/hf/OpenMath2-Llama3.1-8B \
    -e NIM_SERVED_MODEL_NAME=OpenMath2-Llama3.1-8B \
    -v $NIM_CACHE_PATH:/opt/nim/.cache \
    -v $MODEL_WEIGHT_PARENT_DIRECTORY:/opt/weights/hf \
    nvcr.io/nim/meta/llama-3.1-8b-instruct:1.3.0
このコマンドは、NIM マイクロサービスをデプロイするために使用する典型的なコマンドとほぼ同じです。この場合、追加の NIM_FT_MODEL パラメーターを追加し、OpenMath2-Llama3.1-8B モデルを指しています。
これにより、NIM は最適化された推論エンジンをローカル環境でビルドします。この新しい NIM マイクロサービスを使用して推論を行うには、以下の Python コード サンプルを実行します。
from openai import OpenAI

client = OpenAI(
  base_url = "http://localhost:8000/v1",
  api_key = "none"
)

completion = client.chat.completions.create(
  model="OpenMath2-Llama3.1-8B",
  messages=[{"role":"user","content":"What is your name?"}],
  temperature=0.2,
  top_p=0.7,
  max_tokens=100,
  stream=True
)

for chunk in completion:
  if chunk.choices[0].delta.content is not None:
    print(chunk.choices[0].delta.content, end="")
動画 1. ファインチューニングされた AI モデルをデプロイする方法
カスタム パフォーマンス プロファイルで最適化された TensorRT-LLM エンジンのビルド
サポートされている GPU
なら、同様のコマンドを使用して、NIM マイクロサービスを起動できます。
モデル プロファイル
の手順に従ってマイクロサービスを起動し、どのプロファイルにアクセスできるかを確認します。
export IMG_NAME="nvcr.io/nim/meta/llama-3.1-8b-instruct:1.3.0"
docker run --rm --gpus=all -e NGC_API_KEY=$NGC_API_KEY $IMG_NAME list-model-profiles
H100 GPU を使用していると仮定すると、以下のプロファイルが利用可能であることがわかります。
tensorrt_llm-h100-bf16-tp2-pp1-latency
tensorrt_llm-h100-bf16-tp1-pp1-throughput
コマンドを再実行し、目的のプロファイルを指定する環境変数を追加します。
docker run --rm --gpus=all \
    --user $(id -u):$(id -g)\
    --network=host \
    --shm-size=32GB \
    -e NGC_API_KEY \
    -e NIM_FT_MODEL=/opt/weights/hf/OpenMath2-Llama3.1-8B \
    -e NIM_SERVED_MODEL_NAME=OpenMath2-Llama3.1-8B \
    -e NIM_MODEL_PROFILE=tensorrt_llm-h100-bf16-tp2-pp1-latency \
    -v $NIM_CACHE_PATH:/opt/nim/.cache \
    -v $MODEL_WEIGHT_PARENT_DIRECTORY:/opt/weights/hf \
    $IMG_NAME
目的のプロファイルで NIM マイクロサービスを再起動したので、Python を使用してモデルとやり取りします。
from openai import OpenAI

client = OpenAI(
  base_url = "http://localhost:8000/v1",
  api_key = "none"
)

completion = client.chat.completions.create(
  model="llama-3.1-8b-instruct",
  messages=[{"role":"user","content":"What is your name?"}],
  temperature=0.2,
  top_p=0.7,
  max_tokens=100,
  stream=True
)

for chunk in completion:
  if chunk.choices[0].delta.content is not None:
    print(chunk.choices[0].delta.content, end="")
まとめ
モデルのカスタマイズに
PEFT
または SFT を使用している場合でも、NIM は、高性能な推論のためにカスタマイズされたモデルのデプロイをわずかなステップで簡単に高速化します。最適化された TensorRT-LLM 推論エンジンをローカル環境で自動的にビルドすることで、NIM は、高速化された AI 推論をどこにでも迅速にデプロイできるよう新たな可能性を引き出しています。詳細については、
NVIDIA API カタログ
にアクセスし、NVIDIA NIM ドキュメントの
ファインチューニングされたモデルのサポート
をご覧ください。
NVIDIA NIM 開発者フォーラム
では、NVIDIA および NIM マイクロサービス コミュニティとの交流することもできます。
関連情報
GTC セッション:
Kubernetes 用 Oracle コンテナー エンジンを使用した OCI の NVIDIA Nemotron LLM のファインチューニングとデプロイ (Oracle 提供)
GTC セッション:
企業を加速: 次世代 AI デプロイを実現するツールとテクニック
GTC セッション:
NVIDIA NeMo による多様な言語での基盤となる大規模言語モデルのカスタマイズ
NGC コンテナー:
Phind-CodeLlama-34B-v2-Instruct
NGC コンテナー:
Phi-3-Mini-4K-Instruct
NGC コンテナー:
Mistral-NeMo-Minitron-8B-Instruct


Mastering LLM Techniques: Data Preprocessing

The advent of
large language models (LLMs)
marks a significant shift in how industries leverage AI to enhance operations and services. By automating routine tasks and streamlining processes, LLMs free up human resources for more strategic endeavors, thus improving overall efficiency and productivity.
Training and
customizing LLMs
for high accuracy is fraught with challenges, primarily due to their dependency on high-quality data. Poor data quality and inadequate volume can significantly reduce model accuracy, making dataset preparation a critical task for AI developers.
Datasets frequently contain duplicate documents, personally identifiable information (PII), and formatting issues. Some datasets even house toxic or harmful information that poses risks to users. Training models on these datasets without proper processing can result in higher training time and lower model quality. Another significant challenge is the scarcity of data. Model builders are running out of publicly available data to train on, prompting many to turn to third-party vendors or generate synthetic data using advanced LLMs.
In this post, we will describe data processing techniques and best practices for optimizing LLM performance by improving data quality for training. We will introduce
NVIDIA NeMo Curator
and how it addresses these challenges, demonstrating real-world data processing use cases for LLMs.
Text processing pipelines and best practices
Dealing with the preprocessing of large data is nontrivial, especially when the dataset consists of mainly web-scraped data which is likely to contain large amounts of ill-formatted, low-quality data.
Figure 1. Text processing pipelines that can be built using NeMo Curator
Figure 1 shows a comprehensive text processing pipeline, including the following steps at a high-level:
Download the dataset from the source and extract to a desirable format such as JSONL.
Apply preliminary text cleaning, such as Unicode fixing and language separation.
Apply both standard and custom-defined filters to the dataset based on specific quality criteria.
Perform various levels of deduplication (exact, fuzzy, and semantic).
Selectively apply advanced quality filtering, including model-based quality filtering, PII redaction, distributed data classification, and task decontamination.
Blend curated datasets from multiple sources to form a unified dataset.
The sections below dive deeper into each of these stages.
Download and extract text
The initial step in data curation involves downloading and preparing datasets from various common sources such as Common Crawl, specialized collections such as arXiv and PubMed, or private on-prime datasets, each potentially containing terabytes of data.
This crucial phase requires careful consideration of storage formats and extraction methods, as publicly hosted datasets often come in compressed formats (for example, .warc.gz, tar.gz, or zip files) that need to be converted to more manageable formats (such as .jsonl or .parquet) for further processing.
Preliminary text cleaning
Unicode fixing and language identification represent crucial early steps in the data curation pipeline, particularly when dealing with large-scale web-scraped text corpora. This phase addresses two fundamental challenges: improperly decoded Unicode characters, and the presence of multiple languages within the dataset.
Unicode formatting issues often arise from incorrect character encoding or multiple encoding/decoding cycles. Common problems include special characters appearing as garbled sequences (for example, “café” showing as “cafÃ©”). Language identification and separation are equally important, especially for curators who are interested in curating monolingual datasets. Moreover, some of the data curation steps such as heuristic filtering, and model-based quality classifiers are language-specific.
This preliminary preprocessing step ensures clean, properly encoded text in identified languages, forming the foundation for all subsequent curation steps.
Heuristic filtering
Heuristic filtering employs rule-based metrics and statistical measures to identify and remove low-quality content.
The process typically evaluates multiple quality dimensions, such as document length, repetition patterns, punctuation distribution, and structural integrity of the text. Common heuristic filters include:
Word count filter:
Filters out snippets that are too brief to be meaningful or suspiciously long.
Boilerplate string filter:
Identifies and removes text containing excessive boilerplate content.
N-gram repetition filter:
Identifies repeated phrases at different lengths and removes documents with excessive repetition that might indicate low-quality or artificially generated content.
For heuristic filtering, the best practice is to implement a cascading approach. This enables more nuanced quality control while maintaining transparency in the filtering process.  For improved performance, batch filtering can be implemented to process multiple documents simultaneously, significantly reducing computation time when dealing with large-scale datasets.
Deduplication
Deduplication is essential for improving model training efficiency, reducing computational costs, and ensuring data diversity. It helps prevent models from overfitting to repeated content and improves generalization. The process can be implemented through three main approaches: exact, fuzzy, and semantic deduplication. These form a comprehensive strategy for handling different types of duplicates in large-scale datasets, from identical copies to conceptually similar content.
Exact deduplication
Exact deduplication focuses on identifying and removing completely identical documents. This method generates hash signatures for each document and groups documents by their hashes into buckets, keeping only one document per bucket. While this method is computationally efficient, fast and reliable, it’s limited to detecting perfectly matching content and may miss semantically equivalent documents with minor variations.
Fuzzy deduplication
Fuzzy deduplication addresses near-duplicate content using MinHash signatures and Locality-Sensitive Hashing (LSH) to identify similar documents.
The process involves the following steps:
Compute MinHash signatures for documents.
Use LSH to group similar documents into buckets. One document might belong to one or more buckets.
Compute Jaccard similarity between documents within the same buckets.
Based on the Jaccard similarity, transform the similarity matrix to a graph and identify connected components in the graph.
Documents within a connected component are considered fuzzy duplicates.
Remove identified duplicates from the dataset.
This method is particularly valuable for identifying content with minor modifications, detecting partial document overlaps, and finding documents with different formatting but similar content.  It strikes a balance between computational efficiency and duplicate detection capability.
Semantic deduplication
Semantic deduplication represents the most sophisticated approach, employing advanced embedding models to capture semantic meaning combined with clustering techniques to group semantically similar content. Research has shown that semantic deduplication can effectively reduce dataset size while maintaining or improving model performance. It’s especially valuable for identifying paraphrased content, translated versions of the same material, and conceptually identical information.
Semantic deduplication consists of the following steps:
Each data point is embedded using a pretrained model.
The embeddings are clustered into k clusters using k-means clustering.
Within each cluster, pairwise cosine similarities are computed.
Data pairs with cosine similarity above a threshold are considered semantic duplicates.
From each group of semantic duplicates within a cluster, one representative datapoint is kept and the rest are removed.
Model-based quality filtering
Model-based quality filtering employs various types of models to evaluate and filter content based on quality metrics. The choice of model type significantly impacts both the effectiveness of filtering and the computational resources required, making it crucial to select the appropriate model for specific use cases.
Different types of models that can be used for quality filtering include:
N-gram based classifiers:
The simplest approach uses n-gram based bag-of-words classifiers like fastText, which excel in efficiency and practicality, as they require minimal training data (100,000 to 1,000,000 samples).
BERT-style classifiers:
BERT-style classifiers represent a middle-ground approach, offering better quality assessment through Transformer-based architectures. They can capture more complex linguistic patterns and contextual relationships, making them effective for quality assessment.
LLMs:
LLMs provide the most sophisticated quality assessment capabilities, leveraging their extensive knowledge to evaluate text quality. While they offer superior understanding of content quality, they have significant computational requirements thus they are best suited for smaller-scale applications, such as fine-tuning datasets.
Reward models:
Reward models represent a specialized category designed specifically for evaluating conversational data quality. These models can assess multiple quality dimensions simultaneously but similar to LLMs, they have significant computational requirements.
The optimal selection of quality filtering models should consider both the dataset scale and available computational resources. For large-scale pretraining datasets, combining lightweight models for initial filtering with advanced models for final quality assessment often provides the best balance of efficiency and effectiveness. For smaller, specialized datasets where quality is crucial, using models like LLMs or reward models becomes more feasible and beneficial.
PII redaction
Personally Identifiable Information (PII) redaction involves identifying and removing sensitive information from datasets to protect individual privacy and ensure compliance with data protection regulations.
This process is particularly important when dealing with datasets that contain personal information, from direct identifiers like names and social security numbers to indirect identifiers that could be used to identify individuals when combined with other data.
Modern PII redaction employs various techniques to protect sensitive information, including:
Replacing sensitive information with symbols (for example, XXX-XX-1234 for U.S. Social Security Numbers) while maintaining data format and structure.
Substituting sensitive data with non-sensitive equivalents that maintain referential integrity for analysis purposes.
Eliminating sensitive information when its presence is not necessary for downstream tasks.
Overall, PII redaction helps maintain data privacy, comply with regulations, and build trust with users while preserving the utility of their datasets for training and analysis purposes.
Distributed data classification
Data classification plays a vital role in data curation. This process helps organize and categorize data based on various attributes such as domain and quality, ensuring data is well-balanced and representative of different knowledge domains.
Domain classification helps LLMs understand the context and specific domain of input text by identifying and categorizing content based on subject matter. The domain information serves as valuable auxiliary data, enabling developers to build more diverse training datasets while identifying and filtering out potentially harmful or unwanted content. For example, using the AEGIS Safety Model, which classifies content into 13 critical risk categories, developers can effectively identify and filter harmful content from training data.
When dealing with pretraining corpora that often contain billions of documents, running inference for classification becomes computationally intensive and time-consuming. Therefore, distributed data classification is necessary to overcome these challenges. This is achieved by chunking the datasets across multiple GPU nodes to accelerate the classification task in a distributed manner.
Task decontamination
After training, LLMs are usually evaluated by their performance on downstream tasks consisting of unseen test data. Downstream task decontamination is a step that addresses the potential leakage of test data into training datasets, which can provide misleading evaluation results. The decontamination process typically involves several key steps:
Identifying potential downstream tasks and their test sets.
Converting test data into n-gram representations.
Searching for matching n-grams in the training corpus.
Removing or modifying contaminated sections while preserving document coherence.
This systematic approach helps ensure the effectiveness of decontamination while minimizing unintended impacts on data quality, ultimately contributing to more reliable model evaluation and development.
Blending and shuffling
Data blending and shuffling represent the final steps in the data curation pipeline, combining multiple curated datasets while ensuring proper randomization for optimal model training. This process is essential for creating diverse, well-balanced training datasets that enable better model generalization and performance. Data blending involves merging data from multiple sources into a unified dataset, creating more comprehensive and diverse training data. The blending process is implemented using two approaches:
Online: Data combination occurs during training
Offline: Datasets are combined before training
Each approach offers distinct advantages depending on the specific requirements of the training process and the intended use of the final dataset.
Synthetic data generation
Having navigated the intricacies of the preprocessing stage, we now confront a formidable challenge in the realm of LLM development: the scarcity of data. The insatiable appetite of LLMs for vast training datasets, even for fine-tuning purposes, frequently outstrips the availability of domain-specific or language-particular data. To this end,
synthetic data generation (SDG)
is a powerful approach that leverages LLMs to create artificial datasets that mimic real-world data characteristics while maintaining privacy and ensuring data utility. This process uses external LLM services to generate high-quality, diverse, and contextually relevant data that can be used for pretraining, fine-tuning, or evaluating other models.
SDG empowers LLMs by enabling adaptation to low-resource languages, supporting domain specialization, and facilitating knowledge distillation across models, making it a versatile tool for expanding model capabilities. SDG has become particularly valuable in scenarios where real data is scarce, sensitive, or difficult to obtain.
Figure 2. General synthetic data generation architecture with NeMo Curator
The synthetic data pipeline encompasses three key stages: Generate, Critique, and Filter.
Generate:
Use prompt engineering to generate synthetic data for various tasks. Taking
Nemotron-4
as an example, SDG is applied to generate training data for five different types of tasks: open-ended QA, closed-ended QA, writing assignments, coding, and math problems.
Critique:
Use methods like LLM reflection, LLM-as-judge, reward model inference, and other agents to evaluate the quality of synthetic data. The evaluation results can be used as feedback to SDG LLM to generate better results or filter out low quality data. A prime example is the
Nemotron-4-340B reward NIM
, which assesses data quality through five key attributes: Helpfulness, Correctness, Coherence, Complexity, and Verbosity. By setting appropriate thresholds for these attribute scores, the filtering process ensures that only high-quality synthetic data is retained, while filtering out low-quality or inappropriate content.
Filter:
Steps like deduplication and PII redaction to further improve SDG data quality.
Note, however, SDG is not suitable in all cases. Hallucinations from external LLMs can introduce unreliable information, compromising data integrity. Additionally, the generated data’s distribution may not align with the target distribution, potentially leading to poor real-world performance. In such cases, using SDG could actually harm the system’s effectiveness rather than improve it.
Data processing for building sovereign LLMs
As noted previously, open-source LLMs excel in English but struggle with other languages, especially those of Southeast Asia. This is primarily due to a lack of training data in these languages, limited understanding of local cultures, and insufficient tokens to capture unique linguistic structures and expressions.
To fully meet customer needs, enterprises in non-English-speaking countries must go beyond generic models and customize them to capture the nuances of their local languages, ensuring a seamless and impactful customer experience. For example, using NeMo Curator, Viettel Solutions processed
high-quality Vietnamese data
to increase accuracy by 10%, reduce the dataset size by 60% and accelerate training time by 3x.
The main steps for this use case are:
Download several Vietnamese and multilingual datasets (Wikipedia, Vietnamese news corpus,
OSCAR
, and C4) and convert to Parquet for efficient handling and processing of large datasets.
Combine, standardize, and shard into a single dataset
Apply unicode reformatting, exact deduplication, quality filtering (heuristic and classifier-based).
You can
follow along with the full tutorial
.
Improve data quality with NVIDIA NeMo Curator
So far, we have discussed the importance of data quality in improving the accuracy of LLMs and explored various data processing techniques. Developers can now try these techniques directly through
NeMo Curator
. It provides a customizable and modular interface that enables developers to build on top of it easily.
NeMo Curator uses NVIDIA RAPIDS GPU-accelerated libraries like cuDF, cuML, and cuGraph, and Dask to speed up workloads on multinode multi-GPUs, reducing processing time and scale as needed. For example, by using GPUs to accelerate the data processing pipelines,
Zyphra reduced the total cost of ownership (TCO)
by 50% and processed the data 10x faster (from 3 weeks to 2 days).
To get started, check out the
NVIDIA/NeMo-Curator GitHub repository
and available
tutorials
that cover various data curation workflows, such as:
Data processing for pretraining
Data processing for customization
SDG pipelines
You can also gain access through a
NeMo framework container
and request enterprise support with an
NVIDIA AI Enterprise
license.

LLM テクニックの習得: データの前処理

Reading Time:
2
minutes
大規模言語モデル (LLM)
の出現は、企業が AI を活用して業務とサービスを強化する方法に大きな変化をもたらしました。LLM は日常的な作業を自動化し、プロセスを合理化することで、人的リソースをより戦略的な取り組みに割り当てることで、全体的な効率性と生産性を向上させます。
LLM を高精度にトレーニングおよび
カスタマイズ
するには、高品質なデータが必要となるため、多くの課題を伴います。データの質が低く、量が十分でないと、モデルの精度が大幅に低下する可能性があるため、AI 開発者にとってデータセットの準備は重要な作業の 1 つとなっています。
データセットには往々にして重複したドキュメント、個人を特定できる情報 (PII)、フォーマットに関する問題が存在します。データセットの中には、ユーザーにリスクをもたらす有害な情報や不適切な情報が含まれているものさえあります。適切な処理を行わずにこういったデータセットでモデルをトレーニングすると、トレーニング時間が長引いたり、モデルの品質が低下する場合があります。もう 1 つの大きな課題はデータの不足です。モデル開発者はトレーニング用の公開データを使い果たしつつあり、多くの人々がサードパーティのベンダーに依頼したり、高度な LLM を使用して合成データを生成したりするようになっています。
この記事では、トレーニング用のデータの品質を向上することで LLM のパフォーマンスを最適化するためのデータ処理テクニックとベスト プラクティスについて説明します。また、
NVIDIA NeMo Curator
の概要および前述した課題への対処方法を説明し、LLM の実際のデータ処理のユース ケースもご紹介します。
テキスト処理パイプラインとベスト プラクティス
大規模データの前処理は容易ではありません。特に、データセットが主にWeb スクレイピングされたデータで構成されており、大量の不適切なフォーマットの低品質データが含まれている可能性が高い場合はなおさらです。
図 1. NeMo Curator を使用して構築できるテキスト処理パイプライン
図 1 は、以下の手順を含む包括的なテキスト処理パイプラインの概要を示しています。
ソースからデータセットをダウンロードし、JSONL などの望ましいフォーマットで抽出します。
Unicode の修正や言語による分類など、予備的なテキスト クリーニングを適用します。
特定の品質基準に基づいて、標準的なフィルターとカスタム定義のフィルターの両方をデータセットに適用します。
さまざまなレベルの重複排除 (厳密、曖昧、意味的) を実行します。
モデルベースの品質フィルタリング、個人情報 (PII) の削除、(分散処理による) データ分類、下流タスクの汚染除去などの高度な品質フィルタリングを必要に応じて選択的に適用します。
複数のソースから収集され、精選されたデータセットを一体化し、統合したデータセットを作成します。
以下のセクションでは、これらの各段階について詳しく説明します。
テキストをダウンロードして抽出
データ キュレーションの最初のステップでは、 Common Crawl のような、さまざまな一般的なソース、arXiv や PubMed などの専門的なコレクション、自社保有のプライベート データなどからデータセットをダウンロードして準備します。これらのデータセットには、それぞれテラバイト単位のデータが含まれている可能性があります。
この重要なフェーズでは、保存形式と抽出方法を慎重に検討する必要があります。一般に公開されホストされているデータセットは圧縮形式 (例: .warc.gz、tar.gz、zip ファイル) で提供されることが多いため、後続の処理のためにより扱いやすい形式 (.jsonl や .parquet など) に変換する必要があります。
予備的なテキスト クリーニング
Unicode の修正と言語による分類は、特に大規模な Web スクレイピングによるテキスト コーパスを扱う場合、データ キュレーション パイプラインの重要な初期ステップです。このフェーズでは、不適切にデコードされた Unicode 文字と、データセット内に複数の言語が存在するという 2 つの基本的な課題に対処します。
Unicode 形式に関する問題は、多くの場合、文字エンコードの誤りや、エンコード/デコード サイクルが複数回実行されることによって発生します。よくある問題としては、特殊文字が文字化けした文字列 (例:「café」が「cafÃ©」と表示される) として表示されることが挙げられます。言語の識別と分類は、特に単一言語のデータセットのキュレーションに関心のある開発者にとっては同様に重要です。さらに、ヒューリスティック フィルタリング、モデルベースの品質分類器などのデータ キュレーションのステップの一部は言語に依存しています。
この予備的な前処理ステップでは、識別された言語で適切にエンコードされたクリーンなテキストが確保され、その後のキュレーションステップの基盤となります。
ヒューリスティック フィルタリング
ヒューリスティック フィルタリングでは、ルールベースの評価指標と統計的尺度を使用して、低品質なコンテンツを特定し、削除します。
このプロセスは通常、ドキュメントの長さ、繰り返しパターン、句読点の分布、テキストの構造的整合性など、複数の品質基準で評価されます。一般的なヒューリスティック フィルターには以下のようなものがあります。
単語数フィルター:
意味をなさないほど短すぎる、または疑わしいほどに長すぎるテキストをフィルタリングします。
定型文フィルター:
過剰な定型文を含むテキストを特定し、削除します。
N-gram 反復フィルター:
異なる長さで繰り返されるフレーズを特定し、低品質または人工的に生成されたコンテンツである可能性がある過剰な反復を含む文書を削除します。
ヒューリスティック フィルタリングの場合は、カスケード アプローチを採るのが最善の方法です。これにより、フィルタリング プロセスの透明性を維持しながら、より繊細な品質管理が可能になります。処理パフォーマンスを向上させるために、バッチ フィルタリングを採用して複数のドキュメントを同時に処理すると大規模なデータセットを扱う際の計算時間を大幅に短縮することができます。
重複排除
重複排除は、モデルのトレーニング効率の向上、計算コストの削減、データの多様性の確保に不可欠です。繰り返し出現するコンテンツにモデルが過剰適合するのを防ぎ、汎用性を高めます。このプロセスは、厳密、曖昧、意味という 3 つの主な重複排除アプローチを通じて実装できます。これらは、同一のコピーから概念的に類似したコンテンツまで、大規模データセット内の異なるタイプの重複を処理する包括的な戦略を形成します。
厳密な重複排除
厳密な重複排除は、完全に同一のドキュメントを識別し、削除することに重点を置いています。この方法では、ドキュメントごとにハッシュ署名を生成し、ハッシュごとにドキュメントをグループ化してバケットに格納し、バケットごとに 1 つのドキュメントのみを残します。この方法は計算効率が高く、高速かつ信頼性が高いのですが、完全に一致するコンテンツの検出に限定されるため、意味的には同等なのにわずかに異なる文書を見逃す可能性があります。
曖昧な重複排除
曖昧な重複排除は、MinHash 署名と局所性鋭敏型ハッシュ化 (LSH: Locality-Sensitive Hashing) を使用して、類似したドキュメントを識別し、ほぼ重複するコンテンツに対処します。
このプロセスには、以下のステップが含まれます。
ドキュメントの MinHash 署名を計算します。
LSH を使用して、類似したドキュメントをバケットにグループ化します。1 つのドキュメントが 1 つ以上のバケットに属する場合もあります。
同じバケット内のドキュメント間で Jaccard 類似度を計算します。
Jaccard 類似度に基づいて、類似度行列をグラフに変換し、グラフ内の連結成分を特定します。
連結成分内のドキュメントは曖昧な重複と見なされます。
特定した重複をデータセットから削除します。
この方法は、軽微な変更が加えられたコンテンツの特定、部分的なドキュメントの重複の検出、異なるフォーマットであるが類似したコンテンツを持つドキュメントの検索に特に有用です。計算効率と重複検出能力のバランスが取れています。
意味的な重複排除
意味的な重複排除は、最も洗練されたアプローチであり、高度な埋め込みモデルを使用してセマンティックな意味を捉え、クラスタリング技術と組み合わせて意味的に類似したコンテンツをグループ化します。研究では、意味的な重複排除は、モデルのパフォーマンスを維持または改善しながら、データセットのサイズを効果的に縮小できることが示されています。言い換えられたコンテンツ、同じ素材の翻訳版、概念的に同一の情報を特定するのに特に有用です。
意味による重複排除は、以下のステップで構成されます。
各データ ポイントが、事前学習済みモデルを使用して埋め込まれます。
埋め込みは、k-means を使用して k 個のクラスターにグループ化されます。
各クラスター内で、ペアごとのコサイン類似度が計算されます。
閾値を超えるコサイン類似度を有するデータ ペアは、意味の重複と見なされます。
クラスター内の意味的な重複の各グループから、1 つの代表的なデータポイントが保持され、残りは削除されます。
モデルベースの品質フィルタリング
モデルベースの品質フィルタリングでは、さまざまな種類のモデルを使用して、品質指標に基づいてコンテンツを評価してフィルタリングします。モデルの種類の選択は、フィルタリングの有効性と必要な計算リソースの両方に大きな影響を及ぼすため、特定のユース ケースに適切なモデルを選択することが重要です。
品質フィルタリングに使用できるモデルには、以下の種類があります。
N-gram ベースの分類器:
最も単純なアプローチは、fastText のような N-gram ベースの Bag-of-Words 分類器を使用する方法です。必要なトレーニング データ (10 万～100 万サンプル) が最も少なく済むため、効率性と実用性に優れています。
BERT スタイルの分類器:
BERT スタイルの分類器は中間的なアプローチであり、Transformer ベースのアーキテクチャを通じてより質の高い評価を提供します。より複雑な言語パターンや文脈上の関係を捉えることができ、品質評価に効果的です。
LLM:
LLM は、テキストの品質評価に幅広い知識を活用し、最も洗練された品質評価機能を提供します。コンテンツの品質をより深く理解できますが、計算要件も高いため、ファインチューニング用のデータセットなど、小規模なアプリケーションに向いています。
報酬モデル:
報酬モデルは、会話データの品質を評価に特化し設計された専門カテゴリです。これらのモデルは複数の品質基準を同時に評価できますが、LLM と同じく高い計算要件が求められます。
最適な品質フィルタリング モデルの選択には、データセットの規模と利用可能な計算リソースの両方を考慮する必要があります。大規模な事前学習データセットの場合、初期フィルタリングには軽量なモデルを使用し、最終的な品質評価には高度なモデルを組み合わせることで、効率性と有効性のバランスが得られます。品質が重要となる小規模で専門的なデータセットの場合は、LLM や報酬モデルなどのモデルを使用することが、より実現的で有益となります。
PII の削除
個人を特定できる情報 (PII) の削除には、個人のプライバシーを保護し、データ保護規制に対する遵守を確実にするために、データセット内の機密情報を識別および削除することが含まれます。
このプロセスは、氏名や社会保障番号などの直接的な識別子から、他のデータと組み合わせることで個人を識別できる間接的な識別子まで、個人情報を含むデータセットを扱う場合には特に重要です。
最新の PII 削除では、機密情報を保護するために、以下を含むさまざまな技術が用いられています。
データ形式と構造を維持しながら、機密情報を記号に置き換える (たとえば、米国社会保障番号の場合 XXX-XX-1234 に置き換える)。
分析の目的で参照整合性を維持しながら、機密データを機密でない同等のデータに置き換える。
下流タスクに必要でない場合、その機密情報を削除する。
全体として PII の削除は、データのプライバシーを保護し、規制を遵守し、トレーニングと分析の目的でデータセットの有用性を維持しながら、ユーザーと信頼関係を構築するのに役立ちます。
(分散処理による) データ分類
データ分類は、データ キュレーションにおいて重要な役割を果たします。このプロセスでは、ドメインや品質など多様な属性に基づいてデータを整理し、分類することでデータのバランスを取り、さまざまな知識ドメインを代表するものとなるようにします。
ドメイン分類は、主題に基づいてコンテンツを識別してカテゴリー分けすることで、LLM が入力テキストのコンテキストや特定のドメインを理解するのに役立ちます。ドメイン情報は、開発者が潜在的に有害または不要なコンテンツを特定し、フィルタリングしながら、より多様なトレーニング データセットを構築することを可能にする貴重な補助的情報となります。たとえば、コンテンツを 13 の重大なリスク カテゴリに分類する AEGIS Safety Model を使用することで、開発者はトレーニング データから有害なコンテンツを効果的に識別し、フィルタリングすることができます。
数十億ものドキュメントが含まれていることが多い事前学習コーパスを扱う場合、分類を行うための推論を実行するのに多くの計算処理と時間が必要となります。したがって、これらの課題を克服するには、分散処理が適用できるデータ分類が必要です。これは、データセットを複数の GPU ノードに分割することで、分類タスクを高速化することによって実現されます。
下流タスクの汚染除去
トレーニングの後、LLM は通常、見えないテスト データで構成される下流タスクのパフォーマンスによって評価されます。下流タスクの汚染除去は、テスト データがトレーニング データセットに混入、漏洩する可能性に対処するステップです。これは意図しない評価結果をもたらすリスクを抑えます。汚染除去プロセスには、通常、以下の主要なステップが含まれます。
潜在的な下流タスクとそのテスト セットを特定します。
テスト データを N-gram 表現に変換します。
トレーニング コーパスで一致する N-gram を検索します。
ドキュメントの整合性を維持しながら、汚染されたセクションを削除または修正します。
この体系的なアプローチは、データの品質に対する意図しない影響を最小限に抑えながら、汚染除去の効果を確実なものにして、最終的には、より信頼性の高いモデルの評価と開発に貢献します。
ブレンドとシャッフル
データのブレンドとシャッフルは、データ キュレーション パイプラインにおける最終ステップであり、複数のキュレーションされたデータセットを組み合わせると同時に適切なランダム性を確保し、最適なモデル トレーニングを実現します。このプロセスは、モデルの一般化とパフォーマンスを向上させる、多様でバランスの取れたトレーニング データセットを作成する上で不可欠です。データのブレンドでは、複数のソースからのデータを統合して単一のデータセットに結合し、より包括的で多様なトレーニング データを作成します。ブレンド プロセスは、次の 2 つのアプローチを使用して実装されます。
オンライン: トレーニング中にデータが結合される
オフライン: トレーニング前にデータセットが結合される
それぞれのアプローチには、トレーニング プロセスの特定の要件と最終的なデータセットの使用目的に応じて異なる利点があります。
合成データの生成
前処理フェーズの複雑なプロセスを終えましたが、現在、LLM 開発の分野ではデータの不足という大きな課題に直面しています。LLM が学習用データセットを大量に必要とするのは、チューニングを目的とする場合でも同様であり、その飽くなき要求は、特定のドメインや言語に特化したデータの入手可能性を上回ることも少なくありません。この問題に対処する
合成データ生成 (SDG: Synthetic Data Generation)
は、LLM を活用して、プライバシーの保護とデータの有用性を確保しながら、現実のデータ特性を模倣した人工的なデータセットを生成する強力なアプローチです。このプロセスでは外部 LLM サービスを使用して、事前学習、ファインチューニング、他のモデルの評価に使用できる、高品質で多様かつ文脈的に関連性の高いデータを生成します。
SDG は、低リソース言語に LLM が適応できるようにすることで、ドメインの専門性をサポートし、モデル間の知識の抽出を促進し、モデル機能を拡張する汎用的なツールになります。SDG は、特に実データが不足していたり、機密であったり、取得するのが困難だったりするシナリオにおいて、重要な存在となっています。
図 2. NeMo Curator による一般的な合成データ生成アーキテクチャ
合成データ パイプラインには、生成、批評、フィルターの 3 つの主要なステップがあります。
生成:
プロンプト エンジニアリングを使用して、さまざまなタスク用の合成データを生成します。
Nemotron-4
を例にとると、SDG は、5 種類の異なるタスク (自由形式 QA、選択式 QA、記述式課題、コーディング、数学問題) のトレーニング データを生成するために適用されます。
批評:
LLM Reflection、LLM-as-judge、報酬モデル推論、その他のエージェントなどの手法を使用して、合成データの品質を評価します。評価結果は SDG LLM へのフィードバックとして使用し、より良い結果を生成したり、低品質データをフィルタリングしたりすることができます。代表的な例は
Nemotron-4-340B reward NIM
です。これは、5 つの主要な属性、すなわち Helpfulness (有用性)、Correctness (正確性)、Coherence (一貫性)、Complexity (複雑性)、Verbosity (冗長性) を通じてデータの品質を評価します。これらの属性スコアに適切な閾値を設定することで、フィルタリング処理では、低品質または不適切なコンテンツを除外しながら、高品質な合成データのみが保持されるようになります。
フィルター:
重複排除や PII の削除などのステップで、SDG データの品質をさらに向上させます。
ただし、SDG がすべてのケースに適しているわけではないことに注意してください。外部 LLM による幻覚は、信頼性の低い情報をもたらし、データの整合性を損なう可能性があります。加えて、生成されたデータの分布がターゲットの分布と一致しない可能性があり、現実世界のパフォーマンスに悪影響を及ぼす可能性があります。そのような場合は、SDG を使用することで、システムの効率性を改善するどころか、むしろ低下させる可能性があります。
ソブリン AI LLM 構築のためのデータ処理
オープンソース LLM は英語では優れていますが、その他の言語、特に東南アジアの言語では苦戦しています。この主な原因は、これらの言語のトレーニング データの不足、現地の文化に対する理解が限られていること、独自の言語構造と表現を捉えるのに十分なトークンが不足していることです。
英語圏以外の国々の企業は、顧客のニーズを完全に満たすため、汎用モデルにとどまらず、現地の言語のニュアンスを捉えるためにモデルをカスタマイズし、シームレスでインパクトのある顧客体験を確保する必要があります。例えば、Viettel Solutions は、NeMo Curator を使用して、
高品質なベトナム語データ
を処理し、精度を 10% 向上させ、データセットのサイズを 60% 削減し、トレーニングを 3 倍高速化しました。
このユース ケースの主な手順は次のとおりです。
いくつかのベトナム語および多言語データセット (Wikipedia、ベトナム語ニュース コーパス、
OSCAR
、C4) をダウンロードし、大規模なデータセットを効率的に処理するために、Parquet に変換します。
複数のデータセットを結合、標準化し、単一のデータセットにシャードします。
Unicode の再フォーマット、厳密な重複排除、品質フィルタリング (ヒューリスティックおよび分類器ベース) を適用します。
詳細は、この
チュートリアル
を参照してください。
NVIDIA NeMo Curator によるデータの品質向上
ここまで、LLM の精度向上におけるデータ品質の重要性について、そしてさまざまなデータ処理手法について説明してきました。開発者は、
NeMo Curator
を介して直接これらの手法を試すことができます。NeMo Curator は、カスタマイズ可能なモジュール式のインターフェイスを提供しているため、開発者はそれをベースに簡単に構築することができます。
NeMo Curator は、cuDF、cuML、cuGraph、Dask などの NVIDIA RAPIDS GPU で高速化されたライブラリを使用して、マルチノード、マルチ GPU におけるワークロードを高速化し、必要に応じてスケールさせ、処理時間を削減できます。例えば、GPU を使用してデータ処理のパイプラインを高速化することで、
Zyphra は総所有コスト (TCO)
を 50% 削減し、データを 10 倍高速に処理しています (3 週間から 2 日間)。
まずは、
NVIDIA/NeMo-Curator GitHub リポジトリ
と、以下のさまざまなデータ キュレーションのワークフローを網羅している
チュートリアル
をご覧ください。
事前学習のためのデータ処理
カスタマイズのためのデータ処理
SDG パイプライン
また、
NeMo フレームワーク コンテナー
を介してアクセスし、
NVIDIA AI Enterprise
ライセンスでエンタープライズ サポートをリクエストすることもできます。
関連情報
GTC セッション:
セキュアなエンタープライズ データでカスタム LLM アプリを数分で構築する
GTC セッション:
LLM インフラの構築、トレーニング速度の高速化、生成 AI イノベーションの推進のためのエンドツーエンドのソリューションの設計 (Aivres 提供)
NGC コンテナー:
genai-llm-playground
NGC コンテナー:
rag-application-query-decomposition-agent
ウェビナー:
AI による医療ワークフローの変革: CLLM を深く掘り下げる