2025 年 4 月にリリースされた Meta の Llama 4 Scout は、170 億のパラメータを持つ汎用言語モデルであり、GPU なしで実行されるものも含め、より幅広いアプリケーションに強力な推論機能をもたらします。 このブログでは、CPU のみのシステムでの Llama 4 Scout のベンチマークに焦点を当て、次の内容を取り上げます。 1秒あたりのトークン数 トークンあたりのレイテンシ 迅速な処理効率 量子化技術 x86、ARM、RISC-V (RV64) 向けのアーキテクチャ固有の最適化 効率的な展開のためにGGUF形式に変換する CPU をベンチマークする理由は何ですか? ほとんどの LLM は GPU 上に展開されますが、次のような場合には CPU のみの推論が 必要になることがよくあります。 エッジデバイス GPU アクセスのないクラウド VM オープンハードウェアエコシステム（例：RISC-V） コスト重視の導入 これにより、特に量子化されたバリアントでは、Llama 4 Scout が強力な候補になります。 主要なベンチマーク指標 トークン/秒 全体的なスループットは長い完了に重要です レイテンシ/トークン 1トークンを生成するのにかかる時間。チャットに重要 プロンプトのサイズ感度 入力が長くなると推論速度が低下する仕組み メモリ使用量 RAMフットプリントはモデルが実行できるかどうかを決定します 量子化が不可欠な理由 量子化により、大規模モデルのメモリと計算要件が削減されます。Llama 4 Scoutはint4またはint8に量子化され、8～16GBのRAMを搭載したCPUで快適に実行できます。 利点: Llama 4 Scoutへの影響 メモリ節約: 34GB → ~5～7GB (int4) 高速化: float16 より最大 3 倍高速 ハードウェアの適合性: ARMおよびRV64 CPUで推論をホスト可能 ggml、Llama.cpp、MLC などのツールは、CPU バックエンドを含む量子化された Llama 4 モデルをサポートします。 アーキテクチャ固有のパフォーマンスに関する考慮事項 🔹 x86-64 (Intel、AMD) ベクターサポート: AVX2 または AVX-512 推奨 スレッディング: 成熟した OpenMP と NUMA サポート パフォーマンス: 高; Llama モデルで最適化されている ARM (グラビトン、アップルシリコン、ネオバース) ベクター ISA: すべてのチップで NEON (128 ビット)、新しいチップでは SVE/SVE2 スレッディング: コアの異種性によりチューニングが必要 量子化: NEONはint8とint4を効率的に処理します ヒント: 最適なパフォーマンスを得るために、taskset と numactl を使用してスレッドを固定します。 RISC-V (RVV 付き RV64) ベクターISA: RISC-Vベクター拡張（RVV）、可変幅 量子化: 必須。float32 モデルは RV64 エッジデバイスでは実用的ではない。 ツール: llama.cpp のサポートは実験的ですが、成長しています RV64 では、帯域幅が限られているため、メモリレイアウトとキャッシュフレンドリーな量子化が重要になります。 推論結果の例（仮説） 建築 モデルバリアント プロンプトサイズ トークン/秒 RAM使用量 x86_64 Llama 4 スカウト int4 512 11.2 約6.5GB ARM ネオバース Llama 4 スカウト int4 512 8.7 約6.5GB RISC-V RV64 Llama 4 スカウト int4 512 3.2 約6.5GB これらの結果は、llama.cpp または同様のものを使用して量子化された重みを使用したマルチスレッド CPU 推論を想定しています。 RAW モデルから GGUF へ: 理由と方法 CPU のみのシステムで Meta Llama 4 Scout を効率的に実行するには、特に llama.cpp などのツールを使用する場合、モデルは GGUF 形式である必要があります。 GGUF に変換する理由 GGUF (Grokking GGML 統合フォーマット) は、以下を使用して CPU およびエッジ推論用に設計された、コンパクトでメモリが最適化されたモデル ファイル形式です。 llama.cpp mlc-llm テキスト生成 webui GGUFの利点：メリット メモリ効率: 量子化された重みとメタデータをパックします 高速な読み込み時間: 構成の再トークン化や解析は不要 保存されるメタデータ:トークナイザー、語彙、モデルタイプが含まれます 使いやすさの向上: 1 つのファイルを複数のツールで使用可能 Llama 4 ScoutをGGUFに変換する方法 生のモデル（HF形式） をダウンロード Hugging Face から元のモデルを取得します (例: meta-llama/Meta-Llama-4-Scout-17B)。 トランスフォーマーとllama-cpp-pythonツールをインストールする pip でトランスフォーマーをインストール huggingface_hub git でクローン https://github.com/ggerganov/llama.cppcd llama.cppmake GGUF変換スクリプトを実行する llama.cpp/scripts ディレクトリから: python convert.py \ --outfile llama4-scout.gguf \--model meta-llama/Meta-Llama-4-Scout-17B \ --dtype q4_0 3. 推論ツールに読み込む 変換したら、.gguf ファイルを直接実行できます:./main -m llama4-scout.gguf -p "Hello, world" GGUF + 量子化 = CPU のスーパーパワー GGUF に変換すると、変換中に量子化が可能になります。 q4_0、q4_K、q5_1、q8_0 をサポート サイズは劇的に削減されます。約34GBから、第4四半期では約5～7GBになります。 AVX、SVE、RVVなどのCPU SIMD命令との互換性を確保します。 メモリが制限されている RISC-V または ARM ボードでは、GGUF + int4 が Llama 4 Scout を実行する唯一の方法になることがよくあります。 プロのヒント: GGUF 変換オプション 変換設定を微調整できます。 --vocab-type でトークナイザー構造をカスタマイズする --trust-remote-code（Hugging Faceリポジトリがカスタムロードを使用している場合） --quantize q4_K を使用すると int4 の精度が向上します 最後に Meta の Llama 4 Scout は、2025 年の CPU 推論用オープンソース LLM の中で最も実用的なものの 1 つです。量子化と SIMD 対応のデプロイメントにより、次のことが可能になります。 エッジアプリケーション（IoT、電話） ソブリンコンピューティングプラットフォーム（RISC-V） GPUを使用しないクラウドネイティブ環境 CPU アーキテクチャ上のオープン LLM の限界を押し広げることに興味がある場合、Llama 4 Scout は最適な出発点の 1 つです。

