SageMaker JumpStartのELYZA日本語モデル｜4つのmodel_idと入力上限の実測【2026年版】

Amazon SageMaker JumpStartのカタログからELYZAの日本語モデルを選ぼうとすると、最初に突き当たるのが「どれが載っているのか」という問題です。2026年8月時点で公開カタログのマニフェストを走査すると、提供元がELYZAのモデルは4つだけで、いずれも2023年公開のLlama-2世代でした。後発のLlama-3系やQwen系は含まれていません。ここでは実際のmodel_id、通常版とfast版で日本語の入力量がどれだけ変わるかの実測値、7Bと13Bで変わる必須GPUと東京リージョンの実費を、カタログの定義ファイルとモデルの設定ファイルから確認します。

まとめ

JumpStartで選べるELYZAはhuggingface-llm-elyza-japanese-llama-2-7b-chat-bf16、huggingface-llm-elyza-japanese-llama-2-7b-fast-chat-bf16、huggingface-llm-elyza-japanese-llama-2-13b-chat、huggingface-llm-elyza-japanese-llama-2-13b-fast-chatの4つです。model_idの先頭はhuggingface-llm-で、pytorch-ではありません。ここを取り違えると存在しないIDとして弾かれます。

選定で最初に効くのはfast版かどうかです。fast版は日本語の語彙を13,042追加した派生モデルで、日本語4サンプルで実測したところ、同じ文章のトークン数は通常版の52.8%で済みました。JumpStartの既定設定は入力を2,048トークンに制限しているため、この差はそのまま「1回のリクエストに何文字入るか」の差になります。

費用は選んだパラメータ数でほぼ決まります。7Bは既定がml.g5.2xlargeで東京リージョン2.197ドル/時、13Bは既定がml.g5.12xlargeで10.283ドル/時です。24時間30日の稼働に換算すると月あたり5,821.92ドルの差になるため、13Bを選ぶ前に7Bのfast版で要件を満たせないかを先に確かめてください。

カタログに載っているELYZAは2023年世代の4モデル

ELYZA（イライザ）は自社サイトで「Deep Learningを軸としたAIカンパニー」と名乗る国内企業で、2020年に独自の大規模言語モデルの開発に成功して以降、大手企業向けのLLM活用支援を主力事業としています。Hugging Face上では日本語特化モデルを18本公開しており、そのうちJumpStartのカタログに載っているのは初期の4本だけです。

JumpStartのカタログは公開マニフェスト（models_manifest.json）として配布されており、提供元と型番の対応をそのまま読めます。2026年8月13日時点でこのマニフェストの全エントリを走査し、providerがelyzaのものを抽出すると、重複する版番号を除いて次の4つに収束しました。いずれもdeprecatedはfalseで、現役として配信されています。

「元モデル」の列だけは出所が違います。仕様ファイルのHF_MODEL_IDは/opt/ml/modelというコンテナ内のパスで、配布元のリポジトリ名を書いたフィールドは存在しないためモデルカード側から対応させています。model_idにchatと入っていても、Hugging Face側の公開名はinstructです。EULA同意が4つとも必要なのは仕様ファイルのhosting_eula_keyにllamaEula.txtが指定されているためで、7B系の2つはさらにgated_bucketがtrueの非公開バケット配布です。

版の古さは選定の前提として押さえてください。Hugging FaceのAPIでELYZA名義の公開モデルを作成日順に並べると、汎用の日本語モデルに限ってもLlama-2系の7Bが2023年8月28日、13Bが2023年12月25日、Llama-3-ELYZA-JP-8Bが2024年6月25日、推論特化のELYZA-Thinking-1.0-Qwen-32BとELYZA-Shortcut-1.0系が2025年4月30日、拡散モデル系のELYZA-Diffusion-Base-1.0-Dream-7Bとその指示チューニング版が2025年12月10日と並びます（このほか2023年11月にELYZA-japanese-CodeLlama-7bがあります）。JumpStartに載っているのは、このうち最初の2世代だけです。

通常版とfast版で変わる日本語の入力量

fast版は「速い版」という名前から推論速度だけの違いに見えますが、実態は語彙を組み替えたモデルです。ELYZAの公式解説は「新たに13,042個の日本語の語彙を追加」し、その結果として日本語テキストのトークン数を「約55%まで削減」、推論速度に換算して「約1.82倍」と書いています。ここは読み違えが広く起きている箇所で、AWSの日本語ブログも「日本語テキスト内のトークン数を 55% 削減」と紹介しています。一次情報が言っているのは55%削減ではなく55%まで削減、つまりおよそ45%の削減です。

語彙拡張が分割結果に与える差の実測

