Ask HN: 日常的なコーディングでClaude/GPTをローカルモデルに置き換えた人はいますか？

 (news.ycombinator.com)
6 ポイント 投稿者 GN⁺ 8 시간 전 | 2件のコメント | WhatsAppで共有
  • データプライバシーとLLMの無料利用を理由に、クラウドモデルを完全に離れた開発者が現れており、コンテナ化・サンドボックス化されたオフラインのコーディングハーネスによって外部ネットワーク呼び出しなしで作業可能
  • 主力モデルはQwen3.6 35B-A3B（有効パラメータ3bで高速）と27Bのdenseモデルで、コーディング精度とトークン生成速度の間にトレードオフがある
  • Piハーネスとllama.cppの組み合わせが最も多く言及されており、ツール呼び出し（tool calling）がローカルモデルで初めて一貫して動作したことが、利用体験を大きく改善
  • Claude Opusと比べると、ローカルモデルは**「ガイドが必要なジュニア vs 一緒に設計するシニア」**ほどの差があり、精密なプロンプトとタスク分解が必須
  • 現在のローカルモデルは約8〜18か月前のフロンティア水準と評価される一方、無料・プライバシー・利用枠を気にしなくてよいという実利がある

ローカルモデルへの移行事例とハードウェア構成

  • Qwen3.6 35B-A3BをMac Studio 128GBまたはMacBook 36GB RAMでPiハーネス経由で動かし、Django + WagtailベースのWebサイトのホームページとブログ全体を再設計完了
    • インターネット接続なしでは、あまり知られていないWagtail開発でモデルが常に方法を知っているとは限らない
    • 複雑な作業にはQwen3.5 122bを使うが、有効10bパラメータのためかなり遅い
  • Strix Halo 128GBのユニファイドメモリ環境でPiをコンテナとして隔離し、資格情報なしで作業ディレクトリへのアクセスのみ許可
    • チャット・翻訳にはGemma 4 31B、音声にはGemma 4 12Bを使用
    • Qwen 3.5 122B-A10B、Nemotron 3 Super 122B-A12B、Step 3.7 Flash、GPT-OSS 120Bなど多数のモデルを保有しているが、コーディングには35B-A3Bが最適
  • 5年前に組んだデュアルRTX3090マシンでQwen・GemmaモデルをUD-Q4_K_XL量子化で動かし、約150tok/sを達成、300kコンテキスト全体をVRAM内で処理
    • 月額$100のClaudeサブスクリプションを置き換え、個人用途では無料が優先
    • Android TVランチャー、k8s管理ポータル、Home Assistant統合、食料品・献立管理など多様なプロジェクトを実施
  • RTX 6000でQwen 3.6 27b + Open Codeの組み合わせを使用し、コーディングの90%を処理するが、非常に複雑な作業とUIの磨き込みはCodexに戻る
    • 256kコンテキストでも100k超で品質・速度が低下し、150k以降は深刻になる
  • RTX 5090でQwen 3.6 27b（Q6量子化）+ llama.cppを運用し、GPUを600W→450Wに制限して静音性を確保
    • ブランチのコミット・PR作成、Stripe CLIでの請求精算、Elasticsearch負荷分析など日常業務へ拡張

モデルの種類と性能特性

  • MoE vs denseモデルの違いがコーディング品質に直接影響
    • Qwen3.5-122Bは実際には122B-A10Bで、10Bだけが有効化されるMoE、Qwen3.6-27Bは27B全体が常時有効なdenseモデル
    • MoEの有効・総パラメータの幾何平均でdense等価の品質を近似でき、sqrt(35×10)≈18.7
    • MoEは同サイズ比で品質は低いが速度が速く、CPU RAMへのオフロードでも大きなMoEを動かせる
  • 量子化レベルがループ発生と精度に影響
    • Q8量子化は遅いがループを減らし、全体時間を節約
    • KVキャッシュのK部分の量子化に非常に敏感で、F16 K + Q8 Vでループが大幅に減少
  • デュアルGPU追加の目的は推論速度ではなくVRAM容量の確保
    • Gemma-4 31B denseと26B MoEはどちらもQ4量子化で似た品質だが、MoEの方が約3倍速い（150tok/s vs 46tok/s）

ローカルモデルの限界と対応戦略

  • 精密なプロンプトが必要

    • 前提を開いたままにすると、モデルは最短経路（例: HTML内CSS）を選び、アーキテクチャ面で最善でない結果を出す
    • アーキテクチャを明示しないと速くて汚い修正を行い、デバッグ文の削除を指示しなければ残したままにする
    • Claude Opusはユーザーの意図を推測するが、小さなQwenモデルは指示されたことだけを実行するため、設計知識を明示的に「有効化」する必要がある

  • ループと編集ツールのエラー

    • 編集ツール呼び出しを頻繁に間違え、リトライの代わりに思考トークンを消費してファイルを読み直す
    • 直接リトライすれば編集呼び出しが直ることも多いが、モデルは問題がもっと根本的だと仮定して不要なトークンを消費する
    • ハッシュベースの編集アプローチ（各コード行のハッシュ参照）で編集エラーは減らせるが、コンテキスト品質を使い切ると別の形で崩れる
    • AGENTS.mdルールで書き換えではなく編集を制限すると部分的に改善

  • コンテキストウィンドウ管理

    • 65,000ウィンドウではコードファイル構造を読むだけでも超過し、200k以上が必要
    • Qwen3.6-35bは256kコンテキストを16gb VRAMで128kまで正常処理
    • Qwen3.6-27Bは100万トークンコンテキストをサポートし、DGX Sparkでf16 KVキャッシュ時に約100GBメモリを要する

プロンプトキャッシュと推論保持の問題

  • Qwenハイブリッドモデルがプロンプトキャッシュを処理できず、毎ターンでコンテキスト全体を再処理する問題が発生
    • ほとんどのローカルモデルはターン間で推論全体を保持するようには学習されておらず、長いツール呼び出しチェーンの後には、推論が除去された状態で再処理が必要
    • Qwen 3.6は推論保持を学習しており、chat-template-kwargs = {"preserve_thinking": true}設定でキャッシュ再利用が改善
  • 現代のLLMは完全なattentionだけでなくローカルattention（スライディングウィンドウ、Mamba-2状態空間モデル）も使用
    • 完全attentionはO(n²)でコストが高く、時間とともに値が置き換わる推論に弱い
    • ローカルattentionはスナップショットを保存し、キャッシュ再計算時に最後のスナップショットから開始するが、スナップショットが大きいと保持限界がある
    • Qwen 3.5以降はattentionとSSMレイヤーを交互に使うGated DeltaNetを採用
  • VulkanがROCmより逆説的に高速で、llama.cppの最新バージョンを維持することが再処理問題の解決に重要
  • 自己回帰生成トークンがプリフィル時に異なる形で解析されるトークナイザ発散問題は解決が難しい

