投稿

11月, 2024の投稿を表示しています

OCI IAM Microsoft Active Directoryブリッジでの統合の問題のトラブルシューティング (2024/12/01)

イメージ
OCI IAM Microsoft Active Directoryブリッジでの統合の問題のトラブルシューティング (2024/12/01) https://blogs.oracle.com/cloud-infrastructure/post/integration-oci-iam-ms-active-directory-bridge 投稿者: Ranjini Rajendran | Senior Cloud Engineer Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)は、Microsoft Active Directory (AD)ブリッジを提供します。これにより、組織はアイデンティティの認可ソースとしてADを維持しながら、それらのアイデンティティがADと直接統合されていないシステムおよびアプリケーションにアクセスできるようになります。ブリッジは、オンプレミスAD環境とOCI IAM間の接続を確立します。この接続により、OCI IAMアイデンティティ・ドメインへの追加、更新または削除など、AD内のユーザーまたはグループ・レコードに加えられた変更を同期できます。 Microsoft ADブリッジの初期設定中に発生した最も一般的なエラーは、同期に関連しています。このブログ投稿では、ソース・エンドポイントおよびターゲット・エンドポイントへの正常な接続の確立に役立つ重要な情報、ヒントおよび有用なリンクを提供します。続行する前に、「 Microsoft Active Directory (AD)ブリッジについて 」に記載されているガイドラインを確認して、ADブリッジ接続を設定することをお薦めします。 ユースケース1: グループは同期していません 同期の問題の1つは、ユーザーが同期するが、対応するグループは同期しないことです。このような場合、ログに「ERROR IDBridge - GetResponseAsync: The server cannot handle directory requests」などのエラーが表示されることがあります。次のいずれかのトラブルシューティング方法を使用して、原因を特定します。 ディレクトリ統合ページで、組織単位の構成を確認します。ユーザー...

Pythonを使用したテナンシ間でのOCIコンピュートおよびボリュームの移行の簡素化 (2024/11/30)

イメージ
Pythonを使用したテナンシ間でのOCIコンピュートおよびボリュームの移行の簡素化 (2024/11/30) https://blogs.oracle.com/cloud-infrastructure/post/simplify-migration-oci-compute-volume-python 投稿者: Meghashree N | solution Engineer テナンシ間でのコンピュート・リソースおよびボリュームの移行は、複雑なタスクになる可能性があります。ただし、適切にテストされたプロセスを利用することで、テナンシ間でわずかなダウンタイムで安全にデータを移行できます。移行するデータが大きい場合はどうなりますか。複数の仮想マシン(VM)および数百のブロック・ボリュームにまたがるため、プロセス全体がさらに困難になり、さらに複雑になります。 このブログ投稿では、Pythonを使用して移行プロセスの様々なタスクを簡素化し、関連するプロセスと使用するスクリプトについて簡単に説明します。テナンシ間でデータを移動したいお客様を支援するために、次の機能を示します。 異なるサービス・プロバイダなどの運用上の理由やビジネス上の理由により、VMやデータを新しいテナンシに移行 ランサムウェア攻撃からのデータの保護 複数の顧客テナンシ間でのVMの移行 この場合、次のアーキテクチャに示すように、VMとボリュームは2つの異なるテナンシ間で移動されます。 前提条件 テナンシ間でバックアップをリストアするには、事前定義済のポリシーが必要です。これらのポリシーは、OCIアイデンティティ・ポリシーによって制御されます。許可ポリシーは古いテナンシで定義する必要があり、認証ポリシーは新しいテナンシで定義する必要があります。 許可ポリシーには、次の情報が含まれます。 Define tenancy NewTenancy as <new_tenancy_ocid> Define group NewTenancyIdentityGroup as <new_tenancy_group_ocid> Admit group NewTenancyIdentityGroup of tenancy NewTenancy to read boot-volume-backups in t...

Agentic AI: 人工知能の次の進化 (2024/11/28)

