DGX Spark で動作するローカルLLMでは、Vue・Nuxt がどれくらい書けるか

前回の記事「DGX Spark 1台で、2026年秋の最新オープンモデルはどこまで動くか」では、NVIDIA DGX Spark 1台で動く3つのモデルについて、生成速度とメモリ使用量をご紹介いたしました。本稿では、同じ3モデルに、普段の開発業務に近い Vue・Nuxt のコードを日本語の指示で書かせ、出てきたコードを自動テストと型チェックで採点した結果をご紹介いたします。あわせて、どのモデルの回答かを伏せたうえでコードを読み、書き方も採点いたしました。

結論

• 仕様どおりに動くコードを最も安定して出したのは Qwen3.8-Flash-Next でした。テストと型チェックをすべて通過した回答は30回答中28回答で、生成も3モデルの中で最も速い結果です。
• コードの書き方の採点では、GLM-5.3-Flash が3回とも1位でした（15点満点で13.2点）。一方で型チェックで不合格になることが多く、すべて通過した回答は30回答中22回答にとどまりました。
• DeepSeek-V4-Flash-Vision-Exp は考える量が少なく、最も短い時間で解き終えましたが、毎回同じ箇所で誤りました（30回答中21回答）。
• 差がついたのは、日本語入力（IME）の扱い、読み取り専用の ref の型、Nuxt 4 のディレクトリ構成など、細かい知識が必要な箇所でした。Pinia のストアや Options API からの書き換えなどは、3モデルとも3回すべて通過しています。

評価の方法

公開されているベンチマークの多くは英語・Python の問題で、値も量子化する前のモデルのものです。そこで、DGX Spark で実際に動かしている量子化版のモデル（Qwen3.8-Flash-Next は 4bit、GLM-5.3-Flash と DeepSeek-V4-Flash-Vision-Exp は 2bit）に、日本語の指示で Vue 7問、Nuxt 3問の課題を解かせました。

• 採点は自動テストと型チェックで行いました。各課題に、課題文の仕様だけから判定できるテストを用意し（合計75テスト）、モデルには見せていません。回答から取り出したファイルをプロジェクトに置き、テストと型チェック（Nuxt はビルドも）をすべて通過した回答を合格としました。
• テスト自体の誤りも確認しました。当社で用意した模範解答がすべてのテストに通ること、よくある誤りを入れた版が狙ったテストで落ちることを確かめています。この確認と評価の途中で、テスト側の不備を6つ見つけて修正しました（評価の途中で見つかったものは、修正後に全回答を採点し直しています）。
• 各課題を3回ずつ解かせました。サンプリングは各モデルの推奨設定（temperature 1.0 など）とし、毎回答えが変わるため、3モデル × 10問 × 3回で90回答を集めました。
• 考える長さに上限を設けました。回答の前に考える過程（thinking）は 8,192 トークンまでとしました。上限なしで試したところ、Qwen3.8-Flash-Next が1問目で 32,768 トークンすべてを考えることに使い、20分以上かけて回答を1行も出さなかったためです。

使用したバージョンは、Vue 3.5.44、Nuxt 4.6.1、Pinia 4.1.0、TypeScript 6.0.3、vue-tsc 3.3.13、Vitest 5.0.5 です。TypeScript を最新の 7.0 にしなかったのは、vue-tsc がまだ TypeScript 7 にそのままでは対応していないためです。

結果1：テストと型チェック

課題ごとに、3回のうちテストと型チェックをすべて通過した回数は次のとおりです。

最もよく通過したのは Qwen3.8-Flash-Next で、2回目と3回目は10問すべてを通過しました。ただし、型チェックを除いてテストだけで数えると、GLM-5.3-Flash も27回答で、ほとんど差がありません。落ちた回答はすべて中身を確認し、テストの不備ではなく回答の誤りであることを確かめています。

モデルごとの誤りの傾向

