オンプレLLMで社内文書を書き分ける - Mac Studio M1 Max x llama.cpp x gemma-4 31B の構成

Last updated at 2026-04-30Posted at 2026-04-30

オンプレLLMで社内文書を書き分ける - Mac Studio M1 Max x llama.cpp x gemma-4 31B の構成

はじめに

「品質不具合の社内報告書を、プレスリリース用の対外文面と、ISO 9001 準拠の社内是正処置報告に書き分けたい。でも、社内文書を OpenAI や Google のクラウドに投げるのは、規程上ほぼ不可能」
──製造業の品質保証部門や法務部門から、こうした声をよく聞くようになりました。

クラウド LLM の性能は申し分ないものの、型番・ロット番号・顧客名・仕入先情報が載った社内文書を外部 API に送ることは、多くの企業で NG です。かといって自前で大規模モデルを動かすには、数百万円クラスの GPU サーバーと専用の電源・冷却環境が必要──と、これまではハードルが高い選択肢でした。

そこで今回は、手元の Mac Studio M1 Max 64GB に llama.cpp の llama-server を立て、gemma-4-31B-it の GGUF 量子化モデルを動かす構成を検証しました。ポイントは、Apple Silicon の Unified Memory により、GPU と CPU が同じメモリ空間を共有できることです。離散 GPU のように VRAM 容量だけで制約されにくく、40GB 前後のメモリを使う 31B 級モデルでも、64GB 構成の範囲で実務検証が可能でした。

本記事では、Mac Studio M1 Max 64GB + llama.cpp + gemma-4 31B という構成で、クラウドに出せない社内文書をオンプレミスで処理する 実務運用パターンを、具体的な業務文書を題材に検証します。

本記事のデータ測定に関して、弊社の澤口が全面的に実施しております。

本記事は、筆者が所属するクイックイタレート株式会社で検証・運用している社内向けオンプレLLM環境をベースにした事例紹介です。
弊社ではオンプレ LLM 環境の設計・構築・運用のご相談も承っております。
詳細はこちらのページをご覧ください。

システム全体像

今回の検証環境は、単体の llama-server だけでなく、
DOCUMENT 登録、RAG 検索、UI/API を含む小さな社内向けアプリとして構成しています。

設計の核心：社内文書を社外に一切出さない

本構成の核心は、「社内文書を社外に一歩も出さず、LLM の表現力だけを借りる」 という割り切りにあります。Mac Studio を社内 LAN に置き、業務端末からはローカルネットワーク経由でのみアクセスする。これにより、以下の観点を同時に達成しています。

観点	効果
データ主権	型番・ロット番号・顧客名・仕入先情報が一切社外に出ない
費用	月額 API 課金なし。基本はハードウェア費と電気代のみ
ネットワーク依存なし	社内 LAN 内で完結し、外部 API 障害に左右されない
規程対応	外部サービス利用時に必要な DPA・稟議・データ分類確認を大幅に簡略化しやすい
レスポンスタイム	ローカル LAN 内で完結するため、外部 API 往復のオーバーヘッドがない

クラウドLLM / GPUサーバー構築 / 本構成の比較

「社内で業務文書を LLM に処理させたい」という要件に対する代替案と比較してみます。

項目	クラウドLLM（Claude/GPT-4 等）	GPUサーバー自前構築	本構成（Mac Studio M1 Max x gemma-4 31B）
初期費用	ほぼゼロ	GPU + 筐体で数百万円〜	Mac Studio 1台から開始可能
月額コスト	従量課金（文書量次第で増加）	電気代・保守・冷却	電気代と保守のみ
社内文書の社外流出	DPA・契約・規程確認が必要	なし	なし
運用負荷	低	高（GPU ドライバ・CUDA・冷却・騒音）	低（macOS + llama.cpp）
モデル品質	最高クラス	モデル次第	31B クラスで業務文書用途を検証可能
オフライン動作	不可	可	可
チーム利用	API側は容易	GPUリソース設計が必要	数名規模の試験運用から始めやすい

「この LLM は外に何も送っていない」という構造的な安心感は、規程遵守の現場では計り知れない価値があります。これは単なる費用最適化ではなく、データ主権を前提とした防御的設計 として捉えるべきものです。

