ハクソク

世界を動かす技術を、日本語で。

HNに聞く: 消費者向けハードウェアに最適なLLMは何ですか？

360日前

概要

  • 5060ti と 16GB VRAM 環境に適した会話モデルの選定
  • 基本的な会話のみ、 物理や高度な数学は不要
  • リアルタイム に近い速度で動作するモデルを希望
  • 推奨モデル とその特徴を紹介
  • 導入時のポイント も簡潔に解説

5060ti + 16GB VRAMに最適な会話AIモデル

  • Llama 2 7B や Mistral 7B などの 7Bパラメータ クラスのモデルが推奨
    • 16GB VRAM で十分動作可能
    • 基本的な会話や簡単な質問応答に適合
  • リアルタイム性 を重視するなら 量子化(Q4, Q5など) 済みモデルを選択
    • ggml や gguf フォーマットで配布されている量子化版が多数存在
  • Llama.cpp や Ollama などの軽量ランタイムでローカル実行が容易
    • Windows, Linux 両方対応
  • Japanese 対応が必要なら ELYZA-japanese-Llama-2-7b-instruct や OpenCALM 7B も選択肢
    • 日本語会話の自然さを重視する場合に有効
  • 導入手順
    • モデルファイルのダウンロード
    • Llama.cppやOllamaのセットアップ
    • コマンドラインやWeb UIで対話開始

モデル選定の注意点

  • 13B以上のモデル は VRAM不足 で動作困難
  • 8B未満のモデル （例: Llama 2 3B）は 会話性能が低下 しやすい
  • 量子化 により 精度低下 の可能性もあるが、日常会話用途では大きな問題になりにくい
  • 日本語モデル は英語モデルに比べて選択肢が少ないため、用途に応じた選択が必要

おすすめ実装例

  • Llama.cpp + Llama 2 7B Q4_0量子化版
    • 軽量で高速、日常会話に最適
  • Ollama + Mistral 7B Q4量子化版
    • セットアップが簡単、Web UI対応
  • ELYZA-japanese-Llama-2-7b-instruct
    • 日本語会話重視の場合に最適

まとめ

  • 5060ti + 16GB VRAM 環境では 7B量子化モデル が現実的
  • Llama 2 7B や Mistral 7B、 ELYZA-japanese-Llama-2-7b-instruct が主要候補
  • 量子化モデル で リアルタイム対話 が十分可能
  • 導入は簡単 で、軽い用途なら十分な性能

Hackerたちの意見

現在、VRAMは8GBしかないけど、OpenWebUIを使ってollammaのフロントエンドを動かしてるんだ。複数のモデルを同時にロードして戦わせるのがめっちゃ楽だよ。ラウンドロビンでもできるし、時間とともに回答の質を追跡して選択の参考にすることもできるよ。 https://openwebui.com/

└

最近の「Open」WebUIのライセンス変更に注意してね。もうオープンソースじゃなくなったよ。

└

AMD 6700XT持ってるよ（12GB VRAM） - 確認済み。ローカルのROCm設定を理解したら、OllamaはGPUアクセラレーションで問題なく動いたよ。OpenWebUIのDockerインスタンスをローカルのOllamaサーバーに接続するのも、OLLAMA_BASE_URLの環境変数を指定するだけで簡単にできる。これは本番環境じゃないけど、親のコメントが言ってるようなローカル利用にはうまく機能するよ。

LLMをローカルで動かしたいなら、localllamaコミュニティが頼りになるよ: https://old.reddit.com/r/LocalLLaMA/ 一般的に「これが一番！」ってモデルはないから、どれも強みと弱みがあるんだ。いい選択肢がたくさんあるよ。例えば: > DeepSeek-R1-0528-Qwen3-8B - https://huggingface.co/deepseek-ai/DeepSeek-R1-0528-Qwen3-8B 今日リリースされたばかりで、8Bサイズの中では多分一番の推論モデルだよ。 > Qwen3 - https://huggingface.co/collections/Qwen/qwen3-67dd247413f0e2... 最近リリースされたやつで、ハイブリッドな思考/非思考モデルで、性能がすごく良いし、どんなハードウェアにも合うサイズがたくさんあるよ。Qwen3-30B-A3BはCPUでも許容できる速度で動くし、0.6Bの小さいやつでもそこそこ整合性があって、マジで驚きだよ。

└

