Mac・RTX 3090・サーバーでJev型ローカル判断モデルを実行する

一般的なチャットモデルは問い合わせを読み、回答文を生成します。Jev型判断モデルは問い合わせやイベント記録をstateとして受け取り、事前に定義した質問と選択肢を評価します。choiceは選択肢ごとの確率と最上位の選択、scoreは段階ごとの確率から計算したスコア、noulはyes/no判定の真である確率を返します。結果は通常JSONなので、問い合わせ振り分け、安全確認、次の作業選択など、文章回答が不要な工程につなげられます。

たとえば注文の問い合わせをstateとして送り、billing、shipping、technicalの選択と各候補の確率を受け取ります。この確率は業務上の正解率とは異なるため、人が付けた正解と照合してしきい値を決め、確率が低いケースや境界例は確認に回します。

oMLX 0.7.1.dev1とllama.cpp v0.6.0は、TypeSafe互換のPOST /v1/systemoneエンドポイントに対応しています。通常の/v1/chat/completionsはトークン³を生成して文章を返しますが、/v1/systemoneは指定したchoice・score・noul質問の構造化結果を返します。選択したモデルが対応する判断モデルであることを確認してから呼び出してください。

Simple Jevは通常のQwenモデルのlogitを読み、選択結果をJSONに組み立てるサーバーです。この節ではQwen3.5-0.8BをCPUで動かし、二重請求の問い合わせの担当チームを選びます。後半のoMLX経路では、別途学習されたOpenJev・Clefのチェックポイント⁴を使います。

GitとPython 3.12以降を用意します。以下はPython 3.13が入ったmacOS・Linuxのターミナル向けです。リポジトリをcloneし、そのフォルダーで仮想環境⁵を作ってサーバーパッケージをインストールします。

git clone https://github.com/featherless-ai/simple-jev.git
cd simple-jev
python3.13 -m venv .venv
source .venv/bin/activate
python -m pip install -e './hf-server'

同じ仮想環境でCPUサーバーを起動します。初回はHugging Faceからモデルを取得するため、ダウンロードと読み込みの完了を待ちます。後半のoMLXサーバーと重ならないよう、ポート8001を使います。

python hf-server/hf_server.py --model Qwen/Qwen3.5-0.8B --device cpu --dtype float32 --classifier-prompt-policy baseline --max-model-len 4096 --max-batch-size 4 --max-batch-tokens 4096 --port 8001

サーバーのターミナルは開いたまま、新しいターミナルで状態とモデル一覧を取得します。正常状態とQwen3.5-0.8BのモデルIDが出たら、短い分類リクエストを送れます。

curl http://127.0.0.1:8001/health
curl http://127.0.0.1:8001/v1/models

次のリクエストは二重請求の問い合わせをstateで送り、billing・shipping・technicalの担当チームを尋ねます。機密情報のない例から始め、業務サンプルでも個人情報を先に取り除きます。

curl http://127.0.0.1:8001/v1/classifier \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen/Qwen3.5-0.8B","state":"Customer message: I was charged twice for my order last week.","questions":{"route":{"type":"choice","instructions":"Which team should handle this?","criteria":{"billing":"Payments, invoices, and refunds","shipping":"Delivery or tracking issues","technical":"Product or account errors"}}}}'

answers.routeで選ばれたチームと候補別のprobabilitiesを読みます。人が付けた担当チームと照合し、言い換えた問い合わせや情報が不足した例も加えます。誤りの例を使って、選択肢の説明と人による確認基準を調整できます。

接続できなければ、サーバーターミナルのダウンロード・モデル読み込み状態とポート8001を確認します。HTTP 422ならエラー内容を読み、state・questions・criteriaを例と照合します。パッケージの導入に失敗した場合はPythonのバージョンと仮想環境を確認します。終了時はサーバーターミナルでCtrl+Cを押します。

MacでOpenJev・Clefを実行する手順は後述のoMLX API⁶節にあります。この節のSemIf MLX⁷実験は、必要なメモリと共通入力の再利用を比較する参考です。SemIf-OpenJevのMLX経路では、Apple silicon上でQwen3.5-4Bを直接採点する実験ができます。公開ブラウザーデモのQ4重みファイルは約3GBです。macOS、ランタイム⁸、質問ごとの作業領域、キャッシュもメモリを使うため、アクティビティモニタでメモリプレッシャーを確認し、モデルロード後の反復リクエストに使う余裕も確保してください。

ユニファイドメモリ⁹16GBのMacでも小さなリクエストは動く可能性がありますが、ブラウザーや開発ツールを開くと余裕が減ります。普段使うアプリを開いたまま1件処理し、メモリプレッシャーと完了時間を確認してください。複数の質問で長い状態を共有する場合は、共通状態を一度だけ読むshared経路と、質問ごとに読み直すfresh経路を比べます。

24GB以上のユニファイドメモリなら、質問数や入力サイズを増やして試す余裕が得られます。同じ業務サンプルを1件ずつ処理した結果と同時処理した結果に分け、選択・確率・処理時間・メモリを記録します。

35B実行メモリはBF16¹⁰・NVFP4¹¹などcheckpointとserving runtimeで異なります。たとえばJEV-35B NVFP4 cardは重み25.6GB（23.3GiB）を記載し、B200でテストしたとしています。機器選定ではcardのruntime要件と入力条件を確認します。

公開されたRTX PRO 6000の単一質問中央値はJulia-1 3ms、Laya 5ms、Kev-4B 12ms、lev 36ms、OpenJev 43msです。各model名・規模・言語を対応させ、異なる入力長や同時実行のservice遅延とは分けます。

