RTX PRO 6000 Blackwellで、英語 reasoning プロンプトを日本語 3 スタイルに変換するバッチパイプラインを検証した記録。

動画リンク: https://www.youtube.com/watch?v=kSjMKcIJQAg

概要

入力は Claude Opus 4.6 の蒸留データセットに含まれる messages[N].user の質問文 887 件。CAT-Translate-7B で日本語に翻訳し、LLM-JP-4-32B で 3 つの文体 (簡潔体・丁寧体・文語調) に言い換える — これを NVFP4 量子化 + vLLM バッチ処理で流している。

3 スタイルで揃った出力は、用途別のバリエーションを持ったデータセットとして後段で選別・加工しやすい形に揃えてファインチューニング等に利用するユースケース。

使用モデル

モデル用途ライセンス量子化VRAM
CyberAgent/CAT-Translate-7BEn→Ja 翻訳MITNVFP4~4.6 GiB
llm-jp/llm-jp-4-32b-a3b-thinking日本語パラフレーズApache 2.0NVFP4~18.2 GiB

CAT-Translate は CyberAgent が 2026 年 2 月に公開した翻訳特化モデル。Avg BLEU 37.68 で TranslateGemma-12B (32.24) や PLaMo-2 Translate (25.24) を上回る。

LLM-JP-4 は国立情報学研究所が開発した Qwen3 MoE ベースの日本語モデル (32B-A3B)。Harmony Response Format を採用している。

NVFP4 量子化

NVIDIA Blackwell アーキテクチャ (SM120) で利用可能な 4bit 浮動小数点フォーマット。llm-compressor (vLLM 公式) で量子化チェックポイントを生成する。

量子化スクリプト

  import os
os.environ["HF_HUB_CACHE"] = "/mnt/data/models"

from transformers import AutoTokenizer, AutoModelForCausalLM
from llmcompressor import oneshot
from llmcompressor.modifiers.quantization import QuantizationModifier
from datasets import load_dataset

MODEL_ID = "cyberagent/CAT-Translate-7b"
OUTPUT_DIR = "CAT-Translate-7b-NVFP4"

model = AutoModelForCausalLM.from_pretrained(MODEL_ID, dtype="auto", device_map="auto")
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)

dataset = load_dataset("nntsuzu/JESC", split="train[:20]")

def preprocess(ex):
    prompt = f"Translate the following Japanese text into English.\n\n{ex['translation']['ja']}"
    return tokenizer(prompt, truncation=True, max_length=512)

ds = dataset.map(preprocess, remove_columns=dataset.column_names)

recipe = QuantizationModifier(targets="Linear", scheme="NVFP4", ignore=["lm_head"])
oneshot(model=model, dataset=ds, recipe=recipe, num_calibration_samples=20)

model.save_pretrained(OUTPUT_DIR, save_compressed=True)
tokenizer.save_pretrained(OUTPUT_DIR)
  

キャリブレーションデータは nntsuzu/JESC (CC-BY-4.0) から 20 件使用。量子化は 7B モデルで約 40 秒くらい。

pyproject.toml

  [project]
name = "quant-cat-translate-nvfp4"
version = "0.1.0"
requires-python = ">=3.10"
dependencies = [
  "torch>=2.4.0",
  "transformers>=4.47.0",
  "datasets>=3.0.0",
  "llmcompressor>=0.6.0",
  "accelerate>=1.2.0",
  "sentencepiece>=0.2.0",
]
[tool.uv]
package = false
  

vLLM サーバー構成

GPU 0 に CAT-Translate、GPU 1 に LLM-JP を配置。Podman コンテナで起動。

  # GPU 0: CAT-Translate-7B NVFP4
podman run --rm -d \
  --device nvidia.com/gpu=0 \
  --ipc=host \
  -v /mnt/data/models/CAT-Translate-7b-NVFP4:/model:ro \
  -p 9000:9000 \
  registry.home.arpa/vllm-openai:v0.18.0-cu130 \
  /model \
  --host 0.0.0.0 --port 9000 \
  --quantization compressed-tensors \
  --served-model-name cat-translate-nvfp4 \
  --dtype bfloat16 \
  --gpu-memory-utilization 0.80 \
  --max-num-seqs 32 \
  --max-model-len 4096 \
  --max-num-batched-tokens 4096 \
  --no-enable-prefix-caching

