NVFP4で翻訳と日本語3文体のデータを生成
CAT-TranslateとLLM-JPで256件を翻訳・言い換えした検証です。AIシステム開発の学習データ準備として、速度、16件の品質評価、Harmony混入、1万件処理の見積もりを記録しました。
RTX PRO 6000 Blackwellで、英語のreasoning質問を日本語の3文体へ変換しました。AIシステム開発の学習データ準備を想定した、翻訳と言い換えのバッチ検証です。
動画リンク: https://www.youtube.com/watch?v=kSjMKcIJQAg
概要
Claude Opus 4.6の蒸留データには、messages[N].userの質問が887件あります。CAT-Translate-7Bで翻訳し、LLM-JP-4-32Bで簡潔体・丁寧体・文語調へ変換する、NVFP4 + vLLMの構成です。
文体別の出力を選別・加工し、fine-tuning用データなどに使う想定です。
使用モデル
| モデル | 用途 | ライセンス | 量子化 | VRAM |
|---|---|---|---|---|
| CyberAgent/CAT-Translate-7B | En→Ja 翻訳 | MIT | NVFP4 | ~4.6 GiB |
| llm-jp/llm-jp-4-32b-a3b-thinking | 日本語パラフレーズ | Apache 2.0 | NVFP4 | ~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 量子化
Blackwell(SM120)の4bit浮動小数点です。vLLM公式のllm-compressorでチェックポイントを量子化します。
量子化スクリプト
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件でcalibrationしました。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
スループット実測値
| モデル | Peak PP (tokens/s) | Peak TG (tokens/s) | Max 同時リクエスト | KV Cache 使用率 |
|---|---|---|---|---|
| CAT-Translate-7B NVFP4 | 484 | 263 | 4 | < 0.1% |
| LLM-JP-4-32B NVFP4 | 1,978 | 1,724 | 32 | 1.6% |
MoEのLLM-JP(32B total / 3B activated)は、dense 7BのCAT-Translateより高速でした。KV Cacheの使用は少なく、--max-num-seqsを増やす余地があります。
バッチスクリプト (Go)
Dagsterへ組み込む前に、Goのスクリプトで挙動を確認しました。各goroutineで翻訳→言い換えを行い、buffered 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にsystem promptは使わず、公式テンプレートを渡します。
Translate the following English text into Japanese.
{text}
LLM-JP のシステムプロンプト:
あなたは表現豊かな日本語に精通した校閲・添削のエキスパートです。
志賀直哉のような無駄のない、研ぎ澄まされた日本語表現を得意とします。
与えられた日本語テキストを、以下の3つの異なる表現に言い換えてください。
1. 簡潔体: 無駄を削ぎ落とした最小限の表現
2. 丁寧体: 読み手への配慮を含む丁寧な表現
3. 文語調: 格調高く引き締まった文語的表現
出力形式:
<<CONCISE>>
(ここに記述)
<<POLITE>>
(ここに記述)
<<LITERARY>>
(ここに記述)
Sampling パラメータ
| モデル | temperature | top_p | reasoning_effort | 理由 |
|---|---|---|---|---|
| CAT-Translate | 0.3 | 0.95 | — | 翻訳は安定寄りに |
| LLM-JP | 1.0 | 0.95 | low | Qwen3 ベースで推奨値がこのあたり。think を短く抑えて回す |
temperature=1.0 / top_p=0.95を使いました。reasoning_effort: lowで<think>は短くなりましたが、analysisがcontentに混入するため後処理で除きます。
実行結果
concurrency=32で256件を実行しました。
品質統計
| 指標 | 値 |
|---|---|
| 成功率 | 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 フォーマットの問題
使用したvLLMではHarmonyのチャンネルを分離せず、analysisがcontentに混入しました。
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件を抽出し、Claude Opus 4.6で翻訳と言い換えを評価しました。
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/16 | system prompt 改善で対処可能 |
| 翻訳のニュアンスずれ | 1/16 | CAT-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-7B | MIT | CyberAgent |
| LLM-JP-4-32B | Apache 2.0 | 国立情報学研究所 |
| nntsuzu/JESC | CC-BY-4.0 | Stanford / Google Brain / Rakuten |
| TeichAI/Claude-Opus-4.6-Reasoning-887x | Apache 2.0 | TeichAI |
スケーリング見積もり: 1 万件パイプライン
256件の結果から1万件を見積もります。以下は実測ではありません。
VRAM バジェット
192 GB(96 GB × 2 GPU)の80%、153.6 GBを使う計算です。
| モデル | GPU | 重み | KV Cache 利用可能 | Max Concurrency @4k |
|---|---|---|---|---|
| CAT-Translate 7B NVFP4 | GPU 0 | 4.6 GiB | 70.4 GiB | 140x |
| LLM-JP 32B-A3B NVFP4 | GPU 1 | 18.2 GiB | 56.6 GiB | 226x |
モデル重みは計22.8 GiB、KV用の残りは127 GiBです。
最適な concurrency の決定
CATの263 t/sはLLM-JPの1,724 t/sの約1/6.5です。CATへ約6倍のseqを割り当てる案です。
CAT-Translate: seq = n × 6
LLM-JP: seq = n
| n | LLM-JP seq | CAT seq (n×6) | LLM-JP KV | CAT KV | 判定 |
|---|---|---|---|---|---|
| 32 | 32 | 192 → cap 140 | 8 GiB | 17 GiB | OK |
| 64 | 64 | 384 → cap 140 | 16 GiB | 17 GiB | OK (最適) |
| 128 | 128 | 768 → cap 140 | 32 GiB | 17 GiB | OK だが LLM-JP 側過剰 |
CATの最大140に合わせ、n=64(LLM-JP seq=64、CAT seq=140)を上限案とします。合計は約56 GiB / 153.6 GiBです。
所要時間推定
256件はcold start込み90秒、hotでは57秒でした。57秒を線形に伸ばし、concurrency 32→64とCAT seq 32→140で1.5xの改善を見込む計算です。
| 件数 | concurrency=32 hot (実測/推定) | concurrency=64 (推定) |
|---|---|---|
| 256 | 57 秒 | ~38 秒 |
| 10,000 | ~37 分 | ~25 分 |
| 100,000 | ~6.2 時間 | ~4.1 時間 |
初回ウォームアップは差分33秒です。
歩留まりと有効データ量
Claude Opus 4.6による16件評価から、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検証など別モデルを載せる余地があります。
別GPUノードに同じvLLMコンテナを置き、Dagsterでround-robin配分する水平拡張も候補です。処理時間がノード数に比例して減るという見立てで、まだ測定していません。
運用イメージ: judge は週次で
10万件をまとめて処理するより、空き枠に合わせて分ける案です。例えば毎週金曜、Claudeの残枠でjudgeし、NGを除いて保存します。
- 生成側 (vLLM) はいつでも流せるので、入力を切り崩して流すだけ
- Claude 側 judge はレート制限と残枠に合わせて小分けにする
- judge 結果は JSONL で溜め、あとから集計・再評価が効くように保存しておく
生成とjudgeを常時続けず、使える枠に合わせます。
Dagsterへの組み込み案
NVFP4では7Bと32Bを各96GB GPUに置けました。concurrency=32のVRAMは計約23GB、TGはLLM-JP 1,724 t/s、CAT 263 t/sで約6.5倍の差です。
CATのseqを約6倍にする計画で、hot 256件の57秒から1万件約25分を見積もっています。
今回は単発スクリプトの検証です。次はDagsterのasset / opに分け、vLLM拡張、再実行、judge連携を管理する案です。
judgeはClaudeやCodexの空き枠で、金曜などに小分けで行う運用を考えています。
