LLM・RAG

Tanuki-8Bとは?松尾研の国産LLMの仕様・性能・使い方とGGUF版が非推奨の理由

Tanuki-8Bとは?松尾研の国産LLMの仕様・性能・使い方とGGUF版が非推奨の理由

Tanuki-8Bは、東京大学松尾・岩澤研究室が経済産業省とNEDOのGENIACプロジェクトの一環として開発し、2024年8月30日に公開した日本語の大規模言語モデルです。既存モデルの継続学習ではなく、事前学習からフルスクラッチで約1.3兆トークンを学習しています。対話・作文の性能に絞って調整されており、Apache License 2.0で商用利用もできます。

公開から2年が経ちました。Hugging Faceのリポジトリは2024年10月9日のREADME更新が最後で、重みファイルは2024年8月の登録時のままです。それでもHugging Face上の累計ダウンロードは36,930回、直近30日でも352回あります(2026年10月30日にAPIで確認)。本記事ではモデルカード・論文・設定ファイルといった一次情報に加え、トークナイザーを手元で動かした結果をもとに、2026年時点でTanuki-8Bを使う価値があるのはどの場面かまで整理します。

まとめ:Tanuki-8Bの要点

  • 実パラメータ数は7,512,264,704(約75億)。「8B」は約80億クラスを表す呼称で、構造はLlama系のDenseモデルです。
  • コンテキスト長は8,192トークンです。日本語の散文で実測すると1トークンあたり約1.65字なので、入力と出力を合わせて約1.35万字が上限の目安です。
  • Japanese MT-Benchの値は評価系によって7.24、7.3、6.6と変わります。比較するときは同じリーダーボードの値どうしで比べてください。
  • 作文・人文・STEMの説明は9点台ですが、数学は3.9点、コーディングは5.4点です。答えだけを決まった形式で返すタスク(Jaster)も苦手です。
  • BF16の重みは約15GBあるため、24GB級のGPUが現実的な下限です。AWQとGPTQの4bit版なら約4.7GBに収まります。
  • GGUF版とそれを使うOllama版は、トークナイザーを完全に変換できていない恐れがあるとして公式に非推奨です。本記事の調査では、NFKC正規化が抜けていて全角英数字と半角カナが正しく分割されないことを確認しました。

Tanuki-8Bの仕様と「8B」の意味

対話用の公開版は weblab-GENIAC/Tanuki-8B-dpo-v1.0 です。事前学習後にSFT(教師ありファインチューニング)とDPO(直接選好最適化)で対話向けに調整されています。主な仕様は、Hugging Faceのconfig.jsonとJSAI2025の開発報告論文で次のとおり確認できます。

項目 値
総パラメータ数 7,512,264,704(BF16)
アーキテクチャ LlamaForCausalLM(Dense)
層数・隠れ次元 32層・4,096
FFN次元 14,336
アテンションヘッド Q 32・KV 8(GQA)
最大位置(コンテキスト長) 8,192トークン
RoPE theta 500,000
語彙数 65,000(config上は65,024)
事前学習トークン 約1.3T(うち合成データ約220B)
学習データの言語比 日本語1/2〜2/3、残りは英語
ライセンス Apache License 2.0
公開日 2024-08-30
HF上の最終更新 2024-10-09(READMEの更新)

KVヘッドが8本のGQA構成なので、BF16のKVキャッシュは1トークンあたり128KiB(8ヘッド×128次元×32層×K・V×2バイト)です。1系列で8,192トークンを使い切ると約1GiBになり、同時に処理する系列の数だけ増えます。GQAの仕組みはグループ化クエリアテンションとは?GQAの仕組みとKVキャッシュ削減・実装判断を解説で詳しく扱っています。

名前の「8B」と実パラメータ数7.5Bの差

「8B」の「B」はbillion(10億)の略で、約80億パラメータ級のモデルであることを表します。実数はsafetensorsで7,512,264,704、論文の表でも7.5Bです。Llama 3 8Bなど同じクラスと並べるための呼称と考えてください。