# GPU 1: LLM-JP-4-32B NVFP4
podman run --rm -d \
  --device nvidia.com/gpu=1 \
  --ipc=host \
  -v /mnt/data/models/llm-jp-4-32b-a3b-thinking-NVFP4:/model:ro \
  -p 9001:9001 \
  registry.home.arpa/vllm-openai:v0.18.0-cu130 \
  /model \
  --host 0.0.0.0 --port 9001 \
  --quantization compressed-tensors \
  --served-model-name llmjp-nvfp4 \
  --dtype bfloat16 \
  --gpu-memory-utilization 0.80 \
  --max-num-seqs 32 \
  --max-model-len 4096 \
  --max-num-batched-tokens 4096 \
  --no-enable-prefix-caching
  
左が CAT-Translate (`MistralForCausalLM`, :9000)、右が LLM-JP-4-32B (`Qwen3MoeForCausalLM`, :9001)。どちらも `compressed-tensors` 量子化、`bfloat16` dtype、`max_model_len=4096`、`max_num_seqs=32` で Chunked prefill と Asynchronous scheduling が有効になっている

スループット実測値

モデルPeak PP (tokens/s)Peak TG (tokens/s)Max 同時リクエストKV Cache 使用率
CAT-Translate-7B NVFP44842634< 0.1%
LLM-JP-4-32B NVFP41,9781,724321.6%

LLM-JP は MoE アーキテクチャ (32B total / 3B activated) のため、dense 7B の CAT-Translate よりも高速。KV Cache はどちらもほぼ未使用で、--max-num-seqs を大幅に増やせる余地がある。

バッチ実行中。左が :9000 (CAT-Translate) の POST ログ、右が :9001 (LLM-JP) で、LLM-JP 側の Engine は Avg prompt throughput 927.5 tokens/s を記録しているが Running/Waiting は 0 で、リクエスト間は息継ぎしつつ回っている

バッチスクリプト (Go)

dagsterパイプラインを組む前に利用できそうかすぐ試したかったので、各アイテムごとに「翻訳 → パラフレーズ」を一本のゴルーチンで流し、全体の並行度はバッファ付き channel をセマフォとして制限して、使い捨てのスクリプトで検証。

  英語Q (887件) → goroutine (translate → paraphrase) → 3スタイル出力
                  ↑ concurrency = len(sem)
  
  sem := make(chan struct{}, concurrency)
var wg sync.WaitGroup

for _, q := range questions {
    sem <- struct{}{}
    wg.Add(1)
    go func(q Question) {
        defer wg.Done()
        defer func() { <-sem }()

        ja, err := translate(ctx, catClient, q.English)
        if err != nil { record(q, err); return }

        styles, err := paraphrase(ctx, llmjpClient, ja)
        if err != nil { record(q, err); return }

        writeJSONL(out, q, ja, styles)
    }(q)
}
wg.Wait()
  

vLLM 側は --max-num-seqs 32 で連続投入を受けきれるので、クライアント側は投げっぱなし。 CAT-Translate にはシステムプロンプトを使わずに、公式の翻訳プロンプトテンプレートを使用した:

  Translate the following English text into Japanese.

{text}
  

LLM-JP のシステムプロンプト:

  あなたは表現豊かな日本語に精通した校閲・添削のエキスパートです。
志賀直哉のような無駄のない、研ぎ澄まされた日本語表現を得意とします。

与えられた日本語テキストを、以下の3つの異なる表現に言い換えてください。

1. 簡潔体: 無駄を削ぎ落とした最小限の表現
2. 丁寧体: 読み手への配慮を含む丁寧な表現
3. 文語調: 格調高く引き締まった文語的表現

出力形式:
<<CONCISE>>
(ここに記述)
<<POLITE>>
(ここに記述)
<<LITERARY>>
(ここに記述)
  

Sampling パラメータ

モデルtemperaturetop_preasoning_effort理由
CAT-Translate0.30.95翻訳は安定寄りに
LLM-JP1.00.95lowQwen3 ベースで推奨値がこのあたり。think を短く抑えて回す