Qwen3.5-4BのBF16重みの単純計算サイズは約8GBです（40億パラメータ×16ビット÷1バイトあたり8ビット）。RTX 3090のVRAM¹² 24GBから単純に引くと約16GB残りますが、すべてを質問キャッシュに使えるわけではありません。ランタイム、CUDA¹³ドライバー、一時バッファー、KVキャッシュ¹⁴もVRAMを使います。Q4ファイルはダウンロードと重みのメモリ使用量を減らす一方、BF16とは数値表現が異なります。

SemIfリポジトリには、RTX 3090でdirect、prefix reuse、parallel suffixを比較する例があります。一つの共通状態から複数の質問に分岐する作業では、再利用によってprefill¹⁵の重複を減らせる場合があります。SemIfの導入と実行はリンク先リポジトリのREADMEに従います。実行環境を準備してから同じチェックポイントと質問セットでdirect実行を3回記録し、prefix再利用とparallel suffixを一つずつ比較します。

各経路でモデルのリビジョン、量子化¹⁶、入力トークン数、質問数、GPU使用量、結果を保存します。初回実行にはモデルロードが含まれることがあるため、反復実行と分けて記録してください。選択結果が異なる場合は元のstateと各候補の確率を確認し、人が正解を付けたサンプルで両経路を比較します。

OpenJev 27BはQwen3.8-27Bベースの判断モデルで、画像入力にも対応します。llama.cppとoMLXでの対応状況はチェックポイントとプロジェクトのバージョンによって異なります。まずモデル一覧にdecisionタイプとして表示され、/v1/systemoneリクエストが動作することを確認してください。公開言語は英語、ドイツ語、フランス語、ヒンディー語、中国語、日本語です。韓国語業務で使う前に、韓国語の問い合わせサンプルで選択結果と誤りを評価してください。

oMLX 0.7.1.dev1はClef、Clef-Flash、OpenJev判断モデルに対応しています。リリースによると、Clef系はテキストと画像、OpenJev 27Bはテキストと1枚の画像を受け付けます。これらのモデルは文章回答ではなく選択肢の確率を返すため、通常のチャットAPIでは期待する形式が得られないことがあります。

27Bサーバーを複数人で共有する場合は、平均的な単件時間だけでなく、同時リクエスト数、長い入力、画像の有無、モデル常駐時のメモリも計画します。まずRTX 3090でQ4の4B作業のリクエストと結果を確認し、正解付きサンプルと想定運用量をもとに27Bサーバーに必要な容量を見積もります。

Apple unified memoryではOS・app用の余裕を残します。GPUでは重みに加えKV cache・activation・同時実行分も計画します。重み容量だけで安定動作とは判断できません。

ticket振り分けで担当者を飛ばしたり返金を誤承認したりすると損失が大きくなります。confidenceの低い出力を人へ回し、遅延と再確認率が目標内の機器に絞ります。

実務で繰り返し発生する問い合わせを集め、人が正解を付けます。30件は初期確認に使える小さなサンプルです。業務全体の正確さや効果を評価するには、明確な例と境界例を追加し、各モデルの選択・確率・処理時間・誤りを同じ基準で記録します。新しい誤りの種類が見つかったら、その事例をサンプルに加えます。

確率のしきい値は業務で許容できる誤りのコストに合わせます。確率が低い、または候補間の差が小さいリクエストを人に渡す規則を先に決めます。OpenJevの確率はモデルファイルの温度設定で計算されます。業務用のしきい値を別の検証サンプルで確認し、評価できた範囲から自動処理します。

1件ずつ即時処理する業務ではリクエストごとの遅延を、問い合わせをまとめて処理するなら時間当たりの処理量と完了時刻を測ります。回答が正しくても待ち行列ができる場合は、GPUの余裕や並列質問数を検討します。誤りが多い場合は、まず入力状態・選択肢・対応言語を見直してください。反復業務と入力サイズから必要な余力が確認できたら、アップグレードを比較します。

同じ質問集合・model revisionで機器ごとに繰り返し、p50・p95・最大memory・エラーを記録します。model load・初回・warm後の時間を分け、起動遅延と定常遅延を混ぜません。

小batchで合わせた設定をservice負荷へ広げる前に同時要求を段階的に増やします。品質・遅延・memory上限を同時に満たした構成を運用候補にします。

oMLXまたは対応サーバーでOpenJev・Clefのdecisionチェックポイントを取得して起動します。以下の両リクエストのYOUR_OMLX_API_KEYをサーバーに設定したキーへ変えます。認証なしのサーバーでは両方からAuthorizationヘッダーを省きます。まずモデル一覧を取得します。

curl http://127.0.0.1:8000/v1/models -H 'Authorization: Bearer YOUR_OMLX_API_KEY'

応答のdata[].idからdecisionモデルIDをコピーし、YOUR_DECISION_MODEL_IDへ設定します。次に二重請求の担当チームを尋ねる選択式リクエストを送ります。

curl http://127.0.0.1:8000/v1/systemone \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_OMLX_API_KEY' \
  -d '{"model":"YOUR_DECISION_MODEL_ID","state":"Customer message: I was charged twice for my order last week.","questions":{"route":{"type":"choice","instructions":"Which team should handle this?","criteria":{"billing":"The customer reports a duplicate charge or refund issue","shipping":"The customer reports a delivery or tracking issue","technical":"The customer reports a product or account technical issue"}}}}'

answersにrouteの質問、選択結果、確率が含まれていれば、リクエストは処理されています。実際の業務で人が正解を付けたサンプルと照合して結果を評価してください。HTTP 501は未対応のモデルタイプまたは入力形式、HTTP 400は無効なリクエストJSONを示すことがあります。ロードエラーではサーバーログの最初のエラーと空きメモリを確認します。