DeepSeek-R1-0528-Qwen3-8B https://huggingface.co/deepseek-ai/DeepSeek-R1-0528-Qwen3-8B ... 今日リリースされたばかりで、多分8Bサイズの中では一番の推論モデルだよ。... DeepSeek-R1-0528から思考の連鎖を抽出して、Qwen3-8B Baseをポストトレーニングした結果、DeepSeek-R1-0528-Qwen3-8Bが得られたんだ。AIME 2024でQwen3-8Bを+10.0%上回り、Qwen3-235B-thinkingの性能に匹敵するんだ。蒸留がこんなに効果的だとは驚きだね。そりゃ、ほとんどのショップがCoTを「隠す」ようになったのも納得だよ: https://news.ycombinator.com/item?id=41525201

└

今日リリースされたばかりで、多分8Bサイズの中では一番の推論モデルだよ。実際、DeepSeek-R1-0528-Qwen3-8Bは木曜日（昨日）の11 AM UTC / 7 PM CSTにアップロードされたんだ。新しいバージョンが出たか確認しなきゃならなかったよ！他のサイズも待ってるんだ！;D

└

8Bくらいのモデルを選ぶのをおすすめするよ。そうすれば、他の8GBのVRAMを使って、そこそこのサイズのコンテキストウィンドウが持てるからね。上で言ったように、いい8Bモデルがたくさんあるよ。最大のモデルを選ぶと、トークンを多く渡すことになるから、推論が遅くなって、コンテキストも小さくなるよ。

└

そうだね、今のところはモデルの個性が気に入るかどうかって感じになってきてる。どれもそこそこ良いから、OPはまずダウンロードして試してみるべきだよ。16GBあれば、llama.cppで部分的なDDR5オフロードができて、30B（密なものでも）までのものをチャット用に「まあまあ」な速度で動かせるよ。特にテンソルオフロードがあるしね。ただ、Qwenはあんまり会話向きじゃないかな。Mistral NemoとSmallはかなり良いよ。Llama 3.Xは今の基準でもまだまだ優秀なモデルだし、Gemma 3sは素晴らしいけどちょっと変わってる。もちろん、家でGPT4が必要な時はQwQもね。他にも忘れてるものがたくさんあると思う。

└

LLMをローカルで動かしたいなら、localllamaコミュニティが味方だよ: https://old.reddit.com/r/LocalLLaMA/ Redditに不慣れな人には、LocalLlamaは他のインターネットと同じく、特にredditでは誤った「事実」を真実として広める誤解のある人たちが多いことに注意が必要だよ。そこでの品質や真実性を示す指標として、アップボート/ダウンボートの数を使うのはあまり良くない。もっと正確だけど退屈な表現はしばしばダウンボートされ、逆に間違ってるけど面白い/感情的なコメントはアップボートされやすい。ネットで長い時間を過ごしてきた私たちには、この手のバカバカしい検出器がほぼ組み込まれてるけど、redditのように集団思考が強い場所に新しく来た人には、何でも鵜呑みにしない方がいいよ。

└

AiderやRooを使ってコーディングするのにおすすめはある？ツールを効果的に使えるモデルを見つけるのが時々難しいんだよね。

└

先日、llama-cppを使って特定のテンソルをCPUにオフロードして、良いパフォーマンスを維持できるっていう素晴らしい投稿があったよ。これって、一般的なハードウェアで大きめのモデルを使うのにいい方法だね。通常、llama-cppではGPUにどれだけの（フル）レイヤーを入れるか指定するけど、重い計算を必要としない特定のテンソルをCPUにオフロードすることで、GPUのスペースを節約できて、速度にもあまり影響しないんだ。あと、「ホット」なニューロンだけをCPUに読み込むっていう論文も読んだことあるよ。家庭用AIの未来はすごくクールだね！

みんなはローカルのLLMを主に何に使ってるの？パワフルなマシンがないと、GeminiやClaudeみたいなプロプライエタリモデルのクオリティには絶対に届かないけど、これらの小さいモデルにも使い道があると思うんだ。ただ、具体的に何に使うのかはよく分からないな。

└

ローカルLLMの未来は「委任」だと思う。プロンプトを与えると、すぐにその解決に必要なものを特定してくれるんだ。ローカルで動いているMCPで解決できるのか？それともカレンダーを読んだり、メールをチェックしたりするようなシステムAPIなのかな？それとも、最適なクラウドモデルを特定して、プロンプトをそこに送るのかも。要するに、良いSiriみたいな感じだね。