GCCやLLVMなどのRISC-Vコンパイラのファジングは、このアーキテクチャに基づくソフトウェアエコシステム全体の正確性とセキュリティを確保するために不可欠な手法です。目的は、コンパイルされたコードの脆弱性を見つけることではなく、誤ったコード生成、予期しない動作、さらには悪用可能なセキュリティ脆弱性につながる可能性のあるコンパイラ自体の欠陥を明らかにすることです。 コンパイラファジングが特別な課題となる理由 コンパイラファジングは、一般的なアプリケーションにおけるファジングとは異なります。プログラムにランダムなデータを入力するのではなく、 ランダムだが構文的には正しいソースコードを生成し、 それをコンパイラに渡します。バイト列を変更するだけの単純なファジングツールでは、解析すら不可能なコードをすぐに生成してしまい、より深刻なエラーを見逃してしまう可能性があります。 コンパイラ ファジングの主な目的は、主に 2 種類のエラーを検出することです。 クラッシュとパニックアタック： ファジングツールは、コンパイル中にクラッシュ、ハング、または重大なコンパイラエラーを引き起こすコードを生成します。これは、修正が必要なコンパイラのバグを示しています。 ミスコンパイル： これは最も危険なタイプのエラーです。コンパイラはテスト対象のコードを正常にコンパイルしますが、生成されたマシンコード（RISC-Vアセンブラ）には欠陥があります。これは、検出されないデータ破損、セキュリティ上の脆弱性、または予測できないプログラム動作につながる可能性があります。 このようなエラーを見つけるには、 差分ファジング と呼ばれる手法が必要です 。 RISC-Vコンパイラの差分ファジングのパフォーマンス 差分ファジングは、RISC-Vコンパイラのコンパイルエラーを見つけるための非常に強力な手法です。その仕組みは以下のとおりです。 ファジング ツールは、多くの場合、有効な C または C++ コード (csmith など) を生成するプログラムであり、一意のプログラムを生成します。 このプログラムは、少なくとも 2 つの異なるコンパイラ (GCC と LLVM など) によってコンパイルされているか、 異なる最適化フラグ (-O0 と -O3 など) を使用してコンパイルされています。 次に、コンパイルされたバイナリが実行され、その出力が比較されます。 出力が一致しない場合は、少なくともいずれかのコンパイラにコンパイルエラーがあることを意味します。ファジングツールは、この特定のソースコードを開発者による分析のためのテストケースとして保存します。 この方法は基本的に「テストオラクル」を使用し、事前に正しい出力を知る必要なくエラーを自動的に特定します。これが、GCCとLLVMの両方で多くのコンパイラエラーが発見されている主な理由です。 RISC-Vコンパイラのファジングのための重要なツールとリポジトリ 前述の汎用ファザーの多くは (AFL++ など) コンパイラのソース コードをファジングするために使用できますが、有効な RISC-V 固有のコードを効果的に生成してテストするには、専用のツールが必要になることがよくあります。 csmith: これはCプログラム用のよく知られたランダム化テストケースジェネレータです。GCCやLLVMなどのCコンパイラの差分テストに最適な、複雑で妥当なCコードを生成します。RISC-V専用ではありませんが、あらゆるCコンパイラのRISC-Vバックエンドのファジングワークフローにおいて不可欠な要素です。 GitHubリポジトリ: https://github.com/csmith-project/csmith RISCV-DV： RISC-Vコミュニティによってメンテナンスされているこのツールは、主にRISC-Vプロセッサの設計検証に使用されますが、コンパイラバックエンドのテスト用の複雑な命令シーケンスを生成するためにも使用できます。高度な設定が可能で、特定のISA拡張に対応できます。 GitHubリポジトリ: https://github.com/google/riscv-dv IRFuzzer: LLVMバックエンド に特化したファジングツールです 。C/C++ソースコードを生成する代わりに、LLVM中間表現（IR）を生成します。これにより、フロントエンドのエラーを気にすることなく、バックエンドのコード生成を直接テストできます。これは、LLVMのRISC-Vコードジェネレータにおける問題を発見するための、非常に的を絞ったアプローチです。 GitHub: 研究ツールとしてのリソースは、arXivや大学のウェブサイトでよく見つかります。GitHubで「IRFuzzer」を検索すると、関連プロジェクトが見つかります。 RISC-V Vector Intrinsic Fuzzing (RIF): RISC-V Vector Extension (RVV) の組み込み関数を用いてランダムコードを生成する特別なファジングツールです。GCCやLLVMなどのコンパイラが、RISC-V ISAのこの複雑かつパフォーマンスクリティカルな部分を正しく実装しているかどうかを検証するために不可欠です。 GitHubリポジトリ: https://github.com/sifive/riscv-vector-intrinsic-fuzzing Patrick-rivos/compiler-fuzz-ci: このGitHubリポジトリは、RISC-Vコンパイラのファジングのための継続的インテグレーション（CI）環境の優れた例を提供しています。csmithなどのツールとCIパイプラインを組み合わせて、自動的にファジングを行い、GCCとLLVMにエラーを報告する方法を実証しています。 GitHubリポジトリ: https://github.com/patrick-rivos/compiler-fuzz-ci RISC-Vコンパイラのファジングは、現在進行中の重要なタスクです。これにより、ソフトウェア開発者は、基盤となるハードウェアに確実かつ安全に、そして正しくコンパイルすることができ、RISC-Vエコシステム全体の強化につながります。

