Qwen3.5ベースの軽量意思決定モデル「Kev」公開、ローカル実行と実装を検証

2026年9月21日2026年10月4日

基本情報

情報を集めた時点で、当サイトのコードが確定させた値です。日付はJSTで表示しています。

当サイトで確かめたこと

• Kev-4B に、当サイトが書いた判定問題20問を、GPU の無い当サイトのサーバー(3スレッド・llama.cpp b11379)で llama.cpp の /v1/systemone から解かせ、日本語で18問・英語で19問正解しました。

詳しい値と条件は、下の「当サイトでの実測」の節にあります。

概要

Qwen3.5をベースに構築された、ローカル環境で訓練および実行が可能な軽量の意思決定モデルファミリー「Kev」が公開され、オープンソースコミュニティで大きな話題となっています。Kevは、先行するクローズドな意思決定モデル「Jev」のアーキテクチャを参考に設計された、0.8B、4B、9Bのパラメータ数を持つモデル群です。1回のリクエストで「はい/いいえ（noul）」、「多肢選択（choice）」、「スコア評価（score）」といった異なるタイプの質問を同時に処理できる特徴を持ち、開発者が自身のPCやサーバーで独自の意思決定タスクを処理できるようにすることを目指しています。

話題になっている理由

現在、開発者の間ではJevの登場を契機とした「Jevブーム（Jev explosion）」とも言える現象が起きており、同様の構造化された意思決定プロセスをオープンソースで再現しようとする試みが活発化しています。Kevは、トレーニング用のコードや評価データが公開されていること、そしてApache-2.0という商用利用しやすいライセンスを採用していることから、ローカルでの実務応用を検討する技術者にとって格好の検証対象となっています。

議論の論点

コミュニティの議論では、Kevの技術的アプローチに対する鋭い指摘から、具体的な応用先、運用上の懸念点にいたるまで、多角的な意見が交わされています。主な論点は以下の3点に集約されます。

「Jev風」の定義と学習手法の妥当性

参加者の間では、ベースモデルの選定や学習プロセスに関する技術的な議論が活発に行われています。特に、本家JevがRLCDを用いて訓練されているとされるのに対し、KevはRLHFによって訓練されたQwenモデルをベースに構築されているため、「本当にJev風と呼べるのか」という疑問が投げかけられています。また、単に既存のLLMの上にJev風のAPIを被せただけのプロジェクトは、Jevの本質を見誤っているという厳しい意見も見られます。Jevの真の価値はアーキテクチャではなく、その独自のトレーニングデータと訓練方法にあり、実際にいくつかのオープンソースのJev風モデルを言語タスクで試したところ、本家Jevと比較して性能が著しく劣っていたという具体的な体験談も報告されています。

業務自動化における実用的なユースケース

この種の超軽量な意思決定モデルが、実際の開発や業務プロセスにおいてどのように役立つかについて、多くのアイデアが共有されています。カスタマーサポートにおけるチケットの自動ルーティングや顧客の不満度の評価といった典型的なタスクのほか、フロントエンド開発におけるスタイルガイドやReactコンポーネントの作成ルールの強制に活用できるのではないかという提案がありました。これにより、UI/UXのズレやコードの重複を自動的に検知・修正し、開発者の負担を大幅に削減できると期待されています。さらに、スパムメールのフィルタリングにおいて、巨大なモデルを使用するよりも計算コストを抑えつつ高い精度を達成できる可能性についても言及されています。

運用上の制約とローカル実行の課題

意思決定モデルを実務に導入する上での、現実的な制約についても議論が及んでいます。これらのモデルは外部ツールを呼び出す「ツール呼び出し（tool calling）」機能を持たないため、知識のカットオフ（情報の古さ）が問題になりやすいという指摘があります。そのため、ローカルで運用し続けるには継続的なファインチューニングが必要になるか、あるいは定期的に新しいモデルに移行せざるを得ないという運用上の懸念が示されています。また、Jev風のモデルを自作・利用する際の競合プロジェクトとして「logan-markewich/jeff」や「bespokelabsai/nimble」といった代替手段が挙げられているほか、一般的なLLM（Gemma 4 12Bなど）をローカルで動作させた場合のレイテンシと比較し、意思決定モデル専用の軽量モデルを導入するメリットがどこにあるのかについての議論も行われています。