実際の差を確かめるため、両モデルのtokenizer.jsonを取得してトークン数を数えました。語彙サイズはconfig.jsonのとおり通常版が32,000、fast版が45,043です。公式が言う追加語彙13,042との1つの差は、語彙拡張に伴って足された特殊トークンにあたります。技術文書・問い合わせ文・議事録・記事本文から取った日本語4サンプル（合計394文字）を、それぞれのトークナイザで特殊トークンなしにエンコードした結果が次の表です。

合計で52.8%となり、公式が示す「約55%まで」とほぼ一致しました。文体による幅は49.3%から58.8%です。1トークンあたりの日本語は、通常版が0.88文字なのに対しfast版は1.66文字を担います。なお語彙拡張そのものをこれから設計する場合は、追加した埋め込みを埋め戻す継続事前学習の負担まで含めた判断が要るので、トークナイザーとは？BPE・WordPiece・Unigramの違いと日本語での実装判断を解説【2026年版】で整理した採否条件を先に読んでください。

入力2,048トークンで変わる投入可能な文字数

この差が実務に効くのは、4モデルとも同じ入力制限で配信されているからです。仕様ファイルの環境変数にはMAX_INPUT_LENGTHが2048、MAX_TOTAL_TOKENSが4096、SM_NUM_GPUSが1と書かれており、この3つはパラメータ数にかかわらず共通です。入力は2,048トークンまで、入力と出力の合計が4,096トークンまでという制約になります。モデル側のconfig.jsonにあるmax_position_embeddingsも4096で、この設定はモデルの上限そのものです。

上の4サンプルの平均を当てはめると、2,048トークンに収まる日本語は通常版でおよそ1,800文字、fast版でおよそ3,400文字になります。問い合わせメール1通を貼って回答案を作らせる程度なら通常版でも収まりますが、社内規程やマニュアルの章をまるごと投入して要約させる使い方は通常版では入りません。長い文脈を渡す設計なら、fast版を選ぶかどうかは好みではなく前提条件です。環境変数はデプロイ時に上書きできますが、4,096を超える値を入れても位置埋め込みの上限が動くわけではありません。

デプロイ時に指定する値とSDK世代の分かれ目

7Bと13Bで変わる必須インスタンス

仕様ファイルのsupported_inference_instance_typesに並ぶのは、7B系がml.g5.xlarge・ml.g5.2xlarge・ml.g5.4xlarge・ml.g5.12xlarge・ml.g5.24xlarge・ml.g5.48xlargeの6種、13B系がml.g5.12xlarge・ml.g5.24xlarge・ml.g5.48xlarge・ml.p4d.24xlargeの4種です。飛び番があるので連続したレンジではなく、ml.g5.8xlargeを指定しても通りません。どちらもg5系とp4d系のGPUインスタンスに限られ、ml.m5.largeのようなCPUインスタンスは選択肢にありません。70億パラメータの重みをbf16で載せる時点で14GB前後のGPUメモリが要るため、CPUインスタンスを指定した手順書を見かけたら誤りだと考えてください。EBSは4モデルとも512GBが指定され、ネットワーク分離が既定で有効です。

使うインスタンスタイプは、アカウントのサービスクォータで上限が0のままだとデプロイが通りません。この関門とEULA同意の実務はAmazon SageMaker JumpStartの使い方｜SDK v3移行とデプロイ費用【2026年版】に切り出してあります。

SDKの版で変わるモデル指定の書き方

SageMaker Python SDKはv3で作り直され、v2にあったJumpStartModelクラスがなくなりました。v3の環境で旧来のimportを実行するとModuleNotFoundErrorになり、例外メッセージがModelBuilderへの移行と移行ガイドのURLを案内します。v3でELYZAのfast版を立てる場合は、JumpStartConfigにmodel_idとEULA同意を渡してModelBuilderから組み立てます。

from sagemaker.core.jumpstart.configs import JumpStartConfig
from sagemaker.core.training.configs import Compute
from sagemaker.serve import ModelBuilder

config = JumpStartConfig(
    model_id="huggingface-llm-elyza-japanese-llama-2-7b-fast-chat-bf16",
    accept_eula=True,
)
builder = ModelBuilder.from_jumpstart_config(
    jumpstart_config=config,
    compute=Compute(instance_type="ml.g5.2xlarge"),
)
builder.build()
endpoint = builder.deploy()

Computeをsagemaker.train.configsから取ると後方互換シム経由になりDeprecationWarningが出るので、新しく書くなら上のパスを使ってください。v2系のままならJumpStartModelに同じmodel_idとinstance_typeを渡し、EULA同意はdeploy(accept_eula=True)で指定します。どちらの世代で書くかの判断材料は前掲のJumpStart全般の記事にまとめてあります。