LLM-JP-4 は Qwen3 MoE ベースなので、Qwen 系で一般に推奨される temperature=1.0 / top_p=0.95 をそのまま使っている。reasoning_effort: low<think> 部分が短くなるが、Harmony 由来の analysis ブロックが content に混入する問題は残るので後処理で除去した。

実行結果

256 件を実行 (concurrency=32)

品質統計

指標
成功率256/256 (100%)
3 タグ完備率252/256 (98.4%)
EN 平均長174 文字
JA 翻訳 平均長89 文字
JA/EN 圧縮率0.51
簡潔体 平均長98 文字
丁寧体 平均長172 文字 (簡潔体の 1.77x)
文語調 平均長164 文字 (簡潔体の 1.68x)

タグ欠損 4 件の原因

index原因
154**CONCISE** マークダウン記法にすり替わり
172モデルが拒否応答 (著作権)
238<<CONCENSED>> タイポ
253**CONCISE** マークダウン記法

LLM-JP Harmony フォーマットの問題

LLM-JP-4 は OpenAI Harmony Response Format を採用しており、analysis チャンネルの出力が content にフラットに混入する。vLLM が Harmony のチャンネル分離をパースしないため。

   analysis We need to output three versions. assistant final <<CONCISE>>
...
  

reasoning_effort: low は効いており、analysis 部分は短い。後処理で <<CONCISE>> より前を regex で除去して対応。

出力サンプル

技術系 (index 202)

EN: What’s a good ratio of unit tests to integration tests to e2e tests? We have almost no integration tests and our e2e suite takes 45 minutes to run.

JA 翻訳: ユニットテスト、インテグレーションテスト、E2E テストの良い割合はどれくらいですか? 当社ではインテグレーションテストがほとんどなく、E2E スイートは実行に 45 分かかります。

簡潔体: インテグレーションテストがほぼ無く、E2E テストが 45 分かかる状況では、ユニットテスト 70%、統合テスト 15%、E2E テスト 15% が目安となります。

丁寧体: 現在、インテグレーションテストが少なく、E2E テストの実行に 45 分ほど要すると伺っております。そのような環境では、テスト全体の構成比率として、ユニットテストを約 70%、統合テストを約 15%、E2E テストを残りの 15%程度に設定されることが一般的です。ご参考になれば幸いです。

文語調: 統合テストが乏しく、E2E スイートが四十分半もの時間を要すという現状に照らすに、全体のテスト配分は次のごとくあるべきかと存じます。― ユニットテスト 七割 ― 統合テスト 一割五分 ― E2E テスト 一割五分

人間関係 (index 144)

EN: I told my coworker off in front of the whole team because she kept taking credit for my work. Everyone went silent. Did I do the right thing?

JA 翻訳: チーム全員の前で同僚を叱責しました。彼女が私の仕事を横取りしていたからです。すると、全員が黙り込んでしまいました。私は正しいことをしたのでしょうか?

簡潔体: 同僚を叱りつけたのは、彼女が私の仕事を奪おうとしたからだ。皆が黙っていた。これでよかったのか。

丁寧体: 本日のミーティングにおいて、○○さんが私の担当業務を横取りされたように見受けられました。そのため、直接注意させていただきました。しかし、周囲の皆様には沈黙の時間が訪れたようでした。この行為は適切だったでしょうか。

文語調: 会議の場にて、我が同僚の所作が私の業務を侵す様相を呈し、慎みなく叱責致した。その結果、参加者全員は静かに息を潜めた。果たしてこの行為は正当なるものと致すべきか、問う所存である。

品質精査 (Claude Opus 4.6 による 16 件ランダムサンプル評価)

256 件の出力からランダムに 16 件を抽出し、翻訳・パラフレーズの両方を精査した。

CAT-Translate (翻訳) 品質

総評: B+ — 実用レベルだが改善余地あり

評価件数詳細
正確・自然12/16技術用語の訳出も適切
軽微な問題3/16意味は通るがやや直訳的
誤訳1/16“emotional valence” → 「感情的価値」(意図的なナンセンス質問のため仕方ない)

注目すべき問題:

  • index 245: “I’m locked out” → 「家から鍵が閉まっています」 — 「閉め出された」が正しいが、逆方向の意味に翻訳されている
  • JA/EN 圧縮率 0.52 は自然だが、一部で情報の欠落がある (長い EN が短い JA に圧縮されすぎ)