コスト・電力の経済性を巡る議論

  • RTX3090を2枚で約$4400、月$100のClaude基準で3.6年分に相当し、電力・その他部品は含まない
    • 3.6年後でも大容量GPUの価格は維持される可能性が高い
    • 電力コストが高い地域では損益分岐が約1年という場合もある
  • 消費電力は予想より低め
    • 1.2kwフル稼働で約$0.12/時間、ソーラー接続ならさらに安い
    • 推論負荷はゲームと異なり電力問題は軽微で、システムはアイドル200W・推論350-450W程度
  • ハードウェア購入時期について
    • 今は買い時ではなく、24〜36か月後が次の好機と予想
    • 48gbユニファイドRAMのM4 Pro Mac mini（約$2k）は低予算の推論機材として推奨され、約150tok/sで今後10年使える可能性
    • AMD R9700 32gb VRAM（約$1200-1400）は2x 9070よりAI用途に有利
  • レンタル（クラウドサブスクリプション）も正当な戦略であり、誰もがハードウェアに大金を投じられるわけではない

フロンティアモデルとの比較評価

  • ローカルモデルは**「8〜12か月前の先端モデル品質」**という評価が繰り返される
    • ベンチマーク上ではQwen 3.6 35B-A3BがClaude 4 Opusを上回るが、一部オープンソースモデルにはベンチマーク最適化の可能性がある
    • あるYouTubeブラウザOSテストではQwen 3.6がClaude 4 Opusより多くの動作機能を生成
    • ただしそれは1年前のフロンティアモデル基準であり、3B有効MoEを最新のOpus・Sonnetと比較するのは無理があるという反論も強い
  • **「Opus級」**の定義の不一致が議論の核心
    • 2024年のClaude 3 Opus以来その呼称が使われているが、Opus 4.8・4.6の最新モデルとは依然として差がある
    • 昨年11月のOpus 4.5・GPT 5.2でフロンティアモデルの段階的飛躍が起こり、通常「Opus級」は4.5以降を指す
    • 最大級のオープンウェイトモデルは8x H100サーバー級ハードウェアを必要とし、家庭用モデルはまだそこに届かない
  • 一部ではローカルモデルをHaiku 4.5〜Sonnet 4.5の間と評価し、細かく管理すれば良い結果を出せるとされる
  • フロンティアとローカルの差は常に存在する可能性が高いが、多くのユーザーにとってローカルはすでに実用的な水準

ハーネスとワークフロー戦略

  • Piハーネスが最も多く推奨されており、エージェント開発キット的な性格で、「Claudeのvscodeに対するneovim」というたとえ
    • 基本ツール（ファイルアクセス・編集・bash）を提供し、MCPアダプタ・Web検索拡張も追加可能
    • /treeコマンドで失敗したツール呼び出し前のコンテキストへ戻り、/newでコンテキストを初期化
  • 階層型・役割分担ワークフローで限界を補完
    • フロンティアモデルで仕様・設計・実行計画を書き、ローカルモデルで実装する分業構造
    • エージェントを役割別に接続（プロジェクトマネージャー・スキーマエージェント・コーディングエージェント）し、オーケストレータとPlaywrightでエラーだけ次段階へ渡す
    • 作業を原子的なTODOへ分解し、参照ファイルを明示してコンテキストを節約
  • OpenCodeは毎ターンでシステムプロンプトを変更し、KVキャッシュと互換性がなくなる場合があり、ローカルLLMサポート設定も手動かつ複雑
  • Ollamaはクラウドモデル追加と収益化で批判されており、llama.cpp・llama-swapが推奨され、macOSではllm-mlxが10〜15%高速

具体的な設定共有事例

  • AMD 7900xtx 24gb + 5950x + 64gb DDR4環境でQwen3.6-27B-MTP-UD-Q4_K_XLをllama.cpp Vulkanで運用
    • 主なフラグ: -ngl 99（全レイヤーGPUオフロード）, -c 80000（80Kコンテキスト）, --cache-type-k q8_0 --cache-type-v q8_0（8ビットKVキャッシュ）, -fa on（Flash Attention）, --spec-type draft-mtp（MTPドラフト）
    • サンプリング: --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0（Qwenコーディング推奨値）
    • 性能: トークン生成 約65t/s、プロンプト処理 約600t/s、コールドスタート 約30秒
    • Crushハーネス + Headroom + Exa MCP Web検索の組み合わせで個人のClaude Codeサブスクを解約
  • V100 32GBでQwen3.6-27B-UD-Q4_K_XL + Piを運用し、llama-cpp-turboquantフォークとMTPパッチを適用
    • 200,000コンテキスト、--spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3で45-60 t/s
  • Strix Halo 128GBでQwen3.6-35B-A3Bを動かし、プロンプト処理 約800tps・トークン生成 50tps、アイドル時の消費電力はほぼゼロ
    • 122B版が未リリースなのは惜しく、ユニファイドメモリ環境ではdenseモデルはメモリ帯域制約で遅い
  • 詳細情報不足への不満もあり、量子化・パラメータ・コンテキスト・GPU・VRAM・ハーネス構成の具体的明示が求められている

関連記事

2件のコメント

 
b89kim 58 분 전

Pi-coding-agent+Qwen3.6-27B-MTP-GGUFを使ったときは、Sonnet 4.5くらいの性能でした。簡単なアプリを作るには十分で、必要な場合は無料API（GLM5.1など）をたまに組み合わせて使っていました。4090/5090クラスのGPUは消費電力が大きいですが、きちんと作られたagentなら何時間単位で動かし続けることはあまりありませんでした。
 
