JoyCaptionの使い方｜Beta OneをComfyUI・GGUF・4bit量子化で動かす手順

JoyCaptionは、画像から説明文やタグを書き出す無検閲の画像キャプショニングVLMです。LoRAや拡散モデルの学習データ作り、画像からのプロンプト復元に使われます。素の状態では約17GBのVRAMを使うため、つまずくのは「手元のGPUで動くか」と「どの実行方法を選ぶか」の2点です。この記事では2026年10月13日時点の公式リポジトリとモデルカード、公式ComfyUIノードのソースコードを読み、GGUF版とOllama有志版は実機で動かして確かめた結果をもとに、動かし方を手順として整理します。

まとめ

• 最新版はBeta Oneのまま：2025年5月11日の公開以降、Beta TwoやJoyCaption 3は出ていません（2026年10月13日時点）。
• VRAMはbf16で約17GB、nf4なら8GB：4bit化するときは llm_int8_skip_modules で視覚エンコーダを量子化から外すのが作者の指定です。
• ComfyUIの公式ノードは3ノード構成：2026年2月25日のv1.1.0でモデル読み込みが別ノードに分かれました。古いワークフローは繋ぎ直しが要ります。
• GPUが無いならGGUF＋mmproj：llama.cppでQ4_K版を動かすと、GPUなしのIntel Macでも1枚139秒・メモリ約5.3GB（peak memory footprint）で写真と合うキャプションが出ました。
• Ollamaは有志版なら画像を読める：ただしテンプレートが [INST] 形式で、Llama 3.1の会話形式と合っていません。テンプレートを上書きして使うのが安全です。

JoyCaptionの最新版と開発状況（2026年10月時点）

モデル構成：Llama 3.1 8BとSigLIP2を組み合わせたLLaVA型VLM

Hugging Faceのモデルカードは、基盤モデルとして meta-llama/Llama-3.1-8B-Instruct と google/siglip2-so400m-patch14-384 を挙げています。言語側がLlama 3.1の8B、視覚側がSigLIP2のLLaVA形式で、transformersの LlavaForConditionalGeneration でそのまま読み込めます。開発者のfpgaminer氏は、拡散モデルの学習用キャプションを作る目的で、SFWとNSFWを同等に扱う無検閲設計を掲げています。

Beta Two・JoyCaption 3の公開状況

検索では「joycaption beta two」「joycaption 3」も出ますが、Hugging Faceのモデル一覧APIで作者アカウント（fancyfeast）を新しい順に並べると、JoyCaption系の最新は2025年5月11日作成の fancyfeast/llama-joycaption-beta-one-hf-llava（最終更新2025年5月16日）です。2026年10月13日にHugging FaceのモデルAPIで取得した値では、直近30日のダウンロードが111,321件（累計1,834,148件）で、いまも使われ続けています。その後に同アカウントが出したのはbigASP v3やFLUX.2 Klein向けのテキストエンコーダなど別系統のモデルだけです。

GitHubリポジトリの最終コミットは2026年2月24日のデータセットへのリンク追加で、READMEの現状欄も「JoyCaption is currently at Beta One」のままです。新版を待たず、Beta Oneを前提に環境を組んで問題ありません。新規導入では、作者がAlpha Twoより指示追従を改善したと説明するBeta Oneを第一候補にします。

ライセンス：コードはApache-2.0、重みはLlama 3.1の派生

GitHubリポジトリのLICENSEはApache License 2.0です。一方でモデルカードにはライセンス欄の記載が無く、基盤モデルとしてLlama-3.1-8B-Instructが宣言されています。READMEの「no restrictions」は配布方針の表明で、Llamaの派生物に付く条件まで消すものではありません。商用で使うなら、コードのApache-2.0に加え、モデル配布物に同梱されたLLAMA_LICENSEとLLAMA_USE_POLICY.mdを確認してください。

実行方法と必要VRAMの選び方

GPUが無くても試せる公式デモ

まず出力の質を見たいだけなら、作者が公開しているHugging Face Spaceのデモが早道です。ZeroGPU上で動いており、キャプションタイプ・長さ・Extra Optionsを選ぶと、実際にモデルへ送ったプロンプトも表示されます。ここで選んだ組み合わせを、そのままローカル環境の指示文に流用できます。

精度ごとのVRAMと実行方法の対応