このブログ記事では、2つの主要プロバイダー、AWS Graviton4（AWS r8gインスタンスベース）とGoogle Axion（GCP Axionインスタンスベース）のパフォーマンスを比較します。どちらも先進的なArm Neoverse V2アーキテクチャを基盤としています。今回は、人気のインメモリデータストアであるValkey 8.0.1を用いて、それぞれのパフォーマンスを検証します。 競合：AWS Graviton4とGoogle Axion AWS GravitonとGoogle Axionは、AmazonとGoogleが提供する最新世代のARMベースサーバープロセッサです。どちらも、クラウドコンピューティング、機械学習、ハイパフォーマンスコンピューティング（HPC）向けに特別に設計されたArm Neoverse V2 CPUアーキテクチャを採用しています。これらのカスタムビルドチップは、従来のx86ベースのチップと比較して、優れたパフォーマンスとエネルギー効率を提供します。 ベンチマーク: Valkey 8.0.1 有意義な比較を行うため、高性能でオープンソースのインメモリデータストアであるValkey 8.0.1を選択しました。ValkeyはRedisのフォークであり、キャッシュ、セッション管理、リアルタイム分析によく使用されます。そのため、これらのインスタンスの処理能力とストレージ容量をテストするのに最適です。ベンチマーク設定は、公平な比較ができるように構成されています。 Valkey サーバー コア: Valkey サーバーはコア 2 から 7 に制限されていました。 クエリ パラメータ: 各実験には、1 億件の並列リクエスト、256 のクライアント、1024 KiB のペイロード サイズが含まれていました。 主要業績評価指標: スループットの 1 秒あたりのリクエスト数 (RPS) と応答性の P99 レイテンシ (99 パーセンタイル) という 2 つの主要な指標に重点を置きました。 実験1: ネットワークパフォーマンス 最初の実験では、Valkeyのクライアントインスタンスとサーバーインスタンスを同じクラスタネットワーク内の別々のホストで実行した場合のパフォーマンスをテストしました。このシナリオでは、多くの分散ワークロードにとって極めて重要な、基盤となるネットワーク仮想化と接続性の効率性が強調されています。 IRQ ピンニング: このテストでは、コア 0 と 1 で IRQ ピンニングを使用しました。これにより、ネットワーク割り込みを処理するために特定の CPU コアが予約され、Valkey サーバーのワークロードへの影響が防止され、ネットワーク パフォーマンスのより安定した正確な測定が保証されます。 分散アプリケーション AWS r8gインスタンスの結果 GCP Axionインスタンスの結果 RPSを設定 925,860 790,020 P99の遅延の設定 0.431ミリ秒 0.655ミリ秒 RPSを受け取る 941,802 870,920 P99のレイテンシを取得 0.415ミリ秒 0.543ミリ秒 このネットワーク負荷の高いテストでは、AWS r8gインスタンスはSET操作とGET操作の両方でGCP Axionを一貫して上回り、スループットの向上とP99レイテンシの低減を実現しました。これは、Graviton4プロセッサと緊密に統合されたAWS Nitroシステムのネットワーク機能が、分散型でネットワーク依存度の高いアプリケーションに大きなメリットをもたらすことを示唆しています。 実験2: 同一ホストでのパフォーマンス 2つ目の実験では、Valkeyクライアントとサーバーの両方を同一ホスト上で実行することで、純粋なコンピューティング能力を評価しました。このテストでは、ネットワークオーバーヘッドを最小限に抑え、CPUとメモリのパフォーマンスに重点を置いています。 同じホスト上のアプリケーション AWS r8g インスタンスの結果: GCP Axionインスタンスの結果: RPSを設定 1,024,894 894,262 P99の遅延の設定 0.407ミリ秒 0.367ミリ秒 RPSを受け取る 1,060,186 942,720 P99のレイテンシを取得 0.359ミリ秒 0.303ミリ秒 結果はより微妙な様相を呈しています。AWS r8gインスタンスは再び高い総合スループット（RPS）を達成しましたが、GCP AxionインスタンスはSET操作とGET操作の両方でP99レイテンシが低くなっています。これは、AWSアーキテクチャが最大スループットに最適化されている一方で、Googleの設計は低レイテンシを優先していることを示唆しています。これはValkeyのコマンド実行モデルの重要な特徴です。 結論と分析 ベンチマークの結果は明確な状況を示しています。この特定のワークロードでは、AWS Graviton4 ベースの r8g インスタンスが生のスループットの点でリードし、Google Axion インスタンスは低レイテンシで際立っています。 AWS r8g (Graviton4): 両方の実験で RPS が高くなったことは、AWS 実装が並列および高スループットのワークロードに対して高度に最適化されていることを示唆しており、これはおそらく AWS Nitro System との緊密な統合によるものと考えられます。 GCP Axion：同一ホストでのテストにおけるP99レイテンシの低下は重要な指標です。これは、GoogleのAxionプロセッサがより効率的なコア設計、あるいは最適化されたキャッシュ構造を備えていることを示唆しており、特に低レイテンシが求められるワークロードに有効です。

