Documentation Index
Fetch the complete documentation index at: https://docs.arkor.ai/llms.txt
Use this file to discover all available pages before exploring further.
プログラムからの学習実行(CLI なし)
arkor dev と arkor start は反復作業に便利ですが、トレーナーを走らせる唯一の方法ではありません。arkor パッケージは runTrainer を再エクスポートしており、Trainer 自体に start / wait / cancel があるので、任意の TypeScript コードから学習を駆動できます: サーバールート、cron ワーカー、CI ステップなど。
このレシピは最初に出てくる 2 つの形を紹介します。
形 1: runTrainer(arkor start が呼ぶ関数そのもの)
runTrainer は arkor start がビルド後に呼ぶ関数です。引数なしだと src/arkor/index.ts を直接 import します。arkor start はまず arkor build を走らせてから、バンドル成果物 .arkor/build/index.mjs に対して runTrainer を呼びます。いずれにせよロード済みモジュールからトレーナーを選び(arkor を最優先、次に trainer、最後に default)、start() と wait() を呼んでくれます。
src/arkor/ にあって、CLI 以外のコード(GitHub Actions のステップ、ビルドステップ、使い捨てスクリプト)からトリガーしたいだけなら、これが正しい形です。トレーナーのコールバックと abortSignal の配線をそのまま継承します。
.ts エントリでの Node バージョン注意。 arkor CLI の bin は、走っている Node が TypeScript ストリッピングを有効化していないとき自動で --experimental-strip-types で再 exec します。プログラム呼び出し側はその恩恵を受けません。runTrainer() を .ts のソースエントリに対して呼ぶスクリプトを動かすには、Node 23+(TypeScript ストリッピングがデフォルトで有効)を使うか、Node 22.6+ なら --experimental-strip-types を付けてください。実験フラグに依存したくないなら、runTrainer をビルド出力(.arkor/build/index.mjs)に向ければよいです。成果物は素の ESM で、対応 Node であればフラグなしで動きます。
CI で刺さりがちな細かい点: runTrainer()(および trainer.wait())は学習が completed で終わっても failed で終わっても resolve します。SSE ストリームはどちらでも単に終了し、reject するのはトランスポートレベルのエラー(abort、再接続が尽きた等)だけです。runTrainer() を素朴に try / catch で囲むと、失敗した学習ジョブでも CI は 0 で終わってしまいます。CI を失敗させたいなら、トレーナーを直接駆動して終端ステータスを検査してください:
failed を呼び出し側で検知する必要がない場合(例えばトレーナーの onFailed コールバックが既にアラート系に飛ばしている場合)にだけ、await runTrainer() を直接使ってください。
形 2: 直接 start() / wait()(フルコントロール)
トレーナー参照を保持したい、キャンセルを明示的に管理したい、1 プロセスから複数のトレーナーを走らせたい、という場合は自分で Trainer を組み立てて直接駆動します。
start が投入、wait がコールバックを駆動する SSE イベントストリームを動かします。自分で呼ぶことで参照を保持したり、その周りでログを取ったり、学習を合成したりできます。
このパターンが嵌まる場面
Next.js API ルート。 アプリからオンデマンドに学習をトリガーし、jobId を返して、フロントエンドが Studio(あるいは自前のステータスページ)で進捗をポーリング。
createTrainer は開始したジョブをキャッシュするので、単一のトレーナーインスタンスで駆動できる学習は 1 回だけです。同じインスタンスで start() を 2 回呼んでも元の jobId が返ります。長寿命の Next.js サーバープロセスでは、ルートはリクエストごとに新しいトレーナーを作る必要があります。トレーナーモジュールからファクトリを公開してください:
dryRun: true と組み合わせれば、長い GPU 実行を焼かずにトレーナー設定をエンドツーエンドで検証できます:
process.env.ARKOR_SMOKE を読んで dryRun: true を立てるようにします。学習は数分で終わり、トレーナー設定に問題があれば CI ジョブが派手に失敗します。
1 プロセスから複数トレーナー。 createArkor は単一の trainer を受け付けるので、マルチトレーナープロジェクトは宣言的ではなくプログラム駆動です。順次でも並行でも:
wait() も必要なら start() をトリガーします。
心に留めておくこと
runTrainerと直接のstart/waitは同じライフサイクルを共有。 コールバックはwait()から発火します。start()を呼んでwait()をスキップすると、バックエンドで学習が進んでいてもコールバックは動きません。abortSignalとcancelは依然として別物。 二段階パターンは Early stopping を参照。- SDK § overview の補助ヘルパーはこれらのワークフローのためにエクスポートされている。
readCredentials、writeCredentials、ensureCredentials、requestAnonymousToken、state.jsonヘルパーは、CLI を介さずに認証やルーティングをブートストラップする必要があるコード向けです。 runBuild/runStart/runDevはエクスポートされない。 CLI コマンドランナーはcli/commands/以下にあり、意図的に CLI 専用です。arkor startが使うのと同じフローへの公開エントリはrunTrainerだけです。