イメージ
Agentic AI: 人工知能の次の進化 (2024/11/28) https://blogs.oracle.com/ai-and-datascience/post/agentic-ai-the-next-evolution-of-ai 投稿者: Barry Mostert | Senior Director, Artificial Intelligence and Analytics 人工知能(AI)は急速に進化し、業界を変革し、働き方を再定義しています。従来のAIシステムは印象的でしたが、エージェントAIと呼ばれる新しいAIの波が、ビジネス・プロセスの革命を支援します。このブログ記事は、エージェントAIの世界について詳しく説明し、その定義、潜在的なビジネス・アプリケーション、および組織がその重要性を理解することが重要な理由を探ります。 Agentic AIとは Agentic AIを理解するには、まず、新たな形容詞であるエージェントという用語を定義する必要があります。形容詞として、「エージェント」は、特に自律性、自己方向性、または特定の目標を達成し、フィードバックから学ぶための独立した行動を取る能力に関して、エージェントに関連しているか、または特徴的です。名詞として、エージェント・プロパティで設計されたAIシステムを指します。従来のAIとは異なり、エージェントAIはデータ入力を継続的に監視し、その入力やユーザー指示に基づいて、自律的にアクションを開始し、意思決定を行うと同時に、その経験から継続的に学習することができます。つまり、Agentic AIは、複雑なリアルタイム・タスクを自律的に実行できます。 Agentic AIには、次の特徴があります。 自律性- 日常的なタスクを処理し、日常的な意思決定を行い、すべてのステップについて常に監視や詳細な指示を必要とせずに問題を解決できる、高度なAIアシスタントのように考えてください。 目標指向: 専任のプロジェクト・マネージャが主要な目標にどのように焦点を当てているかと同様に、これらのシステムは、業務の最適化、売上の向上、カスタマー・サービスの向上など、定義されたビジネス目標に向けて継続的に取り組んでいます。 学習と適応: 時間の経過とともに仕事でより良くなる経験豊富なプロフェッショナルと同様に、これらのシステムは...

Autonomous Database監査ログをLoggingサービスへ・パート1 (2024/11/28)

イメージ
Autonomous Database監査ログをLoggingサービスへ・パート1 (2024/11/28) https://www.thatfinnishguy.blog/2024/11/28/autonomous-database-audit-logs-to-logging-service-part-1/ OCI Oracle Autonomous Databaseの監査ログをOCI Logging Serviceに取得する必要が最近ありました。これは主に外部SIEMシステムに取得するためです。 通常、ログをLoggingに取得すると、OCI Service Connectorを使用してOracle Streamingに取り込むことができ、そこからStreamingは完全にKafka互換であるため、外部システムはログを取得できます。 Autonomous Databaseを使用すると、データベース・アクティビティを監査する機能を提供するデータベースにOCI Data Safeを簡単に構成できます。残念ながら、デフォルトではこれらのログをさらに取得することはできません。しかし、私は掘り下げて、それに応じてログをフェッチするOracle製のオープン・ソース関数がデプロイされているようです。 Data Safeでは、1か月当たりのデータベース当たり1M監査レコードも無料で提供されます。ネイティブ・サービスでDB機能を強化するために、Oracleのもう1つの優れた製品です。 データ・セーフには、データ・マスキング、SQL Firewall、セキュリティ評価など、その他の機能も多数あります。ここからもっと読むことができます。 Data Safeおよび機能は取付け、組み立て非常に容易です、見てみましょう! ブログ投稿のこのパート1は、Data Safe側で作業し、2番目のパートはファンクションのデプロイとOCI Logging側の検証を行います。 Autonomous DatabaseでのOCI Data Safeの有効化 まず、Autonomous DatabaseでData Safeを有効にする必要があります。OCIコンソールから「データ・セーフ」→「ターゲット・データベース」に移動し、「データベースの登録」ボタンをクリックします。(必要に応じて、ウィザードを使用してプ...

