ArrowCanaria-Llama-8Bとは？雑談性能重視のAItuber向け日本語LLM・SFT版とRL版の動かし方

ArrowCanaria-Llama-8Bは、DataPilotが2026年3月にHugging Faceで公開した、AItuber（AI VTuber）向けの日本語8Bモデルです。SFT版（3月20日）と、それに強化学習を重ねたRL版（3月21日）の2つがあり、2026年10月時点でもこのv0.1が最新です。モデルカードの説明は「雑談性能を重視して設計」の一言に集約されます。本記事では、モデルカードと設定ファイルの実物を読み、学習の中身、必要なVRAMとGPUが無いときの選択肢、動かすときの落とし穴、配信ツールへの組み込み方を整理しました。

まとめ：ArrowCanariaの要点と導入前の確認事項

• 中身：ベースは東京科学大学のLlama-3.1-Swallow-8B-Instruct-v0.5。SFT版は17.5万件超の合成データで学習、RL版はそこへGRPOによる強化学習を3,600件分重ねたもの
• 重さ：BF16の重みは約16.06GB。短い文脈・少数の同時接続では24GB級GPUが目安となり、16GB以下のGPUやMacではGGUF（Q4_K_Mで約4.92GB）かMLX版、GPUが無ければFeatherlessのAPI配信を使う
• 最大の落とし穴：config.jsonのRoPE設定が新しい書式で書かれており、transformers 4系で読むと rope_theta=10000.0 になる。5系を使うか、4系なら値を明示する
• 関数呼び出し：同梱のチャットテンプレートは tools を読まない。公開データセットと同じく、関数定義をシステムプロンプトに書き <functioncall> タグを自前で解析する
• 文脈長：学習時の最大長は4,096トークン。公開データセットのペルソナ設定は、特殊トークンを除く本文だけで中央値2,064トークン
• ライセンス：Llama 3.1 Community LicenseとGemma Terms of Useの両方に従う。公式ベンチマークは公表されていないため、採用前に自分の配信内容で比べる

ArrowCanariaの位置づけと「雑談性能」の意味

DataPilotが公開した2モデルとベースのSwallow 8B

ArrowCanariaは、DataPilotのコレクション「ArrowCanaria-series」に収められた2モデルの総称です。コレクションの説明は「AItuber向けデータセットを用いた、自然な日本語スタイル・すっきりしたMarkdown・高い雑談性能を持ったモデル群」です。

累計ダウンロードはHugging Face APIの downloadsAllTime（2026年10月31日取得）です。モデル・コレクションとも2026年3月21日以降は更新されておらず、v0.2などの後継版は出ていません。ベースのLlama-3.1-Swallow-8B-Instruct-v0.5は、Meta Llama 3.1 8Bに日本語の継続事前学習を施したSwallowシリーズの一つで、モデルカードはgemma-3-27b-itの振る舞いを模倣するよう学習したと説明しています。Swallowシリーズの全体像はGPT-OSS SwallowやQwen3 Swallowを含むSwallowシリーズの一覧にまとめています。

AItuber向けの「雑談性能」を支える学習データ

「雑談性能」は、配信者が企画なしの雑談だけで配信を持たせる力を指す言い回しで、ArrowCanariaのモデルカードもこの語で目標を説明しています。モデルとしては、翻訳調やテンプレート的な応答を避け、共感や相づちを含む自然な日本語で返せることを指します。

SFTデータは日本語124,000件（70.9%）と英語51,000件（29.1%）で、知識応答・雑談と相談・Tool Use・RAG・推論・RP・AItuber RP・クリエイティブの8カテゴリです。データは開発者の合成データ生成フレームワークSDG_LOOMで作られ、生成にはDeepSeek-V3.2とKimi K2.5が使われました。一部は「Canaria-Datasets」として公開されています（ライセンスはいずれもODC-By）。