ハードウェア選定：Mac Studio M1 Max 64GB

今回の用途に Mac Studio M1 Max 64GB を選んだ理由は、31B 級モデルをローカルで扱ううえで、Apple Silicon の Unified Memory が実用上の逃げ道になる からです。

項目	仕様
機種	Mac Studio
チップ	Apple M1 Max
CPU コア	10 コア（高性能Pコア 8 + 高効率Eコア 2）
GPU コア	32 コア
Neural Engine	16 コア
メモリ	64GB Unified Memory
メモリ帯域	400 GB/s
ストレージ	494.38 GB
OS	macOS Tahoe 26.1
消費電力（推論中）	約40.2 W
騒音	ほぼ無音・低騒音で、オフィス設置でも気になりにくい

選定の軸は3つです。

Unified Memory 400GB/s：GPU と CPU が同じメモリを共有するため、離散 GPU の VRAM 容量だけに縛られにくい
64GB で 31B Q8_0 を検証可能：今回の gemma-4-31B-it Q8_0 ではピークメモリが約40.88GBで、OSや周辺プロセスを含めても64GB内に収まった
静音・省電力・省スペース：オフィスのデスク下に置いて終日稼働しやすく、GPU サーバーのような騒音・発熱・ラック設置の問題が小さい

Mac Studio を社内 LAN から直接アクセス可能な LLM サーバーとして運用する場合、llama-server やアプリAPIの --host 0.0.0.0 バインドは社内セグメントに限定し、インターネット側のファイアウォールで完全に遮断してください。オンプレ LLM の意義はデータが外に出ないことであり、誤って外部に公開すると設計思想が根本から崩れます。

llama.cpp と gemma-4 31B のセットアップ

llama.cpp のビルド

Apple Silicon での最短ビルド手順です。
Metal バックエンドは Apple Silicon なら利用できるため、検証時は Metal 有効の Release ビルドを使いました。

# 作業ディレクトリは任意
cd ~/src

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

cmake -B build \
  -DGGML_METAL=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build \
  --config Release \
  -j "$(sysctl -n hw.ncpu)"

./build/bin/llama-server --version
ls build/bin/llama-cli build/bin/llama-server

検証時の llama.cpp バージョンは 8680 (15f786e65)。AppleClang により Darwin arm64 向けにビルドしました。Gemma 4 系は比較的新しいアーキテクチャのため、古いビルドだと対応していない可能性があります。検証時は新しめの llama.cpp を使うのが安全です。

モデルの入手

Hugging Face から GGUF 形式の量子化済みモデルを取得します。検証に使用したモデル一覧は以下です。

モデル	量子化	ファイルサイズ	入手元
gemma-4-E2B-it	Q8_0	約 4.97GB	`ggml-org/gemma-4-E2B-it-GGUF`
gemma-4-E4B-it	Q8_0	約 8.03GB	`ggml-org/gemma-4-E4B-it-GGUF`
gemma-4-26B-A4B-it	Q5_K_M	約 21.2GB	`unsloth/gemma-4-26B-A4B-it-UD-Q5_K_M.GGUF`
gemma-4-31B-it	Q8_0	約 32.6GB	`unsloth/gemma-4-31B-it-GGUF`
Qwen3.6-35B-A3B	Q5_K_M	約 24.7GB	`batiai/Qwen3.6-35B-A3B-GGUF`

メイン検証は gemma-4-31B-it Q8_0。31B dense モデルなので、26B-A4B のような MoE ではありません。そのぶん推論は重くなりますが、品質不具合報告書のような業務文書の書き分けでは、安定した日本語出力を確認する代表モデルとして扱いました。

llama-server の起動

業務文書を扱うなら、llama-cli でワンショットで叩くより、
llama-server を立てて OpenAI 互換 API として使う ほうが実務向けです。

検証時は、アプリ側の API を 8080、llama-server を 8002 に分けて起動しました。

llama-server \
  -m <YOUR_MODEL_PATH>/gemma-4-31B-it-Q8_0.gguf \
  -c 16384 \
  -ngl 99 \
  --reasoning off \
  --host 127.0.0.1 \
  --port 8002 \
  --cache-prompt \
  --cache-reuse 256 \
  --metrics \
  --perf