AIの効率的なスケーリング- MLPerfトレーニングv4.1におけるOCIのNVIDIA加速ブレイクスルー (2024/11/27)

イメージ
AIの効率的なスケーリング- MLPerfトレーニングv4.1におけるOCIのNVIDIA加速ブレイクスルー (2024/11/27) https://blogs.oracle.com/cloud-infrastructure/post/scaling-ai-oci-nvidia-breakthroughs-mlperf-v41 投稿者: Seshadri Dehalisan | Distinguished Cloud Architect Jon Shelley | Consulting Member of Technical Stuff Sanjay Basu PhD | Senior Director - Gen AI/GPU Cloud Engineering OracleのMLPerf v4.1トレーニング・ベンチマーク・スイートへの最近の参加は、Oracle Cloud Infrastructure(OCI)の優れたAIトレーニング機能を例示しています。Oracleは、優れた成果を達成し、広範なAIワークロードの処理におけるOCIのスケーラビリティを示しています。この記事では、MLPerfベンチマークでOracleのパフォーマンスについて詳しく説明します。ベンチマークされたモデル、インフラストラクチャの詳細、およびNVIDIA GPUでのAIトレーニングの価値実現までの時間を短縮するOCIの強みを示す主要な結果に焦点を当てています。 OracleがMLPerfトレーニングに注力4.1 OCIのベアメタル・シェイプは、次のベンチマーク結果を達成しました。 System Number of nodes GPU model GPU count Model: gpt3 in latency per second Model: llama2_70b_lora in latency per second BM.GPU.H100.8 16 NVID...

変化の受け入れ: AWS CloudFormationからOCI Resource Managerへの移行 (2024/11/26)

イメージ
変化の受け入れ: AWS CloudFormationからOCI Resource Managerへの移行 (2024/11/26) https://blogs.oracle.com/cloud-infrastructure/post/journey-aws-cloudformation-oci-resource-manager 投稿者: Sonali Mishra | Principal Cloud Architect 組織がマルチクラウド戦略の導入と拡大を続けるにつれ、クラウド・プロバイダー間のワークロードの移行は共通の課題であり、機会となっています。大きな注目を集めている移行の1つは、Amazon Web Services (AWS) CloudFormationから Oracle Cloud Infrastructure (OCI) Resource Manager への移行です。 この変化は、プラットフォームの変更以上のものです。この戦略的な決定は、OCI独自の強み、特にTerraformの組み込みサポート、自動化機能、コスト効率、マルチクラウドの柔軟性、ドリフト検出、コンプライアンス機能を最大限に活用します。 この投稿では、OCI Resource Managerの主なメリットと、この移行によって、より柔軟でコスト効果の高い、合理化されたマルチクラウド・インフラストラクチャ戦略の舞台となる理由をご紹介します。 OCI Resource Managerの一意なエッジ OCI Resource Managerは、複数のクラウドにわたるインフラストラクチャ管理の合理化を目指すチームにとって魅力的な選択肢となる豊富な機能セットを提供します。次の表に、各サービスが提供する機能を比較します。 Features OCI Resource Manager AWS CloudFormation Infrastructure-as-code (IaC) language Built on Terraform (HCL syntax), fully Terraform compatible ...

シャドーITに光を当てる (2024/11/26)

