CyberAgentLM3（calm3-22b-chat）とは｜VRAM要件の実算とローカル実行・量子化版の選び方

CyberAgentLM3-22B-Chat（Hugging Face上のリポジトリIDは cyberagent/calm3-22b-chat）は、サイバーエージェントが2024年7月9日に公開した225億パラメータの日本語大規模言語モデルです。公式リリースのとおりApache License 2.0で商用利用でき、GPUを用意すれば自社サーバー内だけで動かせます。ただし「22Bだから24GBのGPUに載る」という見積もりで進めると、文脈長が足りなくなります。このモデルはKVキャッシュが1トークンあたり1.125MiBと重く、公称の16,384トークンを使い切るとKVキャッシュだけで18GiBを占めるためです。本記事では、config.jsonからの実算、量子化版の選び方、GGUF版の「暫定版」注記の検証、実行手順、採用の判断基準を扱います。

まとめ｜先に押さえる6つの結論

• 正しいリポジトリIDは cyberagent/calm3-22b-chat です。「CyberAgentLM3-22B-Chat」はモデルの呼称で、この文字列をfrom_pretrainedに渡しても取得できません。
• 長い文脈ではKVキャッシュがモデル本体より大きくなります。4bit量子化（Q4_K_M）の本体12.71GiBに対し、16,384トークン分のKVキャッシュは18.00GiBです。24GB級GPUで16Kトークンを使うなら、KVキャッシュの量子化が前提になります。
• GGUF版の前処理のずれは、半角スペースの直後の記号と濁点を分解した表記で起きます。llama.cpp v0.8.0で照合したところ、記号を含まない日本語の文章1万1,000字余りはトークン列が完全に一致しました。
• 量子化版はGGUF・MLX・GPTQの3形式から選べます。Apple SiliconならMLXの4bit（11.81GiB）、vLLMで社内APIにするなら日本語で校正したGPTQ Int4（12.02GiB）、OllamaやLM StudioならGGUFです。
• Ollamaではタグを付けて取得します。コミュニティ版 schroneko/calm3-22b-chat はタグを省くとファイル容量24GBのq8_0が入るので、24GB級のGPUならq4_k_mなど小さい量子化タグを選んでください。
• 新規案件でこれから採用する理由は薄いと判断します。モデルファイルは2024年7月1日から更新がなく、サイバーエージェント自身も2026年は8Bの推論モデル（CAT-Thinking-8B）などへ軸足を移しています。

CyberAgentLM3-22B-Chatの仕様と公開条件

225億パラメータの内訳とコンテキスト長

公式リリースの「225億パラメータ」は、config.jsonから積み上げても一致します。隠れ層の次元6,144、層数48、中間層の次元16,384、語彙数65,024で計算すると、埋め込みと出力層が各3億9,950万、1層あたり4億5,299万となり、合計22,542,882,816パラメータです。Hugging Faceがsafetensorsのメタデータとして示す値も同じ22,542,882,816で、データ型はbfloat16です。量子化しないファイルは約45GBになります。

コンテキスト長はmax_position_embeddingsの値どおり16,384トークンです。日本語でこれが何文字にあたるかは、トークナイザを走らせれば確定します。transformers 4.57.6で技術文書調の日本語1,125文字を通すと500トークンで、1トークンあたり2.25文字でした。後述のGGUF検証で使った日本語の文章11,164字は5,766トークンで、1トークンあたり1.94文字でした。この2つのサンプルで換算すると16,384トークンは3万1,000〜3万7,000字ですが、英数字や記号が多い文書では下がり、出力とチャットテンプレートの分も同じ枠を使います。実際の文書は後述のコードでトークン数を数えて判断してください。

アーキテクチャはLlama系（LlamaForCausalLM）で、モデルカードには2.0兆トークンでスクラッチから事前学習したと書かれています。プロンプト形式はChatMLで、開始・終了トークンは <|im_start|> と <|im_end|> です。終了トークンID 65001が生成停止条件なので、プロンプトを自前で組む場合にここを取り違えると出力が止まりません。

Apache License 2.0で商用利用できる範囲