LLM-JP (パラフレーズ) 品質

総評: A- — 3 スタイルの書き分けが明確

簡潔体: 無駄を削いだ表現ができている。ただし一部で ** マークダウンが混入 (index 250)。

丁寧体: ビジネス文書として自然な敬語。「ご教示いただけますでしょうか」「ご検討ください」等の定型表現が適切。3 スタイルの中で最も安定している。

文語調: index 27 が秀逸 — 「サービスの闇が降りしきるや、三十分は速やかに灯火を掲げんとす」は創造的すぎるが面白い。index 144: 「会議の場にて、我が同僚の所作が私の業務を侵す様相を呈し」はしっかり文語。ただし一部で現代語と文語が混在 (index 177: 「敷衍すべく、只今策定中でございます」— 「ございます」は文語ではない)。

問題パターンまとめ

問題件数対処
**太字** マークダウン混入2/16後処理で除去
文語調に丁寧語混在2/16system prompt 改善で対処可能
翻訳のニュアンスずれ1/16CAT-Translate の限界
ナンセンス質問の真面目な翻訳3/16元データの性質上やむなし

サンプル

  ...
{"index":82,"english_q":"Explain the mathematics behind random forests. How do bagging and feature randomization create a model that's better than individual decision trees?","japanese_q":"ランダムフォレストの背後にある数学を説明してください。バギングと特徴量のランダマイゼーションは、個々の決定木よりも優れたモデルをどのように作成するのでしょうか?","paraphrases":" analysis We need to output three versions. Provide concise, polite, literary. assistant final \u003c\u003cCONCISE\u003e\u003e  \nランダムフォレストは、ブートストラップサンプルで多数の決定木を育て、各木の学習時に特徴量をランダムに選ぶことで、相関の低い多数の木を集約し、過学習を抑えて汎化性能を向上させます。  \n\n\u003c\u003cPOLITE\u003e\u003e  \nランダムフォレストは、ブートストラップ法によるサブサンプルと特徴量のランダム抽出を組み合わせて、多数の決定木を構築し、それぞれを独立に学習させます。その後、予測を多数決(または平均)で統合することで、個々の木よりも分散が小さく、安定した高精度のモデルを実現します。  \n\n\u003c\u003cLITERARY\u003e\u003e  \n乱択的森林(Random Forest)とは、ブートストラップ抽出により得た多様なデータ群と、各決定木の訓練過程で逐次ランダムに選ばれる特徴集合という二つの乱択手段を用いて、相互独立的なる多数の樹を育み上げる技法である。これらの樹はそれぞれが互いに相関し難い情報を帯びているため、集合的推論においては個々の木の揺らぎが相殺され、全体として極めて堅牢且つ高次元においても過剰適合を免れた卓越した汎化能力を呈すのである。"}
{"index":86,"english_q":"What's the viscosity in centipoise of our deal pipeline, and at what revenue throughput does the flow transition from laminar to turbulent? We need to size the sales team for Q3.","japanese_q":"当社の取引パイプラインの粘性(センチポイズ)はどれくらいで、どの売上スループットで流れが層流から乱流に移行しますか? 第3四半期の営業チームの人員規模を決定する必要があります。","paraphrases":" analysis We need to output three versions. assistant final \u003c\u003cCONCISE\u003e\u003e\n当社の取引パイプラインの粘度(センチポイズ)は X で、売上スループットが Y になると層流から乱流へ遷移します。第3四半期の営業人数はこの結果を基に決定します。\n\n\u003c\u003cPOLITE\u003e\u003e\n弊社の取引パイプラインにおける粘度(センチポイズ)は X であり、売上スループットが Y に達すると層流状態から乱流状態へと変化します。その情報をもとに、第3四半期における営業チームの適切な人数をご決定いただければ幸いです。\n\n\u003c\u003cLITERARY\u003e\u003e\n我が社の取引管路における粘度(センチポイズ)は X と測定され、売上スループットが Y を越える折に、層流は乱れたる流勢へと転換致す。此の事実を踏まえ、第3四半期の営業部門要員数を定めんものとす。"}
{"index":89,"english_q":"Our controller wants to implement a triangulated accrual reconciliation method for intercompany eliminations under U.S. GAAP -- how should we configure the convergence tolerance between the three ledger axes before the quarter-end close?","japanese_q":"当社のコントローラーは、米国会計基準(US GAAP)に基づく企業間消去のための、三角測量による発生調整方式を実装したいと考えています。四半期末の決算前に、3つの会計軸間の収束許容範囲をどのように設定すればよいでしょうか?","paraphrases":" analysis We need to output three rephrasings. Provide concise, polite, literary. assistant final \u003c\u003cCONCISE\u003e\u003e  \n当社はUS GAAPの三角測量法で企業間消去を行う予定です。四半期末前に、3つの会計軸の収束許容範囲をどう設定すべきか教えてください。\n\n\u003c\u003cPOLITE\u003e\u003e  \n弊社では、米国会計基準(US GAAP)に則った企業間消去に三角測量方式の導入を検討しております。四半期末決算前に、三つの会計軸間の収束許容範囲をどのように設定すべきか、ご教示いただけますと幸いです。\n\n\u003c\u003cLITERARY\u003e\u003e  \n是に、米国会計基準(US GAAP)に則り、企業間消去を三角測量の手法にて実施すべく企図いたすところです。四半期末の決算に際し、三軸の会計項目が収束すべき許容範囲を如何に設定すべきか、御指南賜りたく存ず。"}
{"index":90,"english_q":"What's the yield-to-maturity on our residency program's teaching portfolio, and should we rebalance toward more procedural exposure before the next accreditation coupon date?","japanese_q":"当レジデンシープログラムの教育ポートフォリオにおける利回り対満期日比率はどのくらいですか?また、次の認定クーポンの期日までに、より手技的な経験を重視するようにバランスを調整すべきでしょうか?","paraphrases":" analysis Need to rewrite three styles. assistant final \u003c\u003cCONCISE\u003e\u003e\n教育ポートフォリオの利回り対満期日比率は約 X %です。次回認定クーポンの締切までに、手技的経験を重視した構成へ調整すべきか検討してください。\n\n\u003c\u003cPOLITE\u003e\u003e\n当レジデンシープログラムにおける教育ポートフォリオの利回り対満期日比率は、約 X %となっております。次の認定クーポンの期限が近づいておりますので、それまでに手技的経験を重点的に評価するよう、ポートフォリオのバランスを見直すことをご検討いただければ幸いです。\n\n\u003c\u003cLITERARY\u003e\u003e\n我がレジデンシープログラムにおきまして、教育ポートフォリオの利回りは満期日に対し約 X %という数値を呈す。次に掲げられる認定クーポンの有効期限が迫っておるゆえ、手技的経験を一層重視すべく、ポートフォリオ配分を精緻に再調整すべきか否か、熟慮の程を求む。"}
{"index":93,"english_q":"What's the per-brushstroke aesthetic contribution score when painting a room, and how do we identify which strokes are lowering the overall wall beauty index?","japanese_q":"部屋を塗る際、1回の筆遣いあたりの美的貢献スコアはどれくらいか、また、どの筆遣いが壁の全体的な美しさ指数を下げているかをどうやって特定するか?","paraphrases":" analysis We need to output three rewrites. Provide concise, polite, literary. assistant final \u003c\u003cCONCISE\u003e\u003e\n部屋を塗るとき、1本の筆跡が美的貢献度に与える影響と、全体の美観を低下させる筆跡の特定方法を教えてください。\n\n\u003c\u003cPOLITE\u003e\u003e\n部屋を塗装する際に、1回の筆遣いが美的貢献スコアとしてどれほど寄与しているか、そして全体の壁の美しさ指数を下げている筆遣いをどのように判別すればよいか、ご教示いただけますでしょうか。\n\n\u003c\u003cLITERARY\u003e\u003e\n部屋を彩るべく塗料を施す際、一回の筆跡が美的貢献として如何に数値化され得るか、並びに其の筆跡の中で壁面全体の美観を蝕むものを見極めんとする方法論をご提示賜りますよう、謹んでお願い申し上げます。"}
{"index":87,"english_q":"We want to calculate the impedance mismatch between our frontend team's React component model and the backend team's domain-driven design layer — at what ohm-equivalent threshold should we consider introducing a BFF service to match the impedance?","japanese_q":"フロントエンドチームのReactコンポーネントモデルとバックエンドチームのドメイン駆動設計レイヤーとの間のインピーダンス不整合を計算したいと考えています。どの程度の抵抗値相当の閾値で、インピーダンスを一致させるためにBFF(Business Functional Component)サービスを導入すべきでしょうか?","paraphrases":" analysis We need to respond with three paraphrases as instructed. Provide concise, polite, literary versions. assistant final \u003c\u003cCONCISE\u003e\u003e\n\nフロントエンドの React コンポーネントとバックエンドの DDD レイヤー間に生じるインピーダンス不整合を測定し、BFF を導入すべき抵抗値(閾値)を決める。\n\n\u003c\u003cPOLITE\u003e\u003e\n\n現在、フロントエンドチームの React コンポーネントとバックエンドチームのドメイン駆動設計レイヤーとの間に存在するインピーダンス不整合について、どの程度の抵抗値に相当する閾値で合わせるべきか、またその際に Business Functional Component(BFF)サービスを導入すべきかどうかをご検討いただきたく存じます。\n\n\u003c\u003cLITERARY\u003e\u003e\n\nフロントエンド部門における React コンポーネント群と、バックエンド部門が採用する Domain‑Driven Design の層構造との間に顕在化すべきインピーダンス不整合を算定し、其の抵抗閾値を如何に設定すれば、Business Functional Component(BFF)を介して円滑に統合できるか、慎重にご判断いただきたく存じます。"}
{"index":92,"english_q":"What tolerance range in milliempathies should we set for compassion drift among palliative care nurses during consecutive 12-hour shifts, and at what threshold do we mandate a rotation?","japanese_q":"緩和ケア看護師が連続12時間シフト中に経験する共感疲労(コンパッション・ドリフト)に対し、どの程度の許容範囲(ミリエンパシー単位)を設定すべきか、またどの閾値でローテーションを義務付けるべきか?","paraphrases":" analysis Need to rewrite in three styles. assistant final \u003c\u003cCONCISE\u003e\u003e\n共感疲労の許容レベルは「ミリエンパシー」単位で ≤ 200 と設定し、200 を超えたら即ローテーションする。\n\n\u003c\u003cPOLITE\u003e\u003e\n緩和ケア看護師の長時間労働による共感疲労については、許容できる上限を「ミリエンパシー」200単位とし、この数値を超えた場合には速やかにローテーションを実施すべきと考えております。\n\n\u003c\u003cLITERARY\u003e\u003e\n当職業において、連続十二時間に及ぶシフトの中で看護師が抱える共感疲労は、ミリエンパシーという指標で測り得るとすれば、二百単位を超える瞬間こそ警戒すべき転機であり、そこへ到達した暁には必ずやローテーションを執りて、負担の軽減を図らねばならぬ。"}
{"index":53,"english_q":"How does a compiler optimize code? Walk me through constant folding, dead code elimination, loop unrolling, and inlining with examples.","japanese_q":"コンパイラはどのようにコードを最適化しますか? 定数畳み込み、デッドコードの削除、ループのアンロール、インライン化について、例を挙げて説明します。","paraphrases":" analysis We need to output three versions. Provide concise, polite, literary. Use proper Japanese. assistant final \u003c\u003cCONCISE\u003e\u003e\nコンパイラはコードを最適化します。たとえば定数畳み込みでは式 `2 * 3 + 5` をコンパイル時に `11` に置き換えます。デッドコード削除では実行不能な `if (false) { … }` を除去します。ループのアンロールは `for(i=0;i\u003c4;i++) sum+=a[i];` を `sum+=a[0]+a[1]+a[2]+a[3];` と展開し、インライン化は関数呼び出しを呼び出し側に直接埋め込んでオーバーヘッドを減らします。\n\n\u003c\u003cPOLITE\u003e\u003e\nコンパイラはコードの最適化技術を駆使して、プログラムの実行速度やメモリ使用量を改善いたします。例えば、定数畳み込みという手法では、コンパイル時に計算可能な式 `2 * 3 + 5` を事前に評価し、その結果である `11` をコードに組み込みます。デッドコード削除では、実行不可能なブロック(例:`if (false) { … }`)を検出し、不要な部分を除去しますよ。また、ループのアンロールは、繰り返し回数が固定された `for (i = 0; i \u003c 4; ++i) sum += a[i];` を `sum += a[0] + a[1] + a[2] + a[3];` と展開して命令数を削減します。さらに、インライン化は小さな関数呼び出しを呼び出し元に直接埋め込むことで、関数呼び出しオーバーヘッドを低減させます。\n\n\u003c\u003cLITERARY\u003e\u003e\nコンパイラは、鋭利なる刃のごとく冗長を削り、原初の真理へと導く術を以てコードを研ぎ澄ませる。まず、**定数畳み込み**に於いては、`2 * 3 + 5` のような演算を解析し、コンパイル時にその結果である `11` と置換す。次に、**デッドコードの除去**では、`if (false) { … }` の如く決して執行されぬブロックを検出し、闇に葬り去ることで無駄なる痕跡を消し去る。続くは、**ループのアンロール**――有限回の反復を明示的に書き足すことに由り、`for (i = 0; i \u003c 4; ++i) sum += a[i];` は `sum += a[0] + a[1] + a[2] + a[3];` と変容し、命令列は簡潔の峰を成す。最後に、**インライン化**は、小さき関数呼び出しを呼び出し元へ直接巻き込み、スタック操作等の余計な負荷を払拭す。此の三技法により、機械は一層の清浄と効率を獲得し、プログラムは常に最適の姿勢を保つのである。"}
{"index":91,"english_q":"What's the tensile strength of our lesson plan scaffolding, and at what student-to-teacher ratio should we expect the learning framework to undergo brittle fracture?","japanese_q":"私たちのレッスンプランの足場の引張強度はどれくらいで、学習フレームワークが脆性破壊を起こすと予想される生徒と教師の比率はどれくらいですか?","paraphrases":" analysis We need to produce three rewrites. Provide answers? The question asks about lesson plan footing tensile strength and ratio of students/teachers predicted brittle failure. Likely answer is not known; we can say insufficient data. But still rewrite the query.\n\nWe'll output rephrased versions. assistant final \u003c\u003cCONCISE\u003e\u003e\nレッスンプランの足場の引張強度と、学習フレームワークが脆性破壊すると見込まれる生徒と教師の割合は?\n\n\u003c\u003cPOLITE\u003e\u003e\nご教示いただけますでしょうか。当レッスンプランにおける足場の引張強度の数値、および学習フレームワークが脆性破壊を起こすと予測される生徒と教師の比率について教えていただきたく存じます。\n\n\u003c\u003cLITERARY\u003e\u003e\n此処に問うは、我がレッスンプランの足場が耐える引張の力のほど、そして学習枠組みが脆弱なる破砕を呈すと考えられる生徒と教師との比率なり。どうかご教授賜らんことを。"}
...
  

