8Bモデルのファインチューニングで精度76%達成：Tinkerを用いたプロンプト複雑度スコアリングのコスト対効果分析

はじめに：小規模モデルのファインチューニングにおける「精度」と「コスト」のジレンマ

LLMを業務に組み込む初期段階では、汎用モデルをそのまま使うゼロショット推論の精度が課題になるケースが多い。特にドメイン特化の判断を求められるタスクでは、プロンプトの工夫だけでは満足できる精度に届かないことが少なくない。

その解決策としてファインチューニングが検討されるが、70Bクラスの大規模モデルでは学習に数日単位でGPUを占有する必要があり、推論コストも高いため、中小企業やスタートアップにとって採算が合わない現実がある。一方、8Bクラスのモデルであれば、LoRA（Low-Rank Adaptation）などのパラメータ効率的な手法と組み合わせることで、比較的低コストでドメイン適応が期待できる。

本稿では、8BクラスのQwen3-8Bを対象に、Tinkerフレームワークを用いたファインチューニングの実測結果を提示する。ユースケースは「ユーザーリクエストの難易度を0.00〜1.00のスコアで推定する」プロンプト複雑度スコアリングである。ゼロショット状態で50%だった精度が、ファインチューニングにより76%まで向上し、平均絶対誤差も0.125から0.06に改善した実データをもとに、学習データ量と精度の関係性、および推論モードの最適化によるコスト削減効果を分析する。

読み終える頃には、「どの程度の学習データでどの程度の精度が得られるか」「推論コストをどこまで圧縮できるか」について、自社の予算感に照らして判断するための材料が得られるはずである。

前提：なぜ8Bモデルなのか？小規模モデル選定の技術的根拠

モデルサイズ選定の第一判断軸は、推論時に必要なGPUメモリ量である。70BクラスのモデルをBF16精度でロードすると数十GBのVRAMを要するが、8Bクラスであればその数分の1程度のメモリで動作する。これにより、高価なA100クラスではなく、低価格なクラウドGPUやオンプレミスの単一GPUで推論が可能になる。中小企業・スタートアップが「月々のインフラコスト」で判断する際、この差は採用可否を分ける水準である。

LoRAとHybrid設計の相性

8Bクラスをさらに有利にするのが、LoRAによるパラメータ効率的なファインチューニングである。モデルの全パラメータを更新するフルファインチューニングではなく、低ランクのアダプター行列のみを学習するため、学習に必要なメモリと計算量が大幅に削減される。本稿の実験では、Qwen3-8Bに対してLoRAアダプターを1エポック訓練するだけで、ゼロショット時の50%から実用的な精度への到達を確認している（DEVの解説記事）。

もう一つのポイントは、Qwen3-8BがHybridモデルとして設計されている点である。通常、生成（Text Generation）と分類（Classification）は別々のアーキテクチャ前提で設計されることが多いが、Hybridモデルは両方を同一の基盤で扱える。本件のスコアリングタスクのように「最終的な数値を出力する」場合、生成モードではなく分類モードで推論を完結させることができ、トークン逐次生成に伴う計算負荷を回避できる（DEVの解説記事）。

「実装可能で運用可能な精度」を基準にする

本記事の対象読者は、SOTAのベンチマークスコアを追求する研究開発チームではなく、予算制約の中で実用的なAIシステムを構築する必要がある技術者である。したがって、本稿が提示する指標は「Accuracy 76%」「MAE 0.06」のような実測値であり、理論上限やベンチマーク上の数値ではない。この前提を共有した上で、次のセクションから実験設計の詳細に入る。

実験設計：Tinkerを用いたQwen3-8Bのファインチューニング環境構築

学習環境にはPython 3.13、Tinker 0.33.1、Tinker Cookbook 0.5.7を使用する（complexity-scorerリポジトリ）。TinkerはOpenAI系のAPI互換インターフェースを提供するファインチューニングフレームワークであり、従来のPEFTライブラリ群（PEFT + transformers + 自前トレーニングループ）と比較して、設定ファイルの記述量が少なく、小規模チームでも迅速にPoCを進められる点が選択理由である。

タスク定義と出力形式

タスクは「ユーザーリクエストの難易度を0.00〜1.00のスコアで推定する」ことである。出力形式はJSONに固定し、{ "complexity": 0.50 } のように単一のキーで数値を返す仕様とした（complexity-scorerリポジトリ）。出力をJSONに固定する理由には二つある。一つ目は、後処理（パース）のコストを最小限に抑えられること。二つ目は、モデルの出力が自然言語の文章にブレるリスクを構造的に排除できることである。自由記述を許すと、スコア値が「0.50です」「やや難しい（0.5程度）」のように多様な形式で出力され、クライアントサイドでのパース負荷とエラー率が跳ね上がる。