• AItuber-Realworld-Data-beta1：README記載1,946件。AItuberのペルソナを書いたシステムプロンプトに、複数の視聴者のコメントが「名前: コメント」の形で続く4ターンの配信チャット。応答はKimi K2.5、コメントはDeepSeek V3.2が生成
• AItuber-Personas-Japan：195件。ジャンル約25種・性格約20タイプ・話し方約10スタイルなどを組み合わせたキャラクター設計書とシステムプロンプト
• Function-Calling-Japanese-Dataset：7,000件。英語データセットhypervariance/function-calling-sharegptをDeepSeek V3.2で日本語に訳したもの

Realworldデータの応答は1回あたり中央値111.5字で、短い返答を中心とした学習例です（モデルが実際に生成する長さの測定値ではありません）。長文の解説役を期待するなら、後述の比較で確かめてください。

SFT版とRL版の学習パイプラインの違い

SFT版：CPT・Chat Vector・3フェーズのカリキュラム学習

SFT版は3段階で作られています。まずフィルタリング済みの日本語合成小説1万件で継続事前学習（CPT）を行い、崩れた対話能力を元モデルのChat Vectorのマージ（Mergekit）で戻し、最後にLoRA（r=32、alpha=64）でSFTを行います。SFTは「声→能力→人格」の順に3フェーズへ分けたカリキュラム学習です。

設計の要は、2番目のTool Use・RAGの学習率を最も低くしている点です。モデルカードは、補助的な能力のために第1フェーズで作った文体を崩さないためと説明しています。各フェーズでは前フェーズのデータを一部混ぜ直すリプレイバッファで、壊滅的忘却（新しい学習で以前の能力を失う現象）を抑えています。学習はUnslothとTRLのSFTTrainerで、最大系列長4,096トークン、各フェーズ1エポックです。

RL版：GRPOとTRLの「dapo」損失による強化学習

RL版は、SFT版にGRPOで強化学習をかけたモデルです。1つのプロンプトに8つの候補を生成し、外部の報酬モデルのスコアを候補間で比べて方策を更新します。第1フェーズは内製の相談データ1,600件（学習率5e-6・400ステップ）、第2フェーズは知識QAのDataPilot/Zero_SFT_Ja_v3.5から2,000件（3e-6・500ステップ）です。学習データの回答部分は使わず、質問だけを与えて生成させています。報酬は外部報酬モデルのスコアをtanh（scale 3.0）で整形し、冗長な応答には重み0.12のペナルティを課します。

モデルカードは損失関数のDAPOを「Direct Advantage Policy Optimization」と書いていますが、DAPOの原論文（arXiv:2503.14476、2025年3月）での正式名は「Decoupled Clip and Dynamic sAmpling Policy Optimization」です。RL版は学習にTRLのGRPOTrainerを使っており、TRL v1.17.1の説明では loss_type="dapo" がトークン単位の損失を累積バッチ全体の有効トークン数で正規化する既定値で、DAPO論文で導入された方法とされています。KLペナルティ（beta）は0.0です。人手評価と報酬モデルの関係はRLHFの3段階の仕組みで整理しています。

SFT版とRL版の選び分け

RL版のモデルカードは、SFT版の応答が「データに含まれる平均的な応答」に収束しやすいと述べ、相談の共感・傾聴と知識応答の正確さを強化したと説明しています。ただし、RL版が数値でどれだけ改善したかは公表されていません。

• RL版から試す：悩み相談や視聴者の質問への回答が多い配信
• SFT版から試す：キャラクターの口調を強く出したいRP中心の配信。RL版のモデルカードはRP能力を「保持」と説明しており、RLの報酬は相談と知識QAに向けて設計されている。RPでどちらが優れるかの比較は公表されていないため、追加学習の少ないSFT版を比較の基準に置く

公開後に出た第三者の試用記録（zenn.dev/kun432）はRL版をGoogle ColabのL4で動かし、キャラクターを演じさせた応答を「なかなか面白かった」とする一方、「コンテキストが長くなってくると、同じことを繰り返すような感じになることもある」と書いています。配信で長く話させるなら、この点を最初に確かめます。初期比較では、同じシステムプロンプトとコメント列を使って30往復程度の応答を並べ、口調の崩れと繰り返しを確認します。30往復は試行数の例であり、実際の配信テーマでも追加評価して採用を決めます。