推論リクエストの形式とプロンプトの組み立て

ペイロードの構造と応答の取り出し方

4モデルともHugging FaceのText Generation Inferenceコンテナで配信されます。仕様ファイルのdefault_payloadsにサンプルが入っており、外枠はinputsに文字列、parametersに生成条件を置いたJSONです。既定サンプルのparametersはmax_new_tokensが256、temperatureが0.6、top_pが0.9、これにdetailsとdecoder_input_detailsを加えた5つが指定されています。ただしサンプルのプロンプト本文は「User:／Assistant:」という英語の体裁なので、日本語で使うならこの中身は差し替えてください。

応答はオブジェクトではなく配列で返り、生成文は[0].generated_textから取ります。ここを辞書としてresponse["generated_text"]で読むとTypeErrorになります。

import json
import boto3

runtime = boto3.client("sagemaker-runtime", region_name="ap-northeast-1")

system = "あなたは誠実で優秀な日本人のアシスタントです。"
instruction = "SageMakerのエンドポイントを削除する理由を1文で説明してください。"
prompt = f"[INST] <<SYS>>\n{system}\n<</SYS>>\n\n{instruction} [/INST] "

payload = {
    "inputs": prompt,
    "parameters": {"max_new_tokens": 256, "temperature": 0.6, "top_p": 0.9},
}

res = runtime.invoke_endpoint(
    EndpointName="YOUR_ENDPOINT_NAME",
    ContentType="application/json",
    Body=json.dumps(payload),
)
print(json.loads(res["Body"].read())[0]["generated_text"])

Llama 2形式のプロンプトとBOSトークンの扱い

プロンプトの体裁はLlama 2のchat形式を引き継いでいます。[INST]と<<SYS>>でシステムプロンプトを囲み、ユーザーの指示のあとに[/INST]で閉じる形です。この体裁を省いて素の文章だけを投げると、指示に従わず続きを書き足すだけの出力になりやすくなります。日本語の指示チューニングが効くのはこの形で渡したときです。

ELYZAのモデルカードにあるローカル実行の例では、先頭にBOSトークンの文字列を連結したうえでadd_special_tokens=Falseを指定しています。エンドポイント経由ではコンテナ側がBOSを付けるため、上のコードのようにプロンプト文字列へ<s>を書かないでください。モデルカードのコードをそのまま貼るとBOSが二重に付きます。

13Bを選ぶ判断と東京リージョンの実費

AWS Price List APIから取得した東京リージョン（ap-northeast-1）のホスティング単価は、2026年8月12日発行のデータでml.g5.2xlargeが2.197ドル/時、ml.g5.12xlargeが10.283ドル/時です。24時間30日の稼働に換算すると、7Bの既定構成が1,581.84ドル、13Bの既定構成が7,403.76ドル、差額は月あたり5,821.92ドルになります。

ここは判断を言い切ります。日本語の長文を扱いたいという理由だけで13Bを選ぶ必要はありません。文脈長の上限は7Bも13Bも同じ4,096トークンで、13Bにしたところで入る量は増えないからです。入力量が理由なら、支払うべきコストは13Bへのサイズアップではなく7Bのfast版への切り替えです。13Bが効くのは、7Bのfast版で出力品質が要件に届かないと実際のプロンプトで確認できた場合に限られます。

7B系では既定より小さいml.g5.xlargeも選べますが、GPUは同じA10G 1基で単価差は0.154ドル/時しかありません。サイズを下げる費用対効果が薄い理由は前掲のJumpStart全般の記事の単価表で確認できます。

リアルタイム推論エンドポイントは、リクエストが1件も来なくても起動している限り課金されます。検証で立てたエンドポイントを消し忘れる事故が、ELYZAを試すときの最大のコスト要因です。後片付けで消す対象は3つありますが、インスタンス時間の課金を止めるのは最初の1つだけで、残る2つは定義の後始末です。

import boto3

sm = boto3.client("sagemaker", region_name="ap-northeast-1")

sm.delete_endpoint(EndpointName="YOUR_ENDPOINT_NAME")              # 課金が止まるのはここ
sm.delete_endpoint_config(EndpointConfigName="YOUR_CONFIG_NAME")
sm.delete_model(ModelName="YOUR_MODEL_NAME")

SDKのv3が示すクリーンアップの手順もエンドポイント・エンドポイント設定・モデルの3点を消す形になっており、エンドポイントだけ削除して一覧から消えたように見えても、定義そのものはアカウントに残ります。常時稼働が要らない検証用途でサーバーレス推論へ逃がす判断は、前掲のJumpStart全般の記事に整理してあります。

最新のELYZAを使いたい場合に取れる経路