GN⁺ 8 시간 전
Hacker Newsのコメント

  • Greenpants: データプライバシーと無料のLLMが重要なので、Piのコーディングハーネスをコンテナ／サンドボックスに入れて完全オフラインで使っている。
    Mac Studio 128GBやMacBook 36GBでQwen3.6 35Bを使っており、アクティブパラメータが3Bなのでかなり速い。Django + Wagtailでホームページとブログを全面的に再設計したが、Wagtailはあまり知られていないため、インターネットなしだとエージェントがいつも十分に理解しているとは限らない。
    複雑な作業ではQwen3.5 122Bも使ったが、アクティブ10Bなのでずっと遅い。Claudeのような大規模モデルと比べると、質問は非常に正確である必要があり、省略した前提はたいてい安易な方向に処理されて、CSSをHTMLに入れるようなアーキテクチャ的に残念な選択をする。
    編集ツールの呼び出しもよく間違え、ループにはまりがち。Qwen3.6 35Bは全般的な知識はあるが常に導いてやる必要があるジュニアに近く、Claude Opusはアーキテクチャを一緒に考えるシニアに近い。Opusが15倍の加速だとすれば、完全オフラインのQwenは5倍の加速くらいだが、無料であることを考えるとそれでも驚き。

    • lambda: 同様にPiをコンテナで動かし、別コンテナのllama.cppに接続して使っている。
      ネットワークアクセスは許可するが資格情報は遮断し、作業ディレクトリと~/.piだけにアクセスできるようにしている。Strix Halo 128GiB統合メモリのノートPCを使っており、プロプライエタリなツールでプログラミングするのは好まないので、フロンティアモデルと本格的な比較はできていない。
      まだAI懐疑派なので、実際の利用よりモデルを壊して強みと弱みを見る時間のほうが多いが、エージェントコーディングではQwen 3.6 35B-A3Bを最もよく選ぶ。一般的なチャットや翻訳ではGemma 4 31B、音声ではGemma 4 12Bをよく使う。
      Qwen 3.5 122B-A10B、Qwen 3.6 27B、Nemotron 3 Super 122B-A12B、Step 3.7 Flash、Minimax M2.7、GPT-OSS 120Bも保存しているが、この構成ではコーディング用としてQwen 3.6 35B-A3Bが現在のsweet spotに最も近い。
    • geophile: ほぼ同じ経験だ。計画を非常に慎重に立てて、小さく独立した段階に分割しなければならず、設計も人間が明確に書いてやる必要がある。
      細部をqwenに勝手に埋めさせると、実装直前のループにはまる。編集できない問題も奇妙だったので、AGENTS.mdで書き直しより編集を制限するように変えたところ、少し改善した。
    • adyavanapalli: 編集ツールには、各コード行をハッシュ化し、置換時にそのハッシュで参照するハッシュベース方式を検討する価値がある。
      アプローチはhttps://blog.can.ac/2026/02/12/the-harness-problem/で見られる。きちんとベンチマークはしていないが、体感では編集ミスが減り、環境によっては効果が違うかもしれない。

  • horsawlarway: 個人用途ではClaudeの月100ドルのサブスクリプションをやめて、unsloth studioを指すpi harnessとQwen・Gemmaモデルに置き換えた。
    約5年前に作ったデュアルRTX3090マシンでunsloth/Qwen3.6-35B-A3B-MTP-GGUFとunsloth/gemma-4-26B-A4B-it-GGUFをUD-Q4_K_XL量子化で動かしており、どちらも約150tok/sと300kの全コンテキストをVRAM内で処理できる。
    Claudeほど良くはないが無料で、個人用途ではその差が大きな問題にはならない。同じ推論サーバーにOpenClawもつないで使っているが、ローカルモデルにはかなり合った用途だ。
    例として、Android TVの代替ランチャー、k8sサービス向けの管理ポータル、Home Assistantの統合・自動化、買い物・献立管理、ComfyUIの3Dアセット生成ワークフローなどを作っている。収益を生むソフトウェアなら、今でも有料プロバイダーを勧めるが、ローカルモデルでもかなりすごいことができる。

    • rootlocus: RTX3090を2枚だと約4,400ドルなので、電気代や他の部品を除いても、Claude月100ドル換算で3.6年分だ。
    • kpw94: gemmaをUD-Q4_K_XLで量子化して動かすなら、unsloth/gemma-4-26B-A4B-it-qat-GGUFのようなQATモデルも確認してみる価値がある。
      https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUFとhttps://blog.google/innovation-and-ai/technology/developers-...を参照。6月9日のアップデートでMTPサポートも追加された。
    • twothreeone: 同じunsloth/Qwen3.6-35B-A3B-MTP-GGUFを単一の3090、128kコンテキスト、Q4_K量子化で動かしてみたが、40〜60tok/s程度だった。
      最も気になったのは、中程度の複雑さの実際のコーディング作業における出力品質だった。「プロンプトで押す」ことと「自分で実装する」ことの間を行き来し続ける必要があり、認知的な切り替えの負担が大きかった。自分の指示が悪いのかモデルが足りないのかを、数分おきに判断しなければならなかった。
      低レベルの実装詳細から高レベルの設計へ移るのも苦手で、表のようなものすらうまくレンダリングできない。Claudeではこうした問題がないので、今のところ代替とは見なしにくく、数か月後には可能になってほしい。aiderでClaude CLIを置き換えたが、この選択も最適ではないかもしれない。

  • bluejay2387: コーディングの約90%を Qwen 3.6 27B と Open Code、カスタムスキル、Semble でこなしている
    CC や Codex ほど賢くはないが、たいていの仕事は終わらせられる。RTX 6000 があるので TPS は十分速く、もともとこの GPU は別作業用だった
    フロンティアモデルにどこまで近づけるか試してみた実験だったが、十分良かったので使い続けている。本当に複雑な作業や UI の仕上げは今でも Codex に戻っており、Qwen は UI がいちばん弱く見える
    おすすめというわけではない。RTX 6000 を持っている人は多くないし、費用は MAX CC や Codex のサブスク数年分になる。それでも可能性は見えており、数年後には実用的になるかもしれない
    256k コンテキストで compact target を 75% に合わせたが、会話が 100k を超えると品質と速度が落ちはじめ、150k を超えると非常に問題が大きくなる。Qwen 3.5 122B も使ってみたが、3.6 27B よりコーディング性能がかなり劣っていた。Gemma 4 31B は別の作業には良いがコーディングでは Qwen が上で、Nemotron Super 120B もコーディングでは Qwen より劣っていて意外だった

    • heipei: RTX 5090 で llama.cpp により Qwen 3.6 27B Q6 を回していて、今は pi agent だけ使っている
      ローカルなのでトークン価格、割り当て量、時間帯、データの機密性をまったく気にしなくていい。GPU 電力を 600W から 450W に制限したら、推論中でもとても静かになった
      コーディングだけでなく日常の雑務にもかなり使うようになった。ブランチにコミットして PR を作る、Stripe CLI で未収・延滞インボイスを取って銀行 CSV と突き合わせる、Elasticsearch の認証情報で現在の負荷要因を要約する、コードベースが X をサポートしているかと実装場所を探す、といったことをやらせている
    • bo1024: Qwen3.5-122B は実際には Qwen3.5-122B-A10B
      A10B は Mixture-of-Experts モデルなので一度に有効になるのは 10B パラメータだけで、Qwen3.6-27B は常に全 27B パラメータが有効な dense モデル。だから多くの作業では 27B dense モデルのほうが 122B-A10B より良いことがある
    • user43928: 職場で Qwen 3.6 27B を強制的に使わされているが、ほとんど役に立たないと感じる
      自分でやったほうがましで、実装はめちゃくちゃにするかデバッグを完全に外す。より賢い検索機能くらいを除けば、Sonnet 未満は時間の無駄に感じる
      Codex を UI の仕上げに使うというのも変だ。Codex は UI がひどいことで有名で、Claude Opus よりかなり遅れている。Altman も次のモデルでこの部分を改善中だと投稿していた

  • pierotofy: Llama.cpp + Qwen3.6-35B(MTP) + OpenCode の組み合わせは、単一の RTX 3090 でもかなり有能で、ほとんどのクラウドモデルより速い
    品質は 8〜12か月前の最先端モデルを使っている感覚。設定は https://github.com/pierotofy/LocalCodingLLM/ にまとめてある

    • jacobgold: 「8〜12か月前の最先端モデル品質」なら趣味用途には素晴らしいが、プロ開発者がコーディングエージェントの主力として使うには Opus 4.6 が出た 6か月ほど前が臨界点だったと思う
    • trueno: 128GB の M4 Max MacBook Pro があるのでこれを触ってみたいが、なかなか時間が取れない
      似た構成を使っている Mac ユーザーの体験が気になる。ローカル周りの議論はよく見るが、基準点が絶えず変わるし用語にも慣れていない。ローカルに移ることで何を失い何を得るのか、客観的に感じたことを知りたい
    • atomicnumber3: もう Claude を使う気はまったくない

  • codinhood: この質問には「本当の」答えはあまり集まらない気がする。今は最新・最高モデルを使わない 機会費用 が大きすぎる
    毎月調べても結論は同じ。ローカルモデルと周辺のコーディングツールを Claude Code の Sonnet/Opus に近づけるための時間・労力・コストは、まだ見合っていない
    見合っていたなら、もうニュースになるほど破壊的だったはず。誰かが解決している可能性を否定するわけではないが、深い沼にハマらないためのオッカムの剃刀に近い

    • pyeri: その 機会費用 FOMO 列車 にも飽和点は来るし、もう過ぎたと見ている
      Mythos 級モデルは推論の最先端だが、ほとんどの開発者が解こうとしている問題領域にはあまり役に立たない。現在の Sonnet/Opus 系 4.8 前後が、結局は企業で広く使われる水準になる可能性が高い
      ローカルモデルはまだそこまでではないが、DeepSeek、Kimi、GPT、MiniMax 系は NVIDIA、OpenRouter、Groq などの API で安く使えて、これらはかなり Sonnet 級だ
    • mark_l_watson: 同じ結論で正しそうだ。ローカル、OpenCode + DeepSeek v4 flash のような商用 API、DeepSeek v4 Pro へと続く 階層型システム に移ろうとしている
      こうすれば必要な作業を引き続き処理しながら、徐々により多くをローカルへ移せる。同じハードウェアでもローカル構成は 2か月前よりずっと良くなっており、6か月前と比べれば劇的に改善している
    • gunapologist99: オッカムより パレート を考えてみる価値がある
      数年以内に到達すると本気で信じているなら、今から触っておいたほうがいい。特に短い・小さいプロジェクトや、よくモジュール化された大きなプロジェクトでは、かなり驚くかもしれない

  • sosodev: この質問は、能力と期待値の幅が広すぎる。8Bモデルしか回していないのにバイブコーディングやワンショットを期待するのは厳しい。
    30B級のモデルを回せるなら、範囲が適切でよく定義された作業ではかなりうまくやれる。現状このクラスでは Gemma4-31B と Qwen3.6-27B が最も良さそう。
    より高速な推論が欲しければMoEモデルに切り替えられるが、ほとんどの作業で目に見えて性能が落ちる。小さな範囲の作業ならワンショットやバイブコーディングも可能だが、それでもガイドがあった方がずっと良い。
    フロンティア級の能力を求めるなら、少なくとも128GBメモリと大きな計算資源、あるいはかなりの忍耐が必要。たいていの人は金か忍耐のどちらかが足りない。ローカルモデルに必要な忍耐とは、トークン待ちだけでなく、自分のワークフローとハードウェアに合わせて設定し、きちんと動かすための努力まで含む。

    • argee: M4 Pro、48GB RAMのMacBookで Gemma 4 26B A4B を使ってRustの勉強やいろいろな質問を処理している。
      IDEやハーネスでのごく些細な変更でもない限り、ワンショットでうまくやれるとは思っていない。それでも、人間がハンドルを握って前を見ており、制限速度以下で走るという条件なら、小～中規模コンテキストの作業でのコパイロットとしては速くて十分に良い。
      数年前と比べると驚くべきことで、これがなければAIでコーディングすることはほとんどなかったと思う。ネット接続が切れた途端に鈍くなったり詰まったりする感じは嫌だ。
    • user43928: 小型モデル、特に GPT 5.4 Mini に10～20行のコード変更を別ファイルへ移させたが、2回目の試行でもコードを変えてバグを入れた。
      完璧な信頼性は期待していなかったが、差分を指摘すれば少なくとも2回目には正せると思っていた。実際には、コードは同じになったと自信満々に言いながら、また別の微妙なバグを追加した。
      こんな粗悪なモデルで十分な作業が何なのか分からない。数分間は有能そうに振る舞えるが、結果は結局正しくならない。せいぜい、少し賢い検索や自動補完向きだと思う。

  • mgsram: 1年ほどローカルLLMを使った末に、今はMac Studio 512GB RAMで Qwen3.6 27B 密集 GGUF、OpenCode、llmster(LM Studio) の組み合わせに落ち着いている。
    Qwen 3.6 35B-A3Bも使ったが、密集モデルの方が精度が一段高く、その代わりtoken/secを犠牲にする。Qwen3.6 27Bは通常25～40tok/sくらい出る。
    最初は簡単なツールに使っていたが、ここ3～4か月はC/C++の自動車ソフトウェアスタックやPythonツールで、本番レベルのコーディングに実際に使っている。速度が低いことも、むしろ適切なペースで進める助けになっている。
    新規開発や書き直しではSonnetと一緒に設計・アーキテクチャ・推論・詳細な実行計画を作り、それを小さく分解して精密なプロンプトとして投入する。既存コードの作業では判断が必要で、ローカルモデルの限界を感じたらClaude Codeに戻る。
    最近はQwen 3.6で、既存のC++コードを参考にしたCベースの電源管理サービス全体の書き直し、複雑なExcel仕様パーサー、CJKの内容を英語に翻訳してKGに入れるツールを作った。

  • 3abiton: みんなQwenに触れているので、自分も Qwen 3.6 35B Q8(MTP) をStrix Haloとllama.cppで回している。
    40～50t/sくらい出て、性能は本当に良い。zshでforge-codeと直接使ってみたが、長いコンテキストが150kを超えると品質が落ちて忘れ始める。

  • wsintra2022: ここのコメントを読んでいると、AIプロバイダー側に立ってローカル利用をやめさせたいボットなのか、本当にローカルAIモデルで嫌な経験をした人なのか区別がつかない。
    Mac Studio 64GBで Qwen 3.6 27B 8k量子化 を回すのは、フロンティア級の万能超能力ではなく、単に良いという感じだ。無料で、プライベートで、熟練エンジニアを怠け者からさらに怠け者へと送ってくれるのが魔法だ。
    llama.cppとopencodeを使ってコード変更を計画し実行させ、その間にハンモックで寝転んだり皿洗いをしたり別のことをする。tmuxとsshで入って確認する。この点こそが本当に驚くべき部分だ。

    • epolanski: ソフトウェア「エンジニアリング」業界では、MITのLeetcodeニンジャがReact+Tailwindでメモリリークする使い物にならないスロップを書いていることも多いので、基準線が非常に低い。

  • garethsprice: Ada 4000 20GB VRAMで OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM を使っていて、生成は55tok/sほど出る。
    OpenCodeは大量のコンテキストを付けるので、体感では数字より遅い。Piについてもよく言及されているので、近いうちに見てみる予定だ。
    Opusで計画を作り、それにローカルエージェントが従い、最後にOpusで検証している。100%ローカルではないが、これらのモデルは徐々に本番ワークフローの一部になりつつある。
    まだ、趣味として時間とお金をかけていじるのが好きな人でなければ、やる価値はないかもしれない。Opusや他のフロンティアモデルほど良くはないが、反復作業が増える範囲では「十分に良い」。
    Rolls Royceがなくても中古のCorollaでスーパーには行ける。フロンティアLLMだとコストが重い新しいワークフローも可能になる。夜通しChrome devtools MCPでユーザーのようにファズテストを走らせ、マルチモーダルでスクリーンショットまで確認させたが、Claude+スクリーンショットの費用を考えると驚きだ。
    「フロンティアより12～18か月遅れ」という表現は当たっていそうだ。12～18か月後には、5,000ドル未満でローカルのOpus級モデルを回せるようになるかもしれないが、フロンティアモデルもさらに先へ進んでいるだろう。

  • arjie: ローカルでも対話型コーディングでもないが、RTX Pro 6000 Blackwellを2枚でDeepSeek V4 Flashを回している。
    生の速度は160tok/sだが、推論モデルだ。自分の用途はコードの自動作成と、他システムの自動レビュー。Piに時々コードを書かせると非常に速いが、習慣のせいで主にCCとCodexを使い続けている。

    • akersten: RTX Pro 6000 Blackwellをどこで手に入れたのか気になる。
      見つけたサイトはどこも全部売り切れか、企業向け限定か、怪しく見えた。
    • leptons: この機材の 消費電力 を測ったことがあるのか気になる。月額コストがどれくらいになるのか気にしている。

  • stymaar: Qwen3.6-35B-A3B を Strix Halo 128GB Bosgame M5 で動かしている
    このモデルに対しては VRAM が多すぎるが、Qwen が自分のハードウェアに最も合うはずの 122B 版 Qwen3.6 を出していない。代わりに電気代はほぼ無視できるレベル。もともとノート PC 向けのチップなのでアイドル時はほとんど電力を食わず、プロンプト処理中でも 120W を少し超える程度
    Qwen3.6 は意外なほど有効で、Claude はたまに、全体の必要量の 10% 程度しか使わない。最安プランでも割り当て内に収まる。速度はプロンプト処理が約 800tps、トークン生成が 50tps で、推測デコーディングは使っていない

    • manmal: 27B の dense 版も試したのか気になる。コーディングにはずっと良い

  • Kostic: 個人用途では VSCode と llama.cpp をつないで Qwen 3.6 27B や Gemma 4 31B を動かしていて、クラウドのサブスクを切るのに十分なくらいだ
    Qwen は 1 枚目の GPU で q4@176k コンテキスト、MTP ありで 70〜50tok/s くらいなので、コーディングにはかなり良い。Gemma は 2 枚の GPU を両方使い、q8@64k コンテキストで文書の感情分析、要約、校正、翻訳を 25tok/s で処理している
    バッチワークフローには少し遅いが、実用にはなる。llama.cpp が tensor split モードで MTP をサポートすれば、さらに伸ばせそう
    仕事では費用を自分で払うわけではないので、今でも frontier LLM を使っていて、当然そちらの方が良い。1 年くらい後には Sonnet 4.6/Opus 4.5 レベルの 30B モデルが出てほしい
    プロンプト処理は 800t/s から始まって 400t/s まで落ちる。たいてい開始プロンプトが 16k〜24k トークンなので、処理に 60〜90 秒かかるが、良くはないものの許容範囲ではある

  • jodoherty: RTX Pro 6000 Blackwell で Gemma 4 31B を Pi から動かして、すべてのエージェントコーディングに使っている
    役に立つと感じていて、このサイドプロジェクトは職場で自分がプロジェクトのスコープを決めて進めるやり方に近い: https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
    慎重なアーキテクチャ設計と TDD を多く適用する必要がある。難しい部分を初期に処理し、シンプルで使いやすいインターフェースで包むことで技術的リスクを取り除く
    プロジェクトによっては自分で書くより 2〜3 倍速く、退屈だったりスコープの広いプロジェクトでは、アイデアを素早く集めて試せるので 5〜10 倍の時間短縮になる
    構成は nvidia/Gemma-4-31B-IT-NVFP4 を使う vLLM と、MTP 付きの unsloth/gemma-4-31B-it-qat-GGUF を使う llama.cpp を切り替えている。GPU 電力は 400W に制限。現在の llama.cpp 構成では MTP draft の受理率に応じて 60〜150t/s、prefill はコンテキスト長と深さに応じて 1500〜4000t/s 出る

  • jborak: RTX 5070 を 4 枚と第 1 世代 AMD Threadripper 1950X で Qwen3.6 27B MTP Q6_K を llama.cpp 上で動かし、Pi の日常的なドライバとしてうまく使っている
    速度は 50〜60tok/s くらい。他のアプリも OpenWeb UI などでつないでいて、最近は LLM ゲートウェイ Bifrost をモデルアクセスのデフォルトの入口として設定した
    Qwen3.6 35B A3B も試したが、コーディングには 27B の方が合っている。dense モデルなので遅いが、品質はずっと良く見える。35B A3B は non-MTP で 130〜140tok/s と異常に速い
    Qwen3.6 27B を動かすのに 5070 が 4 枚必須というわけではなく、3 枚、もしかすると 2 枚でも可能。ただし 27B を高速化するために MTP を使うと、draft モデルが独自のコンテキストを要求するのでメモリ消費が増える
    ツールのシステムプロンプトも会話ごとにモデルへロードされる点は覚えておくべき。Pi を起動した直後は非常に応答が速いが、Hermes CLI でやり取りすると各プロンプトが skills、tools など多くのコンテキストを積み、そのまま会話の終わりまで残るのでずっと遅くなる
    プライバシーも良いが、割り当てがなく使用量を心配しなくていい点も良い。もし未来が「ループエンジニアリング」なら、クラウドモデルではトークンと金を燃やすことになる。自分のシステムはアイドル時 200W、高い推論負荷時 350〜450W で、デコーディングはあまり効率的ではないため GPU が思ったより頻繁に遊んでいる面もある。拡散のような進展がデコーディングを高速化し、アイドル GPU の活用率を高めるかもしれない

    • zakisaad: 4 枚構成でなぜ 5070 を選んだのか気になる
      最初の印象では演算性能寄りで VRAM は不足気味なので、ゲーマーには良さそうだが LLM 実行にはあまり向いていないように見える。自分のデスクトップにも 5070 を使っている

  • cuttysnark: ローカルモデルは、複数の エージェントをワークフローでつなぐことである程度うまくいった
    各エージェントは役割に応じて異なるプロンプトと異なる ollama モデルを使う。プロジェクトマネージャーやスキーマエージェント (qwen3:14b) は、コーディングエージェント (qwen2.5-coder:7b) と同じモデルを使わない
    各段階の間にはオーケストレーターと Playwright の作業があり、前のコードブロックを作ったエージェントにエラーが見えるようにしている。エラーのないブロックだけが次の段階へ進む
    最大の改善は backend-for-agents のサービス定義を入れて、スキーマエージェントがタスクベースの manifest だけを作り、それを次のエージェントに渡すようにしたこと。要するにワークフローを定義して、エージェントが非常に特定の作業だけを行い、それを次の段階へ渡すようにする。こうすると土台を見失わずに済み、25% あるいは 90% 成功した流れに人間が介入するポイントも作れる

    • pianopatrick: こうした ワークフローのベンチマークや大会があれば、何がうまくいくのか分かりそう
      「このコンシューマー向け GPU だけを使い、好きなモデルとワークフローで xyz ベンチマークをどれだけうまく解けるか」のような形式。参加者に最大 1 時間を与え、解答率、正答率、総時間をスコア化する “The Local AI challenge” のような形が良さそう
    • sowbug: エージェント同士を 競わせることを試したか気になる
      たとえば同じコーディングタスクを 2 つのモデル、あるいは同じモデルの異なるシードに与え、レビュアーがより良い結果を選ぶ方式。人間の脳も、状況を少しずつ違って見る何千ものミニ皮質カラムが多数決で投票するように機能しているという見方がある

  • HappySweeney: Optane と大量の RAM があるので、0.7t/s ほどでフルモデルに近いモデルを一晩中、関数作成に使ってみた。
    現在のテストは、スカラー関数を AVX512 を使うビット行列転置関数に置き換えること。クラウドモデルは簡単に処理するが、Kimi 2.6 と GLM 5.1 は悲惨なほど失敗する

  • etoxin: まだ置き換えられてはいない。仕事のプロジェクトでは openspec を使い、大金をかけずにローカル機材を模擬するため、最新の人気ローカルモデルのホスティング版に課金して使っている。
    ほとんどの小型ローカルモデルはツール呼び出しをまともにできないが、より大きいモデルは今ではきちんとできる傾向がある。ローカル側でまだ考慮されていない点は、生産的なエンジニアは普通、git worktree と一緒に複数の CLI チャットを同時に回していることだ。私はたいてい 3 つの worktree と CLI チャットを開いている

  • blurbleblurble: 今の制約はモデルそのものより、キュー管理・中断・サブエージェント・目標といった機能が妙に欠けている代替ハーネスの使い勝手にあると思う

    • coder543: 完全に同意。OpenCode がローカル LLM をまともにサポートしようとしないのも腹立たしい。
      OpenCode を動かすこと自体は可能だが、設定が非常に手作業的で雑だ。llama-server の設定を OpenCode の設定に自動変換するスクリプトを作ったので助かってはいるが、理想的ではない。
      余暇にもう 1 つコーディングハーネスを作るべきか、本気で考えたことがある。もっと良くできるアイデアがいくつかある
    • horsawlarway: Pi は悪くない
      Claude、Cursor、Pi の CLI エージェントや自作のカスタムハーネス、gastown まで使ってきたが、Pi は単純に十分だ。必要なことをこなし、標準ツールがまともで、他のツールともよく統合され、気にかけることが減る。
      30B 前後のモデルをそこそこの速度で回せるなら、Pi と組み合わせてかなり驚く人は多いはずだ。https://pi.dev/packages/pi-mcp-adapter?name=mcp や https://pi.dev/packages/pi-web-access?name=search のような拡張を付ければ、Web ツール、Perplexity 検索、Chrome 制御用の https://browsermcp.io/、Firefox 用の https://github.com/mozilla/firefox-devtools-mcp のような MCP アクセスも得られる。
      補助金付きの最上位モデルほど良くはないが、無料で、それでも十分有能だ。個人的には https://pi.dev/docs/latest/sdk もとても楽しく使っているが、他のプロバイダーはこうした API アクセスに月数千ドルを取る
    • Insanity: pi.dev について良い話は聞いているが、まだ使ったことはない。挙げられていた欠けている機能の一部を解決してくれるかもしれない

  • _bobm: Claude/GPT モデルと言うとき、その「モデル」が実際には何なのかを考える必要がある。
    GPT がどうやって思考部分を少しずつ送り、その思考ブロック自体に Markdown 見出しの要約を付けられるのかを思い出せばよい。API エンドポイントと出力の振る舞いを観察すると、いわゆる SOTA モデルは見たままのものではなく、インフラ面ではローカルモデルとまったく比較対象にならない。
    この規模の運用には膨大なオーケストレーションがあり、その制約が語られないイノベーションにつながっている。追いつけないとは思わないが、llama や vLLM でローカルモデルをサービングするのは、せいぜいアルファベットの A、B、C レベルにすぎない。
    本当に必要なのは、上で示唆したオーケストレーションの複製だと思う。SOTA の「モデル」は 1 つの単一モデルではなく、複数モデルが一緒に動く深いオーケストレーションだ。したがって単一モデルは、学習とアーキテクチャにおいてこのオーケストレーションを再現するまでは追いつけない。
    一般消費者向けに提供されているこのオーケストレーション構成の 1 モデル自体は、Qwen 3.6 よりはるかに優れているわけではないと思う。見方を変えると、「魔法」の規模が見え始める

    • XCSme: なぜ SOTA モデルが複数モデルの深いオーケストレーションだと思うのか、理解できない。
      GPT が思考部分を Markdown 見出しの要約付きで送るという例も、具体的に見てみたい

  • cheekygeeky: うちのソフトウェア開発者は、私が会った中で最も賢い人なのだが、OpenCode と Tmux をオープンソースモデルと一緒に使っている。
    コーディングでは DeepSeek を最も好み、「かなり良い」と言っている。i9、128GB RAM、3090 を 2 枚で動かしている。https://www.msn.com/en-us/news/technology/china-s-open-deeps...

  • pianopatrick: こういうワークフロー向けのベンチマークと大会があれば、何がうまく機能するのか分かると思う。
    「この民生用 GPU だけを使って、好きなモデルとワークフローで xyz ベンチマークをどれだけうまく解けるか」のような形式だ。参加者には最大 1 時間が与えられ、回答率・正答率・完了時間で採点される「The Local AI challenge」のような大会を見てみたい

  • bravetraveler: ほぼ「ナチュラル」な形で使っていて、少ない LLM 利用もすべてローカルだ。
    128GB の Strix システムで、より疎な Qwen や Gemma の派生モデルなら 50〜80tok/s の出力が出る。Anthropic/OpenAI などを購読するつもりはなく、たとえこれが最後のローカルモデルだとしても必要ない。モデル内ツール使用が最新性への懸念を補ってくれる

  • GodelNumbering: 一日中 LLM と会話している立場からすると、オープンソースのフロンティアモデル + 良いハーネスの組み合わせは、すでに十分だと思う。
    ローカル展開が完全移行できるようになるには、あと 1〜2 世代のハードウェアが必要だ。ただし、ハードウェア企業がデータセンター部門を強く優先しているので、その時期はすぐには来ないかもしれない

  • milchek: 36GBのMacBook Proで試したが、ごく基本的な作業を超えると大きな成功はなかった。
    小さなモデルを使ってもコンテキストがすぐに尽きるうえ、遅いのが問題だった。ある程度まともな性能を出すには128GBメモリが必要そうで、ハードウェアコストが大きく上がる。
    結局はフロンティアモデルのサブスクを使うか、その金を機材に注ぎ込むかの問題。もちろんプライバシーが重要なら、高性能な機材に金をかける以外の選択肢はほとんどない

  • acc_297: 中規模モデルに各プロンプトごとにRLHFを日常的に適用して、個人の利用習慣に合わせて微調整したら役に立つのか気になる。
    モデルを手動で微調整することで、悪化するのか改善するのか分からない。まじめにフィードバックすれば、過剰なお世辞や冗長さ、比喩で説明したがる面倒な癖のような汎用モデルのティックを減らせるといいのだが、個人1人分のプロンプトフィードバックだけで十分なのかは分からない。
    社内ドキュメントで微調整した社内エージェントも妙な挙動を見せ、標準モデルより必ずしも有用ではないという話を聞く。エージェントのすべての応答を編集して、元の応答と編集後の差分で微調整できたらいいと思う。
    個人的には形容詞をかなり削って、要点だけの応答に整えるだろうが、Owain Evansのようなアラインメント研究者の仕事を見ると、こうした調整で予測しにくい傾向に押しやられる可能性もありそうで心配だ。

    • htrp: Cursorがそれをやっている。たぶんプロバイダーとしてFireworksを使っているようだ: https://cursor.com/blog/real-time-rl-for-composer
    • rolisz: OpenClawエージェントで似たようなことを試してみたい。
      Owain Evansの仕事はSFTだった気がする。Twitterで誰かが、RLは彼が示した現象に対してはもう少し脆弱ではないと言っていたが、自分でも実験してみたい

  • heisenbit: 設定作業は必要だが、その過程でかなり学べている。
    48GBのM4 MBPで主にqwen/qwen3.6-35b-a3b mlxを使っており、Docker dev-containerと基本作業のための余裕がかろうじて残る。LM Studioで動かしてVSCodeで使っている。
    システムプロンプトを変えてツール統合を改善したことが大きな違いを生んだ。それまでは変更を適用するよりコードを再生成してしまい、助けになるより壊すことが多かった。
    騒音と発熱を避けるため、電源接続中でもたいてい低電力モードで使っている。最大性能では速度は2倍くらいになるが、消費電力は2倍以上になる。
    できたのはページの簡単な再構成くらいで、Pinia storeの分離は失敗した。GPT-5.4はこの作業を問題なく処理する。ツール利用ガイドや周辺の支援ツールをさらに調整すれば、性能はもっと上げられると思う

  • nfrankel: 試してみたし、理論上は動く: https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
    結果はモデルによって異なり、結局はコンピューターが限界になる。自分のマシンでは残念ながら耐えられなかった

  • K0balt: qwen 3.6 27b denseでかなり良い結果が出ている。
    作業によってはClaude Haiku 4.5に近く、場合によってはSonnet級のこともある

    • kadoban: どのツールでその作業を回しているのか気になる
    • kandros: コーディング作業ならHaikuよりむしろ肉屋に聞く

  • jderekw: 普段使いの機材としてAMD Lemonadeを使っている。
    Ollamaから始めてLMStudioに移り、今はcRAM、CPU、GPU、gRAMの監視に役立つAMD Lemonadeに標準化した。Lemonadeのマルチモデル機能のおかげで、LLM、音声テキスト変換、NPU、画像生成スタックを簡単に回せる。
    プラットフォームはNvidia、Apple、Intel、AMDのチップセットでも動作する

  • redox99: 家で回せるQwen 35Bのようなモデルは、OpusやGPT 5.5にはまったく近くない。
    その近辺のオープンモデルは1Tパラメータ級なので、家庭で回すのは忘れたほうがいい。ボロ車を運転するのに似ていて、AからBへ行けるから十分だと自分に言い聞かせる人も多いだろうが、十分ではない。
    プライバシーが絶対条件であるか、趣味としてやるか、飛行機のような特殊なケースでもない限り、合理的な理由はない。Codexに大幅補助が入った20ドルすら払えないなら、中国系モデルのAPIを使ったほうがこうした小型モデルを圧倒する。

    • pbasista: 「Qwen 35Bのような家庭で回せるモデルはOpusやGPT 5.5にまったく近くない」という評価は、どんな客観的事実やベンチマークに基づいているのか気になる
    • xgulfie: 通勤にFerrariは必要ない

  • sj_tech: Mac Mini 128GBでGitHub Copilot Extension for VSCodeを使い、Qwen 3.6 35B A3Bをエージェントコーディングに使っている。
    モデルサイズのわりには悪くないが、問題が大きくなりすぎるとループにはまるのを見かける。自分がやり方を知っている作業をやらせて時間短縮する用途なら良い

  • julianlam: Framework 13の32GBメモリでQwen 3.6 35B-A3Bをllama.cppで動かしていて、15tok/s出ている。
    コードもテキストも、自分が読む速度より速く出力する

  • moezd: まだ無理。純粋なApple環境か、まともなGPUがなければ、RAMやスレッドが多くても30〜50tok/s程度がせいぜいで、それもthinkingを切った状態だ。
    こうした最適化がないと、モデルはMCP、skills、エージェント説明を好きなだけ食ってしまい、最初の出力トークンを見る前にペンキが乾くのを眺めることになる。
    ローカルモデルのサービングではコンテキストウィンドウ内のあらゆるトークンを節約しなければならず、Claude/GPT/Copilotが業界を押し進めている方向とは正反対だ。

    • amarshall: thinkingは出力速度を変えない。Anthropicモデルの中央値の出力速度はだいたい40〜60t/sだ

  • mitchell_h: 試したが、コンテキストウィンドウが十分に大きくなかった

    • coder543: Qwen3.6-27Bは100万トークンのコンテキストウィンドウをサポートしている。
      もちろん、そのコンテキストウィンドウで動かせるハードウェアが必要で、自分のDGX Sparkではq4_k_xlモデルにf16 KV cacheをフルで使うと約100GBのメモリが必要になる
    • lysace: 似たような結果だった。自分のRTX 4070は12GBしかないので、24/32GBで実用的なほど改善するのか気になる
    • deadbabe: オープンな問いとして投げるより、もっと直接的にプロンプトすればいい

  • drnick1: 現在、高性能なコンシューマー向けGPUで動かせる最高のコーディングモデルは何なのか気になっている。
    RTX 3090/4090があると仮定した場合、どんなスタックを勧めるのかも知りたい。Llama.cpp + OpenCodeのような組み合わせなのか気になっている

  • bijowo1676: 高価なフロンティアモデルでアプリの仕様、製品要件、アーキテクチャのようなMarkdownドキュメントを書いて更新し、その後で安価またはローカルなモデルにその仕様を実装させる構成が興味深かった。
    Markdownは何百ものソースファイルよりも情報をうまく圧縮してコンテキストウィンドウに収まりやすいが、粗い部分を整えるには2回目・3回目のパスが必要になる。こういうやり方を試した人がいるのか気になっている

  • grmnygrmny2: OpenAIやAnthropicの製品を使うことに倫理的な抵抗感があり、LLM導入そのものにも消極的だった。
    ローカルモデルはそうした道徳的な抵抗感の大半を解消してくれるので、1か月ほど仕事と個人プロジェクトで使っている。手元のハードウェアは32GBのMac群と10GBの3080ゲーミングPCで、さまざまな量子化のQwen3.6-35B-A3Bあたりが限界だが、それで十分だ。
    200〜400 PP、20〜30 TG程度で、うまく使うコツを身につけるのに少し時間がかかった。面倒を見たり方向づけたりしないといけない作業もあるが、かなり有用だ。
    CCは使ったことがないので比較はできないが、組み込みC++からVueまで、優秀なアシスタントやペアプログラマの役割を果たしてくれる。27Bを回せたらいいのにと思うし、ときどきこのモデルが何かをほとんど理解しかけていながらできない瞬間もあるが、まれだ。
    多くの作業で大きな時間節約になっており、かなり曖昧な指示だけでもバグを掘り下げて修正する能力が高かった。ハーネスにはPiを使っている