実行環境ごとのVRAM目安と配布形式

BF16の重みは4分割のsafetensors合計で16,060,556,336バイト（約16.06GB、14.96GiB）です。Llama 3.1 8Bの構成（32層・KVヘッド8・ヘッド次元128）から計算すると、KVキャッシュはBF16で1トークンあたり128KiB、4,096トークンで0.5GiBです。

GGUFはSFT版をmmnga-o、RL版をmradermacherが変換して公開しています（サイズはSFT版の値）。16GBのGPUでもBF16の重み自体は14.96GiBなので載りますが、vLLM v0.32.0は既定で --gpu-memory-utilization が0.92（16GiBなら約14.7GiB）のため、重みだけで上限を超えます。16GB以下ならQ8_0以下を選ぶほうが現実的です。量子化の方式ごとの精度の違いはGPTQ・AWQ・GGUFの比較を参照してください。

OllamaはHugging Face上のGGUFを直接取得できます。

ollama run hf.co/mradermacher/ArrowCanaria-Llama-8B-RL-v0.1-GGUF:Q4_K_M

変換済みGGUFのヘッダーを読むと、SFT版・RL版とも llama.rope.freq_base は500000.0で、次章のRoPEの問題はGGUFでは起きません。チャットテンプレートもGGUFに埋め込まれています。

GPU不要のFeatherless API配信と提供仕様

手元にGPUが無い場合は、Hugging Face上のモデルをAPIで提供するFeatherlessがSFT版を配信しています。ページの表示はQuant「FP8」、Context Size「8k」、Tool Calling「Supported」で、状態の表示は「Cold」でした（2026年10月31日確認）。RL版のページもあります。

APIの提供仕様とモデルカードの学習条件は、区別して確認します。Context Size 8kはサービス側で受け付ける長さで、モデルカードの学習時の最大長は4,096トークンです。4,096を超えて入れたときの応答品質は公表されていません。Tool Calling「Supported」がサービス側でどう処理されるかもページには書かれておらず、同梱テンプレートはツール定義を読まず、学習データは後述の <functioncall> 形式です。OpenAI形式の tools を渡す前に、実際のAPI応答に tool_calls が返るのか、本文にタグが出るのかを確かめます。評価はAPI単体でもでき、配信と同じシステムプロンプトとコメント列を送り、応答の最初の文字が届くまでの時間と口調の崩れを見ます。手元にGPUがあれば同じ入力でローカル実行とも比べます。

transformersで動かすときのRoPE設定の落とし穴

ArrowCanariaのconfig.jsonは transformers_version が4.57.1なのに、位置埋め込み（RoPE）の設定をtransformers 5系の書式である rope_parameters に書いています。旧来の rope_theta には10000.0、rope_scaling には null が入っています。ベースのSwallow v0.5のconfigは rope_theta が500000.0、rope_scaling が llama3（factor 8.0）です。

この設定をAutoConfigで読み、実際に使われる値を版ごとに確かめました（2026年10月31日に4.57.6と最新の5.22.1で再測定し、SFT版・RL版とも同じ結果）。

4系の LlamaRotaryEmbedding は config.rope_theta と config.rope_scaling だけを参照するため、4系で読み込むとベースと異なる位置エンコーディングで推論が走ります。第三者によるGoogle Colab（L4）での試用記録（zenn.dev/kun432、2026年3月22日）では、transformers 5.0.0でエラーが出たため4.57.6に下げて動かしており、読み込み後のVRAMは15,526MiBでした。4系に下げた場合は、RoPEの値を明示して読み込みます。

import transformers
from transformers import AutoConfig, AutoModelForCausalLM, AutoTokenizer

model_name = "DataPilot/ArrowCanaria-Llama-8B-SFT-v0.1"
config = AutoConfig.from_pretrained(model_name)
if transformers.__version__.startswith("4."):
    # 4系は rope_parameters を読まないため、ベースモデルと同じ値を明示する
    config = AutoConfig.from_pretrained(
        model_name,
        rope_theta=500000.0,
        rope_scaling={"rope_type": "llama3", "factor": 8.0, "low_freq_factor": 1.0,
                      "high_freq_factor": 4.0, "original_max_position_embeddings": 8192},
    )