-c 16384：今回の実測条件。長文PDFを丸ごと投入するのではなく、RAGで必要チャンクを投入する前提
-ngl 99：Metal GPU へのオフロード
--cache-prompt / --cache-reuse 256：同一文書・同一文脈への連続質問を高速化するための prompt cache
--metrics / --perf：計測用。通常運用では必要に応じて外す

社内 LAN の他マシンから直接叩く場合は --host 0.0.0.0 にできますが、必ず社内セグメントに限定し、インターネット側から到達できないことを確認してください。

ユースケース①：品質不具合報告書からの文書書き分け

ここからが本番です。
「クラウドに出せない社内文書を、ローカルで書き分ける」 というユースケースを具体的に示します。

元ネタ：架空の品質不具合報告書

以下は検証用に作成した完全架空の社内報告書です。製品名・型番・ロット番号・数値はすべて架空ですが、製造業の品質保証部門で実際に書かれる報告書の粒度を意識しました。

────────────────────────────────────────
品質不具合 第一報（社内限）
文書番号：QA-2026-0417
発行日：2026年4月17日
発行部署：品質保証部
────────────────────────────────────────

1. 製品情報
   製品名：産業用 DC 電源装置
   型番：PSU-24V-30A-M2
   対象ロット：L2026-03-A ～ L2026-03-C（製造週：2026年 第11～13週）
   対象ロット製造数：2,400 台
   うち出荷済：1,870 台
   社内在庫：530 台

2. 発見経緯
   2026年4月12日、客先（製造業A社、半導体製造装置向け）より
   「納入後 3～6週間経過した装置で、定格出力付近の連続運転時に
    出力電圧が一時的に 23.4V 前後まで低下する」との申告。
   同日、社内保管の同ロット品 5 台で再現試験を実施、うち 2 台で
   類似の電圧低下（最大 0.8V）を確認。

3. 不具合事象
   - 発生条件：周囲温度 35℃以上、出力負荷 80% 以上、連続運転 2 時間以上
   - 症状：出力電圧が定格 24.0V から 23.3～23.5V へ緩やかに低下
   - 安全性：発煙・発火・感電のリスクは認められない
   - 顧客装置への影響：半導体製造装置の精度仕様（±2%）の境界付近で
     間欠的なアラートが発生している事例あり

4. 原因調査結果（暫定）
   - 対象ロットの出力段平滑コンデンサ（C17、105℃品、公称値 2200μF）に
     使用されたロット（仕入先：部品メーカーB社、ロット BX-202601）で、
     静電容量の初期値が規格下限（1980μF）付近に偏っている個体が混入。
   - サンプリング測定の結果、対象ロット品 20 個中 3 個で 2000μF 未満。
   - 高温・高負荷時のリップル電流増加により、容量低下が出力電圧の
     ドループとして顕在化したと推定。
   - 他ロット（BX-202512 以前）の同一部品では再現せず。

5. 影響範囲
   - 市場で顕在化：1 件（A社、約 15 台分の装置で間欠アラート）
   - 対象出荷ロット：1,870 台（L2026-03-A～C）
   - 想定される潜在影響：低温環境・軽負荷運用の顧客では顕在化していない
     可能性が高く、影響範囲は出荷先運用条件に依存する。

6. 暫定処置
   - 2026年4月15日付で L2026-03-A～C の社内在庫 530 台を出荷停止。
   - 仕入先B社へ該当部品ロット BX-202601 の使用停止を通告、
     代替ロット BX-202604 への切替えを指示。
   - 既出荷品について、顧客へ個別に運用条件の確認と無償交換の
     案内を順次実施中。

7. 恒久対策（検討中）
   - コンデンサ受入検査項目に静電容量の全数測定を追加（現状はサンプリング）。
   - 出力段リップル電流のワーストケース設計見直し、
     設計マージンを 15% から 25% へ拡大する方向で検討。
   - 仕入先B社へ、原料ロット切替時の追加サンプリング試験を要求。

8. 今後の予定
   - 4月25日：恒久対策会議（設計部・製造部・品質保証部）
   - 4月末：対策プロトタイプでの再現試験
   - 5月中旬：対策品の製造開始予定
   - 対外対応：プレスリリース発行・顧客通知文の配信は広報部と協議中