学習手法：LoRAと1エポックの判断

学習手法にはLoRAアダプターを採用し、1エポックの訓練で過学習を防ぐことを意図した。学習データは各スコアレベル500例ずつ、計2,500例を準備している（complexity-scorerリポジトリ）。1エポックに留める理由は、小規模データセットでは複数エポックの反復で過学習が進行しやすく、バリデーションセット上の誤差が逆に悪化するためである。この設計判断が結果にどう影響したかは、次のセクションでデータとともに検証する。

Tinkerの設定例

実際の学習スクリプトでは、TinkerのAPIを数行で呼び出す形になる。以下は、complexity-scorerプロジェクトで用いた設定の骨子である。モデル名、LoRAのランク、エポック数、学習データセットのパスを指定するだけで訓練が開始される。

from tinker import TinkerClient
from tinker_cookbook import LoRAConfig, TrainingConfig

client = TinkerClient(api_key="tinker-xxxx")

lora_config = LoRAConfig(
    rank=16,
    alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
)

training_config = TrainingConfig(
    model="qwen3-8b",
    dataset_path="./data/complexity_2500.jsonl",
    lora=lora_config,
    epochs=1,
    learning_rate=2e-4,
    output_format='{"complexity": 0.50}',
)

job = client.fine_tune(training_config)
print(f"Job ID: {job.id}, Status: {job.status}")

注目すべきは output_format パラメータである。Tinkerは訓練時にモデルの出力を特定のテンプレートに収束させるよう損失関数を調整する。このパラメータにJSONのスキーマを明示することで、モデルが「complexity」キーと数値の組み合わせを安定して出力するよう学習される。この設計により、推論時のpost-processingが単純なJSONパースに留まり、正規表現による補正ロジックの複雑さが抑えられる。

flowchart LR
    A["ラベル付き学習データ"] --> B["Tinker LoRA訓練"]
    B --> C["モデル評価"]
    C --> D["JSONスコア推論"]

上記のフローは、データ準備から推論までの全体像を示している。TinkerのAPI呼び出しは、モデルのロードから訓練ループの開始まで数行のコードで完結する。従来の方式では TrainingArguments、Trainer、DataCollator といった複数のクラスを個別に設定する必要があったが、Tinkerではこれらがフレームワーク内部でデフォルト値として扱われ、必要に応じて上書きするスタイルになっている。この簡素化が、PoC段階での試行錯誤の速度に直結する。

結果分析：学習データ量と精度の非線形な関係性

ファインチューニング後の評価結果は、学習データ量と精度の関係が直線的でないことを如実に示している。Zero-shot（ファインチューニングなし）の状態では精度50%、平均絶対誤差（MAE）0.125であったが、わずか50例の学習データで精度は86%まで急騰した（DEVの解説記事）。この急激な向上は、8Bクラスのモデルが少データからドメインの出力形式とスコアリングの傾向を急速に吸収できることを示している。

しかし、学習データを500例に増加させた時点で精度は74%まで低下し、さらに2,500例（各スコアレベル500例）まで増やした結果、76%で収束した（DEVの解説記事）。この「逆転現象」の要因として、50例段階では学習セットが評価セットと分布的に近い（または評価セットの一部を含む）可能性が高く、実質的に過学習に近い状態であったと推測できる。500例を超えると学習データがより多様な入力パターンを含むようになり、モデルが「正解」の曖昧な境界を学習せざるを得なくなる。結果として、カテゴリ精度（スコアのバインディングが一致する割合）は下がるが、連続値としての予測精度は向上する。

実際、MAEは0.125から0.06へと改善しており、スコアの「連続値としての正確さ」では学習データ増加が明確に有効であった（complexity-scorerのリポジトリ）。この乖離は、実務システムにおいてどの指標を最適化の目標にするかで設計判断が分岐することを意味する。スコアを離散的なレベル（低・中・高）にマッピングして運用する場合はAccuracyが、スコア値そのものを閾値判定や重み付けに使う場合はMAEが、より適切な指標となる。

学習データ量	精度 (Accuracy)	平均絶対誤差 (MAE)
Zero-shot	50%	0.125
50例	86%	—
2,500例	76%	0.06

実務上の示唆として、50例で得られる86%は「見かけ上の精度」であり、未知の入力パターンに対する汎化性能は保証されない。運用環境では76%前後が現実的な精度の天井と捉え、残りの誤差をデータ量ではなく入力前処理やプロンプト設計で吸収する設計を考える必要がある。

