M3 UltraとDeepSeek R1 671Bのローカル性能検証

上記のビデオをNotebookLMに読ませて、次の問い合わせで得た情報

「モデルのサイズに応じたトークン/秒の値を表形式で表示して下さい。」

はい、最新Mac Studio M3 UltraでDeepSeek R1(671B)をローカル実行した際の性能について、モデルのサイズに応じたトークン/秒の値を表形式で以下に示します。

モデルサイズトークン/秒 (mlx)トークン/秒 (gguf)備考
1.5 billion約 230-262
7 billion約 113-116
14 billion約 50-62
32 billion約 29-32
70 billion約 15-16Llamaのクアンタイズモデル
671 billion (4bit)約 13-20約 7-17ggufはGPUオフロード設定により変動、mlxの方が高速な傾向

重要なポイント:

  • mlx形式のモデルは、Appleシリコンに最適化されているため、一般的にgguf形式よりも高いトークン/秒を記録しています。
  • 671 billionパラメータのモデル(4bitクアンタイズ)の場合、mlx形式でおおよそ13-20トークン/秒gguf形式ではGPUオフロードの設定により約7-17トークン/秒となっています。
  • gguf形式の671 billionパラメータモデルでは、GPUオフロードを最大に設定することで、トークン/秒が向上する傾向が見られました。ただし、ビデオRAMの使用量が上限に近づく可能性もあるため注意が必要です。
  • 一般的に、モデルのパラメータサイズが大きくなるほど、トークン/秒の値は低下する傾向にあります。

上記は、提供されたソースに基づいた情報です。特に断りのない限り、数値は動画内で示された計測値や言及に基づいています。

DGX sparkでLLMモデルのサイズ 8B,32B,40Bを実行したさい、予想される性能は?

Grokの答え

NVIDIA DGX Sparkは、NVIDIA GB10 Grace Blackwell Superchipを搭載し、最大2000億パラメータのAIモデルをローカルで処理できるデスクトップ型AIスーパーコンピューターです。128GBの統合メモリと1000 AI TOPS(FP4精度)の性能を持ち、大規模言語モデル(LLM)の推論やファインチューニングに適しています。以下に、8B、32B、40BのLLMモデルを実行した場合の予想性能を、利用可能な情報に基づいて推定します。

1. 8B(80億パラメータ)モデルの性能

  • 推論性能: 8Bモデルは比較的小規模で、DGX Sparkの128GBメモリに十分収まります。FP4精度での1000 TOPSの計算能力を考慮すると、推論速度は数十トークン/秒(tokens/second)が期待されます。類似システム(例:NVIDIA 4090 GPU)では、8Bモデルで50-100 tokens/secondが一般的であり、DGX Sparkはこれを上回るか同等の性能(おおよそ60-120 tokens/second)が見込まれます。
  • ファインチューニング: 8Bモデルはメモリ帯域幅(273 GB/s)や計算リソースの制約を受けにくく、効率的にファインチューニング可能。バッチサイズを大きく設定でき、数時間から1日程度で高品質なチューニングが完了すると予想されます。
  • 消費電力: 約200Wの低消費電力で動作し、8Bモデルでは電力効率が非常に高い。

2. 32B(320億パラメータ)モデルの性能

  • 推論性能: 32Bモデルはメモリ使用量が増加し、128GBのメモリ内で動作可能ですが、量子化(例:FP4や4-bit)が必要な場合があります。GTC 2025でのデモでは、32Bモデル(R1-32B)のLoRAファインチューニング後の推論が「十数トークン/秒」(約10-20 tokens/second)と報告されています。これは、メモリ帯域幅やモデルサイズのスケーリングによる制約が影響している可能性があります。
  • ファインチューニング: 32Bモデルのファインチューニングは可能ですが、メモリ帯域幅(273 GB/s)がボトルネックになる場合があります。デモではリアルタイムでのLoRAチューニングが示されており、数分から数時間で軽量なチューニングが完了する性能が期待されます。
  • 課題: トークン生成速度が生成量増加に伴い低下する傾向が報告されており、長時間の推論では性能がやや落ちる可能性があります。