────────────────────────────────────────
作成：品質保証部 [担当者]
承認：品質保証部長 [担当者]
────────────────────────────────────────

この中には絶対にクラウド API に送ってはいけない情報が詰まっています──製品型番、対象ロット、顧客業界、仕入先名と部品ロット、市場での顕在化件数、恒久対策の検討状況。だからこそ、オンプレ LLM が必要になるのです。

プロンプト設計

この報告書を DOCUMENT に登録し、RAG で関連チャンクを検索したうえで、
3 種類の異なる文書を書き分けさせます。

プロンプトはこうです。

添付の社内品質不具合報告書を読み、以下の3種類の文書を書き分けてください。

【1】プレスリリース用文面
- 一般消費者・報道機関向け
- 技術的詳細は最小限に、安全性・影響範囲・対応姿勢を明確に
- 400字程度、見出し付き

【2】BtoB 顧客への個別通知文
- 納入先の技術部門・購買部門向け
- 発生条件・影響範囲・暫定処置・恒久対策の時間軸を具体的に
- ビジネス文書として丁寧な言い回しで、800字程度

【3】社内向け是正処置報告（ISO 9001 準拠）
- 8D レポート / CAPA の形式を意識
- 不適合内容・原因分析（なぜなぜ）・再発防止策・有効性評価・水平展開
- 箇条書きで簡潔に、体言止め中心

それぞれ明確に見出しで分けて出力してください。

生成結果

以下は gemma-4-31B-it Q8_0 による出力例です。

【1】プレスリリース用文面（31B 出力）

【重要】産業用DC電源装置「PSU-24V-30A-M2」の一部ロットに関する不具合と無償交換のお知らせ

株式会社〇〇（以下、当社）は、産業用DC電源装置「PSU-24V-30A-M2」の一部ロットにおいて、特定の条件下で出力電圧が低下する不具合が判明いたしました。

本件は、内部部品の個体差に起因するものであり、発煙や発火、感電などの安全性に関わるリスクはございません。しかしながら、お客様のご利用環境によっては、装置のアラート発生などの影響を及ぼす可能性がございます。

当社は本件を厳粛に受け止め、対象ロットをご利用のお客様に対し、順次無償交換を実施させていただきます。対象製品をご利用のお客様には、弊社担当者より個別にご案内申し上げます。

お客様および関係者の皆様には多大なるご迷惑とご心配をおかけしますことを深くお詫び申し上げます。当社は今後、品質管理体制をさらに強化し、再発防止に全力を尽くしてまいります。

【2】BtoB 顧客への個別通知文（31B 出力）

【2】BtoB 顧客への個別通知文

2026年4月〇日

お客様各位

株式会社〇〇
品質保証部長 [氏名]

産業用DC電源装置「PSU-24V-30A-M2」の不具合に関するご報告とお願い

拝啓

貴社におかれましては、ますますご清栄のこととお慶び申し上げます。平素は弊社製品をご愛顧いただき、厚く御礼申し上げます。

この度、弊社製品「PSU-24V-30A-M2」の一部ロットにおいて、出力電圧が定格を下回る不具合が判明いたしました。貴社へ納入いたしました製品の中に対象ロットが含まれている可能性があるため、下記の通りご報告申し上げます。

1. 対象製品およびロット
製品名：産業用DC電源装置（型番：PSU-24V-30A-M2）
対象ロット：L2026-03-A ～ L2026-03-C

2. 不具合の内容と発生条件
特定の部品ロット（コンデンサ）の静電容量が規格下限付近であったため、以下の条件下で出力電圧が23.3V～23.5Vまで低下する事象を確認しております。
【発生条件】周囲温度35℃以上、出力負荷80%以上での2時間以上の連続運転時

3. 影響範囲
本件は電圧の緩やかな低下であり、発火等の安全性に影響するものではございません。しかしながら、貴社装置の精度仕様（±2%等）によっては、間欠的にアラートが発生する可能性がございます。

4. 対応および今後のスケジュール
弊社にて代替品を準備しており、対象ロットをご使用のお客様には無償にて交換を実施させていただきます。
・運用条件の確認：弊社担当より順次ご連絡させていただきます。
・代替品への切替え：5月中旬より対策品の製造を開始し、順次配送いたします。