論文は構造を「Llama2の構造をベース」と書いていますが、設定ファイルにはGQA(KV 8本)とRoPE theta 500,000が入っています。どちらもLlama 2 7Bには無く、Llama 3系に近い設定です。transformersやvLLMでは標準のLlamaとして読み込まれるので、trust_remote_code は要りません。

8,192トークンに入る日本語の量(実測)

公式Zenn記事「大規模言語モデルTanuki-8B, 8x8Bの位置づけや開発指針など」の「2024年8月現在」から始まる日本語散文3,000字(空白を除去)を、transformers 4.46.3で特殊トークンを付けずに分割しました。結果は次のとおりです。

トークナイザー 語彙数 トークン数 1トークンあたりの字数
Tanuki-8B 65,000 1,823 1.65
Qwen2.5(0.5B-Instruct) 151,665 1,957 1.53
llm-jp-3(1.8B) 99,574 1,515 1.98

Tanukiのトークナイザーは、MeCabで分かち書きしてからSentencePieceで学習したUnigramモデルです。語彙は6.5万と小さめですが、今回の3,000字のサンプルでは語彙15万のQwen2.5より少し少ないトークン数で収まりました。8,192トークン×1.65字で約1.35万字です。ただしこれは入力と出力の合計です。長い文書を要約させるときは、プロンプトのトークン数に生成させたい長さを足して8,192に収まるかを先に数えてください。今回の比率なら1万字の入力は約6,100トークンで、出力に回せるのは約2,000トークンです。分割方式の違いはトークナイザーとは?BPE・WordPiece・Unigramの違いと日本語での実装判断を解説【2026年版】を参照してください。

Tanuki-8x8Bとの違い:アップサイクリングで作られたMoE版

同時に公開されたTanuki-8x8Bは、Tanuki-8Bを1,080Bトークンまで学習した時点のモデルをもとにしています。FFN層を8つのエキスパートに複製してルーターを足し、さらに635Bトークンを追加学習しました。こうして既存のDenseモデルからMoEを作る手法をアップサイクリングといい、Tanuki特設ページ(tanuki-llm.github.io)は国内初のアップサイクリング成功例としています。

項目 Tanuki-8B Tanuki-8x8B
構造 Dense MoE(8エキスパート・2つ活性)
総パラメータ 7.5B 約47B
推論時のアクティブパラメータ 7.5B 約13B
総学習トークン 約1.3T 約1.71T
コンテキスト長 8,192 4,096
アーキテクチャ名 LlamaForCausalLM TanukiForCausalLM(独自)
transformersでの読み込み 標準 trust_remote_code+flash_attn必須
vLLM 標準版で可 チームの改変版をビルド
JMT-Bench(モデルカード) 7.24 7.96

JMT-Benchの平均スコアは8x8Bが上ですが、独自アーキテクチャなので推論環境を選びます。公式の推論手順記事は、vLLMをチームのフォーク(team-hatakeyama-phase2/vllm)からソースビルドする方法を最も推奨しています。標準ツールだけで動かしたいなら8Bを選んでください。MoEのメモリ要件の考え方はMoE(Mixture of Experts)とは?疎活性化とルーターの仕組み・VRAM要件と採用判断を実装者向けに解説にまとめています。

GENIACでの開発体制と学習データの構成

開発したのは、松尾研の大規模言語モデル講座の修了生や一般公募で集まった約250名の有志です。Phase1では7チームが10Bクラスのモデルを競い、2024年6月1日の結果発表で「チームたぬき」(リーダー:畠山歓)が優勝しました。Phase2ではこのチームがTanuki-8Bと8x8Bを仕上げています。事前学習にはH100を8枚×16ノード(128枚)使い、1日あたり8Bで約60B、8x8Bで約30Bトークンを学習できたと公式ブログに記録されています。プレスリリースによると、モデル名は「日本らしく、親しみを覚える動物の名前」というテーマで案を出し合い、投票で決めました。