イメージ
シャドーITに光を当てる (2024/11/26) https://blogs.oracle.com/security/post/shadow-it 投稿者: Nancy Kramer お客様のITチームは、組織で使用されているすべてのテクノロジーを効果的に管理していますか? 一部のスタッフは、不正な情報技術(IT)や「 シャドーIT 」を利用している可能性が高いです。2027年までに、 従業員の75% がITチームの管理外でテクノロジーを使用することが期待されています。人々は、シャドーITソリューション(ITチームによって管理されていないテクノロジー)を使用することがあります。これは、「公式」または「承認された」ソリューションによって残された認識されたツールのギャップを埋めたいからです。シャドーITソリューションには、多くの場合、 クラウド・サービス 、アプリケーション、ブラウザ拡張機能、および生産性を向上させるためにインターネットからダウンロードされたその他のツールが含まれます。組織内で開発された「自社開発」ツールも、ITチームのコントロール外にある場合、シャドーITソリューションと見なされます。 どうして影を気にするのでしょうか。 過剰な支出に加えて、 適切に管理されていない テクノロジーは、次のような リスク をもたらす可能性があります。 次のことを行うサプライヤにデータを委託します。 契約上の機密 保持 コミットメントおよび/または サプライヤ適格基準を満たしていません パッチが適用されていないソフトウェア を使用して、 脆弱なシステム でのデータの処理 製品および環境における脆弱性 は、悪意のあるアクターが悪用して、 ランサムウェア 攻撃の対象となるシステムなどのデータの機密性、可用性または整合性に悪影響を及ぼす可能性があります。 バックドアやその他の隠れた不変のメカニズムでコンピューティング環境を危険にさらす ダウンロードされたユーティリティまたはプログラムは、 XZ utilsライブラリの破損 などの悪意のあるアクターによって侵害された可能性があります 企業が実現できるメリットを想像してみてください。ビジネス全体に展開されているすべてのテクノロジの正確なインベントリがある場合、それらのシステムはITプロフェッショナルが管理し、テクノロジーは ビジネス...

MySQL Enterprise Editionによる金融サービスにおける開発者のアジリティとパフォーマンスの向上 (2024/11/25)

MySQL Enterprise Editionによる金融サービスにおける開発者のアジリティとパフォーマンスの向上 (2024/11/25) https://blogs.oracle.com/mysql/post/enhancing-developer-agility-and-performance-in-financial-services-with-mysql-enterprise-edition 投稿者: Michel Gerin 急速に進化する金融サービス業界では、競争力を維持するために、イノベーションとソリューションの迅速な提供の能力が不可欠です。顧客の期待が高まり、市場のダイナミクスが変化する中、組織は現在の業務をサポートするだけでなく、開発チームがアジャイルで応答性を発揮できるようにする堅牢なデータベース・ソリューションを必要としています。MySQL Enterprise Editionは、開発者のアジリティとパフォーマンスを向上させるために独自に位置しているため、金融機関はアプリケーションをより効率的に構築およびデプロイできます。 金融サービスにおけるアジリティの必要性 金融サービス企業は、変化する規制、進化する顧客のニーズ、フィンテック競合他社の出現に適応するという強いプレッシャーに直面しています。従来の開発ライフサイクルは煩雑で、イノベーションを遅らせるレガシー・システムによって妨げられることがよくあります。このような状況で成功するには、開発サイクルの短縮、シームレスなコラボレーション、および新機能の効率的なデプロイメントを促進する戦略を採用する必要があります。 MySQL Enterprise Editionが開発者の敏捷性を促進する方法 最新の開発業務のサポート MySQL Enterprise Editionは、アジャイルやDevOpsなどの最新の開発手法をサポートするように構築されています。MySQLは、柔軟でスケーラブルなデータベース環境を提供することで、開発者が反復的なサイクルで作業し、リアルタイムのフィードバックに基づいてアプリケーションを迅速にリリースおよび調整できるようにします。Kubernetesなどのツールとの統合により、デプロイメント・プロセスがさらに合理化され、チームは手作業なしでアプリケーションのスケーリング、監視、更...

EBS 12.2およびAPEXとの統合の強化が利用可能 (2024/11/22)