コミュニティの反応

学習手法と「Jevらしさ」に対する懐疑的な視点

コミュニティ内では、Kevのようなオープンソースの意思決定モデルが本家Jevの代替になり得るのかという点について、厳しい視線を含む多様な意見が交わされています。ある参加者からは、Jevが本質的にRLCD（強化学習関連手法）によって学習されているとされる一方で、KevがベースにしているQwenモデルはRLHFを用いて訓練されているため、得られるモデルが本当に「Jev風」と言えるのかという疑問が投げかけられました。さらに、既存のLLMの上にJev風のAPIラッパーを構築しただけのプロジェクトは根本的な要点を見落としているという指摘もありました。Jevが特別である理由は独自の学習データと訓練方法にあり、アーキテクチャ自体はテキストエンコーダと並列予測ブランチを持つ平易な構造に過ぎないのではないかという見方です。実際に複数のオープンソースのJev風モデルを言語タスクで試したところ、本家Jevと比較して非常に性能が劣っていたという否定的な使用体験も報告されています。

一方で、Jevと従来の分類ニューラルネットワークの違いについて疑問を持つ参加者もおり、テキスト入力を受け取って追加の訓練データなしにワンショットで分類を行う仕組み自体についての技術的な整理を求める声も見られました。また、Qwen3.5をベースにしていることから「Qev」という名称にするべきではないかといった軽妙な反応や、ローカルで動かすために具体的にどのようなスペックが要求されるのかといった導入要件への関心も寄せられています。

実務や開発パイプラインでの応用可能性への期待

意思決定モデルが解決し得る具体的な課題については、肯定的な期待や斬新なアイデアが数多く寄せられています。内部のルーティングロジックの簡素化に直結することを歓迎する声があり、Qwen3.5をベースとした意思決定モデルが実務の自動化に寄与するのではないかと期待されています。

特に開発ワークフローへの応用として、フロントエンド開発におけるスタイル規則やReactコンポーネントの作成ルールを強制する用途が提案されました。モデルのコンテキストウィンドウが大きくなれば、従来のスタイルガイドに頼る代わりに決定木を構築し、UIやUXのズレ、コンポーネントの重複作成を自動で防止できるようになるのではないかという構想です。現在多くの時間をUIの修正作業に費やしているエンジニアにとって、こうした意思決定モデルは魅力的な解決策として捉えられています。

また、スパムフィルタリングへの適用可能性を検討する意見も見られました。日常的に27Bクラスのモデルをスパム判定に利用して高い精度を得ているものの、計算コストの高さが課題となっており、より軽量な意思決定モデルで代替できればコストを大幅に削減できるのではないかという議論です。さらに、コーディングエージェントの内部判断に組み込めるのか、それとも全く異なる文脈で活用すべきものなのかといった、エージェント技術との統合に関する関心も示されています。

運用コスト・保守性とローカル実行における現実味

運用面においては、意思決定モデル特有の制限に対する懸念と、ローカルで運用できること自体の意義についての議論が展開されています。大きな懸念点として挙げられているのが、ツール呼び出し機能を持たないことによる「知識のカットオフ（情報の鮮度低下）」です。外部の最新情報を動的に取得できないため、ローカルで自前運用する場合はモデルの継続的な追加学習が必要になり、クローズドなサービスを利用する場合でも定期的に新しいバージョンへ移行し続けなければ実用性を維持できないのではないかという運用負荷の指摘がありました。

モデルの推論速度やサイズに関しては、Gemma 4 12Bのような高密度な汎用モデルを古いローカルPCで動かした場合でも十分に低いレイテンシ（1ステップあたり200ミリ秒台前半など）を記録できたという実験例が共有され、ハードウェアを強化すれば汎用モデルでも低遅延化が可能な中で、特化型の軽量モデルを導入する実質的な利得をどこに見出すかが問われています。また、先行あるいは類似するオープンソースプロジェクトとして「logan-markewich/jeff」や「bespokelabsai/nimble」といった実装の存在も共有されました。