開発の特徴は合成データへの依存度の高さです。論文によれば、Calm3-22B、WizardLM2 7B・8x22B、Phi-3、Nemotron-4-340Bといった既存LLMとルールベースの手法で対話・作文向けのデータを生成し、事前学習の後半に投入しました。事後学習(SFT・DPO)は人手で作ったデータを使わず、合成データだけで行っています。開発リーダーの畠山歓氏のZenn記事によると、Webデータだけを学習した段階ではJMT-Benchが4〜5点程度にとどまり、自動生成した大量の対話データを学習させて最終的に7〜8点程度まで上がりました。DPO用の選好データは、2つの応答をLLMに判定させるLLM-as-a-Judgeで作られました。

一方、優先度を下げた領域も明言されています。公式ブログは一般知識の量、安全性と倫理性、マルチモーダル機能、ツール利用を後回しにしたと書いています。知識の詰め込みより「与えられた情報を正確に処理する能力」を優先した、という説明です。この設計が、次章で見る得意・不得意にそのまま表れています。

ベンチマークの読み方:同じモデルに3つのJMT-Benchスコア

Tanuki-8BのJMT-Bench評価系によるスコア差

Tanuki-8BのJapanese MT-Bench(JMT-Bench)の値は、出典によって次のように異なります。

出典 評価系 Tanuki-8B Tanuki-8x8B
HFモデルカード GPT-4(gpt-4-0613)採点・-1を除外 7.24 7.96
公式ブログ Nejumi Leaderboard Neo 7.3 8.0
JSAI2025論文 Nejumi Leaderboard 3 6.6 6.8〜7.0

論文は、Leaderboard 3のスコアはNeoより低く出ることがほとんどで、同じモデルでも測るたびに0.1〜0.2点ほど揺れると注記しています。「GPT-3.5と同等」という評価も、Leaderboard 3で比べるとGPT-3.5-turboが6.8点、8x8Bが6.8〜7.0点という関係です。他社モデルと比べるときは、同じ評価系の値どうしで比べてください。評価設計の一般論はLLM評価とは?指標・データセット設計・評価ツールの選び方を実装視点で解説【2026年版】で扱っています。

同じLeaderboard 3の基準では、Tanuki-8Bの6.6点はLlama-3-Swallow-70B-Instruct-v0.1(6.2)、Llama-3-ELYZA-JP-8B(6.1)を上回っていました。国内でフルスクラッチ学習された10B規模のモデルでは、それまでの最高がFugaku-LLM-13Bの5.5点(Neo基準)でした。ただしこれは2024年8月時点の比較です。

JMT-Benchカテゴリ別の作文9点台と数学3.9点の差

カテゴリ Tanuki-8B Tanuki-8x8B
stem 9.35 9.40
humanities 9.1 9.3
writing 9.05 8.85
roleplay 8.75 8.95
extraction 6.65 6.90
reasoning 5.75 7.35
coding 5.4 6.75
math 3.9 5.75

出典はHugging Faceのモデルカードに載っているJMT-Benchの内訳(gpt-4-0613採点)です。文章を書く・説明する系は9点前後ですが、数学は3.9点と半分以下です。8x8Bとの差もreasoningとmathで大きく開いています。計算や論理推論を含む業務に8Bを当てるのは避けてください。

Jasterで低い理由と人手評価の結果

Leaderboard 3の総合点では、Tanukiは順位のわりに低く出ます。開発チームのブログによると、一問一答形式のJasterの0-shot平均は8Bで0.22、8x8Bで0.32でした。JMT-Benchで同じ性能帯にあるモデルは0.4〜0.6程度です。Jasterは「回答の他には何も含めない」といった厳密な出力形式を求め、完全一致採点では「ぬれせんべいです。」と文で答えるだけで0点になります。Tanukiは丁寧に文章で答える方向に調整されているため、形式を厳守させるタスクが苦手です。チームはこれを想定内の挙動と説明しています。開発リーダーも前掲の記事で、「与えられた文章を3点で箇条書きにする」「JSON形式に変換する」といったタスクは個別に相当量の訓練をしないと身につかなかったと書いています(個人の感想と断ったうえでの記述です)。

チームは2024年8月19日〜25日に、Chatbot Arena形式の人手ブラインド評価も行いました。約2,100件の比較で、8x8BはGPT-4o、Gemini-1.5-pro、Claude-3.5-sonnetに次ぐ帯に入っています。一方、8BはGPT-4o-miniやGemini-1.5-flashと同じく、JMT-Benchのスコアのわりに実際の対話では評価が下がる「弟分モデル」の傾向を示しました。チームはエラーバーが大きく順位は変動しやすいとも書いているので、細かい順位差は読み込みすぎないでください。