コスト最適化：Hybridモード切替による推論速度と費用の削減

Qwen3-8BはHybridモデルとして設計されており、テキスト生成（Text Generation）と分類（Classification）の両方の推論パスをサポートしている（DEVの解説記事）。本件のスコアリングタスクでは、モデルが「{ "complexity": 0.50 }」というJSON文字列をトークン単位で逐次生成する必要はなく、最終層の出力値からスコアを直接算出できれば推論が完結する。

ここで設計上の分岐点が生まれる。生成モードのまま運用すると、出力トークン数（本ケースではJSONの長さ）に比例して計算量が増加し、各リクエストのレイテンシが出力長に依存する。一方、推論モードを無効化して分類パスに切替えることで、出力長の影響を受けずに定常的な計算コストで推論が完了する。これは、スループット（TPS）の安定化とGPU計算リソースの使用量削減の両方に寄与する。

コスト面での影響を具体化する。生成モードでは、出力トークン1つごとに1回のフォワードパスが実行されるため、GPUの計算時間は出力長に線形に比例する。分類モードでは、入力シーケンスの1回のフォワードパスで推論が完了し、出力長が計算時間に影響しない。つまり、同じGPUインスタンス上で処理できるリクエスト数が向上し、1リクエストあたりの実効コストが低下する。大規模なユーザーリクエストを扱う場合、この差は月間のGPU利用料に直接響く。

ただし、Hybridモデルの分類パスを利用する際には、モデルが分類ヘッドを正しく学習しているかを確認する必要がある。本件ではLoRA訓練でJSON出力形式を学習したが、分類パスがその学習内容を正しく反映しているかは、生成モードとの出力一致率で検証すべきである。両モードでスコアの分布が一致しない場合、分類パス側の学習が不十分であり、生成モードでの運用を継続する判断も選択肢に入る。

実装パターン：APIエンドポイントと認証設計の実例

ファインチューニングしたモデルを外部サービスとして公開する際、APIの設計はモデルの品質と同じくらい運用の安定性に影響する。本件の実装では、POST /api/complexityエンドポイントを提供し、リクエストボディにユーザーリクエストのテキストを渡すと、レスポンスとして0.00〜1.00の範囲のスコアをJSON形式で返す仕様としている（complexity-scorer-apiのリポジトリ）。

認証設計では、2層のキー構造を採用している。1つ目はTinkerキーであり、モデル推論基盤（Tinker）へのアクセスを制御する。2つ目は呼び出し元キーであり、外部クライアントがAPIを利用するための認証情報である。この分離により、Tinkerキーの漏洩が直接外部APIの濫用につながるのを防ぎ、また呼び出し元キーの更新時にTinker側の設定を変更する必要がない。運用上のメンテナンスコストを下げると同時に、攻撃面を縮小する設計判断である。

バックエンドには.NET 10 SDKを使用している（complexity-scorer-apiのリポジトリ）。.NET 10のKestrelサーバーは非同期I/Oをネイティブサポートしており、LLM推論のような高レイテンシな処理を並列で扱う際にスレッドプールを効率的に活用できる。同時に多数の推論リクエストをキューイングしつつ、TinkerへのHTTP呼び出しを非同期で発行するパターンにより、CPUリソースを待機状態に消費せずに済む。

.NET 10側のフォーマット正規化とエラーハンドリング

API層では、Tinkerから返された生レスポンスをそのままクライアントに渡すのではなく、正規化とバリデーションの処理を挟む。以下は、complexity-scorer-apiで実装した処理の骨子である。

// Tinkerからの生レスポンスをパースし、スコアを正規化する
private static double? NormalizeScore(string rawResponse)
{
    // 1. JSONパース（失敗時はnullを返す）
    try
    {
        using var doc = JsonDocument.Parse(rawResponse);
        if (doc.RootElement.TryGetProperty("complexity", out var val))
        {
            double score = val.GetDouble();
            // 2. 範囲チェック：0.00〜1.00にクリップ
            return Math.Clamp(score, 0.00, 1.00);
        }
    }
    catch (JsonException)
    {
        // 3. JSONパース失敗時のフォールバック：数値部分のみ抽出
        var match = Regex.Match(rawResponse, @"(\d+\.?\d*)");
        if (match.Success && double.TryParse(match.Groups[1].Value, out var num))
        {
            return Math.Clamp(num, 0.00, 1.00);
        }
    }
    return null; // 解析不能
}