5. 再発防止策
部品受入検査における静電容量の全数測定への変更、および設計マージンの拡大（15%→25%）を検討しており、恒久的な品質改善を図ります。

本件により多大なるご不便をおかけしますことを深くお詫び申し上げます。本件に関するお問い合わせは、弊社営業担当または品質保証部までお願い申し上げます。

敬具

【3】社内向け是正処置報告 ISO 9001 準拠（31B 出力）

【3】社内向け是正処置報告（ISO 9001準拠）

不適合報告書（CAPA）
文書番号：QA-2026-0417-CAPA

1. 不適合の内容（D2）
- 対象：PSU-24V-30A-M2（ロット L2026-03-A～C）
- 事象：高負荷・高温環境下での出力電圧ドロップ（24.0V → 23.3～23.5V）
- 影響：顧客装置での精度アラート発生（1件顕在化）

2. 暫定処置（D3）
- 社内在庫（530台）の即時出荷停止（4/15実施）
- 仕入先B社へ該当部品ロット（BX-202601）の使用停止通告および代替ロット（BX-202604）への切替え指示
- 出荷済顧客への運用条件確認および無償交換の案内開始

3. 原因分析（D4：なぜなぜ分析）
- 現象：出力電圧が低下
- なぜ：高温・高負荷時にリップル電流が増加し、電圧ドループが顕在化
- なぜ：出力段平滑コンデンサ（C17）の静電容量が不足
- なぜ：部品メーカーB社の特定ロット（BX-202601）において、容量値が規格下限付近に偏った個体が混入
- なぜ：現行の受入検査がサンプリング測定であり、ロット内のバラツキを検知できなかった

4. 恒久対策（D5/D6）
- 検査強化：コンデンサ受入検査をサンプリングから全数測定へ変更
- 設計変更：出力段リップル電流のワーストケース設計を見直し、設計マージンを15%から25%へ拡大
- サプライヤー管理：原料ロット切替時の追加サンプリング試験をB社へ要求

5. 有効性評価および水平展開（D7/D8）
- 検証：4月末に対策プロトタイプによる再現試験を実施し、電圧低下が解消されることを確認
- 水平展開：同一コンデンサを使用している他製品の受入検査基準および設計マージンの再点検を実施
- 完了予定：5月中旬に対策品製造開始、以降の出荷分より適用

何が起きたか

同じ一本の報告書から、想定読者・文体・構造が完全に異なる 3 種類の文書が、一度のプロンプトで生成されました。注目すべき点は 3 つです。

プレスリリースでは「発煙・発火のリスクなし」という安全性を冒頭に置き、技術詳細（BX-202601 など）は一切出さない
顧客通知文では型番・発生条件・対象ロット番号までを含め、先方の技術部門が設備管理台帳と照合できる粒度で情報を出す
是正処置報告では ISO 9001 の枠組みに沿って、原因分析・再発防止・水平展開が項目化される

もちろんこれらは最終稿ではなく、下書きです。最終的には人間のレビューと法務チェックを経て公開されます。しかし、ゼロから書き起こすのと、下書きをレビューするのでは、かかる時間も精神的負荷も桁違いです。

ユースケース②：長文 PDF からの情報抽出

オンプレ LLM のもう一つの強みは、
クラウドに出せない業務文書を、社内環境だけで検索・要約・構造化できることです。

今回の構成では、PDF全文を128K/256Kコンテキストへ丸ごと投入するのではなく、PDFをDOCUMENTとして登録し、embedding と Qdrant による RAG 検索で関連チャンクを取り出し、その文脈を LLM に渡します。
これにより、数百ページ級のPDFに対しても、必要箇所を抽出しながら質問応答できます。

入力資料

PDF：避難情報に関するガイドライン（令和8年3月内閣府防災担当）
参考URL：https://www.bousai.go.jp/oukyu/hinanjouhou/r3_hinanjouhou_guideline
ページ数：150ページ

プロンプト例：避難情報に関するガイドラインの抽出

添付のPDFから、3つの避難行動である「立退き避難」「屋内安全確保」「緊急安全確保」のそれぞれの定義と特徴を抽出し、箇条書きで整理してください。