公式READMEはbf16で約17GB・24GB以上のGPUを推奨し、公式GUIのREADMEはnf4量子化モードの要件を8GBとしています。標準の前処理では画像を384×384にリサイズするため、元画像の解像度よりも、バッチ数や生成長、他モデルの常駐がVRAM使用量に影響します。

第三者製ComfyUIノードのREADMEには「bf16で約8GB」とする表も見られますが、8Bのパラメータを2バイトで持てば重みだけで16GBになり、公式の約17GBと合いません。VRAMの見積もりは公式の数値で行ってください。量子化形式ごとの前提はLLM量子化とは？仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説【2026年版】で、低精度フォーマットの仕組みはFP8とは？FP16・BF16・FP4との違いとE4M3/E5M2の仕組み、対応GPU【2026年版】で扱っています。

APIとして常駐させるなら、モデルカードが示す vllm serve fancyfeast/llama-joycaption-beta-one-hf-llava --max-model-len 4096 --enable-prefix-caching が起点です。モデルカードは「VLMはvLLM上で気難しく、メモリを大量に使う」と断っており、起動しなければ --max-model-len を下げ、次にeagerモードを試します。vLLMの仕組みはvLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いで整理しています。

ComfyUIでJoyCaptionを使う手順（公式ノードv1.1.0）

インストールと3ノードの繋ぎ方

ComfyUIからは、作者本人が公開しているfpgaminer/joycaption_comfyuiを第一候補にします。ComfyUI Managerで「joycaption_comfyui」を検索して入れるか、custom_nodes にクローンして requirements.txt（transformers 4.51以上・bitsandbytes等）を入れます。

2026年2月25日のv1.1.0で、モデル読み込みが独立したノードに分かれました（コミットメッセージに「BREAKING CHANGE」と明記）。READMEはまだ旧構成の説明のままなので、ノード名はソースコードで確かめるのが確実です。現行の3ノードは次のとおりです。

繋ぎ方は「Load Image → JoyCaption」の画像入力に加え、「Download and Load JoyCaption Model」の出力（JOYCAPMODEL）をJoyCaptionの model へ渡す形です。v1.0系で作ったワークフローを開くとモデル入力が未接続になるので、読み込みノードを足して繋ぎ直します。モデルは初回実行時に models/LLavacheckpoints へ自動でダウンロードされます。JoyCaptionノードは生成したキャプションと、実際に送ったプロンプトの2つを出力します。

memory_modeと量子化の選び方

読み込みノードの memory_mode は「Default」「Balanced (8-bit)」「Maximum Savings (4-bit)」の3択です。4-bitはnf4・二重量子化・計算はbfloat16で、視覚エンコーダとプロジェクタは量子化から外す設定がコードに組み込まれています。24GB未満のGPUなら4-bitから始め、品質に不満が出たら8-bitへ上げる順が無難です。keep_loaded を有効にすると、次の実行でモデルを読み直さずに済みます。v1.1.0の直前には量子化モード時のオフロード不具合の修正も入っています。

JoyCaptionノードの生成パラメータの既定値は、max_new_tokens 512・temperature 0.6・top_p 0.9・top_k 0（無効）です。caption_length は any・very short〜very long の語指定と、20〜260語（10語刻み）の数値指定を選べます。Wan2.2とは？使い方・VRAM要件・ComfyUI導入を解説【2026年最新・後継Wan2.7まで】のような動画生成モデルと併用する場合は、キャプション生成を先に済ませ、keep_loaded を無効にしてJoyCaptionの推論後にVRAMを解放してから動画生成を実行します。

GGUF対応の第三者ノードを選ぶ場面

VRAMが足りない、あるいはGGUFで揃えたいなら第三者ノードを使います。代表的なのは、GGUF用ノード（JoyCaption GGUF／JoyCaption GGUF (Advanced)）を持つ1038lab/ComfyUI-JoyCaption（v2.0.2・2025年10月27日）です。GGUF本体とmmprojを ComfyUI/models/LLM/GGUF に置き、CUDA対応のllama-cpp-pythonを入れて使います。llama-cpp-pythonのGPU版はビルドで詰まりやすく、judian17氏のGGUFノードは作者自身がOllama経由の使い方を案内しています。いずれもJoyCaptionの作者の実装ではないため、指示文が公式と揃っているかは各ノードが出力するプロンプトで確かめてください。

Pythonで4bit(NF4)実行する手順（transformers）

前提となる環境とPythonバージョン