ここまで見たとおり、JumpStartのカタログはELYZAについて2023年で止まっています。2024年6月公開のLlama-3-ELYZA-JP-8Bも、2025年公開のELYZA-Thinking-1.0-Qwen-32Bも、マニフェストを提供元と型番の両方で走査した限り載っていません。新しいモデルを使いたい場合の経路は3つに分かれます。

1つ目は、Hugging Faceで公開されている重みを自分でコンテナに載せてSageMakerのエンドポイントにする方法です。Llama-3-ELYZA-JP-8BはMeta Llama 3 Community License、ELYZA-Thinking-1.0-Qwen-32BとELYZA-Shortcut-1.0系はApache 2.0で公開されており、後者は改変や再配布の条件が緩い点で扱いやすくなっています。JumpStartのワンクリックは使えませんが、推論コンテナは同じText Generation Inferenceを流用できます。

2つ目は、モデルの重みを自前で持たずマネージドなAPIに寄せる方法です。トラフィックが読めない用途でインスタンス時間の課金を避けたいなら、そもそもエンドポイントを管理しないAmazon Bedrockの使い方｜料金・モデル・APIの始め方を4ステップで解説【2026年版】の系統に寄せるほうが費用構造は素直です。

3つ目は、日本語対応の別モデルをJumpStartのカタログ内で探す判断です。同じマニフェストにはhuggingface-llm-calm3-22b-chatとhuggingface-llm-calm2-7b-chat-bf16（サイバーエージェント）、huggingface-llm-rinna-3-6b-instruction-ppo-bf16（rinna）、model-textgenerationjp-japanese-stablelm-instruct-alpha-7b-v2（Stability AI）が並んでいます。ELYZAという固有名詞が要件でないなら、2024年公開のcalm3-22bのほうが世代は新しくなります。

逆に言えば、JumpStartでELYZAを選ぶ積極的な理由は「ワンクリックでVPC内に閉じた日本語モデルのエンドポイントが立つこと」に絞られます。ネットワーク分離が既定で有効なこの構成は、社外にテキストを出せない業務では十分な採用理由です。その要件がないなら、2023年世代のモデルにこだわる必要は薄いと考えます。

よくある質問

SageMaker JumpStartでELYZAのどのモデルが使えますか？

2026年8月13日時点の公開マニフェストでは、ELYZA提供の4モデルです。7B系がhuggingface-llm-elyza-japanese-llama-2-7b-chat-bf16とhuggingface-llm-elyza-japanese-llama-2-7b-fast-chat-bf16、13B系がhuggingface-llm-elyza-japanese-llama-2-13b-chatとhuggingface-llm-elyza-japanese-llama-2-13b-fast-chatです。いずれもベースはLlama 2で、4つとも現役として配信されています。

Llama-3-ELYZA-JP-8BをJumpStartからデプロイできますか？

できません。公開マニフェストを提供元と型番の両方で走査しても、Llama-3系やQwen系のELYZAモデルは登録されていません。Hugging Faceで公開されている重みを自分でコンテナに載せてエンドポイントを作るか、マネージドなAPI経由で使う経路になります。

fast版と通常版はどちらを選ぶべきですか？

日本語を長く入力するならfast版です。日本語4サンプル394文字での実測で、fast版のトークン数は通常版の52.8%でした。入力上限は両方とも2,048トークンなので、収まる日本語はおよそ1,800文字と3,400文字の差になります。短い入力しか扱わないなら通常版でも実害はありません。

ml.m5.largeのようなCPUインスタンスでデプロイできますか？

できません。仕様ファイルのsupported_inference_instance_typesに並ぶのはg5系とp4d系のGPUインスタンスだけです。7B系の既定はml.g5.2xlarge、13B系の既定はml.g5.12xlargeで、CPUインスタンスは選択肢に含まれていません。

ELYZAのモデルは商用利用できますか？

JumpStartに載っている4モデルはMeta社のLlama 2をベースにしており、配布物に同梱されているLlama 2 Community Licenseが適用されます。商用利用は原則として可能ですが、直前の暦月における月間アクティブユーザーが7億人を超える事業者は、Meta社から別途ライセンスを受ける必要があると明記されています。デプロイ時のEULA同意も必須です。なおELYZAが2025年に公開したELYZA-Thinking-1.0-Qwen-32BとELYZA-Shortcut-1.0系はApache 2.0で、条件は大きく異なります。

関連記事

• Amazon SageMaker JumpStartの使い方｜SDK v3移行とデプロイ費用【2026年版】
• トークナイザーとは？BPE・WordPiece・Unigramの違いと日本語での実装判断を解説【2026年版】
• Amazon Bedrockの使い方｜料金・モデル・APIの始め方を4ステップで解説【2026年版】
• Amazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年版】