ライセンスはApache License 2.0です。商用利用、改変、再配布、クローズドな製品への組み込みが許諾され、出力物の利用を縛る追加条項もありません。再配布するときに求められるのは、第4項のとおりライセンス文の同梱、変更したファイルへの変更の明示、元の著作権表示の保持です。元の配布物にNOTICEファイルがある場合は、その帰属表示をNOTICEファイル、文書、所定の表示画面のいずれかに載せます。Llama系との差はここです。Llama 3.1のライセンスは、月間アクティブユーザー7億超の事業者にMetaの個別許諾を求め、Llamaを含む製品の配布・提供時は関連サイトや製品ドキュメントなどへの「Built with Llama」表示、Llamaやその出力で学習したモデルを配布・提供する場合は名称冒頭の「Llama」を義務づけています。

Apache License 2.0が決めるのは配布条件で、出力内容の安全性ではありません。ローカル実行では提供元のフィルタが挟まらないため、生成結果の検査や利用者ごとの制限は導入側で実装します。

「Llama-3-70B同等」という性能主張の前提

公開時のリリースは、Nejumi LLMリーダーボード3でMeta-Llama-3-70B-Instructと同等の性能を示したと述べています。この主張には「2024年7月時点」「スクラッチ開発の日本語オープンLLMとして」という前提が付いています。比較相手のLlama 3-70Bは2024年4月のモデルで、その後Llama 3.1、Llama 3.3が出ました。

サイバーエージェント自身も、17日後の2024年7月26日にLlama 3.1をベースとした705億パラメータの日本語モデル（Llama-3.1-70B-Japanese-Instruct-2407）を公開しています。リーダーボードの比較は、2024年7月時点のモデルと評価タスクでの結果です。比較相手の世代も評価項目も当時のままなので、いまこの数値を判断材料にするなら、自社のタスクデータで評価し直してください。

ローカル実行に必要なVRAMの実算

KVキャッシュが1トークンあたり1.125MiB必要な理由

推論中は、処理済みのトークンごとにKeyとValueをVRAM上に保持します。その量は「2（KとV）×層数×KVヘッド数×ヘッド次元×データ型のバイト数」で決まります。config.jsonはnum_attention_heads、num_key_value_headsともに48です。つまりGrouped Query Attention（GQA）を使っておらず、全ヘッドがKVを個別に持つMulti-Head Attentionの構成です。

計算すると、2×48層×48ヘッド×128次元×2バイト＝1,179,648バイトで、1トークンあたり1.125MiBになります。同じ開発元が2026年5月に公開したCAT-Thinking-8Bは、層数36・KVヘッド8のGQA構成なので、同じ式で1トークンあたり0.141MiBです。パラメータ数は約3分の1なのに、KVキャッシュは8分の1で済みます。仕組みの詳細はKVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】で扱っています。

文脈長ごとのKVキャッシュ見積もり

本体をQ4_K_M（12.71GiB）にしたとき、文脈長ごとのKVキャッシュと合計は次のとおりです。いずれも1系列（同時に1件の会話）分の値で、複数のリクエストを並列に処理するとKVキャッシュがその数だけ増えます。q8_0とq4_0は、llama.cppのggml-common.hが定める32要素ごとのブロック（q8_0は34バイト、q4_0は18バイト。スケールの保存分を含む）で計算しています。f16に対して約53%と約28%で、単純な半分・4分の1にはなりません。

合計欄はモデル本体とKVキャッシュだけの理論値で、実際には計算用のバッファやドライバの確保分が別に加わります。量はGPU、バッチサイズ、実行環境で変わるので、最後は ollama ps や nvidia-smi で実測してください。24GBのGPUでKVをf16のまま使うと、理論値の段階で8,192トークンでも21.71GiBとなり、余裕はわずかです。KVをq8_0にすると16,384トークンで合計22.27GiBです。RTX 4090などの24GB級GPUのメモリは24GiB（nvidia-smiの表示で約24,500MiB）なので、計算用の領域に使えるのは2GiB弱です。16K近くまで使うなら、文脈長を1万2,000トークン程度に抑えるか、GPUのメモリに余裕のある構成を選んでください。40GB以上のGPUなら、Q4_K_MとQ5_K_Mは16,384トークンをf16のまま扱えます。量子化しないbf16を16Kトークンで動かすには合計60GiBが要り、1枚のGPUに全部載せるなら80GB級が必要です。device_map=”auto”なら複数のGPUやCPUに分けて載せることもできますが、CPUに回した分は遅くなります。