• DeepSeek-V4-Flash-Vision-Exp は、毎回同じ箇所で誤りました。日本語入力の判定（後述）と読み取り専用の ref の型（後述）は3回とも、Nuxt のサーバー API を app/server/ に置く誤りは3回中2回でした。Nuxt 4 では server/ は app/ の中ではなくプロジェクト直下に置くため、API が1つも作られません。毎回答えが変わる設定でも同じ誤りを繰り返すことから、たまたまではなく、知識が不足しているか古いものと考えられます。何回か解かせて良い回答を選ぶ使い方では解決しません。
• Qwen3.8-Flash-Next は、1回目に落とした2問を、2回目以降は落としませんでした。1回目の誤りは、返り値が ref になっていない、useFetch を await していないために商品があっても 404 になる、の2つで、たまたまの誤りと見られます。
• GLM-5.3-Flash は、型チェックだけで落ちることが多くありました。落ちた8回答のうち5回答は、テストはすべて通過していました。aria-sort に決められた値へ型を絞っていない文字列を渡す、頼んでいない使い方の例を付けてその中で型エラーになる、など、動作は合っていても型のつじつまが合わない形です。

差がついた2つの課題

1つ目は、タグ入力での日本語入力の扱いです。日本語を入力して変換を確定する Enter で、タグが追加されてはいけません。Chrome では、変換を確定する Enter の keydown の時点で isComposing が true になります。一方 Safari では、変換の確定（compositionend）が先に来るため、keydown の時点で isComposing が false になります。isComposing だけで判定すると、Safari では変換を確定しただけでタグが追加されてしまいます。合格した回答は、いずれも keyCode が 229 かどうかもあわせて確認していました。

function onEnter(e: KeyboardEvent) {
  // Safari では確定の Enter で isComposing が false になるため、keyCode 229 も確認する
  if (e.isComposing || e.keyCode === 229) return
  addTag()
}

2つ目は、読み取り専用の ref を返す composable です。課題文では返り値の型を Readonly<Ref<T>> と指定しました。readonly() で返すと型が DeepReadonly<…> になって一致せず、型チェックで落ちます。この課題を通過したのは、Qwen3.8-Flash-Next の2回目と3回目だけで、どちらも readonly() で返したうえで型を書き換えて（キャストして）合わせていました。当社の模範解答では shallowReadonly() を使っています。

// 返り値の型は Readonly<Ref<T>> と指定している

// 型が DeepReadonly<…> になり、型チェックで落ちる
return readonly(debounced)

// 型が一致する
return shallowReadonly(debounced)

結果2：コードの書き方

テストは「仕様どおりに動くか」しか確認しません。そこで、Vue・Nuxt らしい書き方か、読みやすいかといった点は、コードを読んで採点しました。

• 採点は Claude（Opus 5.5）が行いました。回ごとに新しいエージェントを立て、事前に回答を見ていない状態で採点させています。評価対象の3モデルとは別の会社のモデルのため、自分の書き方を好む偏りはありませんが、採点者自身の好みは入ります。
• 回答からコードだけを取り出し、課題ごとに A・B・C の名前を付けて順番を入れ替えました。説明文やテストの結果は見せていません。
• 「Vue・Nuxt らしさ（現在推奨されている API を使っているか）」「読みやすさ」「配慮（アクセシビリティ、境界値、型の厳密さなど、仕様に書いていない部分）」の3つを、それぞれ1〜5点で採点しました。

（30回答の平均）

• GLM-5.3-Flash：現在の Vue の書き方に最も沿っていました。defineModel、shallowRef・toValue・onScopeDispose の組み合わせ、defineSlots によるスロットの型付け、状態を 'loading' | 'success' | 'error' のユニオン型で持つ、などです。3回とも1位でした。
• Qwen3.8-Flash-Next：テストにはよく通る一方、回りくどいコードが目立ちました。withDefaults で既定値を決めているのに同じ既定値を何度も書く、v-model を使わず手で書く、型の書き換え（キャスト）が多い、などです。並べ替えで null や NaN まで考慮するなど、丁寧な面もありました。
• DeepSeek-V4-Flash-Vision-Exp：少し前の書き方が目立ちました。defineModel を使わずに modelValue と emit を手で書く、リダイレクト先の URL を文字列の連結で組み立てる、などです。

