サポートしているモデル

Arkor バックエンドが現在受け付けるベースモデル、現時点でその 1 つに絞っている理由、そしてこれからの方向。

現在、Studio Playground（ベースモデルモード）と Arkor のホスト型推論が配信するベースモデルはただ 1 つ、Gemma 4 E4B です。createTrainer に渡す識別子は完全修飾された unsloth/gemma-4-E4B-it（SupportedModel の唯一の値。下記の例を参照）で、コンパイラーが型で検査し、トレーナー生成時にも再度検査します。学習バックエンド自体は、この SDK がまだ載せていない識別子を受け付けることがあります。それを使うには createTrainer を経由せず、生のクラウド API クライアントからジョブを投入します。その createJob は config.model を素の string のまま保っています。このドキュメントで解説していない抜け道ですが、「Unsupported model」エラーが案内するのも同じ経路です。以下では、その値が何をもたらすか、そして次に何が来るかをまとめます。

現在選べるもの#

gemma-4-E4B-it は Gemma 4 の instruction-tuned ビルドで、高速な LoRA / QLoRA ファインチューニング向けに Unsloth がパッケージしたものです。同梱のスターターテンプレート（triage、translate、redaction）はすべて、デフォルトでこれを対象にしています。

import { createTrainer } from "arkor";

export const trainer = createTrainer({
  name: "support-bot-v1",
  model: "unsloth/gemma-4-E4B-it",
  dataset: { type: "huggingface", name: "arkorlab/triage-demo" },
});

リストはコンパイラーが強制します#

model の型は素の string ではなく、サポートしているリストから導出したユニオン SupportedModel です。タイプミスはコンパイルが通りません。

createTrainer({
  name: "support-bot-v1",
  // 型 '"unsloth/gema-4-E4B-it"' を型 'SupportedModel' に代入できません。
  model: "unsloth/gema-4-E4B-it",
  dataset: { type: "huggingface", name: "arkorlab/triage-demo" },
});

同じリストはトレーナーの生成時にも強制されます。createTrainer はリスト外のモデルで例外を投げるため、型チェッカーを通らないフロー（素の JavaScript や、esbuild でバンドルする arkor build / arkor start）でも、バックエンドの 4xx ではなく手元で早期に失敗します。

型とリストの両方がエクスポートされているので、実行時にリストを走査できます（ピッカーを描画する場合など）。

import { SUPPORTED_MODELS, type SupportedModel } from "arkor";

この絞り込みが効くのは送る側です。バックエンドから読み戻したジョブ（TrainingJob.config.model）は string のままです。インストール済みの SDK より後に追加されたモデルをバックエンドが動かしている可能性があるためです。

これから#

あわせて読みたい#

• トレーナーのコンセプト。model フィールドが何で、他のフィールドの中でどこに位置するか。
• createTrainer リファレンス。TrainerInput 型の全体像。
• ロードマップ。これからの Arkor 全体像。