└

みんなが自分のデータや質問、プロンプトを外部に送るのに抵抗があるのも分かるよ。

└

今、自分で少しずつ作り上げたローカルコーディングエージェントのためにDevstralを試してるんだ。Codexよりもいくつかの点で優れていて、1) ハードウェアにフルアクセスできるから、VMを立ち上げたり、ネットワークリクエストを送ったり、Codexではできないことができるし、2) 初期設定や作業、パッチ作成がめちゃくちゃ速い。もちろん、Codex自体のモデルには敵わないけど、Codexが使ってるモデルは本当に優れてるから、結果も良くなるよね。でも、今の使い方だとDevstralは小さな変更やリファクタリングができるし、もう少し進化させれば、大きな変更もできるようになると思う。

└

もしパワフルなマシンを持っていないなら 平均的な人はr/locallamaのマシンを見たらr/pcmasterraceのユーザーが赤面するだろうね。

└

ローカルのものでも decent な結果は得られるよ。主にAPIを通じてツールや統合のテストに使ってるから、サブスクリプションにお金を使いたくないんだ。何かがうまく動いてるのを見たら、ベストな結果を得るためにプロプライエタリなものに切り替えるよ。

└

大体のプロンプトでは、まずローカルモデルを試すようにしてる。意外と十分な結果が得られることが多い（確実に50%以上）。クラウドサービスを使わないことができるたびに勝利だね。

└

locallamaを見てみると、ほとんどの人がNSFWや他の怪しいことをしようとしてるだけだよ。普通の家庭用ハードウェア（例えば、単一のGPU）で動かせるものは、そんなに驚くようなものじゃない。GPT-3.5にかなり近いけど、使い慣れたものと比べると古臭くて使いにくい感じがするよ。もしゲーム用に高いGPUをすでに買ってないなら、家庭用にGPUを買うのはあまり意味がないと思う。vast.aiみたいなサイトで、超安く借りて試せるからね。子供の大学資金をH100のラックに使わなくて済んで、退屈しないで済むと思うよ。

└

これはローカルLLMのアプリケーションの素晴らしい例だね。これは、UIUCのコンピュータ入門コース（ECE 120）をサポートするために設計されたAI駆動のチャットシステムで、コース内容や宿題、一般的な問題のトラブルシューティングを手伝ってくれる。UIUCの学習環境に統合された教育支援ツールなんだ。個人的には、コースの学習資料の詳細部分を提供してくれるのがすごく便利だと思う。学生がLLMが提供する答えの信憑性を確認できるからね。RAGはローカルLLMのキラーフィーチャーだと思う。LLMの幻覚の問題を直接解決して、事実に基づいた回答を提供してくれるからね。

└

一般的なローカル推論の強み: - 推論レベルの制御を使った実験ができる。ほとんどのAPIサービスではアウトラインやインストラクターの機能ができないし、高度なサンプリング戦略もできない（追いついてきてるけど、ローカルでできることには12ヶ月遅れてる）。 - 小型で高速、ファインチューニングされたモデル。ドメインを十分に理解してモデルを訓練できれば、他のものを上回ることができる。一般的なモデルは通常勝つけど、プロンプトエンジニアリングの容易さのためだけではない。 - どのモデルを実行するかの制御ができる。リアルワールドのデータが変わるとドリフトは避けられないけど、モデルも変わっていると持続可能なものを構築するのが難しくなる。 - コストの制御がより可能。これはクラウドとオンプレミスの古典的な選択。ほとんどの場合、クラウドにお金を払いたいだけだけど、もうZIRPの時代じゃないから、予測可能な電気代が突然のAPI料金を上回ることもある。一般的に、クラウドサービスへの移行は、元々はGPT-3を閉じ込めるための冷酷なOpenAIの動きだった。彼らは、クラウドモデルを好む理由をたくさん作り上げてきた（大幅に補助された高速推論、最大かつ最先端のモデルなど）。だから、今すぐ最新かつ最高のものが必要で、支払う意欲があるなら、ほとんどのビジネスにとって正しい選択だと思う。エッジデバイスで合理的に動作できるモデルが出てくると、これは変わるだろう。今は、LLM技術を偶然に使うアプリやビデオゲームを構築するのが難しい。ユーザー収益が推論コストを超えることはあまりないから、慎重な計画やサブスクリプションが必要だ。無理ではないけど、ビジネス上の課題が増える。エンドユーザーのデバイスで動作する小型モデルは、コスト効果の面で全く新しいレベルのアプリケーションを開く。正しい答えが必要な場合、時には最大のクラウドAPIモデルしか受け入れられないこともある。もし精度に余裕があって、時々不十分な応答を受け入れられるなら、選択肢はもっと広がる。LLMが最も得意とすることは、常に五九の信頼性が許容されるタスクだから、最大のモデルがより信頼性が高いとはいえ、平均的には小型で高速なモデルで十分な場合も多いよ。

