AI Tips の履歴(No.1)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• AI Tips へ行く。
  • 1 (2026-08-28 (金) 13:22:57)

MenuBar

1. 名前の読み方（命名規則）

Qwen2.5 -Coder -14B -Instruct
[ベース系統] [特化用途] [サイズ] [チューニング種別]

系統名：開発元・世代（Qwen2.5, Llama-3.1, Gemma-2, DeepSeek-V2など）
特化タグ：Coder（コード特化）、Math、Vision など。無印は汎用
サイズ(B)：パラメータ数（10億単位）
チューニング種別：Instruct/Chat＝指示追従用に調整済み（基本これを使う）、Base＝素の事前学習モデル（自分でチューニングしない限り使いにくい）

MoEの場合は 30B-A3B のような表記になります。A3B は「Active 3B」＝活性化パラメータ数。総容量は30B分必要だが、計算量は3B相当という意味です。

2. 量子化タグの意味（GGUF形式）

ダウンロード先でよく見る Q4_K_M のようなファイル名の読み方：

実用目安：Q4_K_Mが「サイズと精度のバランスが良い定番」、Q8_0はほぼ無劣化だが重い、Q3以下は応答品質の劣化が体感で分かり始めます。迷ったらまずQ4_K_Mでよいです。

3. どこで確認するか（具体的な情報源）
Hugging Faceのモデルカード：config.jsonにnum_hidden_layers、hidden_size等の詳細スペック。
トップに総パラメータ数が明記されていることが多い
GGUF配布ページ（bartowski、unsloth、lmstudio-community等のアカウントが変換版を公開）：量子化レベルごとの実ファイルサイズ表があり、
これが一番早い確認方法（例：DeepSeek-Coder-V2-Lite-GGUFのページなど）
ollama.com/library：各モデルページのタグ一覧にサイズ・量子化・パラメータ数が一覧表示される
ベンチマークサイト：コード用途ならSWE-bench・LiveCodeBench・Aider Polyglot Benchmark、
汎用なら Open LLM Leaderboard、日本語なら Nejumi Leaderboard

4. VRAM/RAM見積もりの計算式（実践）
必要メモリ ≈ パラメータ数(B) × バイト/パラメータ + KVキャッシュ + オーバーヘッド
バイト/パラメータ：Q4系で約0.55〜0.65、Q8で約1.05、FP16で2
KVキャッシュ：コンテキスト長に比例して増える。長文・エージェント用途なら重みサイズの1〜3割増しを目安に確保しておくと安全
オーバーヘッド：推論エンジン分で数百MB〜1GB程度
5. MoEモデルは「容量」と「速度」を別の数字で見る
メモリに必要な容量 → 総パラメータ数基準（全エキスパートを保持する必要がある）
生成速度 → 活性化パラメータ数基準（実際の計算量はこちら）

帯域が制約される環境（GPD Win4のような機体）では、この差が大きく効くというのが前回までの結論でした。

6. 実際の選定チェックリスト
用途を決める（コード生成／汎用文書／日本語重視 など）
その用途のベンチマークで候補を2〜3個ピックアップ
GGUF配布ページで量子化ごとのファイルサイズを確認
自分のVRAM/RAMに収まる量子化レベルを選ぶ（できればQ4_K_M以上を確保）
想定するコンテキスト長（コーディングなら長め推奨）に対してKVキャッシュ分の余裕があるか再確認
ライセンスを確認（Apache 2.0/MITか、商用利用に制限のある独自ライセンスか）

メモリ目安表（Bサイズ→GB早見表）
パラメータ数(B)から、量子化レベル別のおおよその必要メモリです。
個別モデル名を調べなくても、この表と簡易計算式でだいたいの当たりがつけられます。