DLRMはディープラーニング・レコメンデーション・モデルの略称です。Facebook AI (Meta) が大規模なパーソナライズされたレコメンデーションシステム向けに開発したニューラルネットワークアーキテクチャです。DLRMは、 パーソナライズされたレコメンデーションやランキング予測が必要な 実世界のアプリケーション で広く利用されています 。DLRMは、クリックスルー率 (CTR) の予測とランキングタスク向けに設計されています。 例: オンライン広告、電子商取引の推奨、ソーシャル メディア フィードのランキング、ストリーミング サービス、オンライン マーケットプレイス、クラシファイド広告など。 DLRM の機能: DLRM インストール オプション: git と python を使用してオリジナルの Facebook DLRM (PyTorch) をインストールします。 TorchRec を使用して DLRM をインストールする NVIDIA DLRMをインストールする Docker に DLRM をインストールする (CPU のみまたは GPU) DLRM と PyTorch の関係は何ですか? DLRMはPyTorchを使用して構築されています。PyTorch は、DLRM内のすべてのコンポーネントを動かす基盤となるディープラーニングフレームワークとして機能します。 PyTorchはフレームワーク、DLRMはモデル DLRM はフレームワークで はなく 、 大規模な推奨システム向けに Meta (Facebook) が設計した 特定のニューラル ネットワーク アーキテクチャ です 。 PyTorch は以下を提供します: DLRM はこれらのツールを使用して、高密度 MLP、埋め込みテーブル、および機能相互作用レイヤーを構築します。 Pytorch インストール オプション: PyTorch は、環境、ハードウェア、ワークフローに応じてさまざまな方法でインストールできます。 pip 経由でインストールする (最も一般的かつ最も簡単) Conda 経由でインストール (GPU 環境に最適) Docker 経由でインストール (分離 & 本番環境対応) ソースからインストール (開発者およびカスタムビルド向け) クラウドベースの PyTorch インストール パッケージ マネージャー経由でインストールする (OS サポートが限定的) Docker 経由の Pytorch インストール: Docker経由でPyTorchをインストールすることは、ディープラーニング環境を構築する最も信頼性が高く、手間のかからない方法の一つです。Pythonのバージョン、CUDAツールキット、cuDNNライブラリ、システムの依存関係を手動で管理する代わりに、Dockerは事前設定済みのコンテナを提供し、すべてがすぐに使える状態になっています。公式のPyTorchイメージ（CPUのみ、またはCUDAサポート付き）をプルすることで、どのマシンでも同じように動作する、分離され再現可能な環境が得られます。 クイックステップ 1. イメージを取得する CPUのみ: docker pull pytorch/pytorch:latest GPU (CUDA 11.8 の例): docker pull pytorch/pytorch:latest-cuda11.8-cudnn8-runtime 2. コンテナを実行する CPU： docker run -it pytorch/pytorch:latest bash GPU (NVIDIA コンテナ ツールキットを使用): docker run -it --gpus all pytorch/pytorch:latest-cuda11.8-cudnn8-runtime bash 3. コンテナ内の確認 python3 -c "torchをインポートします。print(torch.__version__);print('cuda:', torch.cuda.is _available())" PyTorch Docker コンテナ内で DLRM を実行するにはどうすればよいでしょうか? PyTorch Dockerイメージを取得する コンテナを起動する 依存関係のインストール（コンテナ内） DLRMリポジトリのクローン DLRMを実行する DLRM コマンド: DLRMを効果的に実行するには、データの読み込み、モデルアーキテクチャ、トレーニング設定、パフォーマンスチューニングを制御する主要なコマンドラインオプションを理解する必要があります。DLRMは、バッチサイズから埋め込み次元まで、あらゆる設定を可能にする豊富なフラグセットに対応しています。これらのオプションは、主に4つのカテゴリに分類されます。 データオプション トレーニングオプション モデルアーキテクチャオプション システム/パフォーマンスオプション よく使用される DLRM コマンド: python dlrm_s_pytorch.py \     --data-generation=synthetic \     --mini-batch-size=2048 \     --learning-rate=0.01 \     --arch-sparse-feature-size=16 \     --arch-mlp-bot="13-512-256-64-16" \     --arch-mlp-top="512-256-1" \     --print-freq=10 結論 PyTorch Dockerコンテナ を使用して DLRM（ディープラーニング推奨モデル） を実行することで、 異なるハードウェアプラットフォーム間で、合理化され、一貫性があり、再現性の高い環境を実現できます。Dockerは依存関係の競合を排除し、セットアップを簡素化し、PyTorchのバージョン、ライブラリ、最適化など、必要なソフトウェアスタックをシームレスにデプロイすることを保証します。 要するに、PyTorch Docker + DLRM を利用すれば、レコメンデーションモデルのトレーニング、評価、デプロイを、最小限の手間で、信頼性が高く、柔軟かつ効率的に行うことができます。