print(transformers.__version__, getattr(config, "rope_theta", None), config.rope_scaling)

tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name, config=config, dtype="bfloat16", device_map="auto"
)

AutoConfigの部分は4.57.6で 500000.0 {'rope_type': 'llama3', ...}、5.22.1で None {..., 'rope_theta': 500000.0, 'rope_type': 'llama3'} と表示されることを確認しています。SFT版にはgeneration_config.jsonが無く、RL版のものにもサンプリング設定は入っていません。temperature などは毎回指定します。モデルカードの例は temperature=0.7・top_p=0.9・repetition_penalty=1.05 です。

vLLMでOpenAI互換APIとして配信する手順

起動コマンドと4,096トークンの配分

配信ツールから呼ぶなら、vLLMでOpenAI互換APIを立てるのが手早い方法です。vLLM v0.32.0（2026年10月18日）は依存に transformers >= 5.16.1, < 5.20.0 を指定しているため、前章のRoPEの問題は起きません。

vllm serve DataPilot/ArrowCanaria-Llama-8B-RL-v0.1 \
    --dtype bfloat16 \
    --max-model-len 4096 \
    --port 8000

config.jsonの max_position_embeddings はベースと同じ131,072ですが、ArrowCanariaが学習した最大長は4,096トークンです。モデルカードの例も --max-model-len 4096 で揃えています。これより長く取ること自体は可能ですが、学習していない長さでの応答品質は公表されていません。

4,096トークンの内訳は先に見積もっておきます。AItuber-Realworld-Data-beta1の1,945件のペルソナ用システムプロンプトをArrowCanariaのトークナイザーで数えると、特殊トークンを加えずに本文だけを数えた場合、中央値2,064トークン（最小1,167・最大3,012）でした。実際の入力にはチャットテンプレートの制御トークンも加わります。ペルソナを書き込むだけで半分を使うため、コメント履歴は直近数往復に絞り、要約した記憶をシステムプロンプトへ差し込む設計が必要です。同じ1,945件のペルソナ用プロンプトでは、1トークンあたり中央値1.33字（1.20〜1.47字）でした。自分のプロンプトも実際にトークナイザーで数えて確かめてください。

Function Callingの<functioncall>形式と自前の解析

モデルカードはTool Use対応をうたいますが、同梱のchat_template.jinjaは messages のroleと本文を並べるだけです。tools を渡しても出力は1文字も変わらないことを、apply_chat_template で確認しました。vLLMの --tool-call-parser llama3_json はLlama 3.1のJSON形式を前提にしており、ArrowCanariaの学習データの形式とは一致しません。

公開されているFunction-Calling-Japanese-Datasetは、関数定義のJSONをシステムプロンプトに並べ、応答を <functioncall> {"name": ..., "arguments": '...'} </functioncall> の形で返させています。7,000件中5,987件のシステムプロンプトがこの形式を指示し、4,788件のassistant応答に計6,433回の呼び出しが含まれます。その6,433回すべてで arguments が単引用符で囲んだ文字列でした（リビジョン34e5d18、2026年10月31日に再集計）。単引用符はJSONとして無効なので、json.loads にそのまま渡すと失敗します。次の関数は、同じリビジョンのassistant応答に含まれる6,433件の呼び出しを、失敗0件で解析できました。1回の入力で返すのは最初の呼び出しだけで、不正な形式では例外が発生するため、呼び出し側で処理してください。

import json, re

FC = re.compile(r"<functioncall>\s*(.*?)\s*</functioncall>", re.S)
QUOTED_ARGS = re.compile(r"\"arguments\":\s*'(.*)'\s*}$", re.S)

def parse_functioncall(text):
    """応答から <functioncall> を取り出し (関数名, 引数) を返す。無ければ None"""
    m = FC.search(text)
    if not m:
        return None
    body = m.group(1)
    q = QUOTED_ARGS.search(body)
    if q:  # 学習データでは arguments が '...' で囲まれた文字列になっている
        name = json.loads(body[:q.start()] + '"arguments": null}')["name"]
        return name, json.loads(q.group(1).replace("\\'", "'"))
    call = json.loads(body)
    return call["name"], call.get("arguments", {})