└

原則として、できるだけクラウドは使わないようにしてる。例えば、OpenAIが最近、ChatGPTユーザーがチャットを共有できるようなソーシャルネットワーク的なサービスに取り組んでいるって言ってた。ローカルで動かすことで、こういうものが裏でどう動いてるのか理解できるし、仕事市場での価値も上がる。LLMをバックエンドに使った色々なアイデアにも挑戦してる（LLMを使ったWeb検索とかエージェントとか）、クラウドプロバイダーにお金を払う必要もないし、LLaMaが出たときにはすでにゲーミングPCを持ってたからね。

基本的な会話は、実質的にRPだと思う。KoboldCPPやSillyTavernのredditを見てみて。最近、Patricide unslop mellやいくつかのQwenのものを試してた。ある程度までは、パラメータが多い方が量子化を気にするよりも良いけど、最終的には高パラメータで計算の壁にぶつかるよ。KVキャッシュの量子化は素晴らしい（32kコンテキストで1080tiにq4を使ってる！）し、長い会話やストーリー、ゲームにはコンテキストシフトもすごく良い。Oobaを使ってたけど、最近KoboldCPPが同じモデル/設定でより速く動くし、KoboldのコンテキストシフトがOobaの「streaming_llm」オプションよりも一貫して動作することがわかったよ。Oobaはほぼ常にプロンプトを再評価するからね。

16GBなら、Mistral Small 3.1のQ4量子化や、FP8のQwen3-14Bが一番良いと思う。VRAMの使用量のせいでコンテキスト長がちょっとギリギリになるかも… もっと長いコンテキストが欲しいなら、Qwen3-14BのQ4量子化はFP8よりも少し劣るけど、余裕ができるよ。Mistral Smallは画像を入力として受け取れるし、Qwen3は数学やコーディングが少し得意だね。他は人それぞれかも。Q4未満は、私の意見では価値がないよ。もっとコンテキストが必要なら、14BをロボトミーするよりもQwen3-8BのQ4量子化に切り替えた方がいいかも。Qwen3-30B-A3を勧めてる人もいるけど、16GBのVRAMじゃちょっと足りないと思う。Q4だと重みだけで15GB必要だからね。Qwen3-14Bはパラメータ数が少なくても実際にはかなり似たような性能だと思う。密なモデルだから、密なモデルは一般的にスパースモデルよりもパラメータあたりの知能が高いけど、少し遅い。5060なら14Bには十分な速さだと思うけど、すべてをGPU上で動かしてCPUオフロードは避けた方がいいよ。Blackwell世代のNvidiaチップを使ってるなら、特にNVFP4に量子化されたLLMを使うことで、FP8に比べていくつかの速度向上が得られるけど、品質は少し犠牲になるかも（Q4 GGUFよりも速いけど、ほぼ同じくらいの知能）。OllamaはまだNVFP4をサポートしてないから、vLLMを使う必要があるよ（そんなに難しくないし、トークンのスループットも良くなる）。NVFP4で事前に量子化されたモデルを見つけるのは難しいかもしれないけど、llmcompressor [1]を使ってFP16 LLMをローカルでNVFP4に静的に圧縮できるよ — 一度だけCPUにパラメータをオフロードする必要があるから、accelerateを使う必要があるけど、llmcompressorにはそのためのドキュメントがあるよ。この特定のパワーツールには、すでにLLMを決めていて、ただパフォーマンスを速くしたい時に手を出すべきだと思う。初期の量子化プロセスは圧縮中にCPUオフロードがあるから遅くなるけど（それでも一度きりのコストだけどね）。でも、Q4モデルに決まったら、好きなモデルができた時には悪くない選択だよ。 1: https://github.com/vllm-project/llm-compressor

