Qwen 3.6 27Bはローカル開発の最適解

 (quesma.com)
5 ポイント 投稿者 GN⁺ 6 시간 전 | 1件のコメント | WhatsAppで共有
  • Qwen 3.6 27Bは、ローカルモデルに懐疑的だったユーザーにとっても汎用作業で十分に有力な選択肢に見え、35B A3Bより遅いものの、より強力なdenseモデルとして推奨される
  • 創作・コーディングテストでは制約条件の順守が強みとして現れ、OpenCodeでpnpmベースの六角形マインスイーパーを単一プロンプトでNodeパッケージとして生成した
  • llama.cppとHugging Faceの8-bit GGUF量子化を組み合わせればローカル実行が可能で、MTP、GPUレイヤーの読み込み、flash attention、64kコンテキスト設定によりエージェントコーディング環境まで構築できる
  • Macbook Max M5 128GBテストでは、Qwen3.6-27B 8-bitはllama.cpp + MTPで32 tok/s、約42GB RAMを使用し、より高速な35B A3Bよりコード品質が高かったため27Bが好まれた
  • Artificial Analysis基準でQwen3.6-27Bは37点となり、GPT-5 / Claude Sonnet 4.5と同じmid 2025水準に位置づけられ、機密データ・オフライン作業・回収不可能な自前モデル運用に実用的である

Qwen 3.6 27Bを推す理由

  • Qwen 3.6は2つのバリアントで提供されている
  • Qwen 3.6 27Bは「サイズ以上の性能を出す」という反応を多く集めており、関連例としてWill it Mythos?がある
  • ローカル実行中はコンピュータが熱くなることもあるが、それを受け入れるだけの性能を提供する

簡単なテストと実作業での結果

  • 簡単なスモークテストとして、Simon Willisonの「penguins on a bicycle」の代わりに制約付きライティングを使った
  • Zoukダンスと量子物理学をテーマに8行詩を依頼したところ、量子用語と韻律を扱う思考の流れが自然に続いた
  • OpenCodeでpnpmを使って六角形マインスイーパーを作るよう依頼すると、単一プロンプトだけで正しいNodeパッケージを生成した
  • Qwen 3.6 35B A3Bはより高速だったが、パッケージを作れという指示に従わず、単一のindex.htmlとして実装した
  • 一般的な業務タスクでも短いプロンプトで動く成果物を作れ、応答性やデフォルト設定も悪くない
    • frontierモデル基準では特別ではないが、ローカルモデルとしてはすでに実用的な水準である

llama.cppでローカル実行する

  • ローカルモデルの実行は数行のCLIで可能で、推奨ツールはllama.cppである

  • Hugging Faceから容量を削減した量子化モデルを取得して実行する

    • 人気の量子化モデル提供元としてunslothとbartowskiがある
    • ベースモデルは通常BF16精度である
    • 8-bit量子化は品質劣化をほとんど生まずに容量を半分にできる
    • より低ビットの量子化はモデルをさらに小さく、場合によっては高速にできるが、品質面のコストを伴う
    • 27B比較はReddit benchmark、35B A3B比較はHugging Face discussionにある

  • サーバー実行例

    llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 \
    --spec-type draft-mtp -ngl 999 -fa on -c 65536 --port 8080
    • -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0: Hugging Faceからモデルを取得し、以後の実行では再利用する
    • -m ~/models/Qwen3.6-27B-Q8_0.gguf: すでにモデルファイルがある場合はこちらを代わりに使える
    • draft-mtp: 高速なモデルで次トークンを予測するmulti-token predictionを使って速度を上げる
    • -ngl 999: すべてのレイヤーをGPUに載せる
    • -fa on: flash attentionを有効にする
    • -c 65536: コンテキストサイズを64kトークンに設定する
    • Qwen 3.6 27Bのネイティブコンテキストは256kである
    • --port 8080: 他の設定で使うポートを固定する
    • http://127.0.0.1:8080を開けば直接チャットできる

  • OpenCode設定

    • 同じサーバーをvibe codingにも使える
    • OpenCodeでは~/.config/opencode/opencode.jsoncに次の設定を追加する
    {
  "$schema": "https://opencode.ai/config.json";,
  "provider": {
    "llama": {
      "name": "llama.cpp (local)",
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1";,
        "apiKey": "local"
      },
      "models": {
        "qwen3.6-27b": { "name": "Qwen3.6-27B Q8 +MTP" }
      }
    }
  },
  "model": "llama/qwen3.6-27b"
}

  • ターミナルチャット用の実行

    • ターミナルでチャットだけするならllama-serverの代わりにllama-cliを使える
    llama-cli -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 \
                -ngl 999 -fa on -c 65536