システムプロンプトは、データセットと同じく「あなたは以下の機能にアクセスできる親切なアシスタントです」に続けて関数定義を置き、「これらの機能を使用するには、以下の形式で応答してください」と書式を示す形にそろえます。関数呼び出し全般の流れはFunction Callingの仕組みと実装で解説しています。

Open-LLM-VTuberに日本語AItuberとして組み込む設定

Open-LLM-VTuberは、音声認識・LLM・音声合成・Live2Dをつないで会話するAIキャラクターを動かすOSSです（GitHubスター約1.4万、最新リリースはv1.2.1＝2025年8月）。LLMはOpenAI互換APIで差し替えられるので、前章のvLLMサーバーをそのまま使えます。conf.yaml の該当箇所は次のとおりです。

character_config:
  persona_prompt: |
    あなたはAItuberの「〇〇」です。一人称は「わたし」。
    コメントには1〜2文で短く返してください。
  agent_config:
    agent_settings:
      basic_memory_agent:
        llm_provider: 'openai_compatible_llm'
        use_mcpp: False
    llm_configs:
      openai_compatible_llm:
        base_url: 'http://localhost:8000/v1'
        llm_api_key: 'somethingelse'
        model: 'DataPilot/ArrowCanaria-Llama-8B-RL-v0.1'
        temperature: 0.7

既定の設定ファイルでは use_mcpp がTrueで、OpenAI APIのツール呼び出しを使います。前章のとおりArrowCanariaのテンプレートはツール定義を読まないため、Falseにしておきます。既定の persona_prompt は英語の皮肉屋キャラクターなので日本語に書き換えます。音声合成は既定のedge_ttsの voice を ja-JP-NanamiNeural などの日本語音声に、音声認識の言語設定も日本語に合わせます。なお、既定の設定ファイルで配信コメントを取り込む live_config はbilibili_liveのみで、YouTubeのコメントを読ませるには別途の連携が必要です。キャラクターの声を独自に作るならStyle-Bert-VITS2を組み合わせる構成が選べます。

ライセンスと商用利用で確認する条件

SFT版のモデルカードは、本文の表では「Llama 3.1 Community License + Gemma Terms of Use」、冒頭のメタデータでは llama3.3 と gemma を挙げており、表記が食い違っています。ベースのSwallow v0.5も同じで、メタデータは llama3.3、License節の本文は META LLAMA 3.1 COMMUNITY LICENSE と Gemma Terms of Use です。RL版のメタデータは llama3.1 です。表示義務などは共通しますが、月間アクティブユーザー数の判定基準日や配布時の通知文は異なるため、適用ライセンスの表記不一致は公開元への確認が必要です。

• 月間アクティブユーザー7億人超：Llama 3.1のリリース日時点で超えていれば、Metaから別途ライセンスを受ける必要がある
• 表示義務：モデルや、それを含む製品・サービスを配布・提供するなら、ライセンスの写しを添え、関連サイトやUIに「Built with Llama」を目立つ形で表示する
• 派生モデルの命名：Llamaの出力や重みで学習したモデルを配布するなら、モデル名の先頭に「Llama」を付ける
• Gemmaの利用制限：Swallow v0.5はgemma-3-27b-itの出力で学習しており、Gemma Terms of Useは合成データによる蒸留もModel Derivativesに含める。配布時は禁止用途の条項を利用規約に組み込んで下流の利用者に通知し、規約の写しを渡し、変更したファイルに変更した旨を明示し、「Gemma is provided under and subject to the Gemma Terms of Use found at ai.google.dev/gemma/terms」と書いたNoticeファイルを添える（Terms of Use第3.1節）