Tanuki-8Bの使い方:transformers・vLLMでの推論とプロンプト形式

必要なGPUメモリの目安

形式 リポジトリ 重みファイル 公式の扱い
BF16(原本) weblab-GENIAC 約15.0GB 推奨
AWQ 4bit team-hatakeyama-phase2 4.69GB 推奨
GPTQ 4bit team-hatakeyama-phase2 4.70GB 推奨
GPTQ 8bit team-hatakeyama-phase2 8.22GB 推奨
GGUF Q4_K_M team-hatakeyama-phase2 4.56GB 非推奨

重みファイルのサイズはHugging Face APIで取得した値です。公式の量子化版は、開発チームの量子化手順の記事のとおり、AWQ・GPTQともに4bitはグループサイズ128で作られています。キャリブレーションには日本語Wikipedia(izumi-lab/wikipedia-ja-20230720)から無作為に選んだ文書を使い、AWQ版は512件、GPTQ版は1000件です。実行時はこれにKVキャッシュ(8,192トークンで約1GiB)と活性化メモリが加わります。BF16なら24GB級のGPU、4bit版なら8GB級が目安です。量子化方式の違いは量子化(モデル量子化)とは?仕組み・PTQとQATの違いと実装判断を解説【2026年版】を参照してください。Apple Silicon向けにはmlx-communityの4bit版・8bit版もありますが、これは第三者による変換です。

transformersのコード例

モデルカードの例に対し、transformers 5.x系への対応として主に2点を変更しています。1つは非推奨になった torch_dtype を dtype に置き換えたこと、もう1つは apply_chat_template の戻り値を辞書として受け取り generate(**inputs) で渡す形にしたことです。加えて、temperatureを生成に反映させるため do_sample=True を明示しています。5.x系はこの関数が既定でBatchEncodingを返すため、モデルカードのように位置引数で渡すと動きません。戻り値の型とテンプレートの描画は、transformers 4.46.3と5.18.0の両方で確認しました(重みの読み込みと生成は検証していません)。

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, TextStreamer

model_id = "weblab-GENIAC/Tanuki-8B-dpo-v1.0"
model = AutoModelForCausalLM.from_pretrained(model_id, device_map="auto", dtype=torch.bfloat16)
tokenizer = AutoTokenizer.from_pretrained(model_id)
streamer = TextStreamer(tokenizer, skip_prompt=True, skip_special_tokens=True)

messages = [
    {"role": "system", "content": "以下は、タスクを説明する指示です。要求を適切に満たす応答を書きなさい。"},
    {"role": "user", "content": "たぬきに純粋理性批判は理解できますか?"},
]
inputs = tokenizer.apply_chat_template(
    messages, add_generation_prompt=True, return_dict=True, return_tensors="pt"
)
inputs.pop("token_type_ids", None)  # 4.x系はこれも返すがLlamaは受け取らない
inputs = inputs.to(model.device)
model.generate(**inputs, max_new_tokens=1024, temperature=0.5, do_sample=True, streamer=streamer)

vLLMでのOpenAI互換APIサーバー起動

Tanuki-8Bは標準のLlama構造なので、vLLMは8x8Bのような改変版をビルドせずに読み込めます。チャットテンプレートは原本の tokenizer_config.json に入っているため、vllm serve で起動すればOpenAI互換の /v1/chat/completions がそのまま使えます。

vllm serve weblab-GENIAC/Tanuki-8B-dpo-v1.0 --dtype bfloat16 --max-model-len 8192

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "weblab-GENIAC/Tanuki-8B-dpo-v1.0",
       "messages": [{"role": "user", "content": "たぬきに純粋理性批判は理解できますか?"}],
       "temperature": 0.5, "max_tokens": 1024}'

