CyberAgentLM3-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トークンを使い切ると本体とは別に18GiBを消費するためです。本記事では公式リリースとモデル定義ファイルから確定できる仕様、量子化ファイルの実サイズに基づくVRAM計算、transformersとOllamaでの実行手順、そして公開から2年が経った2026年8月時点でこのモデルを選ぶべきかの判断基準を扱います。

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

• 正しいリポジトリIDは cyberagent/calm3-22b-chat です。「CyberAgentLM3-22B-Chat」はモデルの呼称であり、この文字列をfrom_pretrainedに渡しても取得できません。
• VRAMの支配要因はモデル本体ではなくKVキャッシュです。4bit量子化（Q4_K_M）の本体12.71GiBに対し、16,384トークン分のKVキャッシュは18.00GiBを占めます。
• 24GB級GPUで16Kトークンを使うにはKVキャッシュの量子化が事実上必須です。OllamaならOLLAMA_KV_CACHE_TYPEをq8_0にすると、KVが約半分の9.00GiBに収まります。
• Ollamaの公式ライブラリにこのモデルはありません。コミュニティ製GGUFを使いますが、そのGGUFは配布元自身が暫定版と明記しており、日本語の前処理が本来の実装と異なります。
• 新規案件でこれから採用する理由は薄いと判断します。Hugging Face上のファイルは2024年7月1日から更新が止まっており、サイバーエージェントはその3週間後には文脈長131,072トークンの70Bモデルを公開しているためです。

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

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

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

コンテキスト長はmax_position_embeddingsの値どおり16,384トークンです。日本語がこれで何文字に相当するかは、モデルのトークナイザを実際に走らせれば確定します。transformers 4.57.6で技術文書調の日本語1,125文字を通したところ500トークンとなり、1トークンあたり2.25文字でした。文章の性質によって2.0前後まで下がるため、16,384トークンは日本語でおよそ3万3,000字から3万7,000字と見ておくと安全です。

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

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

ライセンスはApache License 2.0です。商用利用、改変、再配布、クローズドな製品への組み込みがいずれも許諾され、出力物の利用に対する追加の制限条項もありません。この点はLlama系モデルとの実務上の差になります。Llama 3.1のライセンスは、リリース日時点で月間アクティブユーザーが7億を超える事業者にMetaからの個別許諾を求め、さらに派生モデルの名称冒頭に「Llama」を含めること、配布物に「Built with Llama」を明示することを義務づけています。Apache License 2.0にこうした条項はありません。残る義務は著作権表示とライセンス全文の同梱、および改変したファイルへの変更明示です。自社製品に組み込んで再配布する場合は、この2点をリリース物に含めてください。

なお、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と後継が出ています。

付け加えると、サイバーエージェント自身がこの3週間後の2024年7月26日に、Llama 3.1をベースとした705億パラメータの日本語モデル（Llama-3.1-70B-Japanese-Instruct-2407）をHugging Faceで公開しています。「22Bで70B相当」という比較の意味は、同じ開発元から実物の70B日本語モデルが出た時点で薄れました。2026年8月時点でこの数値を意思決定の根拠にするなら、当時のベンチマーク結果ではなく、自社のタスクデータで再評価するのが妥当です。

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

量子化GGUFの実ファイルサイズ

ローカル実行では量子化済みのGGUFを使うのが現実的です。コミュニティが公開しているgrapevine-AI/CALM3-22B-Chat-GGUFについて、Hugging FaceのAPIから取得した実バイト数は次のとおりです。ここでのGiBは1,073,741,824バイト基準です。

KVキャッシュを足すと、ここから様相が変わります。

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

推論中は、これまでに処理したトークンごとにKeyとValueをVRAM上に保持します。その量は「2（KとV）×層数×KVヘッド数×ヘッド次元×データ型のバイト数」で決まります。CyberAgentLM3-22B-Chatの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です。同世代以降の主要モデルと比べると重さが際立ちます。Qwen2.5-32B-Instructは層数64と多いにもかかわらずKVヘッドが8しかないため、1トークンあたり0.250MiBで済みます。パラメータ数は約328億（Hugging Faceのsafetensorsメタデータ基準。公式モデルカードの表記は32.5B）とこちらのほうが4割以上大きいのに、KVキャッシュの消費量は4.5分の1です。

合計欄はモデル本体とKVキャッシュだけの数字です。実際にはこれに計算バッファとドライバの確保分が1〜2GiB加わるため、表の値ぎりぎりの構成は避けてください。4bit量子化で本体を12.71GiBまで削っても、16Kトークンを使い切る構成では合計30.71GiBです。24GBのGPUには収まりません。