以下のコードでは、CUDA対応のNVIDIA GPUとCUDA対応版PyTorch、transformers、Accelerate、Pillow、量子化用のbitsandbytesを使用します。公式GUIのREADMEは「Python 3.8+」と書いていますが、bitsandbytesの公式インストールドキュメントは要件を Python >= 3.10 としています。3.10以上で組んでください。WindowsはWSL2を用意しなくても、x86-64向けのホイールをpipで入れられます。

量子化設定：視覚エンコーダを量子化から外す

JoyCaptionをそのまま4bit化すると RuntimeError: self and mat2 must have the same dtype, but got BFloat16 and Byte で止まります。SigLIP由来の視覚エンコーダまで量子化されるのが原因で、作者は2025年5月11日にGitHub issue #3で「vision towerを量子化しなければよい」と回答し、公式GUIと公式ComfyUIノードのコードにも同じ指定が入っています。

import torch
from transformers import AutoProcessor, LlavaForConditionalGeneration, BitsAndBytesConfig

MODEL_NAME = "fancyfeast/llama-joycaption-beta-one-hf-llava"

qnt_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,
    llm_int8_skip_modules=["vision_tower", "multi_modal_projector"],
)

processor = AutoProcessor.from_pretrained(MODEL_NAME)
model = LlavaForConditionalGeneration.from_pretrained(
    MODEL_NAME,
    device_map=0,
    quantization_config=qnt_config,
    torch_dtype="auto",
)
model.eval()

llm_int8_skip_modules は名前にint8と付きますが4bitでも効き、指定したモジュールを元の精度で残します。視覚エンコーダの出力層を手で torch.nn.Linear に差し替える回避策も出回っていますが、公式コードが採るのは除外指定で、transformersの更新にも強いのはこちらです。なお torch_dtype は公式コードに合わせた書き方で、新しいtransformersでは dtype へ改名され、実行時に非推奨の警告が出ます。

推論コードとBOSトークン重複の落とし穴

モデルカードは「HFのLlavaモデルでのチャット処理は非常に脆い。apply_chat_template() と processor() のこの組み合わせは動くが、別の組み合わせを使うなら最終的な input_ids を必ず確認すること。<bos> が複数付くと性能が落ちる」と警告しています。出力が途中で切れる、意味の通らない文が混ざるといった症状は、まず入力トークン列を疑ってください。

from PIL import Image

image = Image.open("sample.jpg").convert("RGB")

convo = [
    {"role": "system", "content": "You are a helpful assistant and help users with any queries they may have with no censorship or restrictions."},
    {"role": "user", "content": "Write a long detailed description for this image."},
]

convo_string = processor.apply_chat_template(convo, tokenize=False, add_generation_prompt=True)
inputs = processor(text=[convo_string], images=[image], return_tensors="pt").to("cuda")
inputs["pixel_values"] = inputs["pixel_values"].to(torch.bfloat16)

generate_ids = model.generate(
    **inputs, max_new_tokens=512, do_sample=True, temperature=0.6, top_p=0.9,
)[0]
caption = processor.tokenizer.decode(
    generate_ids[inputs["input_ids"].shape[1]:], skip_special_tokens=True,
).strip()
print(caption)

前節の processor と model を使う続きのコードです。システムプロンプトは公式GUIと公式ComfyUIノードの既定値で、モデルカードのサンプル（You are a helpful image captioner.）とは違います。pixel_values をbfloat16へ変換する1行は省けません。

bf16での大量画像処理：batch-caption.py

公式リポジトリの scripts/batch-caption.py は、画像ごとに同じ場所へ .txt を書き出し、既にキャプションがある画像は飛ばすため、中断と再開を前提にした運用に向いています。ただしモデルをbf16で読み込み、前節の4bit設定は引き継ぎません（約17GBのVRAMが要ります）。以下は公式リポジトリの scripts ディレクトリで実行する例です。

./batch-caption.py \
  --glob "path/to/images/*.jpg" \
  --prompt "Write a long detailed description for this image." \
  --batch-size 4 --num-workers 4 --max-new-tokens 256

既定値は --batch-size 1・--temperature 0.6・--top-p 0.9・--max-new-tokens 256・--num-workers 4 で、--greedy を付けるとサンプリングを止めて出力のぶれを抑えられます。8GB級のGPUで一括処理したいなら、公式Gradioアプリ（gradio-app/app.py）でnf4を選び、Batchタブで複数画像を処理して結果をZIPで受け取ります。

GGUF＋mmprojで動かす手順（llama.cppで実測）

GGUF本体・mmprojの配置とllama.cpp実行コマンド