ライセンスと帰属

リソースライセンス帰属
CAT-Translate-7BMITCyberAgent
LLM-JP-4-32BApache 2.0国立情報学研究所
nntsuzu/JESCCC-BY-4.0Stanford / Google Brain / Rakuten
TeichAI/Claude-Opus-4.6-Reasoning-887xApache 2.0TeichAI

スケーリング見積もり: 1 万件パイプライン

256 件の実行結果から、1 万件規模でのスケーリングを見積もる。

VRAM バジェット

192 GB (96 GB × 2 GPU) の 80% = 153.6 GB を利用可能。

モデルGPU重みKV Cache 利用可能Max Concurrency @4k
CAT-Translate 7B NVFP4GPU 04.6 GiB70.4 GiB140x
LLM-JP 32B-A3B NVFP4GPU 118.2 GiB56.6 GiB226x

モデル重み合計 22.8 GiB。残り 127 GiB が KV Cache に使える。

最適な concurrency の決定

CAT-Translate の TG (263 t/s) が LLM-JP (1,724 t/s) の約 1/6.5 なので、CAT 側に 6 倍の seq を割り当ててバランスを取る。

  CAT-Translate: seq = n × 6
LLM-JP:        seq = n
  
nLLM-JP seqCAT seq (n×6)LLM-JP KVCAT KV判定
3232192 → cap 1408 GiB17 GiBOK
6464384 → cap 14016 GiB17 GiBOK (最適)
128128768 → cap 14032 GiB17 GiBOK だが LLM-JP 側過剰

