在 H200 GPU 上微调 TranslateGemma-4B 以优化英语与威尔士语的双向翻译！

# 在 H200 上针对威尔士语微调 TranslateGemma-4B：数据策略、LoRA 训练与 GGUF 部署 来源: https://metalglot.com/blog/welsh-translategemma-finetuning-guide/ 威尔士语正是那种能暴露通用翻译微调局限性的语言。法律用语、威尔士议会（Senedd）辩论、政府术语和字典定义的表现各不相同，因此“只是增加更多双语行”并不是一种严肃的策略。如果目标是实现稳健的英威/威英双向翻译，同时保持模型仍像是一个具备指令遵循能力的智能体，那么训练配方（training recipe）的重要性至少不亚于硬件。 本指南是该实验的实用版本。它解释了为什么 TranslateGemma-4B 是合适的基座模型，为什么 NVIDIA H200 是最务实的单 GPU 选择，数据集是如何刻意重新平衡的，为什么某些语料库被下采样或排除，实际脚本输出的样子，以及最终模型是如何合并并转换以供本地推理使用的。 如果你只关心主要结果，结论如下：在一台 H200 上进行的 5% 试点运行大约在 40 分钟内完成，数据集保持了接近 70:30 的翻译与指令混合比例，整个项目的核心目的是在不将模型变成狭窄的“总是翻译”系统的前提下，改善威尔士语翻译。关于为何专用翻译模型能胜过更大的通用基线模型，请参阅 Inside TranslateGemma (https://metalglot.com/blog/gemma-translate/)。 在查看原始日志之前先说明一点：这篇文章结合了来自同一项目的多个工作草稿和真实工件。我故意保留了命令、控制台输出和 JSON 块的原貌，即使它们反映的是配方的相邻迭代版本，而非一个冻结的快照。这比精心重构的版本更有用，因为它展示了实际流程中的真实情况。 如果你正在评估针对其他代表性不足语言的类似微调任务，本文应帮助你在以下方面做出真实决策： - 对于未包含在官方监督微调（SFT）集中的语言，TranslateGemma 是否是合适的基座模型？ - 单张 H200 是否足以进行一次可信的试点运行？ - 你的数据集需要更大的规模，还是更好的平衡？ ## 为什么值得微调威尔士语 威尔士语并不缺乏双语文本，但其分布在不同领域中极不均匀。法律文本、议会记录、政府用语和术语数据库都具有不同的价值。这使得威尔士语成为一个很好的例子，说明低资源或中等资源的翻译工作不能仅靠行数来解决。 标准的 TranslateGemma-4B 为 55 种语言提供了高质量的微调翻译，但威尔士语并非官方微调指令集的一部分。它属于更广泛的“第二梯队”语言群体，这些语言存在于 Gemma-3 的预训练基础模型中，但未获得相同的直接翻译专业化处理。更多关于这种生产就绪框架的信息，请参阅 TranslateGemma 语言质量层级：何时直接翻译 vs 通过英语中转 (https://metalglot.com/blog/gemma-translate-insights/)。 正是这种差距使得威尔士语在此处显得有趣。基础 Gemma-3 已经显示出一定的零样本威尔士语能力，但这与可靠、面向生产的翻译行为并不相同。该项目是一个概念验证，旨在通过透明、可复现的微调管道和一个开放仓库 finetuned-gemmatranslate-cy (https://github.com/grctest/finetuned-gemmatranslate-cy) 来缩小部分差距。该仓库中的脚本采用 MIT 许可证，你可以自由遵循和改编工作流，但你仍应审查基座模型、使用的每个数据集以及依赖的任何加速包所附带的许可证。 ## 为什么 TranslateGemma 是合适的基座模型 TranslateGemma-4B 适合威尔士语有一个简单的原因：模型和仓库在任务框架上已经达成一致。翻译行通过 TranslateGemma 的聊天模板呈现，带有明确的源语言和目标语言代码，而指令行则呈现为标准用户-助手轮次。这很重要，因为微调并不是试图教一种通用提示格式去拙劣地处理所有事情。它是在模型已经预期的结构中教导模型。 训练循环还使用了仅完成损失（completion-only loss）。实际上，这将优化压力集中在模型的回答上，而不是惩罚提示词令牌。结合混合翻译和指令的配方，结果是在改善威尔士语翻译的同时，更有可能保留使模型在单一狭窄提示形状之外仍具可用性的行为。 这种区别比听起来更重要。仅翻译的微调绝对可以改善双语映射，但也可能推动模型走向反射性翻译行为，并削弱通用指令遵循能力。对于本项目，目标不是“一个只会做威尔士语翻译的引擎”。目标是成为一个具备翻译能力的大型语言模型（LLM），同时作为助手保持实用性。 ## 为什么 H200 是务实的单 GPU 选择 本仓库中的实际训练目标是 `H200F` 配置文件。它是代码库中针对 LoRA 训练最具侵略性的单 GPU 配置文件，其存在是为了回答一个非常具体的问题：在需要重新设计整个运行之前，你能将单张 H200 的性能推到什么程度？ 关键设置如下： - `per_device_train_batch_size=12` - `gradient_accumulation_steps=8` - 有效批次大小 = 96 - `max_seq_length=2048` - `bf16=True` - `gradient_checkpointing=True` - `packing=True` - `optimizer=adamw_torch_fused` - 本文后面显示的日志试点运行的 `dataset_fraction=0.05` 该配置非常适合 NVIDIA H200，因为它允许运行保持合理的上下文窗口，利用序列打包（sequence packing），并使用 Hopper 类硬件可用的最快稳定注意力路径。在训练脚本中，后端选择是明确的：如果启用了 Flash Attention 且机器看起来像 Hopper，代码首先尝试使用 Flash Attention 3，否则回退到 SDPA。 换句话说，选择 H200 并不仅仅是因为抽象上拥有更多的 VRAM。它是为了获取本仓库所用确切软件栈的稳定、快速路径。`H200F` 配置文件围绕 H200 的 141 GB HBM3e 内存进行调整，这为更大的批次大小和打包的 2048 令牌序列提供了足够的余地，而不会立即迫使妥协。在这里保留 `2048` 也是刻意的，因为它与 Google 在 TranslateGemma 技术报告 (https://arxiv.org/abs/2601.09012) 中描述的序列长度机制保持一致，而不是为威尔士语运行发明一个截然不同的微调设置。 这种权衡在试点运行中显现出来。使用该配置文件，训练集的 5% 切片在单张 H200 上大约在 40 分钟内完成。 ## 扩展运行：时间、成本和多 GPU 权衡 40 分钟的试点运行证明了该配方对于完整的 100% 训练运行是可行的。完全遍历 135 万行规模的数据集需要处理的数据量要大得多，是几天与几小时的差别。我们仅运行了 5% 以证明一切正常，未来我们（或你）可以使用更多的计算资源运行 100% 的全量训练。 基于记录的基准测试： - **单 GPU 基线**：在 1 张 H200 上的完整运行将大约需要 **33 小时**。 - **多 GPU 路径**：使用 `accelerate` 和 `deepspeed` 的 **8 张 H200** 集群可以将时间压缩至大约 **4.5 小时**。 这是真正的决策点。如果你正在验证数据配方，一张 H200 就足够了。如果你试图实现当天的完整运行，多 GPU 很快就会变得有意义。框架已经为下一步做好了准备，一旦基础设施值得投入成本，相同的逻辑应能进一步扩展到 12B 或 27B 的 TranslateGemma 变体。 更大的模型可能需要不同的配置文件，如果你运行多 GPU 设置，则可能需要一些重构以最好地利用 accelerate 和 deepspeed。 我们使用 Hopper 系列 GPU 是因为其庞大的 VRAM、对 Flash Attention v3 的支持以及对 bfloat16 的支持。我们尝试在 Blackwell GPU 上使用 Flash Attention v4 运行脚本，但发现 beta 版本尚不兼容我们的 Gemma 3 微调技术栈；未来当 v4 完全开发出来时，我们可以评估从 H200 升级到 B200 进行微调任务所能带来的速度提升。 ### 实际运行成本 财务透明度在这里很重要，因为微调项目往往听起来比实际更昂贵。对于此次运行，实际参考点是 Verda (https://verda.com/)（前身为 DataCrunch）上的现货和按需定价： | 实例类型 | 定价（约） | 完整 4B 运行（估算） | | :--- | :--- | :--- | | **1x H200 (Spot)** | ~$1.20 / 小时 | ~$39.60 | | **1x H200 (On-Demand)** | ~$3.40 / 小时 | ~$112.20 | | **8x H200 (On-Demand)** | ~$27.20 / 小时 | **~$122.40** (按 4.5 小时计) | 这是该项目更有趣的结果之一。对于完整的 8 GPU 微调，成本约为 **$122.50**，进行严肃的威尔士语翻译实验的门槛比许多人预期的要低。困难的部分不在于租赁账单，而在于构建值得使用这些硬件的数据集所需的纪律性。 ## 环境设置和 Python 栈 来自仓库的最小化环境仍然很简短。这很有用，因为它保持了设置的诚实性。 ``` python -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt pip install flash_attn_3 --find-links https://windreamer.github.io/flash-attention3-wheels/cu128_torch2110 hf auth login ``` 对于记录的 H200 运行，栈是基于 CUDA 12.8 构建的。这很重要，因为 Flash Attention 轮子和 GPU 路径是围绕该环境选择的，而不是被视为模糊的“最新 CUDA”设置。 在数据准备开始之前，`01_prepare_data.py` (https://github.com/grctest/finetuned-gemmatranslate-cy/blob/main/01_prepare_data.py) 中的准备阶段验证 `./local_model` 是否包含完整的本地 TranslateGemma 快照。这包括分词器文件、处理器配置和模型权重，以便后续阶段可以加载 `AutoProcessor` 和 `AutoModelForImageTextToText` 而不会在管道中途失败。 ### 核心 Python 包实际做了什么 这些库不是偶然的依赖项。每一个都映射到工作流程的具体部分： - **transformers**: 加载 TranslateGemma、分词器以及微调和推理期间使用的标准模型 API。 - **torch**: 处理张量数学、GPU 执行、内存分配和底层训练运行时。 - **datasets**: 在训练之前高效地加载、过滤、采样和去重威尔士语-英语语料库。 - **peft**: 实现 LoRA，以便运行训练轻量级适配器，而不是更新每个模型参数。 - **trl**: 提供 `SFTTrainer`、序列打包以及 `02_finetune.py` 中使用的微调循环。 - **huggingface_hub**: 管理身份验证并将模型资产下载到本地快照。 - **sentencepiece**: 是 Gemma 分词化和模型期望的子词分段所必需的。 - **pillow**: 仍然需要，因为 TranslateGemma 继承了来自 PaliGemma 系谱的多模态处理器期望，即使在以文本为主的工作流中也是如此。 - **matplotlib**: 支持 `01b_analyze_token_lengths.py` 中的令牌长度可视化，有助于证明所选 `max_seq_length` 的合理性。 该包列表也解释了为什么此工作流程不仅仅是一个围绕单一训练脚本的薄包装。它是一个完整的数据准备、微调、分析、合并和推理管道。 ### 将此工作流程用于另一种语言 如果你的目标不仅仅是威尔士语，而是“如何为另一种语言微调 TranslateGemma”，令人鼓舞的答案是，整体方法转移得很好。需要注意的是，数据适配器通常不能直接转移。 在实践中，大多数人需要修改的第一个文件是 `01_prepare_data.py` (https://github.com/grctest/finetuned-gemmatranslate-cy/blob/main/01_prepare_data.py)。不同的双语语料库很少共享相同的字段名称、分割结构、元数据列或语言代码约定。如果你用另一种语言对的威尔士语数据集进行替换，你应该预期需要编辑数据集加载逻辑、行规范化规则以及任何假设特定威尔士语资源（如 TermCymru）的合成示例生成。 配方可复用的部分如下： - 将每个源规范化为任务、源文本、目标文本和语言代码的同一扁平契约 - 将翻译监督和指令遵循数据作为单独的设计选择保留，而不是混合成一堆 - 在每次重大配方更改后重新运行 `01b_analyze_token_lengths.py` (https://github.com/grctest/finetuned-gemmatranslate-cy/blob/main/01b_analyze_token_lengths.py)，而不是假设威尔士语令牌配置文件会转移 - 验证语言代码和提示格式是否仍匹配你想要训练针对的 TranslateGemma 模板 如果你想将本文扩展至布列塔尼语、康沃尔语、盖尔语或任何其他语言，这才是真正的教训：微调机制相当可复用，但数据塑形层是大多数工程工作所在的地方。 ## 数据策略：平衡胜过原始规模 毁掉翻译微调的最简单方法之一就是不断添加语料库，并假设模型会自行理清。这不是此处的目标。目标是创建一个足够广泛的数据集，以涵盖法律、议会、行政和术语密集的威尔士语，同时保留足够的指令数据，以防止模型退化为狭窄的仅翻译行为。 主要目标是大约 `70:30` 的翻译与指令混合物。该比例比为了增加行数而最大化行数更重要。它迫使每个数据集选择回答同一个问题：这是否改善了我们真正想要的模型，还是只是让数据集变大？ 以下是主要的翻译和术语来源： - `techiaith/legislation-gov-uk_en-cy`: 高价值的法律和法定英威文本，有助于稳定的术语和正式结构。 - `techiaith/cofnodycynulliad_en-cy`: 威尔士议会记录，增加了真实威尔士机构文本中常见的公共部门和议会语言。 - `techiaith/bydtermcymru-tm-en-cy`: 帮助覆盖通用语料库通常扁平化的领域特定词汇的术语记忆数据。 - `AndreasThinks/welsh-government-pairs`: 紧凑但有用的对齐公共部门翻译对。 - `TermCymru/TermCymru`: 权威术语数据，用于直接翻译监督以及合成指令-定义对。 这也是克制很重要的地方。卡迪夫大学翻译记忆库和 OPUS 都受到了保守对待： - `techiaith/cardiff-university-tm-en-cy` 即使规模很大，也被限制在 `usage=0.1`。 - `Helsinki-NLP/opus-100` 在此次运行中保持在 `usage=0.0`。 这是刻意的。问题不在于这些数据集不好。问题在于翻译体积已经足够强大，足以淹没指令侧。如果卡迪夫大学的数据集从 `0.1` 跳到 `1.0`，其构建的双语行将从 `290,600` 增加到大约 `2,906,018`。如果 OPUS 也移动到 `1.0`，这将再增加 `289,521` 行。在去重之前，这意味着大约 `2,904,939` 额外的翻译行。 使用当前运行摘要作为基线，翻译行将从约 `1,120,776` 增加到约 `4,025,715`。为了保持相同的 $70:30$ 混合物，指令行则需要达到约 $4,025,715 \times 30/70 \approx 1,725,306$。本次运行当前使用 `412,135` 条指...