GGUF版は第三者が変換したもので、画像を読むには本体GGUFに加えてmmproj（マルチモーダルプロジェクタ）のファイルが要ります。KoboldCpp向けのconcedo氏の配布物は本体（Q4_K・Q8_0・F16）とmmproj（F16）を同じリポジトリに置いており、KoboldCpp 1.91以降を想定しています。llama.cppでは公式のマルチモーダル文書どおり、-m で本体、--mmproj でプロジェクタを渡します。

./llama-mtmd-cli \
  -m Llama-Joycaption-Beta-One-Hf-Llava-Q4_K.gguf \
  --mmproj llama-joycaption-beta-one-llava-mmproj-model-f16.gguf \
  --image cat.jpg \
  -p "Write a long detailed description for this image." \
  -n 300 --temp 0.6 --top-p 0.9 -c 4096

本体GGUFだけを読み込むと画像の入口が無いテキストモデルになり、画像の中身とは無関係な文を返します。GGUFが何を格納する形式なのかはGGUFとは？量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】で説明しています。

GPUなしのIntel Macで動かした実測値

上のコマンドを、2026年10月13日にGPUを使わない環境で実行しました。環境はIntel Core i9-9880H（8コア）・メモリ16GBのmacOS、llama.cppは公式配布のビルド済みバイナリb11576（macOS x64版・2026年10月12日）、モデルはconcedo氏のQ4_K（4,920,735,936バイト）とmmproj F16（877,771,808バイト）です。入力はWikimedia Commonsの茶トラ猫の写真Cat03.jpg（1600×1598ピクセル）です。

表の値はmacOSの /usr/bin/time -l が出すpeak memory footprintで、同じ計測の最大常駐セットサイズ（maximum resident set size）は約7.45GBでした。必要なRAMを5.3GBと保証する数字ではないので、16GB未満のPCでは余裕を見てください。出力は「オレンジの茶トラ猫、黄緑の目、白いひげ、背景はぼけたコンクリートで赤いパイプが斜めに走る」という内容で、写真と食い違う記述はありませんでした。起動時のログには、llama.cppがGGUFに埋め込まれたLlama 3.1形式（<|start_header_id|> 区切り）のチャットテンプレートを使っていることが表示されます。読み込みと生成のほとんどはCPUの計算待ちで、1枚に2分強かかる計算です。数十枚の試し打ちや、GPUを確保する前に出力の傾向を見る用途なら十分に使えます。数千枚の学習データを作るならGPU環境のnf4かbf16を選ぶべきです。Apple SiliconのMacではMetalによるGPU実行を利用できますが、所要時間は機種・メモリ容量・実行設定によって異なり、今回のIntel Macとの速度差は未検証です。

Ollamaで使うときの注意（有志版とテンプレート）

Ollama公式文書におけるmmproj取り込み手順の記載範囲

Ollamaの公式ドキュメント（import・Modelfile、2026年10月13日取得）では、GGUFの取り込みは FROM /path/to/file.gguf を書くだけで、mmprojやプロジェクタを指定する記述がありません。少なくともこの2文書には、手元のGGUFとmmprojを組み合わせて取り込む手順は載っていません。

Ollama有志版の画像入力対応と会話テンプレートの不一致

一方、Ollamaのモデル置き場には有志がアップロードしたaha2025/llama-joycaption-beta-one-hf-llavaがあり、Q4_K_M（5.8GB）からQ8_0（9.4GB）まで4種類が並んでいます。レジストリのマニフェストを見ると、Q4_K_Mは本体（4,920,736,416バイト）とは別にprojectorレイヤ（877,771,808バイト）を持っており、入力も「Text, Image」と表示されます。

気をつけたいのはテンプレートです。この有志版に入っているのは [INST] {{ if .System }}{{ .System }} {{ end }}{{ .Prompt }} [/INST] 形式で、Llama 2やMistralの書式です。JoyCaptionの言語側はLlama 3.1なので、本来は <|start_header_id|> と <|eot_id|> で区切る会話形式を使います。

テンプレートの違いで出力がどう変わるかを、Ollama v0.40.3（2026年10月11日リリース）で確かめました。llama.cppと同じIntel Macと猫の写真を使い、同じ指示文・temperature 0.6・top_p 0.9・seed 42で、既定のままの有志版と、テンプレートをLlama 3.1形式に書き換えた版を1回ずつ動かしています。

