I converted English reasoning questions into three Japanese styles on RTX PRO 6000 Blackwell. The batch test explores training-data preparation for AI system development.

Video link: https://www.youtube.com/watch?v=kSjMKcIJQAg

Overview

The Claude Opus 4.6 distilled dataset contains 887 messages[N].user questions. CAT-Translate-7B translates them; LLM-JP-4-32B produces concise, polite, and literary versions using NVFP4 and vLLM.

The variants are intended for later selection and editing, including fine-tuning data.

Models

ModelPurposeLicenseQuantizationVRAM
CyberAgent/CAT-Translate-7BEn→Ja translationMITNVFP4~4.6 GiB
llm-jp/llm-jp-4-32b-a3b-thinkingJapanese paraphraseApache 2.0NVFP4~18.2 GiB

CyberAgent released CAT-Translate in February 2026. Its Avg BLEU is 37.68, compared with TranslateGemma-12B at 32.24 and PLaMo-2 Translate at 25.24.

LLM-JP-4 is the National Institute of Informatics Japanese model based on Qwen3 MoE (32B-A3B), using Harmony Response Format.

NVFP4 Quantization

NVFP4 is a 4-bit floating-point format on Blackwell SM120. The official vLLM llm-compressor builds the checkpoint.

Quantization script

  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)
  

Calibration used 20 nntsuzu/JESC samples under CC-BY-4.0. Quantizing the 7B model took about 40 seconds.

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 Server Configuration

CAT-Translate runs on GPU 0 and LLM-JP on GPU 1 in Podman containers.

  # 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
  
Left: CAT-Translate (`MistralForCausalLM`, :9000). Right: LLM-JP-4-32B (`Qwen3MoeForCausalLM`, :9001). Both run `compressed-tensors` quantization with `bfloat16` dtype, `max_model_len=4096`, `max_num_seqs=32`, and Chunked prefill + Asynchronous scheduling enabled

Measured Throughput

ModelPeak PP (tokens/s)Peak TG (tokens/s)Max concurrentKV Cache usage
CAT-Translate-7B NVFP44842634< 0.1%
LLM-JP-4-32B NVFP41,9781,724321.6%

MoE LLM-JP (32B total / 3B active) was faster than dense 7B CAT-Translate. Both used little KV cache, leaving room to increase --max-num-seqs.

Mid-batch run. Left: POST logs on :9000 (CAT-Translate). Right: :9001 (LLM-JP). The LLM-JP engine is clocking Avg prompt throughput 927.5 tokens/s while Running/Waiting stay at 0 — it's pacing itself between requests rather than saturating

Batch Script (Go)

Before Dagster integration, I checked behavior with a Go script. Each goroutine translates and paraphrases one item; a buffered channel limits concurrency.

  English Q (887) → goroutine (translate → paraphrase) → 3-style output
                   ↑ 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 accepted continuous requests with --max-num-seqs 32.

CAT-Translate uses the official template without a system prompt:

  Translate the following English text into Japanese.

{text}
  

LLM-JP system prompt:

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

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

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

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

Sampling parameters

Modeltemperaturetop_preasoning_effortRationale
CAT-Translate0.30.95—Translation should stay on the deterministic side
LLM-JP1.00.95lowQwen3-based, so recommended values sit here. low keeps think blocks short

I used temperature=1.0 / top_p=0.95. reasoning_effort: low shortened <think>, but analysis still mixed into content and needed post-processing.

Results

I processed 256 items at concurrency=32.

Quality statistics

MetricValue
Success rate256/256 (100%)
3-tag complete rate252/256 (98.4%)
EN avg length174 chars
JA translation avg89 chars
JA/EN compression0.51
Concise avg length98 chars
Polite avg length172 chars (1.77x concise)
Literary avg length164 chars (1.68x concise)

Causes of the 4 tag-missing items

indexCause
154Flipped to **CONCISE** markdown notation
172Model refusal (copyright)
238<<CONCENSED>> typo
253**CONCISE** markdown notation

LLM-JP Harmony format issue

The vLLM version used here did not separate Harmony channels, so analysis entered content.

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

reasoning_effort: low kept analysis short. A regex removed content before <<CONCISE>>.

Output samples