Apple Siliconでの性能測定

  • テスト結果はbenching-local-llms-on-apple-siliconに整理されており、Macbook Max M5 128GBで実行された
  • Qwen3.6-35B-A3B · 8-bit
    • MLX: 85 tok/s, 37GB RAM
    • llama.cpp: 93 tok/s, 44GB RAM
    • llama.cpp + MTP: 105 tok/s, 45GB RAM
  • Qwen3.6-27B · 8-bit
    • MLX: 17 tok/s, 28GB RAM
    • llama.cpp: 18 tok/s, 41GB RAM
    • llama.cpp + MTP: 32 tok/s, 42GB RAM
  • DeepSeek-V4-Flash · Q2–Q4
    • llama.cpp: 33 tok/s, 103GB RAM
  • 30 tok/sは悪くない速度で、一般的なfrontierモデルAPIの範囲内に入る
  • mlx-lmはApple Silicon向けだが、このテストではllama.cppの方が速かった
  • 実行中のGPU使用率は95%で、利用可能なリソースを効率的に活用していたようだ
  • Qwen 3.6の2つのバリアントはいずれもApple Siliconの共有RAM 48GB内で動作した
  • コンシューマー向けNvidia RTXカードでは、より攻めた量子化が必要になるが、推論はより高速に動作する
    • Hacker Newsのgfoscoは5090でQ6_K量子化とQ4_0 KVにより、123kコンテキストで安定して50 tok/sを得られ、LM Studioで約28/32GB VRAMを使用したと述べている
  • 35B A3Bは3倍速いが、生成されるコード量が3分の1でも品質が高い27Bを選ぶ価値はある

既存の最先端モデルとの比較

  • Artificial Analysisのスコア比較でQwen3.6-27Bは37点である
  • 比較表の主要項目は次の通り
    • Gemma 4 31B: 29点、late 2024水準、o1 / Claude 3.5 Sonnet
    • Qwen3.6-35B-A3B: 32点、early 2025水準、o3 / Claude 4 Sonnet
    • Qwen3.6-27B: 37点、mid 2025水準、GPT-5 / Claude Sonnet 4.5
    • DeepSeek-V4-Flash: 40点、late 2025水準、GPT-5.2 / Claude Opus 4.5
  • 追加ベンチマークはnotesにあり、全体的な傾向は似ている
  • Gemma 4 31Bはローカルコーディングのデフォルトのように使う人が多いため比較対象に含まれている
  • ベンチマークとオンラインの反応の両方で、Qwen 3.6 27BはGemma 4 31Bより大きく好まれている
  • ただし、量子化条件には注意が必要である
    • 8-bit量子化は結果に大きな影響を与えない可能性が高い
    • DwarfStar4はDeepSeek V4 Flashに2–4bitのかなり攻めた量子化を使っているため、フルモデルより明らかに劣る
    • この条件ではQwen 3.6 27BがDwarfStar4と同等か、やや良い印象を与える
    • より長いコンテキストのプロジェクトではDS4が優位になる可能性もある

ローカルモデル運用の次の段階

  • 自分でモデルを動かすことが、ますます現実的な選択肢になっている
  • 独占的なfrontierモデルの状況がこの流れをさらに後押しする可能性がある
    • Claude Fable 5は撤回された
    • 他のfrontierモデルは大規模な補助金の上で運営されており、月100ドルの支払いで数千ドル分のトークンを使える構造になっている
  • ローカル設定のモデルは必要に応じてファインチューニングでき、外部から回収されることもない
  • 企業は独自データや機密データのためにローカルモデルを使える
  • 個人はオフラインプロジェクトや、米国・中国に深い秘密や医療データを共有したくない状況でローカルモデルを活用できる
  • frontier-level open-weight GLM 5.2の公開は、ローカルモデルの流れをさらに加速させる
    • Qwen 3.6は橋渡し的な存在であり、GLM 5.2もローカル実行が可能である
    • GLM 5.2はMacbookや単体のRTX 5090では動作しないが、企業予算なら十分に扱える水準である
  • 現在の最先端より賢く、それでいてローカルデバイス、ひょっとするとスマートフォンでも動作するモデルが登場するかもしれない
  • 現在のモデルは生の知能と事実知識を同じ重みに結び付けているが、将来のモデルは知識をツール呼び出しへ委ね、それらを分離する可能性が高い