コメントでMozillaのLocalScoreがまだ言及されてないね。これは、異なるハードウェアでどのモデルがどれだけ動くかを調べるために作られたものなんだ。

Qwen3ファミリー（R1 qwen3-8b distill）は、プログラミングと推論の分野で1位だね。ただ、中国製のせいで政治的な話題に関してはかなり検閲されてる。世界知識についてはGemma3をおすすめするよ。この投稿は1ヶ月後には古くなるだろうね。最新のベンチマークは、https://livebench.ai と https://aider.chat/docs/leaderboards/ をチェックしてみて。

└

この投稿は1ヶ月後には古くなるだろうね。 変化のスピードは驚異的だよ。モデルだけじゃなく、それを使うためのツールもね。ルーター、ツール、MCP、ストリーミングライブラリ、SDK... 一人で開発していて、同僚やミートアップに囲まれていない人にアドバイスはある？

LocalLLamaのサブレディットをおすすめするよ。最適なモデルを選ぶためじゃなくて、質問に答えたり、ガイドを見つけたり、最新ニュースやゴシップ、ツールの名前、さまざまなモデルの比較をするためにね。「最高の」モデルはないから、いくつか試してみて、パラメータをいじってみて、自分に合ったものを見つけるのが一番だよ。HNにいるなら、OllamaやLMStudioはスキップした方がいいかも。最新モデルへのアクセスが制限されることが多いし、彼らがテストしたものしか選べないからね。それに、内部を覗けないのは面白くないでしょ？ llamacppは自分でいろいろできるし、最近リリースされたモデルも動かせるよ（必要な変更があれば、数日で調整されるし）。huggingfaceからモデルを取得するのはもちろん。GGUFフォーマットが好きで、メモリを節約できるし（低い量子化を使えるから、6ビットのものは結構満足できる）。モデルのGGUFファイルのサイズが、おおよそVRAMに収まるかどうかを教えてくれる。例えば、24GbのGGUFモデルは16Gbには収まらないけど、12Gbなら収まる可能性が高い。ただ、コンテキストを追加すればするほど、RAMが必要になるから注意してね。モデルは特定のコンテキストウィンドウで訓練されているから、8Kbのコンテキスト（ほとんどの古いモデルはこれ）を持っていて、32Kbのコンテキストを読み込むとあまり役に立たないよ。llamacppはLinux、Windows、MacOSで動かせるし、バイナリを取得するか、ローカルでコンパイルできるよ。モデルが16Gbに収まらない場合、VRAMとRAMの間でモデルを分割できるし、シンプルなReactフロントエンド（llamacpp-server）もある。これと同じモジュールがRESTサービスを提供していて、OpenAIや他の「大手」と似た（でも簡単な）プロトコルを持ってる。OpenAIのREST APIを実装しているから、もっと機能が欲しいなら多くのフロントエンドツールとも連携できるよ（例えばoobabooga、別名textgeneration webui）。もしllamacppが生々しすぎると感じたら、Koboldcppという別のバックエンドも試してみて。

└

なんでOllamaをスキップするの？HuggingFaceからGGUFを直接引っ張ってこれるよ。例えば：ollama run hf.co/unsloth/DeepSeek-R1-0528-GGUF:Q8_0

└

HNにいるなら、OllamaとLMStudioはスキップすることをおすすめするよ。私は反対だね。Ollamaを使えば、デスクトップをLLMサーバーとして設定できて、他のデバイスからWiFi経由でやり取りできるし、モデルを切り替えたいときにOllamaがスムーズにモデルを切り替えてくれる。最近何かが変わったわけじゃない限り、llama.cppのCLIでは、サーバーモードで動かしていてもモデルを切り替えるためには、シャットダウンして別のコマンドラインフラグで再起動しなきゃいけないんだ。そのオーバーヘッドは実験の妨げになるし、アプリケーションにも制限をかけることがある。1Bと8Bまたは30Bモデルの間をすぐに切り替えられるように、ウェブリクエストのモデルパラメータを変えるだけで動かせる小さなアプリも作ったことがあるよ。

基礎モデルと同じツール使用（特にウェブ検索）ができるローカルモデルって誰か知ってる？そんなに良くはないだろうけど、推論中に検索できるのは結構便利だと思うんだよね。