本文へ
ハクソク

世界を動かす技術を、日本語で。

Kev: Qwen3.5を基にしたJevに似た小型の意思決定モデルファミリー

元記事: 原文(github.com)

概要

Kev は、Qwen3.5ベースの 小型意思決定モデルファミリー。 自身で訓練・実行可能 で、TypeSafe System One互換APIを提供。 0.8B/4B/9Bモデル、訓練コード・評価データ同梱。 Yes/No・選択肢・スコア 質問を同時に処理可能。 CUDA・Apple Silicon対応、Macでの動作最適化も実装。

Kev: 小型Jev風意思決定モデルの特徴

  • Jev's Architecture Unmasked 記載の設計を基盤とした Qwen3.5 ベースのモデルファミリー
  • 事前学習済み重み の利用、または 独自訓練 が可能
  • TypeSafe System One互換API で、Python SDKからローカルサーバーに直接接続
  • 0.8B/4B/9B の3モデルを用意、全て同一データ・設定で訓練
  • Yes/No (noul)、 選択肢 (choice)、 スコア (score) 形式の質問を 同一リクエスト内で並列処理
  • 質問同士は独立 しており、互いの内容を参照不可
  • CUDA・Apple Silicon 両対応、4B/9Bモデルは 32GB Mac で動作（bf16使用時）
  • Web Playground で入力や選択肢順序の影響を可視化・検証可能

クイックスタートガイド

  • 必要環境 ：Python 3.12+、uv
  • 導入手順 ：
    • git clone https://github.com/jaredpalmer/kev.git && cd kev
    • uv sync --extra serve
    • KEV_DTYPE=bf16 uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8009
  • 初回実行時 にアダプタとベースモデルを自動ダウンロード
  • --run オプションでローカルチェックポイントやHubリビジョン指定も可能
  • API例 ：curlでの問い合わせ、TypeSafe Python SDKによる実装例も用意

サンプルAPIリクエストとレスポンス

  • リクエスト には「状態」と複数質問をJSONで送信
  • レスポンス は各質問ごとに
    • 選択肢の確率分布
    • Yes/No確率
    • スコア値・信頼度
  • token数・応答遅延 などの使用状況も返却

モデル構成と精度比較

  • Kev-0.8B/4B/9B ：Qwen3.5ベース、同一データセットで訓練
  • 精度・Brierスコア （低いほど良い）を 開発/テストセット で比較
    • Kev-9B はJevに近い精度を達成
  • 旧世代（Qwen3）モデル も併存し、Macでの低遅延用途に推奨
  • モデルカード・PLAN.md で詳細な訓練・評価指標を公開

API仕様

  • POST /v1/systemone ：状態テキストと複数質問を評価
    • noul ：Yes/No確率
    • choice ：選択肢ごとの確率・信頼度
    • score ：スコア値・信頼度・分布
  • /v1/models, /v1/systemone/permute, /v1/systemone/separate 等のエンドポイントも実装
  • サーバーは127.0.0.1バインド、認証なし （ローカル運用推奨）

アーキテクチャ詳細

  • LoRAアダプタ ＋ 小型ポインタヘッド をQwenベースに追加
  • Attention-Onlyモデル では全質問・状態を一つのトークン列で処理
  • Qwen3.5 （DeltaNet層あり）は各質問ごとに独立した行で計算
  • 各質問は状態のみ参照可能、他質問は参照不可の設計
  • 選択肢間の順序依存性 もテスト・検証済み
  • 訓練時はクロスエントロピー損失 を利用
  • Jevの出力は訓練データに未使用

サービング・パフォーマンス

  • CUDA環境 ：Qwen3.5モデルはflash-linear-attention推奨、H100上で高速
  • Apple Silicon ：DeltaNet層はPyTorchのリファレンス実装で動作
  • Macでの推奨モデル ：現状はQwen3世代が低遅延、Qwen3.5は今後MLX対応予定
  • LoRA合成・SDPA attention・入力パディング・状態キャッシュ 等で高速化
  • 繰り返しリクエスト時のキャッシュ利用 で応答時間短縮

その他の機能・設定

  • KEV_TEMPERATURE ：確率の温度スケーリングでキャリブレーション改善
  • KEV_DATE_FACTS ：状態内の日付差分を自動付加、締切判定精度向上
  • 全重み・tarball・SHA-256 をGitHubリリースで公開
  • 旧世代モデルとの性能比較 も詳細に公開

まとめ

  • Kev は Jev風の小型意思決定モデル を自分で簡単に訓練・運用可能
  • TypeSafe System One互換API で既存ツールとの連携も容易
  • Web Playground や Python SDK で手軽に試験・評価対応
  • Mac・CUDA両環境 での最適化、 低遅延サービング に配慮
  • 詳細なモデル評価・比較データ も公式リポジトリで提供

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