Technical (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 translation: ユニットテスト、インテグレーションテスト、E2E テストの良い割合はどれくらいですか? 当社ではインテグレーションテストがほとんどなく、E2E スイートは実行に 45 分かかります。

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

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

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

Interpersonal (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 translation: チーム全員の前で同僚を叱責しました。彼女が私の仕事を横取りしていたからです。すると、全員が黙り込んでしまいました。私は正しいことをしたのでしょうか?

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

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

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

Quality review (16 random samples, judged by Claude Opus 4.6)

Claude Opus 4.6 reviewed translations and paraphrases from 16 random samples of the 256 outputs.

CAT-Translate (translation) quality

Overall: B+ — practical, with room to improve.

AssessmentCountDetail
Accurate/natural12/16Technical terms rendered well
Minor issues3/16Meaning comes through but somewhat literal
Mistranslation1/16“emotional valence” → 「感情的価値」 (fair, given that the source was an intentionally nonsensical question)

Notable issues:

  • index 245: “I’m locked out” → 「家から鍵が閉まっています」 — 「閉め出された」 would be correct; the direction of the meaning got flipped
  • JA/EN compression ratio 0.52 is natural, but a few samples drop information (long EN squeezed into too-short JA)

LLM-JP (paraphrase) quality

Overall: A- — the three styles come out clearly distinct.

Concise output was brief, but index 250 retained ** markdown.

Polite was judged the most stable style, using phrases such as 「ご教示いただけますでしょうか」 and 「ご検討ください」.

Literary output included creative wording at index 27: 「サービスの闇が降りしきるや、三十分は速やかに灯火を掲げんとす」. Index 144 used literary 「会議の場にて、我が同僚の所作が私の業務を侵す様相を呈し」. Index 177 mixed modern language: 「敷衍すべく、只今策定中でございます」.

Problem pattern summary

ProblemCountHandling
**bold** markdown leaking in2/16Strip in post-processing
Polite forms mixed into literary2/16Fixable with system prompt refinement
Translation nuance drift1/16Limit of CAT-Translate
Sincere translation of nonsense3/16Inherent to the source data

Sample

  ...
{"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此処に問うは、我がレッスンプランの足場が耐える引張の力のほど、そして学習枠組みが脆弱なる破砕を呈すと考えられる生徒と教師との比率なり。どうかご教授賜らんことを。"}
...
  

License & Attribution

ResourceLicenseAttribution
CAT-Translate-7BMITCyberAgent
LLM-JP-4-32BApache 2.0National Institute of Informatics
nntsuzu/JESCCC-BY-4.0Stanford / Google Brain / Rakuten
TeichAI/Claude-Opus-4.6-Reasoning-887xApache 2.0TeichAI

Scaling estimate: 10k-item pipeline

The 10k estimates extrapolate from 256 items; they are not measured runs.

VRAM budget

192 GB (96 GB × 2 GPU) × 0.80 gives 153.6 GB.

ModelGPUWeightsKV Cache budgetMax concurrency @4k
CAT-Translate 7B NVFP4GPU 04.6 GiB70.4 GiB140x
LLM-JP 32B-A3B NVFP4GPU 118.2 GiB56.6 GiB226x

Weights total 22.8 GiB, leaving 127 GiB for KV cache.

Choosing concurrency

CAT TG at 263 t/s is about 1/6.5 of LLM-JP at 1,724 t/s. The plan gives CAT roughly six times the seq count.

  CAT-Translate: seq = n × 6
LLM-JP:        seq = n
  
nLLM-JP seqCAT seq (n×6)LLM-JP KVCAT KVVerdict
3232192 → cap 1408 GiB17 GiBOK
6464384 → cap 14016 GiB17 GiBOK (optimal)
128128768 → cap 14032 GiB17 GiBOK, LLM-JP side overcommitted

CAT caps at 140, yielding a proposed n=64 limit: LLM-JP seq=64 and CAT seq=140. Estimated VRAM is about 56 GiB / 153.6 GiB.

Time estimate

The 256-item run took 90 seconds cold and 57 seconds hot. The estimate scales 57 seconds linearly, assuming 1.5× improvement from concurrency 32→64 and CAT seq 32→140.

Itemsconcurrency=32 hot (measured/est.)concurrency=64 (est.)
25657 s~38 s
10,000~37 min~25 min
100,000~6.2 h~4.1 h

The first warmup accounts for the 33-second difference.

Yield and effective data volume

The estimated SFT/DPO yield comes from the 16-sample Claude Opus 4.6 review.

AssessmentShareEst. at 10k
Usable as-is62.5%~6,250 items
Salvageable with light post-processing25.0%~2,500 items
Discard (mistranslation / refusal / tag break)12.5%~1,250 items

Discards mainly reflect nonsense source questions and translation drift. Input filtering is a proposed improvement.

Final estimate for a 10k-item run

ItemValue
Inputs10,000
LLM-JP seq (n)64
CAT-Translate seq (n×6, capped)140
Estimated runtime~25 min (hot)
VRAM usage~56 GiB / 153.6 GiB (36%)
Usable as-is (62.5%)~6,250 items
Including salvage (87.5%)~8,750 items

The estimate is 6,000–8,000 useful items in 25 minutes. At projected 36% VRAM use, a larger model or BF16 verification could also fit.

Horizontal scaling could add the same vLLM containers on other GPU nodes and distribute Dagster jobs round-robin. The near-linear time reduction is an estimate, not a measurement.

Operational picture: run the judge weekly

Instead of generating and reviewing 100k at once, use smaller batches. One proposal is Friday judging with remaining Claude capacity, discarding NGs and archiving the rest.

  • The generation side (vLLM) can run any time; just feed in chunks of input
  • Judge on the Claude side gets spread out based on rate limits and remaining quota
  • Judge results get stored as JSONL so aggregation and re-evaluation stay easy

Generation and judging can be paced to available capacity.

Proposed Dagster integration

The NVFP4 7B and 32B models fit on separate 96GB GPUs. At concurrency=32 they used about 23GB total. LLM-JP TG was 1,724 t/s versus CAT 263 t/s, about 6.5×.

The plan assigns CAT around six times as many sequences. A hot 256-item run took 57 seconds; 10k at around 25 minutes is projected.

This test used a standalone script. The next proposal splits work into Dagster assets/ops to manage scaling, retries, and judging.

Friday or other small judging batches could use remaining Claude and Codex capacity.