出力要件：
- それぞれの行動がどのようなものか（定義）
- どのような状況やタイミング（警戒レベル等）でとるべき行動か
- その行動を選択する際の必須条件や注意点
- 各項目の末尾に、参考にしたPDFの出典ページ番号を併記すること

出力例

1. 立退き避難
- 定義：自宅・施設等にいては命が脅かされるおそれがあるため、その場を離れ、災害リスクのある区域等の外側など、安全な場所に移動すること。[p.15]
- 状況・タイミング：警戒レベル3（高齢者等避難）または警戒レベル4（避難指示）の発令時。[p.15]
- 注意点：指定緊急避難場所のほか、安全な親戚・知人宅、ホテル・旅館等も避難先となる。[p.15]

2. 屋内安全確保
- 定義：ハザードマップ等で浸水想定等を確認し、自宅・施設等の上階への移動や高層階に留まることで、計画的に身の安全を確保すること。[p.15]
- 状況・タイミング：洪水等・高潮において、警戒レベル3または4の段階で選択し得る行動。[p.15]
- 必須条件：家屋倒壊等氾濫想定区域にないこと、浸水しない居室があること、水・食糧・電気・トイレ等の支障を許容できること。[p.15]

3. 緊急安全確保
- 定義：避難し遅れた場合や災害が急激に切迫した場合に、その時点でいる場所より相対的に安全な場所へ直ちに移動すること。[p.17]
- 状況・タイミング：警戒レベル5（緊急安全確保）の発令時、または災害が発生・切迫した状況。[p.17, p.24]
- 注意点：この行動をとっても身の安全を確保できるとは限らず、警戒レベル3や4の段階で避難することが重要。[p.17]

何が起きたか

百ページ超の PDF に対して、質問に応じて関連箇所を検索し、構造化された回答を返すことができました。これが意味するのは以下です。

災害対策本部の初動で、マニュアルを人間が探している時間を短縮できる
クラウドに出せない住民情報・個別支援計画書と組み合わせて、同じ社内環境で運用できる
電源・通信が制限される災害現場でも、ローカルで動く LLM が持つ意味は大きい

ここでも、ローカルで完結するという事実が用途を成立させます。

実務上の注意点：prompt cache が前提

長文 PDF や RAG 文脈を扱う場合、初回の prompt eval（入力全体の処理）に時間がかかります。decode 速度は速くても、入力文脈が長くなるほど prompt eval の待ち時間が効いてきます。

今回のモデル比較では、ユースケース①の品質不具合報告書を DOCUMENT に登録し、top_k=10 で検索したうえで min_score=0.45 を適用しました。実際に LLM へ注入された文脈は中央値で2チャンクです。これはPDF全文を丸ごと投入した測定ではなく、RAGで必要箇所を抽出して投入した場合の実測です。

代表値として、gemma-4-31b-it-q8_0 では以下の結果となりました。

指標	実測値
RAG文脈込み入力トークン数	1,365 tokens
実取得チャンク数	2 chunks
初回 prompt eval 時間	11.37 秒
2回目以降 cache hit時	0.109 秒
Decode 速度	9.85 tok/s
ピークメモリ使用量	40.88 GB

gemma-4-31b-it-q8_0 は Q8_0 量子化でピークメモリが約40.88GBまで増え、decode速度は9.85 tok/sとなりました。一方で、prompt cache が効いた2回目以降の prompt eval は0.109秒まで短縮されています。
つまり、初回は入力文脈の処理に待ち時間が発生しますが、同じ文書・同じ文脈に対する連続質問では、prompt eval の負担をほぼ無視できる水準まで下げられます。

実務では --cache-prompt / --cache-reuse を有効にし、同一文書に対する連続質問を前提に運用するのが現実的です。これを忘れると、毎回 prompt eval をやり直すことになり、特に長い文脈では体感待ち時間が大きくなります。

モデル比較：tok/sec とリソース使用率

手元で動かした各モデルの性能を並べます。
測定には、ユースケース1の品質不具合報告書を DOCUMENT に登録し、RAG検索結果を LLM コンテキストへ注入したうえで、プレスリリース・BtoB顧客通知・ISO 9001是正処置報告の3種類を書き分けるタスクを使用しました。