サイト信頼性エンジニアリング（SRE）の世界では、信頼、知識、そして実行力が何よりも重要です。私たちのチームが推論システム分野の大手クライアントの一つにサービスを提供する機会を得たとき、競争が熾烈になることは覚悟していました。多くの大手企業が同じプロジェクトを競い合っていました。しかし、私たちはこれを、専門知識、コミットメント、そして適切なアプローチが、規模やスケールを凌駕することを証明する機会だと捉えました。 私たちは比較的小規模な企業ですが、お客様のニーズに的確に応えられるよう、綿密な ベンチマーク調査の専門知識 と 業界知識 という独自の強みを提供でき ました。複雑なシステムを迅速に理解し、データセンター運用における連携を確立し、ソリューションを開発する能力は、競合他社との差別化要因となっています。この専門知識と、適応力、そして学ぶ姿勢が相まって、契約を獲得し、お客様のシステムのL1サポートという、事業継続にとって極めて重要な業務を担うことができました。 初期学習曲線: SRE の強固な基盤の構築 最初の数ヶ月は容易ではありませんでした。複雑なシステムであればなおさらですが、可用性を確保するために必要なインフラストラクチャは、私たちに厳しい学習曲線を要求しました。私たちはすぐに以下の点を理解する必要がありました。 インシデント ワークロードが本番環境でどのように機能するか。 推論エコシステム内のアーキテクチャ構成要素。 顧客のデータセンターの構造を含むホスティング メカニズム。 システムが障害を起こす可能性のあるさまざまな方法と、各障害モードの潜在的な影響。 シフトごとに新たな学習の機会が訪れました。何が問題だったのかだけでなく、なぜ問題が起きたのかを理解することに全力を注ぎました。ゆっくりと、しかし着実に知識は蓄積されていきました。あらゆるインシデントがケーススタディとなり、お客様のエンジニアとのやり取りを通して理解が深まりました。これが、その後の成功の基盤となりました。 影から主たる責任者へ：責任への移行 当初は 24時間 体制で作業し 、主な窓口となるクライアントのエンジニアをサポートしました。あらゆるインシデントに対し、何時間もかけてチームと協議し、問題のあらゆる側面を分析しました。根本原因の特定から解決策の実装まで、問題を解決するだけでなく、それがアーキテクチャに与える影響も理解しました。 このアプローチにより、システムの包括的な概要を把握することができました。依存関係、エスカレーションパス、そして ダウンタイム の最小化の重要性を特定しました 。特に、クライアントのエンドユーザーは厳格なSLAを遵守していたためです。 数週間後、役割が逆転しました。私たちが 主なオンコール対応を 引き継ぎ 、お客様のエンジニアはサポート役に就きました。これは私たちにとって重要な瞬間でした。お客様が私たちの能力に寄せている信頼を示すものでした。 それ以降、私たちはインシデント対応の責任を負い、依存関係を分析し、必要に応じて上位チーム（L2/L3）にエスカレーションを行いました。タイムリーかつ正確なエスカレーションのおかげで、お客様は少なくとも2件の重大なケースでSLA違反を回避することができました。これらのインシデント発生時のダウンタイムを大幅に削減することで、対応能力だけでなく、 事業継続性を確保する 能力も実証しました 。 イノベーション：ダッシュボードと監視ツールの開発 業務内容を把握した結果、既存のツールでは、私たちが目指すプロアクティブな監視とレポート作成には不十分であることに気づきました。このギャップを埋めるため、私たちは率先して、 透明性と実用的なインサイトを提供する カスタムダッシュボードを 開発しました。 シフト ダッシュボード : 現在勤務中の技術者、未解決の問題、解決済みのケース、エスカレーションなどをリアルタイムで表示します。 インシデント ダッシュボード : 日次、モデル、データ センター レベルでインシデントの傾向が表示されるため、週次分析に欠かせないツールになりました。 週次概要ダッシュボード : エスカレーション データや問題のパターンなど、過去 1 週間のインシデントに関する詳細なレポートが自動的に生成されます。 これらのツールは当初サービス範囲には含まれていませんでしたが、付加価値をもたらすと確信していました。時が経つにつれ、クライアントの週次分析プロセスに不可欠な要素となり、ワークフローの簡素化と意思決定の改善に貢献しました。 継続的な学習と変化への適応 予測管理システムは本質的に動的です。毎週の導入、新しいモデル、そして継続的なアップデートにより、環境が常に静的になることはありませんでした。私たちは、こうした変化に対応し、知識を常に最新の状態に保つためのプロセスを確立しました。 お客様のエンジニアとの 定期的な 短いミーティング、レビューセッション、そして知識共有は、 私たちの日常業務に欠かせないものとなりました。この協調的なアプローチにより、両者の連携が確保され、プロトコル、アーキテクチャ、導入方法の変更にも迅速に対応できるようになりました。 5 ～ 6 か月以内に、私たちはまだ手探りのチームから、付加価値のあるイノベーションを実現しながら L1 タスクを独立して処理できる、自信に満ちた信頼できるパートナーへと変貌を遂げました。 課題とその克服方法 旅には困難がつきものでした。私たちは次のようなことに遭遇しました。 新しいタイプのインシデント : 新しい問題が発生するたびに、問題と解決手順を文書化し、将来の参照用としてリポジトリを構築しました。 頻繁な展開 : これには、俊敏性を維持し、プロセスを毎週適応させる必要がありました。 複数のモデルと新しいデータ センター : 監視とトラブルシューティングの複雑さが増します。 ピーク時の障害 ：8時間シフト中に、時折、複数の障害が発生することがありました。当社のオンコール技術者は、これらの状況を冷静に処理し、問題の優先順位を決定し、必要に応じてエスカレーションを行い、システムの安定性を確保しました。 あらゆる課題は、私たちのプロセスを改良し、知識を深め、顧客への付加価値を高める機会でした。 結論：信頼と感謝の旅 振り返ってみると、大手市場プレーヤーへの競争力のある製品として始まったものが、信頼、成長、そして成功を基盤とした素晴らしい道のりへと進化しました。わずか数ヶ月の間に、私たちは傍観者から システムの信頼性を担う主体 へと変貌を遂げました 。 私たちの貢献は L1 サポートの範囲を超えました。 効果的なインシデント管理とタイムリーなエスカレーションにより、ダウンタイムを短縮することができました。 透明性、監視、レポートを改善するカスタマイズされたダッシュボードを開発しました。 私たちは、ダイナミックな発展に対応するために、継続的な学習と適応のプロセスを確立しました。 インシデントの処理を文書化して標準化したので、将来のソリューションはより迅速かつ信頼性の高いものになります。 最も重要なのは、私たちが単なるサポートチームではなく、クライアントにとって信頼できるパートナーになったことです。私たちの開発は、専門知識、コミットメント、そして革新性が融合すれば、規模は障害にならないことを証明しました。 この成功事例は、私たちのチームの回復力、学習能力、そして付加価値創造への揺るぎないコミットメントを実証しています。今日の急速に変化するテクノロジー環境において、信頼性と信頼こそがあらゆるパートナーシップの成功の礎であることを強調しています。