上書き版は2回目の実行で、画像を含む入力775トークンをキャッシュから再利用しているため、所要時間の差はテンプレートの効果ではありません。この1枚では、既定のテンプレートでも出力は崩れず、茶トラ・ひげ・ぼけたコンクリートと赤い棒状の物体という骨格はどちらも同じでした。テンプレートの不一致が品質にどこまで響くかは、1枚の比較では言えません。それでも上書きを勧めるのは、公式のtransformersやllama.cppと同じ会話形式に揃えておけば、実行方法を移したときに出力の傾向が変わる要因を1つ消せるからです。Modelfileは公式ドキュメントにあるLlama 3系のテンプレート例をそのまま使えます。

FROM aha2025/llama-joycaption-beta-one-hf-llava:Q4_K_M
TEMPLATE """{{ if .System }}<|start_header_id|>system<|end_header_id|>

{{ .System }}<|eot_id|>{{ end }}{{ if .Prompt }}<|start_header_id|>user<|end_header_id|>

{{ .Prompt }}<|eot_id|>{{ end }}<|start_header_id|>assistant<|end_header_id|>

{{ .Response }}<|eot_id|>"""
PARAMETER stop "<|start_header_id|>"
PARAMETER stop "<|end_header_id|>"
PARAMETER stop "<|eot_id|>"
PARAMETER num_ctx 4096

ollama pull aha2025/llama-joycaption-beta-one-hf-llava:Q4_K_M で取得したあと、このファイルを置いた場所で ollama create joycaption-llama3 -f Modelfile を実行すると、上書き版が作られます。画像はAPIの images にBase64で渡します。

import base64, json, urllib.request

img = base64.b64encode(open("cat.jpg", "rb").read()).decode()
body = {
    "model": "joycaption-llama3",
    "prompt": "Write a long detailed description for this image.",
    "images": [img],
    "stream": False,
    "options": {"temperature": 0.6, "top_p": 0.9, "num_predict": 300, "seed": 42},
}
req = urllib.request.Request(
    "http://127.0.0.1:11434/api/generate",
    data=json.dumps(body).encode(),
    headers={"Content-Type": "application/json"},
)
print(json.loads(urllib.request.urlopen(req).read())["response"])

なお、猫の視線はllama.cppでは「やや左」、Ollamaの2回では「やや右」「やや上」と、同じ写真で3通りに書かれました。READMEが認める左右の取り違えがそのまま出た形で、向きや位置関係を学習させたいデータでは、キャプションを人が直す工程が欠かせません。PCにOllamaを入れてローカルLLMを組む全体の流れはローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説で扱っています。

12種類のキャプションモードと出力の作り分け

JoyCaptionのキャプションモードと出力の安定度

JoyCaptionは1つのモデルのまま、指示文の違いで出力形式を切り替えます。公式GUIと公式ComfyUIノードのコードが持つキャプションタイプは12種類で、READMEには全モードの指示文が載っています。READMEは「Descriptive CaptionとStraightforwardが最も有用で、ほかのモードは面白いが少し不安定」と書いており、学習データ作りなら、まずこの2つから選びます。

Booru系のタグモードは、公式GUIのREADMEも「アニメ調・イラストに最適化されており、実写や抽象画では精度が落ちる」と注意しています。写真へのタグ付けでは、Straightforwardで説明文を得てからタグ化する方法も候補になりますが、追加工程を含めた品質は対象画像で確認してください。長さは「long」などの語でも「100」などの語数でも指定できます。語数はモードごとの指示文に組み込まれ、Descriptiveなら「in 100 words or less」、Casualなら「within 100 words」と表現が変わります。

画像からプロンプトを復元する場合の指定

画像からプロンプトを起こしたいときはStable Diffusion Promptモードを使います。READMEの説明は「自然文とbooru風タグを混ぜた、ユーザーが実際に書くSDプロンプトを真似る」で、元画像を再現する保証はありません。約3%は崩れるので、まとめて処理するなら結果を目で確かめてから使います。生成側のモデルによって効く書式は変わり、動画生成で使うならLTX-2.3のプロンプトの書き方と使い方｜日本語セリフ・ComfyUI導入・低VRAM設定で扱っている記法に寄せる調整が要ります。

既知の制限と業務で使うときの線引き

公式が認めている誤りと拒否応答