GPU別に確保できる文脈長

表の数値から逆算すると、判断はこうなります。24GBのGPUでQ4_K_Mを使い、KVキャッシュをf16のまま運用する場合、実際に確保できるのは8,000トークン前後です。日本語では約1万8,000字にあたり、長文の社内規程やソースコード全体を一度に渡す用途には足りません。ここでKVキャッシュをq8_0に量子化すると、16,384トークンでも9.00GiBに収まり、合計21.71GiBとなって24GBの枠に入ります。

KVキャッシュの量子化については、Ollamaの公式FAQに判断材料があります。同FAQは、GQAのカウントが高いモデルほど量子化による精度への影響が大きくなりうると述べています。本モデルはGQAを使わないMulti-Head Attention構成なので、この記述に従えば影響が小さい側です。KVを重く抱える代わりに量子化の副作用は受けにくい、という構図になります。

40GB以上のGPUであれば、Q4_K_MとQ5_K_Mは16,384トークンをf16のまま余裕をもって扱えます。Q6_Kは本体17.23GiBとKV 18.00GiBで合計35.23GiBとなり、40GBのGPUでは残りが数GiBしかありません。実測での確認をおすすめします。無量子化のbf16を16Kトークンで動かすには合計60GiBが必要で、80GB級のGPUが前提になります。

入力する文書が何トークンになるかは、モデル本体をダウンロードしなくても確認できます。トークナイザのファイルだけなら数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)")

量子化そのものでVRAMを削る方向については、三値量子化まで踏み込んだ手法を1bit LLM「Bonsai」とは？三値量子化でスマホ動作するローカルLLMの仕組みと実装判断を解説【2026年】で扱っています。

実行手順｜transformersとOllamaの2経路

transformersで動かす場合の注意点

公式モデルカードが示すコードには、引数名が古くなっている箇所があります。モデルカードは2024年7月1日から更新されていないため、torch_dtypeという引数名のままです。この引数は検証に用いたtransformers 4.57.6で「torch_dtype is deprecated! Use dtype instead!」という警告を出し、現行最新の5.15.0（2026年8月10日公開）でも同じ警告が残っています。互換のため受け付けはされますが、新規に書くならdtypeを使ってください。なおtransformers 5系はPython 3.10以上が必要です。

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によって私たちの暮らしはどのように変わりますか？"},
]
input_ids = tokenizer.apply_chat_template(
    messages, add_generation_prompt=True, return_tensors="pt").to(model.device)
output_ids = model.generate(
    input_ids, max_new_tokens=1024, temperature=0.5, streamer=streamer)

temperatureの指定が効くのは、本モデルのgeneration_config.jsonにdo_sample: trueが入っているためです。この設定を持たないモデルへコードを流用すると、temperatureは警告もなく無視されます。

apply_chat_templateが生成する文字列は、実行して確認すると次のとおりです。上のメッセージ2件は、末尾の生成開始プロンプトを含めて31トークンになります。フレームワークを使わず自前でHTTP経由の推論サーバーに投げる場合は、この形を厳密に再現してください。

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

推論をAPIとして社内提供する段階まで進める場合の構成は、LLM Servingとは？推論をAPI提供する仕組みと主要フレームワーク比較【2026年版】で整理しています。

OllamaでGGUFを動かす場合の指定方法

Ollamaの公式モデルライブラリに、CyberAgentLM3およびcalm3という名前のモデルは登録されていません。したがって「ollama pull calm3」のような取得はできません。経路は2つあります。ひとつはHugging Face上のGGUFリポジトリをhf.coドメイン付きで直接指定する方法で、Hugging Face公式ドキュメントが案内している記法です。量子化タグを省略した場合はQ4_K_Mが選ばれます。もうひとつはコミュニティがOllamaへ登録した schroneko/calm3-22b-chat を使う方法で、こちらは名前空間付きの短い指定で済みます。ただし後述する前処理の制約はどちらの経路でも変わりません。

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

ollama run schroneko/calm3-22b-chat

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

文脈長とKVキャッシュの設定はサーバー起動時の環境変数で指定します。Ollama公式のContext lengthページによれば、既定の文脈長はVRAM容量で段階的に決まり、24GiB未満なら4K、24GiB以上48GiB未満なら32K、48GiB以上なら256Kが選ばれます。つまり16GB級のGPUでは既定が4Kとなり、モデル上限16,384トークンの4分の1しか使えません。24GiB以上のGPUなら既定の32Kがモデル上限の16,384に丸められるため、文脈長の明示指定は不要です。VRAM節約のためにKVキャッシュを量子化する場合は次のように起動します。