関連記事

1件のコメント

 
GN⁺ 6 시간 전
Hacker News の意見

  • MacBook Pro M5 128GB RAM と qwen3.6 は気に入っているが、ローカル LLM で本気でコーディングするつもりなら、この MacBook は買わないほうがいい
    理由は単純で、指が熱くなり、ファンの騒音で頭が破裂しそうになるから
    実際に使うノートPCで複雑な作業を走らせるのは現実的ではなく、クラムシェルモードなら可能でも、AI コーディングやエージェント作業中には触りにくい
    Qwen3.6 27B/35B をきちんと動かしたいなら、MacMini M4 64GB を買って地下室、少なくとも数メートル離れた場所に置き、LAN や Tailscale で接続するほうがよく、価格も MacBook Pro のほぼ 1/3 程度

    • 同じ理由で普通の 32GB ノートPCを買った
      デスクトップ GPU で Qwen 27B や Gemma 4 31B のような比較的小さなモデルを動かすだけでも、どれほど騒がしく熱くなるか分かっている
      Strix Halo は大きなファンが1つなのでうるさくはないが熱くなり、ノートPCの小さなファンでその熱を逃がそうとすれば、結局悲鳴を上げるしかない
      どこでもモデルを動かせるノートPCという発想は良いが、それはクラウドモデルに任せるのが正しく、データが大量に行き来するわけでもないので大きな問題でもない
      プライバシーが必要な作業は、自宅の大型機にセルフホストしたモデルを載せ、VPN で接続すればよい
      ただし Gemma 4 12B QAT 4-bit のように 16GB 機器やタブレットでもよく動くモデルは特定の作業には非常に良く、分類・識別・ラベリング用途のセルフホスト型ビジョンモデルとしては、テストした中で最高だった
      散文も悪くなく、ツール利用もそれなりにこなすが、7GB の中に世界知識がそれほど多く入っているわけではないので調査には検索が必要で、ごく単純なコードを超えるコーディングには使いたくない
    • DwarfStar 4 で --power フラグを試すとよい: https://github.com/antirez/ds4#reducing-heat-power-usage-and...
    • 「指が焼けて騒音で頭が破裂する」というなら、単に Mac mini を別の部屋に置けばいいのでは、と思う
      この半年ほどノートPCでコーディングエージェントを YOLO モードで走らせていて、ほとんどはローカルではなかったが、怖がらずに使う方法は、エージェント専用の Linux ユーザー agent を別に用意することだった
      エージェントは /agent ホームディレクトリを吹き飛ばしてもよいが、私のホームディレクトリには触れられず、読むこともできない
      毎回 sudo でそのユーザーに入る必要があったのでエイリアスを作り、権限・所有権の問題が起きたら1日に1回直す関数で対処している
      それでも面倒ではあったので、専用マシンがあれば普通に root を渡していたと思うし、冗談半分で Claude に3ドルの VPS の root を渡したところ、うまく動いている
      数カ月の試行錯誤の末、結局「ただ Mac mini を買え」を最初から再発明したようなもの
    • M4 Max でローカル LLM 作業を pi で試したとき、これまで使ったどの MacBook よりも熱く感じた
      数インチ離れていても輻射熱を感じ、使ったことのある Intel MacBook よりもさらに熱い感じがしたので中止した
      供給問題と値上げのせいでノートPCを10年は使い続けることになるかもしれず、壊したくなかった
    • まさにその構成で使っている: Mini M4 Pro 64GB と qwen3.6 の組み合わせ
      聴力はそれほど良いほうではないが、ファンの音がすれば聞こえたはずなのに一度も聞こえず、実際にファンがあるのか検索して確認したほど

  • この記事は 128GB MacBook Pro で Qwen 3.6 を動かした内容に基づいている
    ちなみに 128GB MBP は現在 $6699 からとなっている [0]
    プライバシーのためにそのプレミアムを喜んで払う人もいるだろうが、MacBook Neo の約10倍の費用なら、OpenRouter や最先端研究所の API クレジットをかなり大量に買える
    [0]: https://www.apple.com/shop/buy-mac/macbook-pro/14-inch-space...

    • 計算は否定しにくいが、自分ならそこで線を引くことはしない
      Gemma 4 12B のような手頃なローカル LLM を動かせるマシンを持つことには本当に価値がある
      MacBook 1台で本格的な無人エージェントコーディングをどれほどやることになるかは分からないが、ローカルモデル、llama.cpp、LM Studio などを自分で触っていなければ、この分野をここまで理解することはなかったはずだ
      この分野はあまりにも大きく、疲弊させられ、専門用語だらけで、50代を超えた立場からすると圧倒されやすかった
      中古マシンに自分で設定し、API 呼び出しを見て、用語を理解していく中で、ようやく手触りが出てきた
      Neo は、こうした機会をより実感しやすく理解しやすいものにするには小さすぎる
    • Qwen 3.6 の実験はすべて 48GB Apple Silicon で十分だった
      より強めの量子化を使えば、さらに下げられるかもしれないと思う
      経済的には、ノートPCでモデルを動かすことに大きな意味はなく、純粋な電力コストだけを見ても、大規模に生成されるトークン価格に勝つのは難しいかもしれない
      それでもこれはゲームを変える ブレークスルー だ
      以前は、消費者向けデバイスでこうしたバイブコーディングを行うことは、難しいとか高いとかではなく、そもそも不可能だった
    • Qwen 3.6 27B の dense モデルは DGX Spark でも同程度の性能で動かせて [1][2]、価格は約 $4000 だ
      Asus Ascent GX10 も複数の販売店で $3999 となっている
      理論上は 3090 を2枚使って 48GB VRAM を確保することもできるが、MacBook Pro や GB10 と比べると場所を取り、発熱も大きい
      [1] https://x.com/MiaAI_lab/status/2070859135399182444
      [2] https://github.com/MiaAI-Lab/Qwen3.6-27B-NVFP4-vLLM
    • 言及されているモデルは 24GB 以上の VRAM があれば簡単に動かせるし、16GB VRAM でもよく動く似たようなモデルもある
      ここで 128GB が必須というわけではない
    • トークンやクレジットは使えば消えるが、MacBook は残る
      同じ MacBook で他のモデルも動かせる
      人々が毎月 SaaS に費やしている金額を見ると、そのお金なら5か月で MacBook の元が取れるケースもある
      そしてこれは単なる「データプライバシー」の問題ではない
      Claude を使うということは、すべてを Anthropic に送るようなものなので、かなり正気ではない

  • 例が「実務」を反映しているとは見なしにくい
    少なくとも自分が実務だと考えるものではない
    ゼロショットの新規プロジェクトを当てるのは、小さなモデルにも比較的簡単
    積み上げるべき文脈が多くなく、学習データ内の似た例に簡単に戻れるため
    まったく新しいものを発明しろと言わない限り、それなりにこなせる可能性は高い
    本当のテストは、既存のコードベースで作業できるかどうか
    限定的に試した実験では、Qwen 3.5 は Rust+React アプリでは問題なく、C# のモノリスではいまひとつだった
    使い物にならないほどではないが、20分で Claude に戻るくらいには微妙で、クラウドモデルへのアクセスを失って Qwen だけを使わなければならないなら、かなり悲しい気持ちになりそう

    • 「ゼロショットの新規プロジェクトを当てるのは小さなモデルにも比較的簡単」という話と直接関係はないが、昔は概念実証を1つ立ち上げるのに1週間かかり、こういう文は純粋なSFのように聞こえた時代があった
    • 小さなモデルを評価する際、標準的なサンプルコードから外れるほど弱点がよりはっきり表れる点は過小評価されている
      Qwen3.6 は、どこにでもある単純なアプリでは小型モデルとしては驚くような結果を出した
      React TODO アプリや shadcn のような人気ツールで小さなボイラープレートアプリを作らせると、かなりそれらしい結果を出す
      しかし一般的な作業を外れて、自分のよりニッチな作業に入ると、何時間も堂々巡りした末に、結局うめき声が出るような使えない結果を出した
      単純なリファクタリングや、非常に明確な指示を与えた小さな作業でタイピングを代行させる用途ならかなりうまくやる
      しかし長いコンテキストのセッションや非主流のトピックに入ると、弱点は非常に明白になる
      小さなハードウェアに合わせるためによく使われる量子化も問題を悪化させる
      オンラインでは 4-bit 量子化はほぼ無損失で、q8_0/q8_0 のキー・バリューキャッシュ量子化も実質的な損失はないという雰囲気があるが、実際のプロジェクトでは、こうした量子化は長いコンテキストでの性能をかなり落とした
    • 業務開発で pi と以前の codex cli を Qwen 3.6 27B 100k コンテキストと併用してきたが、うまく動く程度に非常に驚いた
      完璧ではないが、普段の開発フローを加速するには十分で、主に Go と C# の記述に使っている
    • Gemma 4 12B級モデルでうまくいく作業がいくつかある
      小さなライブラリ群で構成された大きなプロジェクトを設計し、それぞれを独立してコーディング・テストできるようにすること、古いコーディングプロジェクトの整理、README の追加、コードへのコメント付け、新しい API の使用例を示して API の使用箇所を更新する、といった作業
      いずれも小規模な作業だ
      大きな統合プロジェクトでは、DeepSeek v4 Pro の商用 API が非常に安価で、良い結果を出すのに役立っている
    • 自分の経験では、小さなモデルは基本的なプロジェクト概念でも新規プロジェクトの開始に苦労する
      下さなければならない判断が多すぎて、それがうまくできない
      賢くやってくれることを期待しないなら、既存コードの修正のほうがはるかに簡単
      「X 機能を追加して」と言ってコードベースを探索させるのではなく、関連ファイルを指定したうえで「このコードに X 機能を追加するのが目的で、Y の指針に従って」と言うほうがよい
      最も難しい判断の部分を人間が処理すれば、モデルは指示に従って線の内側を塗るだけでよい

  • オフラインで 48GB メモリの MacBook Pro でこのモデルを動かすと作業はこなすが、当然 Claude や Codex よりは遅い

  • 数千ドルもする 128GB MBP を買って、最先端より客観的にはるかに劣るモデルを動かしているのを見ると、気が変になりそうな感じがする
    128GB M5 MAX に使う金額なら、こちらでは新車も買える
    自分が何を見落としているのか分からないし、他国の開発者は本当にこんなに違う世界に住んでいるのかと思う
    自分の住む場所では米国より絶対価格もさらに高いことは分かっていて、だからなおさらそう感じる
    正気の人が別の国でこういうものを買ったなら、こちらに到着するやいなや売ってお金を節約すると思う

    • ノートPCのフォームファクターに行くのは愚かだと思う
      去年の秋に中古の 3090 を2枚でワークステーションを組み、それぞれ 850 カナダドルを払ったが、今は最安値が 1200 くらい
      48GB VRAM ならかなり妥当で、Qwen 3.6 27B をテキストコーパスから知識グラフを作って推論する複数の作業に使っている
      OpenRouter で可能なものと比べてみたが、トークン費用 $0 という条件ではローカルの 27B Qwen に勝つのは難しい
      より遅く、オフィスが数度暖かくはなるが、誰にもプラグを抜けず、肩越しに監視されず、結果は最先端モデルに近い水準
      同じくらいのサイズの Qwen 3.7 に期待している
      これまで見た限りでは、前バージョンからの大きな飛躍だ
    • この価格帯の人たちが、GPU 搭載のデスクトップではなくMac ノートを買う理由が理解できない
      持ち運べることを誇示したいのかと思ってしまう
    • 自分の帳簿上ではすでにかなり価値が上がっている資産で、今後7〜10年のあいだ購入価格で再販できる可能性が高い
      Apple の月払いなので $5k は1年間、月 $416 で、利息もない
      DS4級モデルや他の公開モデルを、量子化なしで、ときには複数同時に動かせる
      台湾・中華圏での戦争、あるいは世界的な接続性や商用モデルの信頼性に関する暗いシナリオが起きたときの価値を想像してみてほしい
      歴史上の別の時点では作るのが非常に難しい装備で、もっと買っておけばよかったと思う
      シグナルと価格トレンド、品切れをリアルタイムで見ていたし、余裕のある他の人たちもきっと備蓄しているはず
    • その通り、多くの人にとって6千ドルははした金だ
    • そうだ
      あなたの側の人たちは、米国人より所得が一桁以上低い

  • ローカルモデルを動かすハードウェアが高いという話は多いが、Apple製品に興味がないなら、かなりコスパが良さそうな Intel Arc Pro B50/B60/B70 はあまり言及されていない
    最近、B70の32GB RAMモデルを米国外の居住地基準で消費税と関税込み約$1200で買ったが、地域によってはもっと安いかもしれない
    メモリ帯域幅は608GB/s
    M5 Maxの32コアGPUは460GB/s、40コアGPUは614GB/sで、3090は約900GB/sと依然として速いが、同クラスのNvidiaカードよりはるかに安く32GB VRAMを得られる
    5090の約1/3の帯域幅を1/3の価格で得つつ、同じ32GB VRAMを持つ形なので、より大きな量子化モデルとある程度のコンテキストを低予算で動かしたいなら魅力的な妥協点だ
    まだローカルモデルを探っている段階なので、テストに$5000〜$10000相当を使いたくはないし、もっと安く実験できるなら多少遅い性能でも構わない
    最初は70W TDPのB50 16GBを買って自分のスタックでIntelカードを試したが、UbuntuとVulkanで簡単に動作した
    面倒で使い物にならないという投稿をよく見たが、たいていSYCL関連のようで、SYCLがVulkanより性能が良さそうにも見えないのに、あえて使う理由はなさそうだ
    B50は税金と関税込みで$370で、文字通りVulkanライブラリを apt install したら、26.04の標準xeドライバとllama.cppのVulkanビルドで動作した
    SR-IOV PF/VF もqemu/kvmで特別な小細工なしに動作し、購入後にfwupdmgrがファームウェアを2回更新したので、Intelはこれらの製品を本気でサポートするつもりのようだ

  • 今のスイートスポットは 3090を2枚 とPCIe 4マザーボード、64〜128GB DDR4 RAMの組み合わせだと思う
    今なら$3k程度で組めて、Qwen 27B/35Bをint4で非常に高速に動かせる

  • 参考までに 5090 でgemma4 31Bを動かしているが、かなり優秀
    QAT、MTP、128kコンテキストを使っている
    Qwen 3.6 27Bも良かったが、Gemma4は少し過小評価されている気がする

    • 自分の経験も似ている
      4090でllm.cppとunslothモデルを使って gemma4 31B を動かしている
      Qwen 3.6も併用しているが、Qwenはより速いので思考や計画に向いていて、Gemma4は最初の試行で生成されるコード品質がずっと高い
      Rust、C++、C#基準で、マージしてもよいと感じるレベルまでに必要な修正が少ない
    • Gemma4にターンをきちんと終了させられずにいる
      いつも突然途切れるか、誤ったツール呼び出しを作ってしまい、おそらくoMLXかOpencodeの設定を自分が間違えているのだと思う
    • 良い
      4080 Superで Qwen 3.5 9B Q6_M とGemma4 12B Q4_K_Mを行き来して使っている
      両者は速度が似ていて、互いの計画や変更差分をレビューさせられる
      小さなプロジェクトではかなり有能で、少し難しい作業にはより良い量子化に上げられる

  • ユニファイドメモリのコンピュータ を買いに行く前に、例えばDGX Spark、Mac、Ryzen AI Max 395 / Strix Haloのような機器では、密モデルは概して遅いという点を知っておくべき
    専用GPUの方が密モデルをはるかにうまく動かせる
    買う機器のベンチマークを探すのがよく、本当にこうした機器が欲しいなら、Qwen 3.6 35Bや他の疎なMoEモデルを動かす方がよい

  • M3 Max 64GB RAM 16インチMacBook Pro でopencodeを使ってqwen 3.6 35b a3bを動かしてきたが、ローカルでの計画・コーディング用途には非常に良かった
    正直、64GBがこれほど強力なのを見ると、128GBにして将来に備えるべきだったのではと思うことがある
    一方で、qwenより少し大きいモデルが原因で壁にぶつかったこともまだない

    • WindowsノートPCでも Qwen 3.6 35B A3b を動かしているが、64GB RAMと4GB GPUの組み合わせで少なくとも我慢できる程度ではある
      速くはなく、秒間数トークンで、読む速度より遅いが、作業を投げておいて後で戻ればよい
      数年前にeBayで買った$600のノートPCであって、$6000のマシンではない
      ユニファイドメモリのMacや巨大な24GBデスクトップGPUが、10〜20倍のコストに見合う秒間数十〜数百トークンを出しているのか気になる
    • 応答速度がどのくらいか気になる、秒間トークン基準で
      経験上、20〜35GBモデルとキー・バリューキャッシュだけでも標準の64GBをかなり食うので、ブラウザやエディタなど他のものを常に起動しておくなら、128GB全体が間違いなく役に立つ