CAT-Translate の max concurrency が 140 で頭打ちのため、n=64 (LLM-JP seq=64, CAT seq=140) が実用上限。VRAM 使用量は合計 ~56 GiB / 153.6 GiB で余裕がある。

所要時間推定

256 件 / concurrency=32 の実測は cold start 込みで 90 秒。2 回目以降 (モデルが暖まった hot な状態) は 57 秒で回った。スケーリング見積もりは hot 側の 57 秒を基準に線形に延ばし、concurrency を 32→64 に引き上げた場合は LLM-JP のバッチ効率向上と CAT の seq 増加 (32→140) で保守的に 1.5x を見込む。

件数concurrency=32 hot (実測/推定)concurrency=64 (推定)
25657 秒~38 秒
10,000~37 分~25 分
100,000~6.2 時間~4.1 時間

参考: 256 件の cold start 込みは 90 秒で、33 秒が初回ウォームアップ分。長時間バッチでは相対的な影響は小さい。

歩留まりと有効データ量

16 件のランダムサンプル精査 (Claude Opus 4.6 評価) から、そのまま SFT/DPO に利用可能なデータの割合を推定する。

評価比率1 万件での推定
そのまま使える62.5%~6,250 件
軽微な後処理で救済可能25.0%~2,500 件
破棄 (誤訳・拒否・タグ崩壊)12.5%~1,250 件