配信で応答を流す使い方がこの「製品・サービス」に当たるかはライセンス本文から明確に読み取れないため、配信の概要欄などに「Built with Llama」を表示しておくのが安全です。ArrowCanariaをさらに追加学習して公開する場合は、モデル名の先頭の「Llama」とGemmaの制限の引き継ぎに加え、Llama 3.1ライセンス第1.b.iii項のNoticeファイル（「Llama 3.1 is licensed under the Llama 3.1 Community License, Copyright © Meta Platforms, Inc. All Rights Reserved.」）と、同第1.b.iv項によるAcceptable Use Policyの順守が必要です。

公表されていない情報と導入を見送る条件

SFT版・RL版とも、モデルカードには日本語MT-Benchなどのベンチマークスコアが載っていません。「ELYZAやSwallowより雑談が上手い」といった比較は、2026年10月時点で公式の数値に基づいて言えるものではありません。バージョンもv0.1のままで、モデルの最終更新は2026年3月21日です。

次のどれかに当てはまるなら、ArrowCanariaより汎用の日本語モデルを選びます。

• 1回のやり取りで長い資料を読ませるRAGや、数十往復の会話履歴をそのまま保持したい場合（学習長4,096トークン）
• OpenAI形式のツール呼び出しにそのまま対応したエージェント基盤へ載せたい場合（前述の自前解析が要る）
• ベンチマークの数値で採用理由を説明する必要がある業務用途

同じ8Bクラスで日本語の汎用モデルを探すなら、Llama-3-ELYZA-JP-8Bの性能・必要スペックとOllamaでの使い方が比較の起点になります。

逆に、配信のコメントに短く返すキャラクターを手元のGPU1枚で動かしたい用途では、配信チャット形式の合成データで学習している点がArrowCanariaを試す理由になります。配信用ではなく自社の問い合わせ窓口などで日本語の会話モデルを使いたい場合は、モデル選定から運用までAIチャットボット開発として支援しています。

よくある質問

VTuberや配信者の「雑談性能」とはどういう意味ですか？

企画やゲームに頼らず、視聴者のコメントとのやり取りだけで配信を盛り上げられる力を指す言い回しです。ArrowCanariaのモデルカードはこの語をLLMの目標に転用し、翻訳調や定型文を避けて共感や相づちを含む自然な日本語で返すことを「雑談性能」と呼んでいます。

ArrowCanariaはOllamaやLM Studioで動かせますか？

動かせます。有志が変換したGGUF（SFT版はmmnga-o、RL版はmradermacher）を読み込めば使え、MacならMLX版（4bit・8bit）もあります。GGUFではtransformers 4系のRoPEの問題も起きません。

動作に必要なVRAMはどのくらいですか？

BF16のままなら重みだけで約16.06GBあり、24GB級のGPUが目安です。GGUFのQ4_K_Mは約4.92GBで、短い文脈・単一会話なら8GB級GPUが目安です。実行時にはKVキャッシュなどの追加メモリも必要です。

ArrowCanariaは商用利用できますか？

Llama 3.1 Community LicenseとGemma Terms of Useの条件を満たせば利用できます。主な条件は「Built with Llama」の表示と、Gemmaの禁止用途ポリシーの順守です。Llama 3.1の公開日（2024年7月23日）時点で、自社と関連会社の製品・サービスの前月の月間アクティブユーザーが7億人を超えていた場合は、Metaから別途許諾を受ける必要があります。

ArrowCanariaの最新版はどれですか？

2026年10月31日時点の最新はSFT版・RL版とも v0.1 です。どちらも2026年3月の公開以降更新されていません。GGUF版とMLX版は、v0.1を第三者が量子化して変換したものです。元の版はv0.1で同じですが、重みの数値精度が下がるため、応答はBF16版と完全には一致しません。

関連記事

• Swallow LLMとは？最新のGPT-OSS Swallow・Qwen3 Swallow v0.2とモデル一覧・選び方【2026年10月】
• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説
• LLM量子化とは？仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説【2026年版】
• GRPOとは？公式（目的関数・アドバンテージ）の読み方とPPOとの違い・TRL実装【2026年10月】
• Style-Bert-VITS2の使い方｜導入・学習・モデル配布・商用利用とONNX高速化【v2.7.0】