LLMはより良く、より小規模になっている Llamaを例に考えてみましょう。これらのモデルの急速な発展は、AIにおける重要なトレンド、つまり効率性とパフォーマンスの優先を示しています。 Llama 2 70Bが2023年8月に発売された当時、最高級のエントリーモデルと目されていました。しかし、その巨大なサイズのために、NVIDIA H100アクセラレータなどの強力なハードウェアが必要となりました。約9か月後、MetaはLlama 3 8Bを発表しました。これはサイズが約9分の1に縮小されたモデルです。これにより、より小型のAIアクセラレータや最適化されたCPUでも動作できるようになり、ハードウェアコストと消費電力を大幅に削減しました。驚くべきことに、Llama 3 8Bは精度テストにおいて、大型の前モデルを上回る性能を発揮しました。 セットアップの詳細 llama.cppでテスト済み マシン: Gv4 r8g.24xlarge オペレーティングシステム: Ubuntu 2204 カーネル: 6.8.AWS モデル: Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 試運転 nproc x nthreads x bs [1-32] 利点を強調する観察結果を示すグラフ トークン生成は自己回帰的であり、必要な出力長に非常に敏感です。ARM最適化により、バッチサイズが大きくなってスループットが2倍以上に向上します。 結論 Meta-Llama-3.1-8B-Instruct-Q8_0.gguf の場合、Graviton4 では 1 秒あたり 161 トークンを生成でき、これは 1 ドルあたり 102,486 トークンに相当します。