条件は top_k=10、min_score=0.45、context_size=16384、temperature=0.2、出力上限2048 tokensで統一しています。min_score 適用後に実際に投入された文脈は中央値で2チャンク、RAG文脈込みの入力トークン数は約1,361〜1,482 tokensでした。

各モデルは3回ずつ実行し、表には中央値を掲載しています。
測定には llama.cpp 内蔵の --perf ログに加え、powermetrics と ps による llama-server プロセスのリソース監視を使用しました。

生成速度とメモリ使用量

モデル	量子化	初回prompt秒	prompt tok/s	decode tok/s	cache後prompt秒	Peak Mem GB	GPU avg %
gemma-4-e2b-it-q8_0	Q8_0	0.82	1,661.7	65.02	0.018	5.02	100.0
gemma-4-e4b-it-q8_0	Q8_0	1.55	880.3	44.91	0.026	8.34	99.9
gemma-4-26b-a4b-it-q5_k_m	Q5_K_M	1.85	753.9	45.97	0.025	22.37	99.8
gemma-4-31b-it-q8_0	Q8_0	11.37	120.1	9.85	0.109	40.88	99.8
qwen3.6-35b-a3b-q5_k_m	Q5_K_M	2.12	700.4	46.15	0.045	24.13	99.9

初回prompt秒 は、prompt cache が効いていない初回実行時に、RAG文脈込みの入力をモデルが処理するのに要した時間です。cache後prompt秒 は、同一プロンプトを2回目に実行した際の prompt eval 時間です。decode tok/s は回答生成速度を示します。

GPU 使用率は powermetrics --show-process-gpu による GPU active residency を採用しました。Apple Silicon では NVIDIA GPU のように VRAM 使用量を独立して見るのではなく、Unified Memory 上のプロセス RSS と GPU active residency を組み合わせて推論時の負荷を評価しています。
今回の測定では全モデルで GPU active residency がほぼ100%となっており、llama.cpp の Metal バックエンドで GPU を使えていることが確認できました。

グラフ

生成速度：Decode tok/s

メモリ使用量：Peak Mem GB

Prompt cache効果：初回prompt秒 vs cache後prompt秒

観察されたこと

gemma-4-31b-it-q8_0 は decode 9.85 tok/s、ピークメモリ40.88GBで、今回の比較では最も重い結果になった。31B dense Q8_0 は品質確認用の代表モデルとして扱いやすい一方、速度・メモリ面では明確に重い。
gemma-4-26b-a4b-it-q5_k_m は decode 45.97 tok/s で、gemma-4-e4b-it-q8_0 の 44.91 tok/s とほぼ同等だった。MoE により、総パラメータ26B級でありながら生成速度は小型モデルに近い
gemma-4-26b-a4b-it-q5_k_m は gemma-4-31b-it-q8_0 と比べて decode が約4.7倍速く、ピークメモリも約18.5GB少なかった。
qwen3.6-35b-a3b-q5_k_m は decode 46.15 tok/s、ピークメモリ24.13GBで、26B-A4Bに近い実用レンジだった。
GPU avg % は全モデルでほぼ100%となり、llama.cpp の Metal バックエンドでGPUを使えていることを確認できた。ただし、モデル間の差はGPU使用率そのものではなく、decode tok/s とピークメモリに強く現れた。

設計上のちょっとした工夫

Mac Studio を「社内LLM推論エンジン」として位置づける

このアーキテクチャで重要なのは、Mac Studio の役割を 「社内 LAN 向けの LLM 推論エンジン」に限定 し、外部公開の責務 を一切担わせないことです。

役割	アクセス手段	想定ユーザー
一般利用者（品質保証・法務・設計部）	業務端末のブラウザ / CLI	社内ネットワーク内から `http://mac-studio:8080`
LLM サーバー管理者	Mac Studio の macOS 画面 / SSH	llama.cpp のアップデート、モデル差し替え
セキュリティ担当	ファイアウォールポリシー確認	インターネット側からの接続を全遮断する責務