KVキャッシュの量子化による精度への影響について、OllamaのFAQは「GQAのカウントが高いモデル（Qwen2など）ほど影響が大きくなりうる」と書いており、GQAを使わない本モデルは影響を受けにくい側です。ただしq4_0は「文脈が長いほど劣化が目立ちうる」ともあるので、長文ではq8_0を選んでください。

入力する文書が何トークンになるかは、モデル本体を落とさずに確かめられます。トークナイザのファイルは数MBで、PyTorchも要りません。

from transformers import AutoTokenizer

tok = AutoTokenizer.from_pretrained("cyberagent/calm3-22b-chat")
text = open("doc.txt", encoding="utf-8").read()
n = len(tok(text)["input_ids"])
print(n, "tokens", round(n * 1.125 / 1024, 2), "GiB (KV f16)")

量子化版の選び方｜GGUF・MLX・GPTQの3形式

形式ごとのファイルサイズと動かす道具

サイバーエージェントは量子化版を出していません。Hugging Face上のコミュニティ版のうち、実用上の候補は次の3形式です。サイズはHugging FaceのAPIで取得した重みファイルの合計で、GiBは1,073,741,824バイト基準です。

選び方は実行環境で決まります。MacのユニファイドメモリならMLXの4bitが最も小さく、mlx-lmはトークナイザをtransformersのAutoTokenizerで読むため、元のモデルと同じ前処理で動きます。使い方はMLXとは？mlx-lmの使い方｜生成・量子化・サーバ・LoRAの手順とApple Siliconでの採用判断【2026年10月】にまとめています。社内向けAPIとして複数人で使うなら、リポジトリ名のとおり日本語1,000件で量子化を校正したGPTQ版をvLLMで配信する構成が合います（vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違い・0.32.0の脆弱性対応）。1台のPCで手軽に試すならGGUFで、OllamaやLM Studioから扱えます。形式ごとの違いはGGUFとは？量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】を参照してください。

GGUF版の「暫定版」注記を実トークナイザで検証した結果

GGUF版の配布元READMEは冒頭で、このファイルが本来の性能を発揮できていない「暫定版」だと書いています。2024年7月3日時点のllama.cppがCALM3固有のpre-tokenization（文字列をトークンに分ける前の前処理）に対応しておらず、llama.cppの既定の前処理で代用したためです。2026年11月1日時点でも、llama.cppのmasterにある前処理の登録一覧にcalm3はありません。GGUFのメタデータも tokenizer.ggml.pre = default のままです。

では実際にどこで差が出るのか。元モデルのtokenizer.jsonが定める前処理は、NFC正規化、数字を1桁ずつに分ける処理、GPT-2系の正規表現による分割の3つです。これをHugging Faceのtokenizers 0.23.3で動かした結果と、llama.cpp v0.8.0（2026年10月28日公開）のllama-tokenizeにQ4_K_M版GGUFの語彙を読ませた結果を、同じ入力で突き合わせました。

語彙だけのGGUFは、Q4_K_M版ファイルの先頭40MBを取得し、メタデータ部分（トークン一覧・マージ規則・設定値）だけを抜き出してテンソル0本のファイルとして作りました。重みを含まないファイルで前処理を比べたもので、生成品質を評価したものではありません。この範囲では、本記事の旧版本文から取った日本語の文章11,164字のトークン列が完全に一致しました。数字を1桁ずつに分ける処理も、語彙に2桁以上の数字トークンが1つも無いため、既定の前処理で結果が変わりません。入力の分け方が同じなら、モデルが受け取る入力も同じです。ただし生成結果は量子化の影響も受けるので、READMEの性能に関する警告そのものを否定する根拠にはなりません。