総じて、Jevが巻き起こしたブームによって、多くの企業や開発者が「自分たちの用途はSystem Oneのような意思決定モデルで十分に機能するのではないか」と認識し始めているという前向きな受け止め方があります。その結果として、Kevのようなオープンソースの選択肢を活用したり、独自のデータでファインチューニングを行って自前のインフラ上でモデルを稼働させたりする動きが加速するのではないかという展望が語られています。

当サイトでの実測

当サイトのサーバー(GPUなし)で、このモデルのファイルを実際に読み込み・動かして確かめた値です。モデルカードの記載ではなく、当サイトが測った結果です。測り方と全モデルの一覧は観測データにまとめています。

意思決定モデルとしての評価(当サイトの判定問題)

当サイトが書いた11の状況・20問の判定問題(はい/いいえ・名前付きの選択肢・順序のある段階の3種類)を、llama.cpp の llama-server の /v1/systemone(TypeSafe 互換の API)で、日本語と英語の両方で解かせました。日英は同じ内容で、選択肢の名前(billing など)は共通です。どの問いも、判定の規則を状況か問いの文に書いて答えが1つに決まるようにしています。正解は当サイトが確かめ、日付・金額・時刻が絡む問いはコードでも検算しています。正誤はコードが判定しています(はい/いいえは「はい」の確率が0.5以上なら「はい」、選択肢と段階は確率が最も高いもの)。ベンチマークの問題ではなく、モデルの総合的な性能の順位でもありません。

条件は Neoverse-N1・3スレッド・GPUなし・llama.cpp b11379・Kev-4B-Q4_K_M.gguf(Q4_K_M)・方式 kev・文脈 4,096トークンです。1回の判定の時間は、1つの状況(1〜3問)を送ってから答えが返るまでを測った CPU での値で、GPU の速さの目安ではありません。確率は llama.cpp がモデルファイルに記された温度で換算した値で、llama.cpp の説明のとおり較正されている保証はありません。

この記事は1つのリポジトリではなくモデルの系統を扱っています。以下は、そのうち Kev-4B(ggml-org が jaredpalmer/kev-4b を GGUF に変換したもの)の結果で、当サイトがほかの意思決定モデルとの比較の参考として測っているものと同じです。

日本語では英語より1問少なく正解しました(20問中 日本語18問・英語19問)。

ほかの行は同じ条件で測ったほかの意思決定モデルです(「参考」は比較のために測ったモデル)。方式はモデルごとに違い、量子化もそれぞれの配布のものです。

時間に(GPU)とある行はクラウドの GPU で、それ以外は当サイトの CPU で測ったため、その間で時間は比べられません(正解の数は比べられます)。

問いごとの答え

状況と問いの全文と、正解の根拠は観測データに載せています。

手元で同じことをするには

llama.cpp の公式配布を次のコマンドで起動し(モデルのファイル名は当サイトが落としたもの)、状況ごとに次のように送りました。

llama-server -m Kev-4B-Q4_K_M.gguf -t 3 -c 4096 -b 2048 -ub 2048 -np 1 --no-mmproj --host 127.0.0.1 --port 8080

curl -s http://127.0.0.1:8080/v1/systemone \
  -H 'Content-Type: application/json' \
  -d @- <<'EOF'
{
  "model": "lmw",
  "state": "お客様からのメッセージ: 昨日の注文 #5521 で、カードに同じ金額が2回請求されていました。重複した分を返金してください。",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "このメッセージはどのチームが担当すべきですか。",
      "criteria": {
        "billing": "支払い・請求・返金",
        "shipping": "配送・荷物の追跡",
        "technical": "不具合・エラー・障害",
        "sales": "新規の購入・見積もり"
      }
    },
    "refund": {
      "type": "noul",
      "instructions": "お客様はお金を返すよう求めていますか。"
    },
    "outage": {
      "type": "noul",
      "instructions": "このメッセージは、サービスが止まっていることを伝えていますか。"
    }
  }
}
EOF

次に読むなら

• この記事が載った週の動きをまとめて読む → 週次まとめ: MiMo-V2.6一族や軽量意思決定モデルが登場

出典

• https://github.com/jaredpalmer/kev/tree/main
• https://news.ycombinator.com/item?id=49783999

更新履歴

• 2026-10-03: 当サイトでの実測(意思決定モデルとしての判定の評価)を追加しました。