上の例では、まずvllm serveを起動し、サーバーの準備完了後に別のターミナルでcurlを実行してください。設定上の注意点は2つあります。1つ目はサンプリングの既定値です。原本の generation_config.json に入っているのはBOS・EOSのトークンIDだけで、温度の指定がありません。モデルカードの例に合わせるなら、リクエストごとに temperature を0.5にしてください。2つ目はsystemの扱いです。messagesにsystemを入れなければ、テンプレートが学習時のデフォルトのシステムプロンプトを自動で差し込みます。AWQ版を使うときはモデル名を team-hatakeyama-phase2/Tanuki-8B-dpo-v1.0-AWQ に替え、起動引数は --dtype half に変更してください。通常のAWQカーネルはfloat16に対応しており、上のbfloat16指定をそのまま使えるとは限りません。量子化方式はconfig.jsonの quantization_config(quant_method: awq)から読み取られます。vLLMの導入はvLLMとは?PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説にまとめています。

システムプロンプトとマルチターンの形式

プロンプトは日本語版Alpaca形式です。上のコードでチャットテンプレートを描画すると、次の文字列になります。

<s>以下は、タスクを説明する指示です。要求を適切に満たす応答を書きなさい。

### 指示:
たぬきに純粋理性批判は理解できますか?

### 応答:

モデルカードは、デフォルトのシステムプロンプト以外は学習していないため、このプロンプトの使用を推奨すると明記しています。テンプレート自体は任意のsystemを受け付けますが、役割や口調の指定はユーザー側の指示文に書くのが安全です。マルチターンでは、各応答の末尾に </s> が入ったうえで「### 指示:」と「### 応答:」が繰り返されます。

公式デモ(Hugging Face Spaces の weblab-GENIAC/Tanuki-8B-dpo-v1.0)は、2026年10月30日にAPIで状態を確認したところ RUNTIME_ERROR でした(10月6日の確認時から変わっていません)。プレスリリースでも「期間限定公開」とされていたため、試すときは自分の環境かColabで動かす前提で考えてください。

GGUF版・Ollama版が非推奨な理由:NFKC正規化の欠落

公式のGGUF版(team-hatakeyama-phase2/Tanuki-8B-dpo-v1.0-GGUF)には、「tokenizerを元モデルから完全に変換出来ていない可能性があり、性能低下が発生している恐れ」があるという注記が付いています。原因はコミット履歴から追えます。

  • 2024-08-14:GGUF版がアップロードされる
  • 2024-09-02:原本のtokenizer.jsonに「全角記号・数字のNKFC正規化を追加」(NFKC正規化の追加)
  • 2024-09-03:AWQ版のtokenizer.jsonも更新される(GGUF版の重みファイルは2024-08-14以降も更新されていない)

GGUFのヘッダを読むと、トークナイザーは tokenizer.ggml.model = llama として格納されていて、NFKC正規化の情報はありません。この正規化の有無でどれだけ差が出るかを、NFKC追加前と追加後のリビジョンのトークナイザーで比べました(「▁」は空白を表す記号で、今回の入力では先頭に付加され、単独の1トークンとして数えられています)。

入力 追加前のトークン数 追加後のトークン数 追加後の分割
GPUは24GB(全角) 23 6 ▁/GPU/は/2/4/GB
タヌキの性能(半角カナ) 12 4 ▁/タヌキ/の/性能
GPUは24GB(半角) 6 6 同上

正規化が無いと、全角英数字や半角カナは語彙に無いため、UTF-8のバイト単位(<0xEF> など)に分解されます。トークン数が4倍近くに膨らみ、現行の公式トークナイザーとは異なる系列がモデルに渡ります。Ollamaで公開されているコミュニティ版 7shi/tanuki-dpo-v1.0 もこのGGUFを使っており、「NFKC正規化がサポートされていないため、全角英数字や半角カナが認識できません」と注意書きしています。

8x8BのGGUF版も非推奨です。量子化手順の記事によると、llama.cppが独自構造のTanukiForCausalLMに対応していないためMixtralForCausalLMとして推論され、JMT-Benchで約0.5点の性能低下が確認されています。

結論として、Tanuki-8Bを量子化して使うならAWQかGPTQを選んでください。llama.cppやOllamaをどうしても使う場合は、入力をアプリ側でNFKC正規化してから渡すと、少なくとも全角英数字と半角カナの問題は避けられます(Pythonなら unicodedata.normalize("NFKC", text))。