OLLAMA_FLASH_ATTENTION=1 \
OLLAMA_KV_CACHE_TYPE=q8_0 \
ollama serve

OLLAMA_KV_CACHE_TYPEの既定値はf16です。q8_0はFlash Attentionが有効なときにだけ機能し、全モデルに一律で適用される全体設定である点に注意してください。実際に何トークン割り当てられたかは ollama ps のCONTEXT列で確認できます。Ollama経由でローカルモデルを開発ツールに接続する手順は、OllamaでCodexをローカルLLM実行する方法｜ollama launch codex-appの手順と対処法が具体例になります。

GGUF版に残る日本語前処理の制約

ここは導入前に必ず確認してください。GGUF配布元のREADMEは冒頭で、このGGUFが「本来の性能を十分に発揮できていない『暫定版』」であると宣言しています。理由として、2024年7月3日現在のllama.cppがCALM3モデル固有のpre-tokenization（前処理）をサポートしていないことを挙げ、妥協策としてllama.cppの既定の前処理を使うよう改造したうえで、「モデルの性能低下を引き落としている可能性が極めて高いです」と自ら記載しています。

つまりOllamaやllama.cpp経由で得られる日本語の品質は、transformersでモデル本体を動かした場合と一致しない可能性があります。量子化ファイル自体は日本語データセット（TFMC/imatrix-dataset-for-japanese-llm）でimatrixを取って作られていますが、それは量子化誤差の最小化であって、トークン分割の差異を埋めるものではありません。

この制約は、評価と本番で経路を変えたときに再現しない不具合を生みます。Ollamaで試して品質を判断したなら本番もOllamaで動かす、transformersで評価したならtransformersで動かす、というように経路を揃えるのが安全です。品質比較の結論を経路をまたいで持ち越さないでください。

2026年8月の選定基準｜このモデルを選ぶか、別モデルにするか

サイバーエージェント自身が公開した後継モデルの系譜

判断材料として最も有効なのは、開発元がその後どう動いたかです。Hugging Face APIから取得した公開日とパラメータ数を時系列に並べると、CyberAgentLM3-22B-Chatの位置がはっきりします。公開日はHugging Faceリポジトリの作成日（createdAt）で、プレスリリースの日付とは数日ずれます。ダウンロード数はHugging Faceの仕様上、直近30日間の値です。

この表は主要なテキスト生成モデルの抜粋です。実際にはサイバーエージェントは2024年7月以降、翻訳特化版や画像系を含めて18のリポジトリをHugging Faceに追加しています。読み取れる点は3つです。第一に、calm3-22b-chatのファイルは2024年7月1日の公開以降、一度も更新されていません。第二に、スクラッチ開発の系譜はcalm3で止まり、以降は既存モデルの日本語追加学習（Llama 3.1、Mistral NeMo、DeepSeek-R1蒸留版）へ路線が変わりました。第三に、文脈長で完全に追い抜かれています。calm3の16,384トークンに対し、その2か月後のMistral-Nemo-Japanese-Instruct-2408は128,000トークン、DeepSeek-R1-Distill-Qwen-32B-Japaneseは131,072トークンです。しかもこれらはいずれもKVヘッドが8のGQA構成で、1トークンあたりのKVキャッシュはそれぞれ0.156MiB、0.250MiBと軽くなっています。

他モデルと比較するときにconfig.jsonで見る4項目

ローカルLLMを比較する記事の多くはパラメータ数とベンチマークスコアを並べますが、それだけでは本記事で扱ったような見落としが起きます。モデル選定の実務で確認すべきなのは、Hugging Faceの各リポジトリで公開されているconfig.jsonの次の4項目です。いずれもモデル本体をダウンロードせずに読めます。

• num_key_value_heads と num_attention_heads：両者が同じ値ならMulti-Head Attentionで、KVキャッシュが重くなります。前者が8などの小さい値ならGQA構成で、同じ文脈長でもVRAM消費が数分の1に収まります。
• num_hidden_layers と hidden_size：この2つとヘッド数から、1トークンあたりのKVキャッシュ量を「2×層数×KVヘッド数×（hidden_size÷ヘッド数）×2バイト」で計算できます。GPUに載るかどうかは最終的にこの数字で決まります。
• max_position_embeddings：文脈長の上限です。ただしこれは位置埋め込みの上限であって公称値と一致しないことがあります。Mistral NeMoは設定上1,024,000ですが、Mistral公式は「up to 128k tokens」と案内しています。開発元の公称値と突き合わせてください。
• リポジトリの最終更新日とライセンス：config.jsonの外ですが同じページで確認できます。更新が止まったモデルは不具合が修正されません。ライセンスは商用利用の可否だけでなく、上のLlama 3.1のような名称・表示義務の有無まで読んでください。