破棄の主因はナンセンス質問 (元データの性質) と翻訳のニュアンスずれ。入力データを事前にフィルタすれば破棄率はさらに下がる。

1 万件パイプラインの最終見積もり

項目
投入件数10,000
LLM-JP seq (n)64
CAT-Translate seq (n×6, cap)140
推定処理時間~25 分 (hot)
VRAM 使用量~56 GiB / 153.6 GiB (36%)
そのまま使える (62.5%)~6,250 件
後処理救済込み (87.5%)~8,750 件

25 分の実行で 6,000〜8,000 件級のまとまった日本語出力が取れる。VRAM は 36% しか使っていないため、さらに大きなモデル (BF16 での検証等) を同居させる余地も残る。

単一ノードでのスケーリングとは別に、vLLM インスタンスを水平スケールさせればスループットは素直に伸びる。CAT-Translate / LLM-JP ともにモデルサイズが小さいので、他の GPU ノードに同じコンテナを追加して Dagster 側でジョブをラウンドロビンに流せば、1 万件あたりの処理時間はノード数にほぼ比例して縮む。

運用イメージ: judge は週次で

一気に 10 万件を回して精査する形より、手元のリソースに合わせて小刻みに貯めるほうが運用しやすい。たとえば毎週金曜に余った Claude 枠で judge を走らせて、NG だったものを弾きつつ少しずつアーカイブしていく、という回し方。

  • 生成側 (vLLM) はいつでも流せるので、入力を切り崩して流すだけ
  • Claude 側 judge はレート制限と残枠に合わせて小分けにする
  • judge 結果は JSONL で溜め、あとから集計・再評価が効くように保存しておく

連続で走らせる必要がないので、GPU も Claude も遊ばせない・焦らせないで回せる。

まとめ

NVFP4 量子化により、7B + 32B の 2 モデルを 96 GB GPU 1 枚ずつに収め、合計 VRAM 使用量は約 23 GB (concurrency=32 時)。LLM-JP-4 の MoE アーキテクチャ (32B-A3B) は TG 1,724 t/s と、dense 7B の CAT-Translate (TG 263 t/s) を 6.5 倍上回る。

パイプラインのスケーリングでは、この速度差を利用して CAT 側に 6 倍の seq を割り当て、GPU の遊びを最小化する設計が有効。256 件を hot 状態で 57 秒、1 万件を 25 分程度で回せる見込み。

今回は使い捨てのバッチスクリプトで挙動を確かめた段階で、本筋はこの一連の処理を Dagster の asset / op にばらしてパイプライン化すること。vLLM の水平スケールや再実行ポリシー、judge との組み合わせは Dagster 側で扱うほうが素直に収まる。

運用も、生成を一度にまとめてやるのではなく、毎週金曜の余った Claude, Codex 枠で judge を走らせると良いと思う。