Tanuki-8Bの追加学習:ベースモデルの利用条件と学習コード

SFT・DPOをかける前のベースモデルは、weblab-GENIACではなく開発チームのアカウントから team-hatakeyama-phase2/Tanuki-8B-base-v1.0 として公開されています。パラメータ数はDPO版と同じ7,512,264,704(BF16)で、2024年8月14日から更新されていません。自分のデータで一から指示調整したい場合の出発点になりますが、2026年10月30日にリポジトリを確認した時点で次の2点が欠けています。

  • ライセンスの表記:モデルカードは自動生成のひな形のままで、License欄は「More Information Needed」です。LICENSEファイルもありません。Apache License 2.0と明記されているのはDPO版と量子化版です。
  • NFKC正規化:ベースモデルの tokenizer.json の正規化はスペースを「▁」に置き換える処理だけで、DPO版に2024年9月2日に追加されたNFKCがありません。GGUF版と同じ状態です。

商用の製品に組み込む前提で追加学習するなら、ライセンスが明記されたDPO版を土台にするか、ベースモデルの利用条件を開発元に確認してから使ってください。ベースモデルで学習する場合は、学習データと推論時の入力の両方をNFKC正規化してそろえておくと、全角英数字がバイト単位に分解される問題を避けられます。

事前学習と継続事前学習のコードは GitHubのmatsuolab/tanuki にあり、LICENSEファイルはApache License 2.0です。チームの解説記事によると、継続事前学習はMegatron形式のチェックポイントを前提としていて、Hugging Face形式のモデルからは変換が必要です。対話用に軽く調整するだけなら、4bit量子化した重みにLoRAを重ねる手法(QLoRAとは?4bit量子化+LoRAの仕組み・VRAM目安・実装手順と採用判断を解説【2026年版】)を候補にし、必要なGPUメモリと調整後の回答品質を確認してください。Hugging Face上では、DPO版を土台にしたファインチューン済みモデルが7件登録されています(大喜利の回答用アダプターなど)。

ライセンスと商用利用の条件

Tanuki-8B、Tanuki-8x8B、公式の量子化版はいずれもApache License 2.0です。Apache 2.0は、著作権表示とライセンス文の同梱、変更箇所の明示などを守れば改変・再配布・商用利用ができる、いわゆるパーミッシブ(寛容型)ライセンスです。Llama 3のコミュニティライセンスのような月間利用者数の条件や、利用規約の別途承諾はありません。

ただし、ライセンスが緩いことと業務で安全に使えることは別の話です。論文は安全性について「今後の検討を要する」と書いており、公式ブログも安全性・倫理性の作り込みは教師LLMの出力に任せたと説明しています。顧客向けの対話に組み込むなら、入出力のフィルタやガードレールを別に用意してください。学習データには他社LLMが生成した合成データが含まれるため、生成元の利用条件まで確認が必要な案件では、論文の合成データの記述を法務と一緒に確認しておくのが確実です。

2026年にTanuki-8Bを選ぶ場面・選ばない場面

Tanuki-8Bの採用候補:日本語作文・出自説明・開発教材

  • 日本語の作文・言い換え・説明文の生成:Tanuki-8BのJMT-Benchはwriting・humanitiesが9点台です。なお、プレスリリースが共感性のある返答や自然な言葉遣いを特長に挙げているのは8x8Bについてで、8B単体の評価ではありません。
  • 出自を説明する必要がある案件:海外モデルの継続学習ではなくフルスクラッチの国産モデルで、学習コード(GitHub matsuolab/tanuki)、学習ログ、評価データ(LLMChat 約2,000件)が公開されています。
  • LLM開発の教材:事前学習で30回以上行った設定変更の履歴や、合成データを投入したタイミングがZennで公開されています。8Bは標準のLlama構造なので、学習済みモデルを手元で動かして記録と照らし合わせることもできます。

Tanuki-8Bを社内向けのチャットボットに組み込む場合は、モデルの回答精度に加え、入出力フィルタの検知漏れと、回答対象外の質問への応答を評価してください。設計から運用までまとめて任せたい場合は、弊社のAIチャットボット開発でも相談を受けています。