国産オープンLLMの現行世代を横断で見たい場合は、LLM-jp-4とは？国産オープンLLMの2モデル構成・性能・使い方を解説で同種の観点を整理しています。

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

新規案件でこれから採用する積極的な理由は、2026年8月時点では見当たりません。同じ開発元の新しいモデルのほうが、文脈長でもVRAM効率でも上回っているためです。避けるべきなのは次の条件に当てはまる場合です。長い文書を一度に読ませたい（16,384トークンの上限に当たります）、24GBのGPU1枚で運用したい（KVキャッシュを量子化しないと8Kトークン程度しか確保できません）、Ollamaやllama.cpp経由で日本語品質を厳密に評価したい（前処理の差異が残っています）、そして最新のベンチマーク結果を根拠として社内稟議を通したい（公開時の比較対象はLlama 3世代です）。

逆に、採用が合理的な場面もあります。ひとつは、すでにこのモデルで検証を終えて本番稼働している場合です。Apache License 2.0で配布条件が変わることはなく、モデルファイルも更新されないため、動作は固定されます。挙動が変わらないこと自体が価値になる用途では、乗り換える必要はありません。もうひとつは、日本語データでスクラッチ事前学習された22B級モデルとしての比較対象や、ファインチューニングのベースが必要な場合です。2.0兆トークンの日本語中心の事前学習を経た商用可能なモデルという条件を満たすものは、いまも多くありません。ベースモデルとして手を入れる方向であれば、Unslothとは？読み方・使い方・対応モデルと高速ファインチューニングの仕組みで扱っている手法が選択肢になります。

よくある質問

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

外部のAPIを経由せず、自社のサーバーや手元のPCのGPU上でモデルの重みを読み込んで推論を実行する形態を指します。入力したデータが社外に出ないこと、従量課金が発生しないこと、通信断でも動くことが利点です。一方でGPUの調達とVRAMの見積もりが導入側の責任になり、本記事で扱ったKVキャッシュの計算がそのまま必要な作業になります。

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

ありません。Ollamaの公式モデルライブラリにcalm3およびCyberAgentLM3という名前の登録はないため、ollama pull calm3のような取得はできません。Hugging Face上のGGUFを ollama run hf.co/grapevine-AI/CALM3-22B-Chat-GGUF:Q4_K_M と直接指定するか、コミュニティ登録の ollama run schroneko/calm3-22b-chat を使います。

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

上限16,384トークンで、技術文書調の日本語では1トークンあたり2.25文字を実測しました。文章の性質で2.0前後まで下がるため、3万3,000字から3万7,000字が上限の目安です。ただしこれは応答（出力）に使う分も含む枠なので、長い出力を求める場合は入力をさらに絞る必要があります。またVRAMの制約から、24GB級GPUでKVキャッシュを量子化しない構成では8,000トークン程度、日本語で約1万8,000字が実質的な上限になります。

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

必要です。クラウドのAPIと違い、ローカル実行では提供元による出力の検閲や年齢制限のフィルタが介在しません。Apache License 2.0は配布と利用の条件を定めるものであり、出力内容の適切性を保証するものではないためです。不適切な出力の抑止が要件になる用途では、システムプロンプトでの指示に加えて、生成後のテキストを判定する仕組みを導入側で実装してください。

8B級のモデルと22B級では、ローカル運用で何が変わりますか？

VRAMの必要量が桁で変わります。同じサイバーエージェントのCAT-Thinking-8Bは81.9億パラメータでKVヘッドが8のGQA構成のため、KVキャッシュは1トークンあたり0.141MiBです。本モデルの1.125MiBに対して8分の1で、しかも文脈長の上限は40,960トークンと2.5倍あります。8B級なら量子化なしでも24GB級GPUに収まる一方、22B級は4bit量子化とKV量子化の両方を前提に設計する必要があります。品質はタスク依存なので、自社データで両方を試して判断してください。

関連記事

• LLM-jp-4とは？国産オープンLLMの2モデル構成・性能・使い方を解説
• OllamaでCodexをローカルLLM実行する方法｜ollama launch codex-appの手順と対処法
• 1bit LLM「Bonsai」とは？三値量子化でスマホ動作するローカルLLMの仕組みと実装判断を解説【2026年】
• LLM Servingとは？推論をAPI提供する仕組みと主要フレームワーク比較【2026年版】
• Unslothとは？読み方・使い方・対応モデルと高速ファインチューニングの仕組み