// コントローラー内の呼び出し例
[HttpPost("/api/complexity")]
public async Task<IActionResult> Score([FromBody] ComplexityRequest req)
{
    // 呼び出し元キーの検証（ヘッダーまたはボディから取得）
    if (!ValidateCallerKey(req.ApiKey))
        return Unauthorized();

    // Tinkerへの非同期推論呼び出し
    var raw = await _tinkerClient.InferAsync(req.Prompt);

    // 正規化
    var score = NormalizeScore(raw);
    if (score is null)
        return StatusCode(502, new { error = "Model returned unparseable output" });

    return Ok(new { complexity = Math.Round(score.Value, 2) });
}

この実装の設計判断を整理すると、以下の3層のガードがある。第一層はJSONパースのtry-catchで、モデルがJSON形式から逸脱した場合に例外がAPI全体に伝播しない。第二層は範囲チェック（Math.Clamp）で、モデルが0.00未満や1.00超過の値を出力した場合に境界値にクリップする。第三層はフォールバックの正規表現抽出で、JSON構造が崩れていても数値部分だけ回収できる。この3層により、モデル側のフォーマット違反がクライアントに「500エラー」として伝播する確率を最小限に抑えている。

このアーキテクチャの利点は、モデルのバージョンアップやLoRAアダプターの差し替えがAPI層のコード変更を伴わずに行える点にある。Tinkerキーを新しいモデルインスタンスに切り替えるだけで、外部クライアントには影響を与えずにモデルの更新を反映できる。マイクロサービス間の契約（APIのスキーマ）が安定している限り、モデルの改善を独立したサイクルで回せる。

sequenceDiagram
    participant C["クライアント"]
    participant API[".NET 10 API"]
    participant T["Tinker"]
    C->>API: POST /api/complexity
    API->>API: 呼び出し元キー検証
    API->>T: 推論リクエスト
    T->>T: モデル推論実行
    T->>API: スコア結果
    API->>API: フォーマット正規化と範囲チェック
    API->>C: JSONレスポンス

上記のシーケンスは、認証の2層構造がリクエスト処理のどの段階で効くかを明示している。呼び出し元キーの検証はTinkerへのリクエスト発行前に完結し、無効なキーでは推論コストが発生しない。TinkerキーはAPIサーバーの環境変数として保持され、クライアントには露出しない。この分離が、APIの公開範囲を広げた場合でも内部モデルのアクセス制御を維持する基盤となる。また、正規化ステップがTinkerのレスポンス受信後・クライアントへの返却前に配置されている点に注意してほしい。この位置に置くことで、モデル側の不具合が外部契約を破綻させることを構造的に防げている。

トレードオフ考察：精度向上と学習コストのバランス設計

前述の結果分析で確認した通り、学習データ量と精度の関係は直線的ではなく、ある閾値を超えると追加投資の効果が頭打ちになる。ここで重要なのは、技術的な収束点ではなく「自社のビジネスモデルが許容する精度の下限」を先に定義することである。例えば、スコアを3段階（低・中・高）にマッピングしてルーティングに使う場合、76%のAccuracyが業務上十分か、それとも80%以上が必要かは、誤分類1件あたりの機会損失額で判断すべきである。精度の目標値を技術的な収束点ではなく業務影響額から逆算することで、「どこまでデータに投資するか」の判断基準が明確になる。ラベリングコストが1件あたり数百円規模であれば、76%から80%への向上に必要な追加データ量と、それによる誤分類削減の年間効果を比較するだけで、投資判断の根拠が得られる。

推論モードの選択についても、技術的な優位性だけでなく運用上のリスク管理を設計に組み込む必要がある。分類モードへの切替はコスト削減に寄与するが、切替後に精度の劣化が検出された場合のロールバック手順を事前に決めておくことが重要である。具体的には、生成モードと分類モードの出力一致率を継続的に監視し、閾値（例えば95%）を下回った場合に生成モードへ自動復帰するルールを設けることで、モード切替のリスクを運用面から管理できる。この「切替の条件」と「復帰の条件」を事前に定義しておくことで、モード切替が属人的な判断に依存しない運用体制を構築でき、オンコール対応の負荷も軽減される。

推論モード	レイテンシ特性	GPU計算量	スループット安定性	適用条件
生成モード	出力長に比例して増加	トークン数 × フォワードパス	変動大（入力長・出力長に依存）	分類パスの検証が未完了の場合
分類モード（推論無効化）	入力長のみに依存	1回のフォワードパスで完結	安定（出力長の影響なし）	分類ヘッドの学習が確認済みの場合