Tanuki-8Bを避ける条件と代替モデル

次の条件に当てはまるなら、Tanuki-8Bは選ばないでください。

  • 数学・コード・多段推論:mathが3.9点、codingが5.4点です。
  • 形式を厳守させる抽出・分類:Jaster 0-shotが0.22で、JSONや単語だけを返させる用途に向きません。
  • 入力と生成予定分の合計が8,192トークンを超える用途:長い議事録や契約書の一括要約は、分割して渡す前提になります。
  • 2024年8月以降の知識が要る用途:重みファイルは2024年8月の登録時から更新されておらず、後継モデルもHugging Faceの weblab-GENIAC には公開されていません(2026年10月30日確認)。
  • systemプロンプトで人格や役割を切り替える用途:デフォルト以外のシステムプロンプトを学習していません。

日本語の汎用性を求めるなら、海外のオープンモデルを日本語で継続学習したモデルが候補になります。同じ8BクラスならLlama-3-ELYZA-JP-8Bとは|性能・必要スペックとGGUFのダウンロード、Ollamaでの使い方、版の新しいモデルから選ぶならSwallow LLMとは?最新のGPT-OSS Swallow・Qwen3 Swallow v0.2とモデル一覧・選び方【2026年10月】で扱っているSwallowシリーズです。フルスクラッチの国産オープンモデルという条件を外せないなら、更新が続いているLLM-jpのシリーズ(LLM-jp-4とは?8B・32B-A3B・33Bと4.1の違い・性能・使い方【2026年10月】)を先に検討するのが妥当です。

よくある質問

Tanuki-8Bの「8B」とはどういう意味ですか?

8 billion、つまり約80億パラメータ級であることを表す呼称です。Tanuki-8Bの実際のパラメータ数は7,512,264,704(約75億)です。

Tanuki-8Bは商用利用できますか?

できます。Apache License 2.0で公開されており、ライセンス文と著作権表示の同梱などの条件を守れば、改変・再配布・商用利用が可能です。安全性の評価は今後の課題とされているため、業務利用では出力のフィルタリングを併用してください。

Tanuki-8Bの動作に必要なGPUメモリはどれくらいですか?

BF16の原本は重みだけで約15GBあり、KVキャッシュなどを含めると24GB級のGPUが目安です。AWQやGPTQの4bit版は重みが約4.7GBなので、8GB級のGPUから検討できます。実際の必要量はコンテキスト長や推論エンジンで変わるため、使う長さで一度測ってください。

Tanuki-8BはOllamaやllama.cppで使えますか?

GGUF版とそれを使うOllamaのコミュニティ版はありますが、公式には非推奨です。開発チームはトークナイザーを完全に変換できていない可能性を理由に挙げており、本記事の調査ではNFKC正規化が抜けていて全角英数字や半角カナが正しく分割されないことを確認しました。使う場合は入力を事前にNFKC正規化してください。

Tanuki-8Bの後継モデルや更新はありますか?

2026年10月30日時点で、weblab-GENIACのHugging Face上に後継の言語モデルは公開されていません。Tanuki-8Bのリポジトリも2024年10月9日のREADME更新が最後で、重みファイルは2024年8月12日の登録時から変わっていません。派生モデルとしては、画像を扱うTanuki-8B-visionが2024年8月に実験的に公開されています。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.09 テックブログ エディオン不正アクセス第2報:カード番号の対象確認とログ・決済画面の改ざん対策
  2. 2026.11.09 テックブログ LANSCOPE不正アクセス第2報:製品への影響と偽連絡の確認、停止中のライセンス認証の窓口
  3. 2026.11.10 テックブログ Claude Fable 5.2とは:料金・破壊的変更4点とFable 5.1からの移行手順【2026年11月】
  4. 2026.11.09 テックブログ ステップゴルフ不正アクセス:口座情報の対象確認と偽連絡・引き落としの注意点
  5. 2026.11.10 テックブログ ニトリの情報漏洩:最大3,762万件の対象確認となりすまし連絡の見分け方

RELATED POSTS 関連記事

目次