「LLM を社内に閉じ込めることで、セキュリティ責務を『社内 LAN に閉じていること』へ寄せられる」 のが、この構成の構造的優位性です。
クラウド LLM を使おうとすると、DPA 締結・社内稟議・データ分類ポリシー策定・監査ログ要件などの確認が増えます。オンプレ LLM なら、それらを大幅に簡略化しやすくなります。

モデル差し替えが「ファイル 1 つ置くだけ」で済む

新しいモデルが出たら、基本的な作業は以下です。

Hugging Face などから GGUF ファイルをダウンロード
models/ ディレクトリに配置
.env の LLM_MODEL_ID / LLM_MODEL_PATH を差し替え
llama-server を再起動

これだけで済みます。GGUF + llama.cpp の強みで、「最新モデルが出るたびに環境構築をやり直す」必要がありません。

まとめ

本記事では、以下を見てきました。

Mac Studio M1 Max 64GB を社内 LAN 設置の LLM サーバーとして構築
llama.cpp + gemma-4 31B を Q8_0 で動作
品質不具合報告書から 3 種類の文書を書き分けるユースケースを検証
長文 PDF を RAG で検索し、必要箇所を構造化抽出するユースケースを検証
モデルサイズ別に tok/sec・メモリ・GPU 使用率を実測

ポイントは、「クラウドに出せない社内文書を、手元で書き分けられる」 という割り切りです。LLM の表現力をクラウド API から借りるのではなく、Apple Silicon と GGUF モデルを使って社内に閉じる。この責務分離が、コスト・セキュリティ・運用負荷・規程遵守を構造的に軽くしてくれます。

担う層	何に専念しているか
Mac Studio M1 Max	Unified Memory で31B級モデルを抱えること
llama.cpp	Metal バックエンドで推論を回すこと
gemma-4 31B	業務文書の書き分け・長文抽出の表現力を提供すること
RAG基盤	社内文書から関連チャンクを検索すること
社内 LAN	Mac Studio と業務端末をつなぐこと
ファイアウォール	インターネット側との遮断を担保すること

「クラウド LLM を使えない業務がある。だから LLM を諦める」 ではなく、
「クラウドに出せないなら、手元で動かせばいい」
──Mac Studio M1 Max と gemma-4 31B の組み合わせは、この選択肢を現実的なコストで手に入れられるところまで来ました。
同じ構成を検討されている方の判断材料になれば幸いです。

関連リンク

本記事は、筆者が所属するクイックイタレート株式会社での検証・運用実績をもとに執筆しています。関連する公開事例は事例紹介をご覧ください。
オンプレ LLM 環境の設計・構築・運用のご相談も承っております。
詳細はこちらのページをご覧ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

オンプレLLMで社内文書を書き分ける - Mac Studio M1 Max x llama.cpp x gemma-4 31B の構成

オンプレLLMで社内文書を書き分ける - Mac Studio M1 Max x llama.cpp x gemma-4 31B の構成

はじめに

システム全体像

設計の核心：社内文書を社外に一切出さない

クラウドLLM / GPUサーバー構築 / 本構成 の比較

ハードウェア選定：Mac Studio M1 Max 64GB

llama.cpp と gemma-4 31B のセットアップ

llama.cpp のビルド

モデルの入手

llama-server の起動

ユースケース①：品質不具合報告書からの文書書き分け

元ネタ：架空の品質不具合報告書

プロンプト設計

生成結果

【1】プレスリリース用文面（31B 出力）

【2】BtoB 顧客への個別通知文（31B 出力）

【3】社内向け是正処置報告 ISO 9001 準拠（31B 出力）

何が起きたか

ユースケース②：長文 PDF からの情報抽出

入力資料

プロンプト例：避難情報に関するガイドラインの抽出

出力例

何が起きたか

実務上の注意点：prompt cache が前提

モデル比較：tok/sec とリソース使用率

生成速度とメモリ使用量

グラフ

生成速度：Decode tok/s

メモリ使用量：Peak Mem GB

Prompt cache効果：初回prompt秒 vs cache後prompt秒

観察されたこと

設計上のちょっとした工夫

Mac Studio を「社内LLM推論エンジン」として位置づける

モデル差し替えが「ファイル 1 つ置くだけ」で済む

まとめ

クラウドLLM / GPUサーバー構築 / 本構成の比較