イメージ
EBS 12.2およびAPEXとの統合の強化が利用可能 (2024/11/22) https://blogs.oracle.com/ebstech/post/enhanced-integration-with-ebs-122-and-apex-now-available 投稿者: Santiago Bastidas | Product Management Director Oracle APEXは、Oracle E-Business Suite (EBS)拡張を実装するための優先プラットフォームになりました。EBSエコシステムにOracle APEX拡張機能を埋め込んだ新しいEBS 12.2の機能拡張セットが利用可能であることをお知らせします。 Oracle APEXとは Oracle APEXは、Oracle Database用のローコード・アプリケーション開発プラットフォームです。APEXは、パーソナル・データベースの品質(生産性、使いやすさ、柔軟性)と、エンタープライズ・データベースの品質(セキュリティ、整合性、パフォーマンス、スケーラビリティ、可用性、およびWeb用に構築)を組み合せます。 ブラウザベースのインタフェース、宣言型プログラミング・フレームワークおよびシンプルなウィザードにより、Oracle APEXを簡単に学習でき、堅牢なアプリケーションを迅速に構築できます。 APEXの詳細は、Oracle APEXリリース24.1の ドキュメント を参照してください。 拡張統合の新機能 次に、EBS環境と緊密に統合された拡張機能を開発できる新しい拡張機能のリストを示します。 新しいEBSファンクション・タイプを使用したAPEXページの登録 埋め込みウィンドウとフルウィンドウは、2つのサポートされるモードです。 埋込みモードでは、カスタムAPEXページがOA Frameworkページ内に表示され、ユーザーが標準ページとカスタム・ページ間を移動するときに、より一貫したルック・アンド・フィールが提供されます。 フル・ウィンドウ・モードでは、APEXページが別のブラウザ・ウィンドウで開きます。 EBS構成認証を使用して、EBSからAPEXにシームレスにナビゲート 認証は、Oracle Access Manager (OAM)を使用したローカル・サインオンまたはシ...

GraphRAG Oracle Database 23aiでのLangchainおよびOracle Graphの使用(パート1) (2024/11/21)

イメージ
GraphRAG Oracle Database 23aiでのLangchainおよびOracle Graphの使用(パート1) (2024/11/21) https://medium.com/oracledevs/graphrag-using-langchain-and-oracle-graph-on-oracle-database-23ai-part-1-dc76b48a4ca1 投稿者: Rahul Tasker 生成AIの新しい世界では、企業は自社の能力とその欠点を認識し始めています。AIは、豊富な情報を持つ非常に強力な世代エンジンですが、トレーニングされた情報に限定され、プライベート・ビジネス・データに関する洞察はありません。つまり、Large Language Model(LLM)には、最近のイベントやビジネス・データに関する情報がなく、次の質問が求められます。 データを使用してLLMから関連する回答を得て、情報に基づいたビジネス上の意思決定を行うには、どうすればよいでしょうか。 可能なソリューションには、カスタム生成事前トレーニング済トランスフォーマ(GPT)、ベクトル・ベース取得拡張生成(RAG)およびグラフ・ベース取得拡張生成(GraphRAG)があります。カスタムGPTの作成は煩雑で、広範なトレーニングを使用できるようにする必要があり、新しいデータが常にビジネスに来るときにエラーが発生しやすく、カスタムGPTは新しいデータで再トレーニングされないため、多くの人にとってメンテナンスが懸念されます。RAGは、一部のユース・ケースでは優れたオプションですが、コンテキストや、私たちが真であると知っているものとのつながりが欠けています。これは、グラフが特に役立つ場合です。 グラフは、LLMからより正確な結果を得るために情報取得のコンテキストを提供できます。より複雑なユース・ケースでは、ベクター・ベースとグラフ・ベースの取得を組み合せてLLMから高品質な結果を得ることができます(パート2で説明します)。ただし、多くの場合、グラフのみを使用して情報を取得すれば十分です。 この記事では、Oracle Database 23aiでSQLプロパティ・グラフをChatGPTなどのAIサービスとともに使用して、LLMが質問に答えるためのより多くのコンテキストを提供...

oracle.comから直接AutoUpgradeをダウンロード (2024/11/21)