今回ずれが見つかった条件は2つです。ひとつは半角スペースの直後に記号が来る箇所で、「 =」「 “」「 (」を元のモデルは1トークンで読み、GGUF版は2トークンに割ります。コードに多い並びですが、日本語の文でも「これは (参考) です。」は元の前処理で6トークン、GGUF版で7トークンになりました。元のトークナイザと異なる分け方でモデルに渡ることになるので、コード生成やJSON出力を頼む用途や、半角括弧を多用する文書を扱うならtransformers・MLX・GPTQのどれかを選んでください。もうひとつは、macOSのファイル名などから来る濁点を分解したNFD表記です。元の前処理はNFC正規化で1文字に戻しますが、GGUF版はバイト列のまま読むため「ガ」が3トークンに割れます。こちらはモデルに渡す前に unicodedata.normalize(“NFC”, text) を通せば避けられます。照合に使ったコマンドは次の形です。

# 元の前処理（Hugging Face tokenizers）
python -c "from tokenizers import Tokenizer; t=Tokenizer.from_file('tokenizer.json'); print(t.encode(open('in.txt').read(), add_special_tokens=False).ids)"
# GGUF版の前処理（llama.cpp v0.8.0）
llama-tokenize -m calm3-vocab.gguf -f in.txt --ids --no-bos --log-disable

実行手順｜transformersとOllama

transformersで動かす場合の注意点

公式モデルカードのコードは、2024年7月1日から更新されていないため、transformers 5系では2か所を直す必要があります。ひとつは引数名で、2026年10月30日公開のtransformers 5.22.1でもtorch_dtypeには「torch_dtype is deprecated! Use dtype instead!」という警告が出るので、dtypeに替えます。もうひとつはapply_chat_templateの戻り値で、v5の移行ガイドのとおり、input_idsのテンソルではなくinput_idsとattention_maskを持つ辞書（BatchEncoding）を返すようになりました。カードのようにそのままgenerateの第1引数へ渡す書き方は、5系では成り立ちません。transformers 5.22.1はPython 3.11以上が必要で、PyTorchと、device_map=”auto”を使うためのaccelerateも併せて入れておきます。

from transformers import AutoModelForCausalLM, AutoTokenizer, TextStreamer

model = AutoModelForCausalLM.from_pretrained(
    "cyberagent/calm3-22b-chat", device_map="auto", dtype="auto")
tokenizer = AutoTokenizer.from_pretrained("cyberagent/calm3-22b-chat")
streamer = TextStreamer(tokenizer, skip_prompt=True, skip_special_tokens=True)

messages = [
    {"role": "system", "content": "あなたは親切なAIアシスタントです。"},
    {"role": "user", "content": "AIによって私たちの暮らしはどのように変わりますか？"},
]
inputs = tokenizer.apply_chat_template(
    messages, add_generation_prompt=True, return_tensors="pt",
    return_dict=True).to(model.device)
output_ids = model.generate(
    **inputs, max_new_tokens=1024, temperature=0.5, streamer=streamer)

temperatureが効くのは、このモデルのgeneration_config.jsonにdo_sample: trueが入っているためです。この設定を持たないモデルにコードを流用すると、temperatureはサンプリングに使われません。

apply_chat_templateが作る文字列は次の形です。上のメッセージ2件は、末尾の生成開始プロンプトを含めて31トークンになります。推論サーバーの生のプロンプトを受け取るAPI（completion系）に投げる場合は、この形をそのまま再現してください。messages形式で受け取るチャットAPI（OllamaのAPI/chatやOpenAI互換のchat completions）はサーバー側でテンプレートを当てるので、この文字列を送るとテンプレートが二重にかかります。

<|im_start|>system
あなたは親切なAIアシスタントです。<|im_end|>
<|im_start|>user
AIによって私たちの暮らしはどのように変わりますか？<|im_end|>
<|im_start|>assistant

推論をAPIとして社内に提供する段階の構成は、LLM Servingとは？vLLM・SGLang・Ollamaの比較と推論サーバーの構築・性能指標で整理しています。

OllamaでGGUFを動かす場合のタグ指定

Ollamaの公式ライブラリに、CyberAgentLM3やcalm3という名前のモデルはありません。「ollama pull calm3」は通らず、経路は2つです。ひとつはHugging FaceのGGUFリポジトリをhf.coドメイン付きで指定する方法で、タグを省くとQ4_K_Mが選ばれます。もうひとつはコミュニティがOllamaに登録した schroneko/calm3-22b-chat です。こちらはタグ一覧でlatestとq8_0が同じダイジェストを指しており、タグを省くと一覧の表示で24GBのq8_0が入ります。表示はファイル容量で、実行時にはKVキャッシュと計算用の領域が上乗せされます。24GB級のGPUでは文脈を短くしてもCPUへのオフロードが起きやすく、速度が大きく落ちるので、q4_k_m（表示14GB）など量子化タグを明示してください。

ollama run hf.co/grapevine-AI/CALM3-22B-Chat-GGUF:Q4_K_M

ollama run schroneko/calm3-22b-chat:q4_k_m

チャットテンプレートを別に用意する必要はありません。GGUFにはChatML形式のchat_templateとcontext_length 16384がメタデータとして入っており、Ollamaが読み取ります。

文脈長の既定値は、OllamaのContext lengthページによるとVRAMで段階的に決まり、24GiB未満は4K、24GiB以上48GiB未満は32K、48GiB以上は256Kです。16GB級のGPUでは4Kになり、モデル上限の4分の1しか使いません。24GiB以上なら既定の32Kが選ばれますが、Ollamaのソース（llm/server.go）は要求値が学習時の文脈長を超えると警告を出して上限まで下げるので、実際は16,384トークンになります。KVキャッシュを量子化する場合は次のように起動します。

OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

現行のOllamaは、対応するバックエンドとGPUならFlash Attentionを自動で有効にし、KVキャッシュの量子化はFlash Attentionが有効なときだけ効きます。自動で有効にならない環境では OLLAMA_FLASH_ATTENTION=1 を併せて指定します。OLLAMA_KV_CACHE_TYPEはサーバー全体の設定で、同じサーバーで動かす全モデルに適用されます。割り当てられた文脈長は ollama ps のCONTEXT列で確認できます。

CyberAgentLM3の採用判断｜2026年11月時点の後継モデルとの比較

公式の派生モデルと後継モデルの系譜

判断材料として最も確かなのは、開発元がその後どう動いたかです。Hugging Face APIから取得した値を時系列に並べると次のようになります。日付はリポジトリの作成日で、一般公開日やプレスリリースの日付とは一致しないことがあります。

calm3の系統で唯一の公式派生が、2025年2月公開のcalm3-22b-chat-selfimprove-experimentalです。calm3自身に、国立情報学研究所のAnswer Carefully Datasetを元にした不適切な質問と応答のデータを作らせ、DPO（Direct Preference Optimization）で学習させています。モデルカードのNejumi LLMリーダーボード3の値は、汎用的言語性能（GLP）が0.6193から0.6107へわずかに下がる一方、アライメント（ALT）は0.6703から0.7207、そのうち毒性は0.7053から0.8239へ上がりました。同じコードとプロンプトで動き、構成もcalm3と同一なので、本記事のVRAM計算はそのまま当てはまります。社外の利用者に出力を見せる用途でcalm3を使い続けるなら、まずこちらとの比較をおすすめします。名前のとおり実験版である点は承知のうえで選んでください。

Hugging Faceで公開されたテキスト生成モデルを見る限り、スクラッチで事前学習したモデルはcalm3が最後で、以降の公開は既存モデルへの日本語追加学習です。2026年のCAT-Thinking-8BとCAT-Paws-8Bは、東京科学大学のQwen3-Swallow-8B-CPT-v0.2を土台に、日本語で推論過程を書くよう強化学習したモデルです。Paws はコーディングやツール利用を含む複数ターンのエージェント用途向けで、モデルカードは単発のタスクにはThinkingを勧めています。どちらも出力は4,096トークンで学習されており、難しい指示では繰り返しに陥りやすいとモデルカード自身が注意しています。土台のSwallowについてはSwallow LLMとは？最新のGPT-OSS Swallow・Qwen3 Swallow v0.2とモデル一覧・選び方【2026年10月】で扱っています。

他モデルと比較するときにリポジトリで見る4項目

ローカルLLMの比較記事の多くはパラメータ数とベンチマークを並べますが、それだけでは本記事のKVキャッシュのような見落としが起きます。選定の実務では、各リポジトリのconfig.jsonとモデルページで次の4項目を見てください。どれもモデル本体を落とさずに読めます。

• num_key_value_heads と num_attention_heads：同じ値ならMulti-Head AttentionでKVキャッシュが重くなります。前者が1より大きく後者より少なければGQAで、同じ文脈長でもKVキャッシュは「KVヘッド数÷アテンションヘッド数」の比率に縮みます。
• num_hidden_layers と hidden_size：ヘッド数と合わせて、1トークンあたりのKVキャッシュを「2×層数×KVヘッド数×（hidden_size÷ヘッド数）×2バイト」で計算できます。head_dimが別に書かれているモデル（Qwen3系など）はその値を使います。
• max_position_embeddings：位置埋め込みの上限で、公称の文脈長と一致しないことがあります。Mistral NeMoは設定上1,024,000ですが、Mistral公式の案内は「up to 128k tokens」です。開発元の公称値と突き合わせてください。
• リポジトリの更新履歴とライセンス：config.jsonの外ですが同じページで確認できます。最終更新日に加えて、コミット履歴とCommunityタブの既知の問題が対応されているかを見てください。重みの更新が止まっていても、推論ライブラリ側の修正で解決する問題はありますが、モデル固有の不具合は直りません。ライセンスは商用可否に加え、Llama 3.1のような名称・表示義務まで読んでください。

国産オープンLLMの現行世代を同じ観点で見たい場合は、LLM-jp-4とは？8B・32B-A3B・33Bと4.1の違い・性能・使い方【2026年10月】が参考になります。

採用してよい場面と、避けたほうがよい場面

新規案件でこれから採用する積極的な理由は、2026年11月時点では見当たりません。同じ開発元の新しいモデルのほうが、文脈長でもVRAM効率でも上回るためです。次の条件に当てはまるなら避けてください。長い文書を一度に読ませたい（16,384トークンの上限に当たります）、24GBのGPU1枚でKVを量子化せずに運用したい（8Kトークン程度しか確保できません）、推論過程を見せる応答やツール呼び出しが必要（calm3はどちらも学習していません）、最新のベンチマークを根拠に社内稟議を通したい（公開時の比較相手はLlama 3世代です）。

採用が合理的な場面もあります。ひとつは、すでにこのモデルで検証を終えて本番で動かしている場合です。モデルファイルが更新されないので、重みは固定されます。推論ライブラリの版、量子化形式、temperatureなどの生成設定も合わせて固定すれば、検証時と同じ条件で動かし続けられます。条件が変わらないこと自体に価値がある用途なら、乗り換える必要はありません。もうひとつは、日本語中心のデータでスクラッチ事前学習された商用可能な22B級モデルが、比較対象やファインチューニングの土台として必要な場合です。追加学習の手法はUnslothとは？読み方とDesktopの使い方、Studio・Coreとの違い【2026年10月】が選択肢になります。モデル選定から社内環境への組み込みまでを外部に任せたい場合は、当社の生成AI導入支援でも扱っています。

よくある質問

CyberAgentLM3とcalm3は同じモデルですか？

同じモデルです。CyberAgentLM3が正式な呼称で、calm3はHugging Face上のリポジトリ名に使われている略称です。対話向けに調整したChat版のリポジトリIDは cyberagent/calm3-22b-chat で、プログラムから読み込むときはこちらを指定します。

CyberAgentLM3-22B-ChatはOllamaの公式ライブラリにありますか？

ありません。hf.co/grapevine-AI/CALM3-22B-Chat-GGUF:Q4_K_M のようにHugging FaceのGGUFを指定するか、コミュニティ版 schroneko/calm3-22b-chat を量子化タグ付きで使います。

日本語の文章は何文字くらい入力できますか？

上限は16,384トークンで、文字数の上限はありません。本記事の2つの日本語サンプルでは3万1,000〜3万7,000字に相当しましたが、英数字や記号が多いと減り、出力の分も同じ枠を使います。実際の文書はトークナイザで数えてください。

出力内容のフィルタリングは自前で用意する必要がありますか？

必要です。ローカル実行では提供元のフィルタが挟まらないため、入力と出力の検査層は導入側で用意します。不適切な質問への応答をDPOで改善した公式派生 calm3-22b-chat-selfimprove-experimental も比較候補になります。

ローカルLLMとは何ですか？

外部の推論APIを使わず、自社のサーバーや社内PCにモデルの重みを読み込んで推論する形態です。GPUで動かすのが一般的ですが、llama.cppなどはCPUだけでも、CPUとGPUの併用でも動きます。推論のために入力データを外部へ送らない、外部の推論APIの従量課金がかからない、モデルの取得後は通信が切れても推論できる、という利点があります。ただし周辺のアプリやツールが外部と通信する場合は、その分は別に管理が必要です。その代わりハードウェアの調達とメモリの見積もりは導入側の作業になり、本記事のKVキャッシュの計算がそのまま必要になります。全体像はローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説で解説しています。

関連記事

• ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説
• KVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】
• GGUFとは？量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】
• Swallow LLMとは？最新のGPT-OSS Swallow・Qwen3 Swallow v0.2とモデル一覧・選び方【2026年10月】
• LLM-jp-4とは？8B・32B-A3B・33Bと4.1の違い・性能・使い方【2026年10月】