ローカルQwenは劣化したOpusではなく、別の道具だ
(blog.alexellis.io)- ローカル Qwen 3.6 27B は、顧客データや内部テレメトリのようにクラウドへ上げにくい作業で実用的な価値を生むが、クラウドの SOTA モデルを置き換えることはできない
- ローカルモデルの強みは、最高性能モデルとのスコア競争よりも、固定費、プライバシー保護、ベンダーリスクの軽減にあり、重い利用量や SaaS の内部機能で特に差が出る
- SWE-Bench Verified で Qwen 3.6 27B は 77.2 点、Claude Opus 4.8 は 88.6% で、「ローカルは SOTA に 12% しか劣らない」という主張は、ベンチマークのチューニング可能性や Go のような実際のドメイン差を見落としている
- 約 12,000 ドルで購入した RTX 6000 Pro Blackwell 96GB は、顧客ライセンスの過少申告を見つけた 売上回収 の事例だけで費用を回収した
- 最大の制約は、長い作業で反復出力や幻覚が発生する ループ問題 であり、ローカル Qwen は長期の無監督コーディングよりも、顧客サポート、範囲の狭い保守、コードベースの読解と説明により適している
AI 活用の背景と事業文脈
- OpenFaaS をはじめ、SlicerVM、Actuated、Inlets など、低レベルインフラ・Linux プリミティブ中心の製品を小規模チームで運営している
- コンテナ、Firecracker microVM、ネットワークプロトコル、トンネル、CLI、Kubernetes ベースで、主に Go で書かれ、一部に React UI を含む
- VS Code のタブ補完時代から AI ツールを使っており、現在はコードの大半を Claude または Codex が担い、手書きのコーディングはほとんどしない
- tmux での長時間作業の流れを管理するために Superterm.dev を作り、セッション・ノート管理やコーディングエージェントの視覚的フィードバックに使っている
フロンティア知能の転換点
- 2025 年 11 月〜2026 年 1 月の間に転換点が起き、X では多くの開発者が Claude Opus なら 自分の作業を丸ごと処理できる と評価した
- 最上位のコーディングプランの費用は個人向けで月 約 200 USD に落ち着き、過度な無監督作業さえ避ければ 5 時間・週間上限の範囲で利用できる
ローカルモデルが興味深い理由
- 2026 年は、誰でもサブスクリプション 1 つでアイデアを一晩で複製できる時代であり、SlicerVM と Superterm もクローン事例を経験している
- ソフトウェアのコストが 0 に近づく 市場では、「無料で十分に良い」ことが重要になりうる
- 先端モデルは 0.5〜2T パラメータ と推定され、ローカルハードウェアの最上位とは次元の違う規模である
-
ベンチマキシング (Benchmaxxing)
- ベンチマークは公開されているため、スコアを上げるように チューニング可能 であり、絶対指標としては信頼しにくい
- SWE-Bench Verified は Python の issue ベースだが、コードの大半は単一スレッド・同期型である一方、Go の分散システムでは channel・context・struct が大きな実行領域にまたがる
- ベンチマークの点数だけを見て「ローカルは SOTA より 12% 劣る」とは言いにくく、実務では 言語とシステム特性 が成否を大きく左右する
-
コスト (Cost)
- 「ローカルモデルはコストの問題ではない」という話は、すべての利用者に当てはまるわけではない
- 個人向けコーディングプランは 月 200 ドルで高い使用量と SOTA 水準の知能を提供 するが、プラン自体は補助金付き (subsidised) の構造に見える
- GitHub Copilot は月 39 ドルで 1,500 件のリクエストを提供していた構造からトークン課金へ移行し、これに対する反発は大きかった
- API トークン課金になると、損益分岐点はすぐに来る可能性がある
- Uber は開発者 1 人あたりツールごとに 月 1,500 ドルで AI 支出を制限 している
- Uber の年収中央値 330,000 ドルを基準にすると、開発者が 2 つのツールを上限まで使えば年収の約 12% に相当する
- 大量利用・ループ・エージェント分析・SaaS 内蔵機能では、open weight・ローカルモデルが大きな価値を提供する
-
主権とプライバシー (Sovereignty and privacy)
- 顧客データや契約条件のため、クラウドプランにデータを上げにくいケースがある
- ChatGPT Pro と Claude Max は 30 日保持に設定できるが、その水準でさえ顧客契約を無効化する可能性があると見ている
- 米国外の利用者向けに Anthropic の Fable 5 モデルが一晩で削除された事例は、ベンダーリスク として働く
- ローカルモデルは「フロンティアラボが X をしたらどうする？」への解決策である
刀鍛冶の比喩 — ローカルモデルの本質
- 鋼の熱処理では一段階でもやり過ぎると最初からやり直しになるように、ローカルモデルも 熱く動かしすぎると目標を通り過ぎてループに陥る
- 唯一の解決策はハーネスを停止し、空になった context で別の結果を期待することだ
- 刀鍛冶を無監督で放置しないように、Qwen 3.6 27B に長期 horizon の作業は任せない
-
私が探していたもの (What I was looking for)
- 目標はプライバシー、固定費、ベンダーリスクへの防御
- ローカルモデルを Claude・Codex と同じように扱うと失望が生じた
- Claude は短い指示（"do it and test it end to end"）だけで、5〜15 分以内に PR 作成・自動コードレビュー・反復まで効率的なループを回せる
3090 から得た教訓
- 2023 年に単体の 3090 で始め、モデルのロードと十分な context のためにもう 1 枚必要になった
- Qwen 3.5 がエージェントとして 実際に仕事になるのを初めて見た 時期だった
- 「マシンをあらゆる角度から調べてフォレンジックレポートを書け」と指示すると、すべてのファイルを 1 つずつ読みながら context を埋め、ファイル名・tool call を幻覚 した（
~/faas-netes→~/faaned）- 作業範囲を狭めて「軽く見て回れ」とすると、約 40〜50 tok/s で明快なレポートを生成した
- 27B モデルは 3090 1 枚にフル精度では載らないため、調整変数は 重み量子化・context 長・KV キャッシュ圧縮 だった
- KV キャッシュの keys 部分は Q4_0 で問題が起きる というのが通説で、最も攻めても keys Q8_0 / values Q4_0 までしか使わなかった
- vLLM + NVLink + tensor parallelism の実験でも生成速度は llama.cpp より 毎秒 3 トークン遅く、ループも発生し、重みのロードには数分を要した
- vLLM は大規模な同時サービングには適しているが、プロシューマー環境では起動時間・単純さ・単一ユーザーの遅延のほうが重要である
大きな出費 — RTX 6000 Pro 導入
- 顧客サポートチケットを迅速に解決するため、約 12,000 USD の RTX 6000 Pro Blackwell (96GB VRAM) を購入した
- その後価格は約 15,400 USD に上昇し、2 枚目のカード追加は難しくなった
- PCI レーン・帯域幅・カード間隔・PSU 負荷などの理由で、一般向けマシンに単純追加はできない
- 計算された賭けとして成果は出したが、Claude のサブスクリプションを置き換えることはできない
データ流出なしの手軽な顧客サポート
- 運用担当者が簡単に実行できる CLI ツール
diagを作り、OpenFaaS の Kubernetes インストールの 完全なスナップショット を取得できるようにした- 受け取ったダンプは、Slicer が生成した ephemeral VM 内の airgapped ローカルモデル で分析する
-
売上回収 (Revenue recovery)
- テレメトリ DB をローカルモデルに投入して、ある顧客の 12 か月以上にわたるライセンス過少申告・4〜5 倍の未払い を発見し、この回収だけでカード代を賄えた
- テレメトリや
diagダンプは、データ保持ポリシーに関係なく どのクラウドプランにも 入れない - ChatGPT Pro・Claude Max は 30 日保持設定が可能だが、その水準でも顧客契約を無効化するおそれがある
- 初期モデルは算術に失敗し（27.3K を 273,000 と計算）、関数数が少ないという理由で頻繁な実行を無視し、離脱の可能性だと誤判定した
- 結論として、解釈より分析に集中させる ほうがよい
現在のセットアップ
- RTX 6000 rig で Qwopus の最新世代と base Qwen 3.6 27B を並行運用しており、新しい finetune やポイントリリースに応じて変えている
- Qwopus は、Qwen の上に Chain of Thought の追跡を重ねて推論とコーディング性能を高めようとするファインチューニングモデルである
- 最近まで thinking を完全に切って運用していたが、再び有効にした時期がループ増加と重なった
- 2 つの独立した llama.cpp インスタンス でサービングしてフル context 長を維持しており、
--parallel 2は context を半分に減らしてしまう - 投機的デコーディング (MTP) では約 93% の受理率 で、速度は安定した 67 tok/s から 130〜200 tok/s へ上がり、体感ではクラウドより速い
- モデルカードのチューニング指針に従うことが重要で、Qwopus は thinking を切り、temperature を 0.85〜1.0 のかなり高めに設定したときに最適だった
反復出力と長期作業の限界
- Qwen の最大の問題は、長い範囲の作業で ループ に陥ることだ
faas-cliに追加すべきコマンドを尋ねると、最初はもっともらしい提案をしたが、同じコマンド一覧を繰り返し出力しながら約 30 分間 600W を消費したgetとlistコマンド全体に--jsonを追加させたときも、最初の 1〜2 個はそれらしかったうえにテストも書いたが、その後で問題が大きくなった--json出力でhttp://リモートエンドポイントの insecure TLS 警告を防ぐために Python の reverse proxy を使わせたときも、最初の版はもっともらしかったがインデントが崩れており、修正の過程でファイルを壊したあと、詰まったまま繰り返した- チームメンバーの Han も似たループを経験しており、特にモデルやエージェントが能力の限界で止まりながら助けを求めない形が多かった
- この問題のため、ローカル Qwen は顧客サポートや更新向けのテレメトリ・
diag分析を除くと、簡単には信頼しにくい
アクセス計測と配分
- 初期は単一の inlets トンネルを使っていたが、同じ llama.cpp インスタンスに 2 つのエージェントが接続すると、キャッシュ済み prefix が互いに無効化されて プロンプト全体の再処理 が発生した
- 複数人で使うと、プロトタイプの域を超えて、誰がどのインスタンスを・どれだけ・どのモデルで使うのか、電力コスト、離脱時の処理など運用上の課題が出てくる
opencode.jsonを手作業で編集・配布する代わりに、opencode 向け provider「Toilgate」 を作成し、モデルピッカーから base から実験的な Qwopus 変種まで選べるようにした- Toilgate は 100% vibe-coded で、オープンソース化の負担は大きい
- 壁コンセントで Shelly Plus Plug 2 台 を使って消費電力を計測しており、RTX 6000 Pro は推論時 600W で静か、3090 2 枚は合計約 750W で非常にうるさい
-
間違った比較 (The wrong comparison)
- 100 万トークンあたりの入出力コストを GPT-5.5 API 価格と比較するのは、現時点の能力では 間違った比較 である
- 「ローカル AI」は結局、ID・アクセス制御・メータリング・クォータ・モデルルーティング・電力監視が必要な 運用問題 に帰着する
実際に役立った利用パターン
- ローカルモデルとハーネスを専門化された作業に合わせることが重要である
- 顧客サポート
- 範囲が明確な保守
- エンドツーエンドテスト
AGENTS.mdに詳細な指示を追加すると、ローカルモデルが新しい CLI をより速く効率的に追加し、自分でテストできるようになった- alexellis/arkade でこの効果が見られた
- ローカルモデルはコードを直接書くことには限界があっても、コードベースを素早く読んで説明することには強みがある
- Agent Skills も役立ち、ローカルエージェントが新しい mini PC で Slicer をゼロから設定 した事例がある
- 同じ作業をローカルモデルとクラウドモデルの両方で実行してみるやり方を一般化する必要がある
- 同一作業の比較事例 のように、結果に失望することもあれば、運が良いと感じることもある
- 長い範囲の無監督エージェント作業は避けるべきであり、約 15,000 ドル近い機材でもこの問題は解決できない
現在の結論とモデル選択の限界
- ローカル Qwen は「Opus 級に近い」ものというより、特定の作業やワークフローで価値のある 別の道具 である
- Qwen 3.5 は実用になる結果を出した最初のモデルと評価されており、3.7 の噂はあるが、革命的な変化より段階的改善を期待している
- 70B モデルの大半は古く、世代遅れだと見ている
- Qwen 35-A3B は MacBook で速く見えるため人気だが、生成時に有効なパラメータは 3B しかないため、速度より品質を選ぶという立場である
- GLM 5.2、Kimi 2.7、Minimax M3、Deepseek V4 Flash のようなより大きいモデルは、一部のローカル環境では可能でも、量子化版ですらロードするのに RTX 6000 Pro が 4〜6 枚必要なことが多く、対象外である
- 現在の 27B dense モデルは、Go コードを一日中書くには不十分であり、限られた知識と注意力はコードレビューですぐ露呈する
- Qwen は簡潔にせよという指示にうまく従えず、自動コードレビューで不要に詳しく書いたり、並行性の問題や race condition を幻覚したりして、実験はすぐ中断された
- より安価で高速な Grok Coder Fast 1 は deprecated になるまで数か月うまく機能した
- 関連事例は code review bot と OpenFaaS の painless customer support and architecture review にまとめられている
1件のコメント
Hacker Newsの意見
これらのモデルを長く使っていると、単に「XがYより賢い」とか「YがZより安い」といった話ではないと分かる。互いに異なるツールであり、プロンプトのやり方も違うので、楽器を演奏するのとかなり似ている
Claudeは、実装に味を出したり創造的な結果を引き出したりするには、あえて少し曖昧にしたり間接的に表現したりしたほうがよい場合がある。そして奇妙に聞こえるかもしれないが、Claudeには親切にすると報われ、荒っぽく接すると損をする。Claudeは口調をより強くなぞるので、ネガティブなループに入らないほうがよい
GPTには正確さが必要で、曖昧さを減らすべきだ。GPTは「XをするがYにはしない」のような最小最大式で曖昧さを解消しようとし、範囲を明確に言わないとあらゆる境界事例を拾おうとして過剰設計しがちな傾向がある
Qwenは、まず形を与えてその中を埋めさせる必要がある。QwenはXML、JSON、リストを好み、過去の作業例をたくさん見せるとうまくいく。まったく科学的な話ではなく単なる感覚なので、結果は違うかもしれない
しかし見た目はどれも似たり寄ったりで、何がどこで少し優れているのかを突き止めるには、広範囲で時間もかかり、場合によっては高コストなテストを自分でやる必要がある
誰にでもやってみることを勧める。普段使っているデータ以外に特別なデータは不要で、結果はかなり衝撃的だ。思っているよりはるかに多くのランダム性や不安定さがあり、よりよいプロンプト技法や、とても良い／悪い結果だと思っていたものも、単なる偶然やモデルのバージョン・サイズごとの挙動差かもしれない。小さな入力の違いが結果を大きく偏らせることもある。会社ではこうしたものの一部を魔法の言葉と呼んでいて、特定の技術用語や参照・手法に触れるだけで結果が大きく改善する
ここには技術がある。エージェントループの中で、モデルがごまかしや近道を使いにくい自己評価構造に入れられ、学習済みの構造や領域と合っていれば非常にうまく機能する。だが最適点を見つけるのは難しい。ひとつヒントを挙げると、Opus 4.8にPyTorchモデルをONNXや量子化モデルへ変換させたり、別のハードウェアで動かさせたりすると、本当に特殊能力を有効化したかのようにうまくやる。一方で、一般言語や形式のEBNF形式化を、ごまかしなしで正しく書かせてテストさせるのはどうしてもできない
最悪なのは、こうした知識があまりに頻繁に変わるため、実際にモデルを訓練している人でなければ深く掘り下げる効用がほとんどないことだ。出力の安定性が学習でより重視され、もっと予測可能になってほしい。過学習や探索・活用ループを壊さずにそれを実現するのは難しいだろうが、バッチ処理をもっと安定してこなせるなら、LLMにもっと多くの金を使うと思う
同じ依頼をClaude Sonnet 4.6にしたところ、まるでそのゲームが最初からJSで書かれていたかのような結果になった。しかもなぜか単一のHTMLファイルにし、すべてのアセットを削除したうえでグラフィックと音楽を動的に生成し、さらにより良い新しい背景まで作ってくれた
頼んだのは単にゲームの移植だけだったので驚いた。選択自体はかなり気に入ったが、こうした挙動をどうやってオンオフするのかは分からない。創造性が必要なときもあれば、実際に言ったとおりそのままやってほしいときもある
この記事とその称賛を見ると、裸の王様のように感じる。この文からして意味がおかしい
“These products use very low level Linux primitives like containers, Kubernetes, Firecracker microVMs, and networked protocols.”
「低レベルのLinuxプリミティブ」と呼べそうなものの中では、ネットワークプロトコルくらいはどうにかそう主張できるかもしれない。そして明らかにAI生成の文章のように見える。内容だけ信頼できるなら構わないが、信頼できない
文章はAI生成ではなく、コードはAIで生成するが文章は自分で書いている。どの部分が理解しにくいのか気になる。この記事は私たち自身の経験と歩みを説明したもので、特定の主張については喜んで根拠を示せる
AIの強みは、結局は延々と金を払い続ける必要があり、時間がたつほど企業の株主の強欲を満たすために劣化していく、また一つのクラウドサービスとしてではなく、ローカルで安全かつ非公開に適用されるときにこそ発揮されると今でも信じている。
ChatGPTやAnthropicに自分の健康データを自社システムに縛り付けさせる気はまったくないが、自分が見落とすデータのパターンをAIが見つけ出す能力は今でも信じている。だからこそ、QwenやGemmaのようなものにデータを安全かつ非公開で渡して処理できるローカル専用のエコシステムが切実に必要だ。
スマートホームや個人アシスタントも同じだ。A社がB社に保存されたデータへアクセスし、D社・E社が処理し、それが広告主やデータブローカーに売られる一方で、自分のローカルハードウェアに取り出したり閲覧したりする方法すらないような企業的アプローチは、こうした私的用途では持続可能ではない。自分のデータは自分の条件で所有・制御・開示されるべきであり、まず自分の生活を改善するために使われるべきで、他人の損益計算書を改善するために使われるべきではない。技術が再び自分の時間を取り戻し、結果を改善してくれることを望んでいるし、Big Techには十分痛い目に遭わされてきたので、AI-as-a-Serviceという事業モデルに高尚さや公益性があるという前提は断固として拒否する。
能力はすでにあり、ローカルモデルの潜在力を支え、解き放つローカルツールを作っている人たちは正しい方向にいると思う。彼らが作るものを見るのは楽しい。
QwenやDeepSeekのようなモデルを使えば、一社に縛られず、より良いプライバシー保護を提供するかもしれない独立系プロバイダーの間を移動できる。そうすれば、インターネット接続さえあれば、自分で直接実行できないデバイスでもモデルを使える。
AIの強みはオープンソースモデルにある。ベンダーロックインを避け、ローカル利用と独立系プロバイダーホスティングの両方を許容するモデルを使うべきだ。
いい文章だと思う。ただ、改善の可能性を過小評価しているようにも見える。
書き手たち自身、1年前のローカルモデルと今を比較するのは意味がないと認めている。実際、多くの人は昨年11月のOpus 4.5、つまり8か月前を、フロンティアなホスティングモデルでもエージェントコーディングが広く可能になった最初の時点と見ている。
だが、現時点でローカルモデルが何を得意とし何が苦手かという概念を、なぜわざわざ固定する必要があるのだろうか。今どうであれ、1年後にはおそらく違っている。コンシューマー向け・プロ向けハードウェアで長いレンジの作業まで可能になると考えるのは素朴な楽観主義かもしれないが、ここまではその素朴な楽観論者たちが勝っている。
車を買うのと似ている。その車を運転し、特性に慣れていくのであって、その車や似た車が今後どう改善されるかは考えない。自分の道具であり、できる限り活用したいだけだ。
もちろん、ローカルモデルを入れ替える技術的コストは非常に低いが、そのモデルから最大性能を引き出すにはかなりの時間がかかり、その努力が新しいバージョンでは通用しないかもしれない。
興味深い文章だ。個人的には、書き手には二つほどうまくやってほしかったことがある。
第一に、llama.cppではなくvLLMを使うべきだった。NVIDIAハードウェアでは、複数ユーザーの負荷やキャッシュにおけるvLLMの差は非常に大きい。二人以上のユーザーがモデルを使う場合や、キャッシュが消える問題に不満を述べている箇所では、「そりゃそうだろう」と思った。
第二に、単一カードに使った予算はSPARKにもっと有効に使えたはずだ。2 x GX10クラスタが使え、総費用は今の時点でも書き手が払った額の半分以下で、vLLMとDeepseek v4 Flashを回している。Qwenと比べると差は非常に大きい。ループに陥るのを一度も見たことがなく、これまで試した中で最もSonnetっぽいモデルだ。antirezも同意しているようで、そのためにds4フォークを作ったように見える。
2台のGX10でどう設定したかはここにある: https://forums.developer.nvidia.com/t/deepseek-v4-flash-offi...
性能はプリフィルが2Kトークン/秒で、巨大なコンテキストウィンドウに大量のソースコードを入れるときに非常に有用で、pi.devハーネスでコーディングするときの生成は約50〜60トークン/秒だ。書き手が払った金額ならGX10を4台買えたはずで、vLLMはテンソル並列化でほぼ線形にスケールするので、両方の数値を2倍にできたはずだ。
後でもう少し試すかもしれないが、無限にいじっていられる時間があるわけではなく、ここまでの道のりと判断を共有しただけだ。
同時バッチサービングにはvLLMが正しい選択で、下のbarrkelの言うことはその通りだ。しかし私たちの使い方では、llama.cppのほうが依然として優れている。
Spark/GX10のルートは本当に別の賭けで、数値を共有してくれたのはありがたい。数か月前までは、GX10はファインチューニング専用で、性能値もひどく低いというのが大方の空気だった。
そして、そのカードはClaude Maxサブスクリプションを置き換えるために買ったものではまったくない。実際に買った用途の作業では140〜200トークン/秒が出ており、それが重要なんだ。
長い文章だったが、それでもなお書き手が何を言いたいのか、いまだによく分からない。タイトルから推測できること以外には。
ただ、書き手が物理的なものも作り、ソフトウェアも作るかなりすごい人で、他の人たちがその人に金を払っているということは分かった。それがタイトルの示唆する主題と関係あるのかは分からない。
この記事はローカルモデルをうまく要約している。ときどき コーディングやエージェントのローカル作業のための幻想的なツールのように誇張されるのとは違い、現実にはかなり制約が多く、長い作業や複雑な作業には弱く、ループにはまったり作業を忘れたりしやすい。
この記事で抜けている点は、コストもかなりかかることだ。ハードウェア費用だけでなく電気代もある。3090 や 5090 のマシンは電力を多く消費し、こうしたマシン上ではモデルはかなり遅いため、トークンあたりの電力消費も大きくなる。
光る点は、制御可能性、プライバシー保護、予測可能性だ。たとえば写真・動画ライブラリの分類のような反復作業には向いており、電気料金次第ではコスト面でも利点があるかもしれない。
ツール呼び出しは 99% 信頼できる必要があり、何より「この作業は自分の能力の範囲外だ」と言ったうえで、どこか巨大なデータセンターにある オンライン高性能モデルへ渡せる必要がある。
そうなれば単純な作業はすべてデバイス上で処理しながら、データを集めて問題の文脈を把握し、簡単な仕事が終わったあとで賢いモデルが入ってきて問題を解決できる。
ローカルモデルが 100% できる
/commitのような技術でオンラインモデルを呼び出すのは本当にばかげて感じる。ただしこれは大半がハーネスの問題なので、かなりの部分は解決可能だ。非常にうまくこなし、コーディング作業も大げさな計画を丸ごと投げるのではなく使い方を分かっていれば優秀だ。
他と比べてどうかは分からないが、5090 は同じ電力制限内でもっと速いはずなので、少し安くなると予想している。
vLLM が llama.cpp より遅いと片付けられていたのが興味深かった。
私の経験では vLLM は llama.cpp よりかなり速く、特に 同時負荷のバッチ処理では圧倒的だ。欠点は調整の柔軟性が劇的に低いことだ。量子化重みを実行する選択肢が非常に少なく、計算グラフを最適化するぶん起動時間もずっと長くかかる。だから機材に対して少し大きめのモデルを単一ユーザーが試す場合には、vLLM はもどかしく感じることがある。
「片付けられた」という表現は強いが、もう少し詳しく言うと、2x 3090 の機材でロードに 4 分以上かかり、単一リクエストでは 3 トークン/秒遅かった。
一番悪かったのは、設定とチューニングの手間をすべてかけたのに、それでもなおループにはまったことだ。あちこちで聞く「とにかく vLLM を使え」という助言が万能の解決策であってほしかった。
ここで一つ注意したいのは、人々が Ollama に対してやったように llama.cpp を貶め始めるべきではないということだ。llama.cpp は非常に有能なツールで、私たちが実際にそのカードを使おうとしている用途にはより適している。
大きなチームが Claude のサブスクリプションを置き換えようとするなら vLLM が唯一の選択肢かもしれないが、GLM 5.2 のようなものを載せるには RTX 6000 カードを 5 枚ほど追加しなければならない。
「モデルが熱く回りすぎて目標を通り越し、ループする」と言っておきながら、後では vLLM を最新の実験として設定したが、NVLink とテンソル並列化を有効にしても llama.cpp より生成が 3 トークン/秒遅かったとも言っている。
私のすべてのテストでは、vLLM を動かす価値はあった。ループ問題、エージェントがおかしくなる問題、作業への集中を失う問題、長いコンテキストが事実上役に立たなくなる問題に対して、最も大きく効いた単一の要素だった。
vLLM で FP8 モデルと非量子化キャッシュを使うと、他のどのスタックよりも全体的な体験が一段良くなる。そのあとは設定をいじるのをやめて、モデルを別の仕事に使うことへ集中できる。
そして、このような形で vLLM が有用になるには最低限のハードウェア要件があると感じるかも気になる。週末プロジェクトとして古いデータセンター部品を使ってホーム推論サーバーを作る予定で、最終構成を頭の中でずっと詰めているところだ。
自前の AI 機材を買って組みたい人には、まず複数ある 推論プロバイダーのどれかにつないで、さまざまなモデルをしばらく自分で使ってみることを勧める。
費用はほとんどかからないが、自分の機材で何が得られるかについて、かなり良いプレビューになる。単なる親切なアドバイスだ。