イメージ
oracle.comから直接AutoUpgradeをダウンロード (2024/11/21) https://mikedietrichde.com/2024/11/21/download-autoupgrade-directly-from-oracle-com/ 投稿者: Mike.Dietrich 私たちは長い間これを約束していましたが、Billの持続性とハードワークのおかげで、最終的にDBAの生活を楽にする何かを提供することができます: oracle.comから直接AutoUpgradeをダウンロードする機能。 oracle.comから直接AutoUpgradeをダウンロード Photo by John Rodenn Castillo on Unsplash これはどういう意味ですか。 MOSノート:2485457.1– AutoUpgradeをダウンロード して、My Oracle Supportから新しいバージョンのAutoUpgradeをダウンロードできることがわかっています。これは、1日目以降で、約5.5年前にOracle Database 19cとともにAutoUpgradeをリリースする前でもありました。9ヶ月の長いベータ段階ですでにノートを使用しました。 さらに、AutoUpgradeの最新バージョン、および通常から2-3の以前のバージョンもダウンロードできます。 MOS Note:2485457.1– AutoUpgradeをダウンロード します。 しかし、 www.oracle.com/goto/upgrade から直接クリックスルーすることなくAutoUpgradeをダウンロードできる可能性もご提供できて本当にうれしいです。 www.oracle.com/goto/upgrade から直接AutoUpgradeをダウンロード 特に、 AutoUpgradeの新機能 では、My Oracle Supportからパッチおよびバンドルをダウンロードでき、Oracleホーム全体を構築できるので、自動化されたプロセスで最新バージョンのAUをダウンロードすると非常に便利です。 直接リンクはありますか? もちろん、直接リンクも用意されており、バージョンを交換しても変更・変更することはありません。ミラー化する必要があるため、MOSの最新バージョンが orac...

Azure、AWSおよびGCP上のOracle Transaction Manager for Microservices (MicroTx) (2024/11/21)

Azure、AWSおよびGCP上のOracle Transaction Manager for Microservices (MicroTx) (2024/11/21) https://blogs.oracle.com/database/post/oracle-transaction-manager-for-microservices-microtx-on-azure-aws-and-gcp 投稿者: Todd Little | Chief Architect, Transaction Processing Products コストの最適化、Enhanced Resilience、進化するビジネス・ニーズへの対応のためにマルチクラウド戦略を採用する企業が増えるにつれ、これらの多様な環境でのトランザクションの管理が最重要になります。Oracle Transaction Manager for Microservices(MicroTx)により、これだけを実行できます。MicroTxは、Microsoft Azure、Amazon Web Services、Google Cloud Platformの拡張サポートにより、マイクロサービスがどこにいてもトランザクションの整合性を維持できるようにします。 この投稿では、MicroTxのマルチクラウド機能の概要を説明します。後続の記事では、各プラットフォームにMicroTxをデプロイするためのアーキテクチャの詳細とベスト・プラクティスについて説明します。 マイクロサービスにとってマルチクラウドが重要な理由 マルチクラウド導入には、次のような多くの利点があります。 コストの最適化: 各プロバイダーから最もコスト効率の高いサービスを活用します。 柔軟性の向上: ベンダーのロックインを回避し、変化するビジネス要件に適応します。 Enhanced Resilience: 複数のクラウドにサービスを分散することで、可用性とディザスタ・リカバリを向上させます。 規制コンプライアンス: サービスを戦略的に特定することで、データ主権とコンプライアンスの要件に対応します。 MicroTxを使用すると、分散マイクロサービス全体でシームレスなトランザクション管理を確保しながら、これらのメリットを実現できます。 MicroTx: クラウドに依存しな...

Autonomous DatabaseおよびOCI Computeリソース・ページからFull Stack DRを簡単に表示および管理 (2024/11/21)