精度が期待値に届かない場合、データ量増加よりプロンプト設計や入力特徴の見直しの方が費用対効果が高いケースが多い。ユーザーリクエストの文字数・技術用語の出現頻度など、スコアと相関のあるメタ情報をプロンプトに付加することで、モデルが判断に使えるシグナルが増え、同等のデータ量でより高い精度が得られる可能性がある。データ準備の工数を削減しつつ精度を底上げする手段として、まず検討すべき選択肢である。

中小企業・スタートアップでは、80%程度の精度でサービスを開始し、運用中の誤分類パターンを分析して学習データを補充するアジャイルなサイクルが現実的である。完璧な精度を追求してリリースを延期するよりも、フィードバックループを回す方が最終的な品質向上速度が速くなる。特に、誤分類が集中する入力パターンを特定し、それらのパターンに偏った学習データを追加する「ターゲットドリブンなデータ拡張」は、均等にデータ量を増やすよりも費用対効果が高い場合がある。運用ログから誤分類のクラスタを抽出し、そのクラスタに相当するラベル付きデータを優先的に収集するプロセスを確立しておくことで、毎回のデータ拡張の方向性を属人化せずに運用できる。

運用における落とし穴：JSON出力の安定性とフォーマット違反対策

ファインチューニングによりスコア値の正確性は向上したが、出力形式の安定性は別途保証する必要がある。complexity-scorerの仕様では { "complexity": 0.50 } 形式のJSONを返すよう学習されているが、推論時に波括弧の欠落や引用符の誤りが発生するケースが観測される。特にスコア値が境界値（0.00や1.00）に近い場合、モデルが数値を切り捨てて「0」や「1」と出力し、JSON構造が崩れる傾向がある。

対策としてまず検討すべきは、推論時のtemperatureパラメータを0に設定することである。temperatureが0に近いほど出力の確率分布が尖り、同じ入力に対して常に同一のトークン列を生成する。これによりフォーマットの一貫性が向上するが、スコア値の解像度が落ちるトレードオフがある。連続値の細かな差がビジネス判断に影響する場面では、temperatureを完全に0にせず0.1程度に設定し、post-processingで補正する方がバランスが良い場合がある。

より実務的な対策は、post-processing層で正規表現による補正ロジックを設けることである。出力が期待形式に一致しない場合、数値部分のみを抽出して範囲チェック（0.00〜1.00）を行い、範囲外の値は境界値にクリップする。このガードレールをAPI層で実装することで、モデル側のフォーマット違反がクライアントに伝播することを防げる。スコアが範囲外に出るケースはハルシネーションに相当し、そのままクライアントに渡すと下流のビジネスロジックが不整合な状態に陥る。前述の.NET 10コード例における NormalizeScore メソッドが、このガードレールの具体実装である。

これらの対策を怠ると、クライアントサイドでJSONパースエラーが発生し、リトライやフォールバック処理が必要になる。結果としてAPIのスループットが低下し、推論コストが想定を超えて増加する。小規模モデルの運用では、モデルの精度よりも出力形式の安定性の方が、システム全体の信頼性に与える影響が大きい場合がある。

まとめ：小規模モデルファインチューニングの設計指針

本稿では、Qwen3-8BをTinkerでファインチューニングし、プロンプト複雑度スコアリングタスクで精度50%から76%へ向上させる過程を分析した。MAEも0.125から0.06へ改善しており、スコアの連続値としての正確性においても実用的な水準に達している。この結果は、8Bクラスのモデルが適切な学習データと手法の組み合わせにより、大規模モデルに依存しない実用的な精度を達成し得ることを示している。

得られた知見を設計指針として整理すると、以下の3点が重要である。第一に、小規模モデルは少量の学習データ（50例程度）で急速にドメイン知識を吸収するため、まず少量データでPoCを行い、汎化性能を検証した上でデータ量を段階的に増やすべきである。第二に、データ量と精度の関係は非線形であり、76%付近で収束した後は追加投資の効果が限定的になる。第三に、Qwen3-8BのHybridモードを活用して推論コストを削減でき、小規模モデルの採算性を大きく改善できる。

最終的に、8Bクラスのモデルを軸とした設計は、「完璧な精度を大規模モデルで追求する」アプローチとは異なる哲学に基づいている。76%の精度で運用を開始し、MAE 0.06という誤差許容範囲の中でビジネスロジックを設計する。不足した精度はデータ量の増加ではなく、プロンプト設計や入力特徴の見直しで補い、運用フィードバックから改善サイクルを回す。この「実装可能で運用可能な精度」を前提とする設計思想こそが、予算制約のある環境でAIシステムを成功に導く鍵である。

参考

本記事は海外の技術トレンド「Fine-Tuning Qwen3-8B with Tinker: From 50% to 76% Accuracy, and Burning Through My Budget」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。