3. 40B(400億パラメータ)モデルの性能

  • 推論性能: 40Bモデルは32Bモデルよりさらにメモリを要求しますが、DGX Sparkの128GBメモリで量子化を活用すれば動作可能。推論速度は32Bモデルより若干低下し、10-15 tokens/second程度が現実的な範囲と考えられます。これは、メモリ容量と帯域幅の制約によるものです。
  • ファインチューニング: 40Bモデルのファインチューニングは可能ですが、効率的な量子化やバッチサイズの調整が必要。32Bモデル同様、LoRAなどの軽量手法なら数時間で完了する可能性が高いが、フルファインチューニングはメモリ制約から時間がかかる(1日以上)。
  • スケーラビリティ: 2台のDGX SparkをNVIDIA Connect-Xで接続すれば、最大4050億パラメータのモデルに対応可能ですが、40Bモデル単体では1台で十分動作します。

全体的な考察と注意点

  • メモリ制約: DGX Sparkの128GBメモリのうち、ユーザーデータ用は約100GBとされており、システムが28GBを占有します。これにより、32Bや40Bモデルでは量子化(FP4や4-bit)が必須となる場合があります。
  • 比較: 32BモデルをNVIDIA 4090(24GB VRAM)で動作させる場合、量子化を強く適用してもDGX Sparkより高速(20-30 tokens/second)な場合がありますが、メモリ容量の制約でファインチューニングは困難。DGX Sparkは大容量メモリと統合ソフトウェアスタック(NVIDIA AIソフトウェア)の利点で、推論とチューニングの両方でバランスが良い。
  • 電力効率: 200Wの低消費電力は、データセンター級の性能をデスクトップで実現する上で魅力的。8Bモデルでは余裕があり、32Bや40Bでも実用的な性能を発揮。
  • 実測値の不足: 現時点で具体的なベンチマーク(例:トークン生成速度の公式数値)が公開されておらず、推定はデモや類似システムに基づいています。実際の性能はモデル構造や最適化に依存します。
モデルサイズ推論性能 (tokens/second)ファインチューニング時間メモリ制約と注意点
8B60-120数時間128GBメモリで余裕あり。高速かつ効率的。
32B10-20数分~数時間 (LoRA)量子化推奨。メモリ帯域幅がボトルネックになる可能性。
40B10-15数時間~1日量子化必須。32Bよりやや低速、メモリ制約厳しい。

: 性能は量子化(FP4/4-bit)使用時の推定値。実測値はモデルやタスクにより変動する可能性あり。

手持ちのPCで実行した結果(数値はトークン/秒)

NucBox_M7 Pro Ryzen 9 PRO 6950HRTX3080+GTX1080
gemma3:4b15.3122.9
deepseek-r1:8b9.528.6
gemma3:12b20 – 25.9
deepseek-r1:32b3 – 4

AIMOS USB ボリュームコントローラ

参考URL

初期設定

メモ帳を起動し、フォーカスした状態で、AMOSのノブを押しながらPCと接続する。

iWit USB Controller V4.01
http+//iWit.me

Sort Press ) <1 Second To Enter Windows Mode

Long Press ) >1 Second To Enter Mac Mode
Enter Setup Mode