作者はREADMEで、複数の被写体・左右の取り違え・文字の読み取り（OCR）で誤りが出ると明言しています。出力が崩れる「グリッチ」の発生率は1.5〜3%で、比較としてGPT-4oは0.01%と書いています。この発生率は作者の報告値であり、任意の画像群にそのまま当てはまるとは限らないため、学習データに入れる前に、極端に短い出力や同じ語の繰り返しを機械的に弾く工程を挟んでください。

また、Beta Oneを汎用のVLMとして質問に使うと、NSFWの問いに対してまれに拒否応答が返ることがあります。作者は「Beta One自体は検閲していないが、Llama由来の安全挙動が出ることがある」と説明し、聞き直す・言い換える・システムプロンプトを変えることで回避できるとしています。READMEは「Beta Oneは汎用の指示追従モデルではない」とも書いており、公式のモード以外の指示では、完全な指示追従を期待せず、対象画像で結果を確認してください。

無検閲モデルを業務に組み込む範囲

SFWとNSFWを同等に扱う設計は、商用VLMが応答を拒みやすい画像を含む学習用データセットを作る現場で利点になります。ただし前節のとおり、拒否応答や記述の誤りがなくなるわけではありません。一方で、エンドユーザーが任意の画像を送れる機能に直結させるのは避けるべきです。既定のシステムプロンプトは「検閲や制限なしに答える」指示を含むため、公開サービスの運用基準に合わない文言を返す可能性があります。社内のデータセット構築やカタログ整備のように、出力を人が確認してから次の工程へ渡すバッチ処理に用途を絞るのが現実的な線引きです。生成AIを業務フローへ組み込む範囲の設計から相談したい場合は、生成AI導入支援で承っています。

運用では、キャプションと一緒に生成条件を残しておくと、差し替えが要ったときに再生成の範囲を絞れます。最低限、次の5項目をファイルごとに記録してください。

• モデルID（例：fancyfeast/llama-joycaption-beta-one-hf-llava）と実行方法（transformers・GGUFの量子化レベル・Ollama）
• 精度・量子化の設定（bf16／8bit／nf4、llm_int8_skip_modules の有無）
• キャプションタイプと、実際に送った指示文の全文
• 生成パラメータ（temperature・top_p・max_new_tokens、または --greedy）
• 生成日と、人による確認の有無

指示文の全文まで残すのは、同じプリセット名でもノードやスクリプトによって指示文が違うことがあるためです。ローカルで完結させる構成そのものの利点と制約はローカルLLMの活用事例｜個人・業務での使い方とELYZAでの始め方で整理しています。

よくある質問

JoyCaptionのBeta TwoやJoyCaption 3は公開されていますか？

2026年10月13日時点では公開されていません。作者のHugging Faceアカウントで最も新しいJoyCaptionは2025年5月公開のBeta Oneで、GitHubのREADMEも「currently at Beta One」のままです。

手持ちのGPUではどの精度を選べばよいですか？

24GB以上ならbf16、16GBは8bit、12GBや8GBはnf4が目安です。8GBは公式GUIのREADMEが示すnf4のVRAM要件です。標準設定では画像を384×384にリサイズしますが、バッチ数や生成長、他モデルの常駐によって必要量が増えます。GPUが無い、または6GB以下なら、GGUF＋mmprojをllama.cppで動かす構成に切り替えてください。

ComfyUIでJoyCaptionノードのモデル入力が赤く表示されるのはなぜですか？

公式ノードがv1.1.0（2026年2月25日）でモデル読み込みを別ノードに分けたためです。「Download and Load JoyCaption Model」を追加し、その出力をJoyCaptionノードの model に繋ぐと動きます。

Ollamaで使えますか？

有志がアップロードした aha2025/llama-joycaption-beta-one-hf-llava ならprojectorを含んでおり、画像を渡せます。ただし作者の公式配布ではなく、テンプレートがLlama 3.1の会話形式と違うため、本文の手順でテンプレートを上書きしてから使ってください。手元のGGUFとmmprojを取り込む手順は、Ollamaの公式ドキュメント（import・Modelfile）には載っていません。

NSFW画像もキャプションできますか？

できます。SFWとNSFWを同等に学習対象とし、婉曲表現に逃げずに記述することが設計目標に掲げられています。出力の扱いは利用者の責任になるため、業務では人の確認を挟むバッチ処理に限定するのが前提です。

関連記事

• GGUFとは？量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】
• LLM量子化とは？仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説【2026年版】
• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違い
• ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説
• Wan2.2とは？使い方・VRAM要件・ComfyUI導入を解説【2026年最新・後継Wan2.7まで】