コードを読む採点には限界も見えました。GLM-5.3-Flash の読み取り専用の ref の課題は、3回の平均が15点満点中14.0点と高い評価でしたが、型チェックでは3回とも落ちています。「模範的」と評価された readonly() の使い方が、まさに型エラーの原因でした。反対に、コードを読む採点が、テストの見落とし（タグが上限に達すると一覧ごと消えて削除できなくなる不具合）を見つけたこともあります。テストと型チェックを実際に動かす採点と、コードを読む採点は、お互いの見落としを補い合う関係にあります。

なお、同じ回答でも採点者が変わると1〜2点は動くため、0.5点程度の差には意味がありません。GLM-5.3-Flash とほかの2モデルとの約2点の差は、3回とも同じ向きに出ています。

生成にかかった時間

（10問の合計時間は3回それぞれの値の範囲、1問の出力は中央値、生成速度は平均です。右端の列は、考える長さが上限の 8,192 トークンに達した回答の数です）

Qwen3.8-Flash-Next と GLM-5.3-Flash は、ほとんどの問題で考える長さを上限まで使いました。上限で打ち切られても、回答は全問出てきています。DeepSeek-V4-Flash-Vision-Exp は考える量が少なく、ミドルウェアの課題を、考える過程を含めて 397 トークン、16秒で答えた回もありました。GLM-5.3-Flash の半分以下の時間で終わりますが、落とした回答は最も多い結果です。

生成速度は、前回の記事でご紹介した値（Qwen3.8-Flash-Next で 43.3 tok/s）より下がりました。前回の計測は temperature 0 で行いましたが、今回は推奨設定の 1.0 としたため、投機的デコード（小さな予測器で先のトークンを予想し、本体のモデルでまとめて検証することで速くする手法）の予想が当たりにくくなったためです。たとえば Qwen3.8-Flash-Next では、予想が採用される割合が、temperature 0 でコードを書かせたときの約85% から、37〜56% に下がりました。90回答の生成には、合計で約6時間25分かかっています。

用途ごとの使い分け

• 普段使い：Qwen3.8-Flash-Next。書き方は少し回りくどいものの、誤りが最も少なく、生成も最も速いモデルです。DGX Spark で Vue・Nuxt のコードを書かせる場合は、まずこのモデルをおすすめします。
• 書き方の質を重視する場合：GLM-5.3-Flash。最も今風の書き方をしますが、型のつじつまが合わないことが多いため、型チェック（vue-tsc、nuxt typecheck）とセットにして、エラーを直させる流れで使うのが適しています。メモリをほぼ使い切る点にもご留意ください。
• 速さを重視する場合：DeepSeek-V4-Flash-Vision-Exp。最も早く解き終えますが、同じ知識の不足を毎回繰り返します。Nuxt 4 のディレクトリ構成や日本語入力の判定のように、不足が分かっている点は、課題文であらかじめ伝えることで避けられる可能性があります（今回は試していません）。

なお、本稿の結果は DGX Spark で動かした 2bit・4bit の量子化版によるもので、課題も10問と限られています。業務でご利用になる場合は、実際の用途に近い課題でご確認いただくことをおすすめいたします。

評価の時点と参考資料

本稿の内容は、2026年10月16日〜17日に、llama.cpp（llama-server のルーターモード）で3モデルを切り替えて行った評価に基づいております。

• 前回の記事：DGX Spark 1台で、2026年秋の最新オープンモデルはどこまで動くか
• モデル：Qwen3.8-Flash-Next / GLM-5.3-Flash / DeepSeek-V4-Flash-Vision-Exp
• Nuxt：Nuxt 4.6
• vue-tsc の TypeScript 7 への対応状況：vuejs/language-tools #6124 / #6156
• Vue・Nuxt を含むコード生成のベンチマーク：Web-Bench

お問い合わせ

当社では、ローカルLLMの実行環境の選定・構築から、開発業務や業務システムへの組み込み、導入後の運用までを一貫してお引き受けしております。ソースコードや機密性の高いデータを社外に出さずに AI を活用したい場合など、ご検討の初期段階からご相談を承っております。

お気軽にお問い合わせください。