カスタマイズ

  • WINDOWS MODE –
    1 Clockwise + PageUp
    2 Counterclockwise + PageDown
    3 Press + Volume Mute
    4 Press~Clockwise + Volume~2
    5 Press~Counterclockwise + Volume-2
    6 Long Press + Volum Mute
    @RESTORE DEFAULT[
    @SAV ‘ QUIT[

LLM/RAG環境の構築

実行スクリプト

PS C:\Users\mars> docker run -d -p 3000:8080 –e RAG_EMBEDDING_ENGINE=ollama -e RAG_EMBEDDING_MODEL=bge-m3:latest –add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data –name open-webui-rag –restart always ghcr.io/open-webui/open-webui:main

PS C:\Users\mars>docker run -d -p 3000:8080 -e RAG_EMBEDDING_ENGINE=ollama -e RAG_EMBEDDING_MODEL=bge-m3:latest –gpus all –add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data –name open-webui –restart always ghcr.io/open-webui/open-webui:cuda

埋め込みモデル設定

  • 設定画面 → ドキュメント(Documents)セクションで:
  • セマンティックベクトルエンジン: Ollama
  • モデル名: bge-m3:latest
  • チャンクサイズ: 1500
  • チャンクオーバーラップ: 100
  • その他パラメータはデフォルト維持13
  • **知識ベース作成**
  • 1. Workspace → Knowledge → [+ Create Knowledge Base]
  • 2. 名前と用途(例: Assistance)を設定
  • 3. ドキュメントファイル(PDF/TXT/Markdown)をドラッグ&ドロップでアップロード[2][5]
  • **質問方法**
  • 1. 新規チャット作成時に使用するLLMを選択(例: Qwen2.5系モデル)
  • 2. チャット入力欄に`#`を入力→アップロード済みドキュメントを選択
  • 3. 自然言語で質問を入力[1][5]


openwab-uiの画面のchat controlパラメータで、設定をdefaultから変更した方が良い項目と内容を教えて

推奨される変更例:

以下は、一般的なユースケースにおける例です:

ユースケースMax TokensTemperatureTop-pRepetition Penalty
短い正確な回答1000.50.81.2
長文で詳細な説明3000.70.91.1
創造的・自由な文章生成5001.01.01.0

Grokに問い合わせた結果

Open WebUIのRAG機能を利用する場合、重要なパラメータなどの要素と、その設定値は?

Open WebUIでRAG(Retrieval-Augmented Generation)機能を利用する際、効果的な動作を実現するためには、いくつかの重要なパラメータや設定要素を適切に調整する必要があります。以下に、主要な要素とその設定値について説明します。これらはOpen WebUIの管理者パネル(例: 「設定 > ドキュメント」や「ワークスペース > モデル」)で調整可能な項目に基づいています。


1. 埋め込みモデル (Embedding Model)

  • 役割: ドキュメントをベクトル化し、検索時の類似度計算に使用するモデル。
  • デフォルト: Sentence Transformers(例: all-MiniLM-L6-v2)。軽量だがパラメータ数が少ない。
  • 推奨設定値:
  • 高精度を求める場合: nomic-embed-text(137Mパラメータ)やmxbai-embed-large(334Mパラメータ)など、より大きなモデルを選択。
  • 多言語対応が必要な場合: bge-m3(多言語対応で高性能)。
  • ポイント: デフォルトモデルは軽量だが精度が不足する場合があるため、用途に応じて変更を検討。モデル変更後はドキュメントの再アップロードが必要。

2. モデル再ランキング (Model Reranking)

  • 役割: 検索結果の関連性を再評価し、より適切なドキュメントを上位に配置。
  • デフォルト: 再ランキングなし。
  • 推奨設定値:
  • 軽量モデル: cross-encoder/ms-marco-MiniLM-L-6-v2(高速だが精度は中程度)。
  • 高精度モデル: cross-encoder/ms-marco-MiniLM-L-12-v2(より正確だが処理負荷が増加)。
  • ポイント: 再ランキングを有効にすると回答の質が向上する。特に情報量が多いドキュメントを扱う場合に有効。

3. チャンクサイズ (Chunk Size)

  • 役割: ドキュメントを分割するサイズ。検索精度とコンテキストのバランスに影響。
  • デフォルト: 1500トークン。
  • 推奨設定値:
  • 小規模ドキュメント: 500〜1000トークン(細かい粒度で検索精度を向上)。
  • 大規模ドキュメント: 1500〜2000トークン(コンテキストを広く保持)。
  • ポイント: 小さすぎるとコンテキストが不足し、大きすぎるとノイズが増えるため、ドキュメントの内容に応じて調整。

4. コンテキストの長さ (Context Length)

  • 役割: LLMが回答生成時に参照するコンテキストの最大長。
  • デフォルト: 2048トークン。
  • 推奨設定値:
  • 短い回答: 1024〜2048トークン。
  • 詳細な回答: 4096トークン(モデルが対応している場合)。
  • ポイント: 使用するLLMの最大トークン数に依存。長すぎると処理速度が低下する可能性がある。

5. トップK (Top K)

  • 役割: 検索結果から上位何件のドキュメントをコンテキストとして使用するか。
  • デフォルト: 10。
  • 推奨設定値:
  • 高精度重視: 3〜5(関連性の高いものだけを厳選)。
  • 情報量重視: 10〜15(幅広い情報をカバー)。
  • ポイント: 値が大きいほど多様な情報を含むが、ノイズも増える可能性がある。

6. ドキュメントの前処理

  • 役割: 検索用データの品質を向上させる。
  • 設定値:
  • テキストファイル推奨(PDFやWordは事前にテキスト変換)。
  • ノイズ除去(余分な空白、タブ、改行の整理)。
  • ポイント: 前処理が不十分だと検索精度が落ちるため、きれいなデータを用意することが重要。

7. 生成モデル (LLM)

  • 役割: 検索されたコンテキストをもとに回答を生成するモデル。
  • 推奨設定値:
  • ローカル: gemma2:2b(軽量)、ELYZA-japanese-Llama-2-13b(日本語対応)。
  • API経由: gpt-4o-mini(高精度だがコストがかかる)。
  • ポイント: RAGの効果は生成モデルの性能にも依存。ローカル環境ではハードウェアスペックを考慮。

設定の流れ(例)

  1. 管理者パネル > 設定 > ドキュメントで埋め込みモデルをbge-m3に変更。
  2. モデル再ランキングcross-encoder/ms-marco-MiniLM-L-12-v2を指定。
  3. チャンクサイズを1000、コンテキストの長さを2048、トップKを5に設定。
  4. 前処理済みのテキストファイルをアップロード。
  5. ワークスペース > モデルで生成モデル(例: gemma2:2b)を選択し、RAG用にカスタムモデルを作成。

注意点

  • ハードウェア依存: ローカル環境ではGPUやメモリ容量が処理速度に影響。
  • 再アップロード: 埋め込みモデルやチャンクサイズを変更した場合、既存ドキュメントを削除して再登録が必要。
  • 試行錯誤: 最適な設定はデータや用途により異なるため、実験しながら調整する。

これらのパラメータを適切に設定することで、Open WebUIのRAG機能を最大限に活用し、高精度で有用な回答を得られる環境を構築できます。

100K文字程度のテキストをRAGで検索すると仮定した際に、それぞれのパラメータの最適値は

100K文字程度のテキストをRAG(Retrieval-Augmented Generation)で検索する場合、データ量としては中規模(日本語で約50K〜100Kトークン程度と仮定)に該当します。この規模のテキストを効率的かつ高精度に処理するためには、パラメータの設定に以下の点を考慮する必要があります。以下に、前回の回答をベースに具体的な最適値を提案します。


前提条件

  • テキスト量: 100K文字(日本語の場合、約50Kトークンと仮定。句読点や単語の長さに依存)。
  • 目的: 関連性の高い情報を迅速に検索し、正確な回答を生成。
  • 環境: ローカル(GPUあり)またはクラウド(API利用)を想定。

1. 埋め込みモデル (Embedding Model)

  • 最適値: bge-m3
  • 理由:
  • 100K文字は複数のトピックを含む可能性が高く、多言語対応かつ高精度な埋め込みが必要。
  • bge-m3は約568Mパラメータを持ち、日本語を含む多言語で優れた性能を発揮。
  • 代替案: リソースが限られる場合、all-MiniLM-L12-v2(軽量かつそこそこの精度)。

2. モデル再ランキング (Model Reranking)

  • 最適値: cross-encoder/ms-marco-MiniLM-L-12-v2
  • 理由:
  • 中規模テキストでは検索結果にノイズが混ざりやすいため、再ランキングで精度を向上。
  • L-12-v2は精度と速度のバランスが良く、100K文字程度の処理に適している。
  • 代替案: 高速処理優先ならMiniLM-L-6-v2

3. チャンクサイズ (Chunk Size)

  • 最適値: 800〜1000トークン
  • 理由:
  • 100K文字(約50Kトークン)を50〜60チャンクに分割可能。
  • 800〜1000トークンは、1チャンクで十分なコンテキストを保持しつつ、検索時のノイズを抑える。
  • 補足:
  • 日本語は英語よりトークン数が多くなりがちなので、1000トークン以下に抑えるのが現実的。
  • 小さすぎると(例: 500トークン)コンテキストが不足し、大きすぎると(例: 2000トークン)関連性が薄れる。

4. コンテキストの長さ (Context Length)

  • 最適値: 2048トークン
  • 理由:
  • 検索結果から複数チャンク(例: トップ3〜5)を参照する場合、合計で1500〜2000トークン程度になる。
  • 2048トークンは多くのモデル(例: Llama系やGemma系)が対応可能で、実用的な上限。
  • 補足: 高性能モデル(例: GPT-4o, 128Kトークン対応)を使う場合、4096トークンも検討可能だが、ローカルでは負荷が増大。

5. トップK (Top K)

  • 最適値: 5
  • 理由:
  • 100K文字から50〜60チャンクが生成されると仮定し、上位5件で十分な関連性を確保。
  • 5は精度と情報量のバランスが良く、生成時のコンテキスト過多を防ぐ。
  • 補足: 幅広い情報を求める場合、10まで増やしても可。ただし、ノイズが増えるリスクを考慮。

6. ドキュメントの前処理

  • 最適値:
  • テキストを事前に整形(余分な空白や改行を削除)。
  • 段落ごとに明示的な区切り(例: ---)を挿入。
  • 理由:
  • 100K文字は構造化されていない場合が多く、前処理で検索精度を向上。
  • 日本語特有の曖昧な句読点を整理することで、チャンク分割が自然に。

7. 生成モデル (LLM)

  • 最適値:
  • ローカル: gemma2:9b(9Bパラメータで高精度かつ中規模データに適応)。
  • クラウド: gpt-4o-mini(コスト効率と性能のバランス)。
  • 理由:
  • 100K文字のコンテキストを理解し、自然な日本語で回答するには、中〜大規模モデルが必要。
  • gemma2:9bはローカルで実行可能な高性能モデル、gpt-4o-miniはAPI利用時の最適解。

具体的な設定例

  • 埋め込みモデル: bge-m3
  • 再ランキング: cross-encoder/ms-marco-MiniLM-L-12-v2
  • チャンクサイズ: 1000トークン
  • コンテキストの長さ: 2048トークン
  • トップK: 5
  • 前処理: 整形済みテキスト、段落区切り付き
  • 生成モデル: gemma2:9b(ローカル)またはgpt-4o-mini(クラウド)

想定される動作

  • チャンク数: 100K文字 ÷ 1000トークン ≈ 50チャンク。
  • 検索時間: 埋め込み生成と再ランキングで数秒〜十数秒(ハードウェア依存)。
  • コンテキストサイズ: トップ5 × 1000トークン = 約5000トークン(2048に制限されるため、実質上位2〜3チャンクが使用される)。

調整のポイント

  • 精度不足の場合: トップKを3に減らし、再ランキングモデルの精度を上げる(例: L-12-v2Electra)。
  • 速度不足の場合: チャンクサイズを1200に増やし、チャンク数を減らす。
  • コンテキスト不足の場合: コンテキスト長を4096に拡張(対応モデルが必要)。

この設定なら、100K文字程度のテキストをRAGで効率的に検索し、高精度な回答を生成できるはずです。実際のデータやハードウェアに応じて微調整してください。

世界一堅い軍事基地の内部【アメリカで最も安全な秘密の要塞】シャイアン・マウンテン

1987年に見学したことがあります。当時は、軍からの申し込みや各州の有力者等を介して団体で見学するツアーがあったようで、米空軍を通じてその中に加えてもらった。この動画によると、2006年にピーターソン宇宙軍基地へ移転し、2015年に電磁パルス攻撃に対しても有効なこの基地を復活させたとのこと。

出典 https://www.youtube.com/watch?v=RJg1iPwnaQg&t=4s&ab_channel=USAMilitaryChannel2

Googleのgeminiで内容を要約してみました。

このビデオは、シャイアンマウンテン宇宙軍基地と呼ばれる、コロラド州のロッキー山脈の地下にある巨大な地下要塞についてです。

この要塞は、冷戦時代に北米航空宇宙防衛司令部(NORAD)の司令部として使用するために建設されました。NORADは、人工衛星、核ミサイル、弾道ミサイル、戦略爆撃機の動きを24時間体制で監視するために、1957年にアメリカとカナダによって設立された組織です。

シャイアンマウンテン宇宙軍基地は、1961年から1967年にかけて建設され、総費用は1億4240万ドルでした。花崗岩の山の下に建設され、30メガトンの核爆発にも耐えられるように設計されています。

基地内には15棟の建物があり、最大600万ガロンの水を貯蔵できる4つの貯水槽と、容量50万ガロンのディーゼル燃料貯蔵タンクがあります。また、核シェルターとしても機能し、食堂、売店、医療施設、フィットネスルームなど、生活に必要な設備がすべて揃っています。さらに、化学兵器、生物兵器、放射線などの汚染物質を除去するための換気フィルターも備えています。これらの設備により、核戦争後も最大800人が生き残ることが可能だと言われています。

冷戦が終結し、核の脅威が減少したため、NORADの司令部は2006年にピーターソン宇宙軍基地に移転しました。しかし、電磁パルス攻撃に対しても有効なこの基地を活用しようと、2015年にアメリカ国防総省は7億ドルをかけて基地を回収し、再稼働させました。

現在、シャイアンマウンテン宇宙軍基地は、有事の際に地下司令部として、また訓練施設として機能しています。

歴史は繰り返す(?) 米空軍が見通し外レーダーOTH-Bの復活を模索

USAF Considering Reuse of Previous Backscatter Sites

米国メイン州のOTH-Bサイト。1987年に訪問。このサイト専用の発電所もあったと記憶している。

The U.S. Air Force said that it is considering reuse of the previous Over the Horizon Backscatter (OTH-B) radar sites to augment the U.S.-Canadian North Warning System (NWS).

In fiscal 2024 the Air Force requests more than $423 million for rapid prototyping of OTH-B to supplement NWS, including funds to satisfy a classified U.S. European Command requirement, $360 million to fund the first two OTH-B sites in the U.S., and funds for the detection of stratospheric balloons and unidentified aerial phenomena.

BlackHat2016

2016年9月

BlackHat2016のarsenal部門に採択されてraspberry piとhackRFで構成したRF信号発生器WALB:Wireless Attack Launch Boxを発表

  • WALBから次のRF信号を生成
  • GPSスプーフィングでGoogleMap上でクリックし、位置を偽装するデモ(ポケモンGoの位置偽装に応用できるが、諸般の事情で直接的な説明は割愛)
  • ADSBの偽信号を生成し、幽霊航空機を出現させるデモ
  • デモ中の様子