OSSのJevみたいなモデルに人々が注いでるエネルギーにかなり感心してる。盛り上がりは理解できるけど、こういうモデルの使い道って何なんだろう？コーディングエージェントの文脈で使えるのかな、それとも全然違う場面での方が関連性があるのかな？

└

同じく。APIにアクセスできるようになったけど、すぐに使うケースがないことに気づいた。

└

Jevみたいなモデルは、JSONっぽい構造を持たせると呼ぶべきだと思う。コードにちょっとした知能が必要な時に役立つよ。追記：Jevは賢いif文みたいなものだと考えてもいいと思う。

└

2DローグライクプラットフォーマーのためのスマートAIシステムを開発する？ゲームにはクラシックなステートマシンAIには多すぎる動くシステムがあって、開発に時間をかけられない。低遅延が魅力的なんだよね。

└

LLMに選択肢やカテゴリを出力させる「強制」する状況を考えてみて。そういうワークフローがあれば、コストと遅延の大幅な削減が約束されてるよ。コーディングエージェントには、特定の状況でしか役に立たないかもしれない。例えば、bashツールの呼び出しを安全と危険に分類するのに使えるかもしれないね。

└

この種のモデルの利用ケースは何ですか？コーディングエージェントの文脈で使えるかな？ うん、使えると思う。一番明らかな使い方は、遅くて高価なエージェント（例えば、ccやcodex、opencode）に対して、ローカルで速くて安価な「フィードバック」や「コントロール」を持つことだね。「ゴール」みたいなものを長いプロンプトから「アクション」と「バリファイア」に分けることができる。各アクションに対してバリファイアも作成する。で、各アクションの後にこの「ユニバーサル分類器」を使ってバリファイアを実行して、そのステップが正しく行われたか、フォローアップが必要かどうかを判断する。例えば、リポジトリで認証を実装する→ llm_plan() → プランのアイテムごとにgenerate_verifier() → プランのアイテムごとにimplement() ; verify() ; accept() / followup()。バリファイアはこんな感じ。プランのアイテムを入力として受け取り、タスクを確認するための分類質問を生成する。「これはプロジェクトの規約に従っている？」とか「これは他のタスクのファイルに触れている？」みたいな。LLMを使えばできるけど、いくつかのことはもっと安く、速くなるかも。どんどん増える規約リストに対してチェックするのにも使えるよ。自分のプロジェクトに特有のやつでもね。

└

上にリンクされているgitリポジトリには、特定の部署への自動メール転送のためのメール分類の良い例がいくつかあるよ。顧客サービスのメールのトーンや重要度を判断するのも含まれてる。編集: Flipper OneはLLM加速用のコプロセッサを持つ予定で、最大4GBのVRAMサイズのLLMをホストできるようになるみたい。彼らが計画しているユースケースの一つは、マイクを使ってテキスト読み上げと組み合わせて、「このシステムの仕様で.iniファイルを作成して」と言えるようにすることなんだ。小さなLLMがデバイス上でそれを実行できて、ユーザーはそのファイルを使ったり送信したりアップロードしたりできるんだ。

Jevの爆発的な流行が起きてるね。これって、私たちがもっと理解しやすいシンプルな時代に戻ってるからかな？分類モデルはもうしばらく前からあるけど。

└

実際に役立つから、以前は実現不可能だったことができるようになったんだよね。

└

各ユースケースごとに別のモデルをファインチューニングしなくていいのは魅力的だよね。そうすれば、ビジネスロジックを進化させたり、構築を続けたりする柔軟性が増すし。

└

Ansibleがうまくやったことを思い出すな。ユーザーコミュニケーションだね。基盤となる技術は長い間存在してたかもしれないけど、天才的なのは、普通の開発者に「はい、君でもMLが理解できるよ、ちょっとしたJSONを使うだけで」と提示することなんだ。その貢献は過小評価されるべきじゃないよ、最近は特に明らかだし。

└

私の見方では（JevやOSS版のLaylaをいじったことはないけど）、分類器はずっと存在していて、MLの世界では認識されたツールなんだ。でも、普通は何を分類するかを知るだけじゃなくて、入力を分類するためにどの重みを使うかを決める必要がある。Jevが登場して、「分類器をトレーニングしたり重みを決めたりする必要はないよ、したくなければ、ただ分類された答えを得るだけでいい」とその魔法を加えたんだ。これが人々の目を輝かせている理由だと思う。

Hacker Newsで議論の続きを見る

同じ出典の記事