license: apache-2.0 library_name: transformers pipeline_tag: text-generation

Fin-R1 GGUFモデル

適切なモデルフォーマットの選択

適切なモデルフォーマットを選択するには、ハードウェアの性能とメモリ制約を考慮する必要があります。

BF16（Brain Float 16）– BF16アクセラレーションが利用可能な場合に使用

• 高速な計算を可能にしつつ、良好な精度を維持する16ビット浮動小数点フォーマットです。
• FP32と同様のダイナミックレンジを提供しながら、メモリ使用量を削減します。
• BF16アクセラレーションをサポートするハードウェア（新しいGPUやTPUなど）での使用が推奨されます。
• FP32と比較してメモリフットプリントを削減しつつ、高性能な推論を実現します。

📌 BF16を使用する場合:
✔ ハードウェアがBF16をネイティブサポートしている（例: 新しいGPU、TPU）。
✔ 高い精度を維持しつつメモリを節約したい。
✔ モデルを別のフォーマットに再量子化する予定がある。

📌 BF16を避ける場合:
❌ ハードウェアがBF16をサポートしていない（FP32にフォールバックし、速度が低下する可能性がある）。
❌ BF16最適化がされていない古いデバイスとの互換性が必要。

F16（Float 16）– BF16よりも広くサポートされている

• 16ビット浮動小数点フォーマットで、高い精度を提供しますが、BF16よりも値の範囲が狭いです。
• FP16アクセラレーションをサポートする多くのデバイス（GPUや一部のCPU）で動作します。
• BF16よりも数値精度はわずかに低いですが、一般的に推論には十分です。

📌 F16を使用する場合:
✔ ハードウェアがFP16をサポートしているが、BF16はサポートしていない。
✔ 速度、メモリ使用量、精度のバランスが必要。
✔ GPUやFP16計算に最適化されたデバイスで実行する。

📌 F16を避ける場合:
❌ デバイスがネイティブFP16サポートを欠いている（予想よりも遅くなる可能性がある）。
❌ メモリ制約がある。

量子化モデル（Q4_K、Q6_K、Q8など）– CPU & 低VRAM推論用

量子化により、モデルサイズとメモリ使用量を削減しつつ、可能な限り精度を維持します。

• 低ビットモデル（Q4_K） → メモリ使用量が最小、精度が低い可能性あり。
• 高ビットモデル（Q6_K、Q8_0） → 精度が向上、より多くのメモリを必要とする。

📌 量子化モデルを使用する場合:
✔ CPUで推論を実行し、最適化されたモデルが必要。
✔ デバイスのVRAMが低く、フル精度モデルをロードできない。
✔ 合理的な精度を維持しつつ、メモリフットプリントを削減したい。

📌 量子化モデルを避ける場合:
❌ 最大の精度が必要（フル精度モデルの方が適している）。
❌ ハードウェアがより高精度なフォーマット（BF16/F16）に対応する十分なVRAMを持っている。

超低ビット量子化（IQ3_XS、IQ3_S、IQ3_M、Q4_K、Q4_0）

これらのモデルは極端なメモリ効率を実現し、低電力デバイスやメモリが重要な制約となる大規模展開に最適です。

• IQ3_XS: 超低ビット量子化（3ビット）で極端なメモリ効率を実現。

  • 使用例: Q4_Kでも大きすぎる超低メモリデバイスに最適。
  • トレードオフ: 高ビット量子化と比較して精度が低い。

• IQ3_S: 最大のメモリ効率を実現する小さなブロックサイズ。

  • 使用例: IQ3_XSが過剰な低メモリデバイスに最適。

• IQ3_M: IQ3_Sよりも精度が向上した中ブロックサイズ。

  • 使用例: IQ3_Sが制限となる低メモリデバイスに適している。

• Q4_K: 4ビット量子化でブロック単位の最適化により精度を向上。

  • 使用例: Q6_Kが大きすぎる低メモリデバイスに最適。

• Q4_0: 純粋な4ビット量子化で、ARMデバイスに最適化。

  • 使用例: ARMベースのデバイスや低メモリ環境に最適。

モデルフォーマット選択のまとめ表

含まれるファイルと詳細

Fin-R1-bf16.gguf

• BF16で保存されたモデル重み。
• モデルを別のフォーマットに再量子化したい場合に使用。
• デバイスがBF16アクセラレーションをサポートしている場合に最適。

Fin-R1-f16.gguf

• F16で保存されたモデル重み。
• FP16をサポートするデバイスで、BF16が利用できない場合に使用。

Fin-R1-bf16-q8_0.gguf

• 出力と埋め込みはBF16のまま。
• その他の層はQ8_0に量子化。
• デバイスがBF16をサポートし、量子化バージョンが必要な場合に使用。

Fin-R1-f16-q8_0.gguf

• 出力と埋め込みはF16のまま。
• その他の層はQ8_0に量子化。

Fin-R1-q4_k.gguf

• 出力と埋め込みはQ8_0に量子化。
• その他の層はQ4_Kに量子化。
• メモリが限られたCPU推論に適している。

Fin-R1-q4_k_s.gguf

• 最小のQ4_Kバリアントで、精度を犠牲にしてメモリ使用量を削減。
• 非常に低メモリ環境に最適。

Fin-R1-q6_k.gguf

• 出力と埋め込みはQ8_0に量子化。
• その他の層はQ6_Kに量子化。

Fin-R1-q8_0.gguf

• 完全にQ8量子化されたモデルで、より高い精度を提供。
• より多くのメモリを必要とするが、高精度を実現。

Fin-R1-iq3_xs.gguf

• IQ3_XS量子化で、極端なメモリ効率を実現。
• 超低メモリデバイスに最適。

Fin-R1-iq3_m.gguf

• IQ3_M量子化で、中ブロックサイズを採用し精度を向上。
• 低メモリデバイスに適している。

Fin-R1-q4_0.gguf

• 純粋なQ4_0量子化で、ARMデバイスに最適化。
• 低メモリ環境に最適。
• より高い精度が必要な場合はIQ4_NLを推奨。

🚀 これらのモデルが役立った場合

いいね ❤ をクリックしてください。また、私のNetwork Monitor Assistantをテストしていただけると非常に嬉しいです 👉 Network Monitor Assistant。

💬 チャットアイコン（メインページとダッシュボードページの右下）をクリックしてください。LLMを選択し、LLMタイプをTurboLLM -> FreeLLM -> TestLLMと切り替えます。

テスト内容

ネットワーク監視サービスに対する関数呼び出しを実験しています。小さなオープンソースモデルを使用しています。「どれだけ小さくても機能するか」という疑問に取り組んでいます。

🟡 TestLLM – llama.cppを使用し、CPU VMの6スレッドで現在のテストモデルを実行（約15秒でロードされます。推論速度はかなり遅く、一度に1つのユーザープロンプトしか処理しません—スケーリングについてはまだ作業中です！）。興味があれば、その仕組みを共有します！

その他の利用可能なAIアシスタント

🟢 TurboLLM – gpt-4o-miniを使用、高速！注意: OpenAIモデルは高価なためトークンに制限がありますが、ログインまたはダウンロードしてFree Network Monitorエージェントを入手すればより多くのトークンを取得できます。またはTestLLMを使用してください。

🔵 HugLLM – オープンソースのHugging Faceモデルを実行、高速、小さいモデル（≈8B）のため品質は低め、Hugging Face APIの利用可能性に応じて2倍のトークンを取得可能