イメージ
Autonomous DatabaseおよびOCI Computeリソース・ページからFull Stack DRを簡単に表示および管理 (2024/11/21) https://blogs.oracle.com/cloud-infrastructure/post/imrorved-udx-between-adb-compute-fsdr 投稿者: Gregory King | Senior principal product manager for OCI Full Stack Disaster Recovery Oracle Cloud Infrastructure(OCI)のAutonomous DatabaseおよびComputeサービスには、Full Stack Disaster Recovery(Full Stack DR)のアクティブ化とステータス情報が、個々のOCIリソースのOCIリソース詳細ページ内に含まれるようになりました。追加の情報により、システム管理者やデータベース管理者は、管理するOCIリソースが、複数のOCIサービスにまたがるより大規模で包括的なディザスタ・リカバリ計画の一部であることをすぐに認識しやすくなります。 Full Stack DRは、Infrastructure as a Service (IaaS)とPlatform as a Service (PaaS)の完全なエンドツーエンド・リカバリを自動化するOCIのディザスタ・リカバリ・アズ・アズ・ア・サービス(DRaaS)ソリューションです。コンピュート、ストレージ、データベース、ロード・バランサが最初に作成され、ディザスタ・リカバリ用にデプロイされた後、その後Full Stack DR保護グループに追加されます。利害関係者がDR保護グループを通じてのみメンバー・リソースを表示できるこのパラダイムは、ディザスタ・リカバリの設定を担当するユーザーと、日々の運用と個々のOCIリソースのメンテナンスを担当する人の間の認識にギャップを残しました。 サービス間のこの緊密な統合を詳しく見てみましょう。日常業務を担当する担当者に、彼らが管理しているものは、認識していない可能性があるより大きなディザスタ・リカバリ図の一部であることを通知します。まず、Autonomous Databaseのサービ...

本番グレードのGenAIソリューション向けのOKEでのLLMのホスティングとスケーリング (2024/11/21)

イメージ
本番グレードのGenAIソリューション向けのOKEでのLLMのホスティングとスケーリング (2024/11/21) https://blogs.oracle.com/cloud-infrastructure/post/hosting-and-scaling-llms-on-oke 投稿者: Subhankar Sahu | IT Director Kiran Kumar Vemula | Principal Consultant Rao Nelakurti | Principal Application Engineer 大規模言語モデル(LLM)は、世界中の業界に革命をもたらしています。カスタマー・サービス・ワークフローの変革から医療診断の推進、コンテンツ作成の推進に至るまで、LLMは自動化、パーソナライズ、意思決定の新たな次元を開拓しています。企業が競争力を維持するために生成AI(GenAI)を採用するにあたり、特に現実世界のアプリケーションにLLMを導入する際には、スケーラブルで高性能なインフラストラクチャに対する需要が高まっています。 ハイパースケーラやその他の大規模なクラウド・プロバイダはLLM推論のためのマネージド・サービスを提供していますが、これらのモデルのスケーリングには大きなコストがかかる可能性があります。最先端の機能と幅広い一般的な知識を提供するが、1.8兆のパラメータを持つGPT-4など、最先端の大規模なモデルでは、多くの場合、強力な計算能力と専門的なGPUが必要であり、大規模な運用にはコストがかかります。対照的に、Llama 3のような小規模なモデルでは、パラメータの範囲は1Bから8Bまでであり、パフォーマンスとリソースの効率のバランスをとり、ハードウェアのコストをかけずに堅牢な機能を提供します。さらに、リアルタイム推論や、低レイテンシとコスト効率が優先される状況などのエンタープライズ・ユース・ケースでは、特にllama.cppのような最適化されたフレームワークを使用して、これらの小規模なモデルをCPUで実行すると、非常に効果的です。 本記事では、OCI Kubernetes Engine(OKE)上でLLM(特にMetaのLlama 3モデル)をホスティングおよびスケーリングするための、効率的でコスト効率の高いアプローチを探ります。ま...