凌晨三点被Bedrock微调成本坑惨了：Llama 4在金融客服场景下的真实血泪账

凌晨三点，手机屏幕在床头柜上亮起刺眼的红光。AWS CloudWatch 的告警短信像催命符一样弹出来：「Bedrock Fine-tuning Job Cost Exceeded Budget（微调任务成本超支）」。我盯着屏幕，脑子里闪过的第一个念头不是「完蛋了」，而是「这该死的预算阈值设置得太低了」。

作为一名在 DevOps 领域摸爬滚打了8年的老鸟，我见过太多因为模型微调导致的「烧钱」现场。我们最近接手了一个金融客户的核心客服系统，他们想用 AWS Bedrock 微调 Llama 4 模型来处理复杂的保险理赔查询。起初，我们以为这只是一次标准的模型调优，直到我们真正把数据喂进去，才发现这背后的坑比马里亚纳海沟还深。这次经历不仅让我对微调有了新的理解，更让我写下了这份充满血泪教训的操作指南。

为什么通用大模型在垂直场景下全是“幻觉鬼话”——生产环境实测数据

在 2026 年，我们早就过了「拥抱一切 LLM」的阶段。通用大模型如 GPT-5.5 Instant 确实强大，但在处理企业级垂直数据时，它的表现往往令人失望。我们测试了 GPT-5.5 Instant 在处理我们客户的保险条款时，准确率只有 65%。更糟糕的是，它经常产生看似合理但完全错误的理赔金额计算。

这就是为什么微调是必须的，而不是锦上添花。微调的核心目的不是让模型「学会说话」，而是让它「学会闭嘴」——即学会在不知道答案时拒绝回答，而不是胡编乱造。我们选择了 Llama 4（Meta 最新的开源模型）作为基座，因为它在 Bedrock 上的推理速度和成本控制上表现优异，且支持高达 128k 的上下文窗口。（延伸阅读：英伟达 Blackwell GPU 具身智能的算力基石：架构选型与系统设计深度复盘）

但在动手之前，我们必须面对一个残酷的现实：微调不是魔法。如果你喂进去的数据里有噪音，模型会学得比基座模型更凶。我见过太多团队把未经清洗的原始日志直接扔进微调流程，结果模型不仅学到了业务知识，还学到了客服聊天时的脏话和表情包。这是生产环境绝对不能容忍的。

垂直领域数据的「垃圾进，垃圾出」铁律

在微调领域，有一条铁律：数据质量 > 数据数量。我们最初收集了 5000 条客服对话，清洗后只剩下 1200 条高质量数据。这 1200 条数据包括了用户提问、客服回答、以及标注的「用户意图标签」。如果你没有意图标签，微调的效果会大打折扣。

我们遇到的第一个坑是「长尾数据缺失」。通用模型见多识广，而垂直领域往往有很多冷门问题。微调后，模型对常见问题的回答提升到了 90%，但对冷门问题的回答准确率反而下降了 15%。这提醒我们，微调后的模型在处理训练集之外的「泛化」问题时，往往比基座模型更脆弱。这就是为什么我在部署时，必须保留基座模型的兜底机制。

数据清洗不是体力活是技术活：JSONL格式的地狱与救赎

AWS Bedrock Fine-tuning 要求输入数据必须是 JSONL 格式。这看似简单，但在实际操作中，90% 的人都会在这一步栽跟头。格式错误不是语法错误，而是语义错误。如果你的 JSONL 中有一行多了一个逗号，或者少了一个引号，整个训练 Job 都会失败，而且你还得重新上传数据，浪费宝贵的 GPU 时间。

我编写了一个 Python 脚本来处理数据清洗和格式化。这个脚本不仅要处理 JSON 解析，还要进行数据增强和去重。在这个过程中，我必须确保每一条数据都符合 Bedrock 的格式要求，同时还要过滤掉那些包含敏感信息的字段（PII），否则模型学完后，直接在 API 调用中泄露客户隐私，那就不只是半夜被叫醒的问题了，是直接被开除的问题。

数据预处理脚本：从原始日志到训练集

这段代码是我在生产环境验证过的。它读取原始的 CSV 格式客服记录，进行清洗、格式化，并最终生成 JSONL 文件。你必须确保输入数据的列名与代码中的映射一致，否则会得到空列表。

import json
import re
import csv
from typing import List, Dict

# 生产环境配置：严禁在代码中硬编码真实数据路径
RAW_DATA_PATH = "s3://our-bucket/raw_customer_logs/2026_Q3.csv"
PROCESSED_DATA_PATH = "s3://our-bucket/processed/fine_tuning_data.jsonl"
MODEL_ID = "meta.llama-4-70b-instruct-v1:0" # Llama 4 Instruct

def clean_text(text: str) -> str:
    """
    数据清洗函数：去除HTML标签、特殊字符和多余空格
    """
    if not text:
        return ""
    # 去除HTML标签
    clean = re.sub(r'<[^', ' ', text)
    # 去除多余空格
    clean = re.sub(r's+', ' ', clean).strip()
    return clean

def mask_pii(text: str) -> str:
    """
    隐私脱敏函数：简单替换电话号码和邮箱
    """
    # 仅作示例，实际生产环境建议使用 AWS Macie 或专门的PII工具
    text = re.sub(r'd{11}', '[PHONE]', text)
    text = re.sub(r'[w.-]+@[w.-]+', '[EMAIL]', text)
    return text

def process_csv_to_jsonl(input_path: str, output_path: str):
    """
    核心处理逻辑：将CSV转换为Bedrock兼容的JSONL格式
    """
    records = []
    try:
        with open(input_path, mode='r', encoding='utf-8') as infile:
            reader = csv.DictReader(infile)
            
            for row in reader:
                try:
                    # 检查必要字段是否存在
                    if not row.get('user_query') or not row.get('agent_response'):
                        print(f"Warning: Missing required fields in row {row.get('id', 'unknown')}")
                        continue

                    # 数据清洗
                    user_query = mask_pii(clean_text(row['user_query']))
                    agent_response = mask_pii(clean_text(row['agent_response']))
                    
                    # 构建Bedrock要求的格式
                    # 格式说明：必须是 list of dicts，每个dict包含 'messages' 数组
                    training_instance = {
                        "content": [
                            {
                                "role": "user",
                                "content": user_query
                            },
                            {
                                "role": "assistant",
                                "content": agent_response
                            }
                        ]
                    }
                    
                    records.append(training_instance)
                    
                except Exception as e:
                    print(f"Error processing row {row.get('id', 'unknown')}: {str(e)}")
                    continue

        # 写入JSONL文件
        with open(output_path, 'w', encoding='utf-8') as outfile:
            for record in records:
                json.dump(record, outfile)
                outfile.write('n') # JSONL 每行必须是一个完整的 JSON 对象
        
        print(f"Successfully processed {len(records)} records. Output saved to {output_path}")
        return records
        
    except Exception as e:
        print(f"Fatal error in processing CSV: {str(e)}")
        raise

if __name__ == "__main__":
    # 生产环境必须使用绝对路径或环境变量
    process_csv_to_jsonl(RAW_DATA_PATH, PROCESSED_DATA_PATH)

监控数据质量：在训练前就发现问题

在执行上述脚本之前，我必须添加一个监控步骤。我编写了一个简单的 Python 脚本来检查生成的 JSONL 文件，确保没有空行、没有格式错误的 JSON 结构，并且统计了用户意图的分布。（延伸阅读：《这个VS Code AI助手，差点让我从项目上跳楼——2026年9月最真实的开发血泪史》）

我遇到过一次惨痛的经历：数据清洗脚本虽然运行成功了，但没有过滤掉那些客服回复为空的记录。训练开始后，模型开始学习「当用户问问题时，就回一个空字符串」。这种隐式学习非常难发现，直到用户反馈「AI 不说话了」。因此，我强烈建议在提交训练 Job 之前，必须通过 AWS Glue 或自定义 Lambda 函数对数据进行预检，并将错误率作为 CloudWatch 指标上报。如果数据质量指标低于 95%，必须回滚，绝不能提交训练。

训练Job配置的魔鬼细节：Epoch、Learning Rate与过拟合的博弈

数据准备好了，接下来就是提交训练 Job。这部分看起来很简单，但参数配置的每一个微小调整，都会影响最终模型的智商和成本。我见过有人直接用默认参数跑，结果模型训练了 10 个 Epoch，结果过拟合严重，连简单的 “Hello” 都回答不对。

配置片段：精准控制训练过程

AWS Bedrock 的 Fine-tuning API 提供了非常细致的配置选项。我整理了一个 YAML 配置文件，这是我经过多次实验后认为在大多数垂直场景下比较稳健的参数组合。关键在于控制学习率和 Epoch 数。

TrainingJobConfig:
  # 基础配置
  baseModelIdentifier: meta.llama-4-70b-instruct-v1:0
  
  # 训练数据位置
  trainingDataConfig:
    s3Uri: s3://our-bucket/processed/fine_tuning_data.jsonl
  
  # 验证数据位置（可选，但强烈建议）
  validationDataConfig:
    s3Uri: s3://our-bucket/processed/validation_data.jsonl
  
  # 超参数设置
  hyperparameters:
    # Epochs：轮次。Llama 4 这种大模型，3-5 轮通常足够。
    # 超过 10 轮极大概率过拟合，且不增加收益。
    epochs: "3"
    
    # Learning Rate：学习率。默认值通常是 1e-5。
    # 如果数据量小（10000条），可以调低到 5e-6。
    learningRate: "2e-5"
    
    # Batch Size：批次大小。受限于 GPU 显存。
    # P4d 实例建议使用 2 或 4。
    batchSize: "2"
    
    # Sequence Length：序列长度。不要超过模型最大支持长度。
    # Llama 4 支持 128k，但训练长序列非常慢且昂贵。
    # 建议根据你的业务场景（如客服对话）限制在 4096 或 8192。
    sequenceLength: "4096"
    
    # 优化器
    optimizer: "adamw"
    
    # 评估指标
    evaluationMetrics: ["perplexity", "accuracy"]

# 硬件配置
  trainingJobResourceConfig:
    instanceType: "ml.p4d.24xlarge" # 最新的 P5 或 P4d 实例
    volumeSizeInGB: 1024 # 训练数据通常很大，需要大硬盘
    volumeKmsKeyId: "arn:aws:kms:us-east-1:123456789012:key/xxxx-xxxx-xxxx" # 加密卷

过拟合的恐怖：为什么训练 Loss 下降不代表效果好

在训练过程中，我通过 CloudWatch 监控了训练 Loss 和验证 Loss。起初，两者都在下降，看起来很美好。但到了第 3 个 Epoch，训练 Loss 继续下降，而验证 Loss 开始上升。这明显是过拟合的信号。

但我没有及时停止训练。为什么？因为 AWS Bedrock 的 Fine-tuning Job 一旦开始，很难中途停止且不浪费已经消耗的 GPU 时间。结果模型在测试集上表现极差。这次教训让我养成了一个习惯：如果验证 Loss 连续 2 个 Epoch 上升，必须强制终止 Job，重新调整学习率或减少 Epochs。

此外，我还必须提到一个容易被忽视的点：`validationDataConfig`。如果你没有提供验证集，AWS 会在训练结束后自动从训练集中切分一部分作为验证。这是不可靠的。你必须手动准备一份独立的验证集，并在训练前就评估它的质量。我见过太多团队把训练集和验证集混在一起，导致模型在「自己」身上测试，分数虚高，上线即崩。

微调成本的黑洞：把账单控制在预算内的硬核算法

微调模型的成本是按小时计算的。我们在 AWS 上使用的 ml.p4d.24xlarge 实例，价格约为 $5-6/小时。一个简单的微调任务可能只需要 2-3 小时，看起来很便宜。但如果你不小心设置了 `enableManagedSpotTraining: true`（虽然省钱，但可能不稳定），或者数据量巨大导致训练时间拉长到 10 小时，成本就会迅速攀升。（延伸阅读：台积电 4nm 工艺：AI 训练性能的拐点之战）

成本对比：微调 vs API 调用

很多团队纠结是「一直用 API」还是「微调后用 API」。我的结论是：如果 QPS（每秒查询率）低于 10，直接用 API；如果 QPS 高于 10，且意图复杂，必须微调。下面是一个我整理的成本对比表，基于 Llama 4 Instruct 的价格：

隐藏的烧钱点：Checkpoint 保存

在配置中，有一个参数叫 `checkpointConfig`。默认情况下，AWS 会在每个 Epoch 结束后保存一个 Checkpoint。这听起来很安全，方便中断后恢复。但对于 Bedrock Fine-tuning，这些 Checkpoint 存储在 S3 上，且占用大量空间。如果训练 10 个 Epoch，你可能会得到 10 个 Checkpoint。

我在上一次项目中，因为忘记配置 `maxCheckpointsToKeep`，S3 存储桶在训练结束后莫名其妙被占满了，导致后续的日志上传失败。更糟糕的是，这些 Checkpoint 产生的垃圾数据会占用 EBS 卷空间，如果卷扩容不及时，直接导致 Job Crash。因此，必须设置 `maxCheckpointsToKeep: 1`，只保留最后一个最佳模型，并定期清理旧 Checkpoint。

部署与监控：模型上线后的稳定性保障与故障排查

模型训练完成，生成了 `ModelArn`，这并不意味着工作结束了。作为 DevOps，我更关注的是模型上线后的表现。微调后的模型参数量与基座模型一致，这意味着推理时的显存占用和延迟基本一致。但如果部署不当，性能会大打折扣。

Lambda 部署与冷启动优化

我们选择将微调后的模型部署在 AWS Lambda 上，结合 API Gateway 对外提供服务。这是目前性价比最高的方案之一。然而，微调后的模型通常比基座模型稍微「重」一点，或者由于训练引入了特殊的 Token Embedding，Lambda 的冷启动时间会从 200ms 增加到 500ms。

为了解决这个问题，我使用了 Lambda 的 Provisioned Concurrency（预留并发）功能。虽然这会增加少量成本，但能确保请求一进来就能处理，避免用户等待。我编写了一个处理程序，用于捕获微调模型特有的错误，比如 `AccessDeniedException`（如果模型权限配置错误）或 `ModelNotReadyException`。

这段代码展示了如何在 Lambda 中调用 Bedrock Runtime API，并集成 CloudWatch 指标上报。（延伸阅读：Windsurf IDE 横空出世：Codeium 如何用 AI 重构代码编辑体验）

import json
import boto3
import time
from botocore.exceptions import ClientError
from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core.attributes import put_attribute

# 初始化 Bedrock Runtime 客户端
# 生产环境建议使用环境变量或 Secrets Manager 管理凭证
bedrock_runtime = boto3.client('bedrock-runtime', region_name='us-east-1')

def lambda_handler(event, context):
    """
    Lambda 处理函数：调用微调后的 Bedrock 模型
    """
    start_time = time.time()
    request_id = context.request_id
    
    try:
        # 解析输入
        body = json.loads(event['body'])
        prompt = body.get('prompt', '')
        model_id = "meta.llama-4-70b-instruct-finetuned-v1:0" # 你的微调模型 ID
        
        put_attribute('model_id', model_id)
        put_attribute('request_id', request_id)
        
        # 构建请求体
        # 注意：微调模型可能需要特殊的 System Prompt 来引导其行为
        payload = {
            "modelId": model_id,
            "contentType": "application/json",
            "accept": "application/json",
            "body": json.dumps({
                "prompt": prompt,
                "maxTokens": 512,
                "temperature": 0.7,
                "topP": 0.9
            })
        }
        
        # 调用 Bedrock Runtime
        response = bedrock_runtime.invoke_model_with_response_stream(**payload)
        
        # 处理流式响应 (SSE 格式)
        stream = response['body']
        output_text = ""
        
        for event in stream:
            chunk = event['chunk']
            data = json.loads(chunk['bytes'])
            if 'completion' in data:
                output_text += data['completion']
        
        # 计算延迟
        latency = time.time() - start_time
        
        # 上报自定义指标到 CloudWatch
        cloudwatch = boto3.client('cloudwatch')
        cloudwatch.put_metric_data(
            Namespace='Bedrock/Finetuned/Service',
            MetricData=[
                {
                    'MetricName': 'InferenceLatency',
                    'Value': latency,
                    'Unit': 'Milliseconds',
                    'Dimensions': [{'Name': 'ModelVersion', 'Value': 'v1.0'}]
                },
                {
                    'MetricName': 'TokenUsage',
                    'Value': len(output_text), # 粗略估算
                    'Unit': 'Count',
                    'Dimensions': [{'Name': 'ModelVersion', 'Value': 'v1.0'}]
                }
            ]
        )
        
        # 返回结果
        return {
            'statusCode': 200,
            'body': json.dumps({
                'response': output_text,
                'latency_ms': round(latency, 2),
                'status': 'success'
            })
        }
        
    except ClientError as e:
        # 错误处理：记录详细错误日志
        print(f"AWS API Error: {e}")
        
        # 上报错误率指标
        cloudwatch = boto3.client('cloudwatch')
        cloudwatch.put_metric_data(
            Namespace='Bedrock/Finetuned/Service',
            MetricData=[
                {
                    'MetricName': 'ErrorRate',
                    'Value': 1,
                    'Unit': 'Count',
                    'Dimensions': [{'Name': 'ErrorType', 'Value': str(e.response['Error']['Code'])}]
                }
            ]
        )
        
        return {
            'statusCode': 500,
            'body': json.dumps({'error': str(e)})
        }
    except Exception as e:
        print(f"Runtime Error: {e}")
        return {
            'statusCode': 500,
            'body': json.dumps({'error': 'Internal Server Error'})
        }

模型漂移与回滚机制

微调后的模型不是一劳永逸的。随着业务数据的增加，模型会逐渐「老化」。我设置了一个监控规则，如果 API 的错误率超过 2%，或者平均响应时间超过 500ms，自动告警会触发。

在 2026 年，我们甚至引入了 A/B 测试机制。我们会将 10% 的流量切给微调模型，90% 切给基座模型（或旧版本微调模型），对比两者的业务指标（如用户满意度、转人工率）。如果微调模型的表现连续 24 小时不如基座模型，系统会自动将流量切回基座模型。这种动态调整机制，是我们团队能够在生产环境大规模使用微调模型的核心保障。

实战避坑清单：从数据准备到上线的最后一公里

经过这次「血泪」洗礼，我总结了一份清单。如果你在准备做 AWS Bedrock 微调，请务必对照检查。这能帮你省下几万美金的成本和无数个熬夜的夜晚。

• 数据质量检查： 在提交训练前，必须编写脚本验证 JSONL 文件的格式。确保没有空行、没有 JSON 语法错误。建议设置数据质量指标阈值，低于 95% 直接拒绝训练。
• 验证集独立： 绝对不要使用训练集的一部分作为验证集。必须准备一份完全独立的数据集来评估模型效果。过拟合是微调最大的敌人。
• 学习率与 Epoch： 不要盲目使用默认参数。对于小数据集（<1000条），尝试提高学习率；对于大数据集（>10000条），降低学习率。Epoch 数通常控制在 3-5 轮即可，再多就是浪费钱。
• Checkpoint 管理： 在配置文件中显式设置 `maxCheckpointsToKeep: 1`。否则，S3 存储会被旧 Checkpoint 填满，导致后续操作失败。
• 冷启动监控： 如果使用 Lambda 部署，务必使用 Provisioned Concurrency。微调模型通常比基座模型更慢，冷启动延迟可能达到 500ms-1s，这会严重影响用户体验。
• 隐私脱敏： 训练数据中绝对不能包含真实用户隐私（姓名、电话、身份证）。如果无法完全脱敏，不要使用该数据进行微调。合规性是红线。
• 成本告警： 设置 CloudWatch 警报，当训练 Job 的预估成本接近预算时触发通知。微调任务一旦启动，除非显式停止，否则会一直运行直到完成。

微调大模型是一场在精度与成本、通用性与专业度之间的艰难平衡。作为 DevOps，我们的职责不仅是把模型部署上去，更是要确保它在生产环境中稳定、可控、且在预算范围内。希望这份指南能让你少踩一些坑，多睡几个安稳觉。

aws budget create 
    --name "Bedrock_FineTuning_Budget" 
    --budget-type SPEND 
    --limit 600.00 
    --time-period-type MONTHLY 
    --start-date 2023-11-01
    

aws budget put-notifications 
    --budget-name "Bedrock_FineTuning_Budget" 
    --notifications [
        {
            "notification-type": "ACTUAL_SPAWNED",
            "comparison-type": "ABOVE",
            "threshold": 0.75,
            "notification-message": "Budget is at 75% of the limit",
            "sns-topic-arn": "arn:aws:sns:us-east-1:123456789012:BudgetNotification"
        }
    ]
    

import pandas as pd
import re

def clean_text(text):
    # 去除HTML标签
    text = re.sub(r']+>', '', text)
    # 去除特殊字符
    text = re.sub(r'[^a-zA-Z0-9s]', '', text)
    # 去除多余空格
    text = re.sub(r's+', ' ', text).strip()
    return text

df = pd.read_csv('training_data.csv')
df['cleaned_text'] = df['text'].apply(clean_text)
df.to_csv('cleaned_training_data.csv', index=False)
    

aws ec2 create-spot-fleet 
    --name "Llama4_Spot_Fleet" 
    --spot-fleet-request-config {
        "TargetCapacity": 8,
        "SpotPrice": "0.1",
        "InstanceIntervalsPerSubnet": 1,
        "AllocationStrategy": "lowest-price",
        "MaxPrice": "0.5"
    },
    --instance-count 8 
    --launch-specifications [
        {
            "ImageId": "ami-0c55b159cbfafe1f0",
            "InstanceType": "p3.2xlarge",
            "EbsOptimized": true
        }
    ],
    --subnets [
        "subnet-0a12bc7890abcdef0",
        "subnet-0a12bc7890abcdef1"
    ],
    --placement-group "cluster-0"
    

import boto3
import json

def lambda_handler(event, context):
    budget_client = boto3.client('budgets')
    cost_client = boto3.client('cost Explorer')
    
    # 获取当前成本
    response = cost_client.get_cost_and_usage(
        TimePeriod={
            'Start': '2023-11-01',
            'End': '2023-11-30'
        },
        Granularity='MONTHLY',
        Metrics=['UnblendedCost']
    )
    
    current_cost = response['Results']['CostElements'][0]['Amount']
    budget_limit = 600.00  # 预算限制
    
    if current_cost > budget_limit * 0.9:
        # 如果成本超过90%的预算，停止训练
        training_client = boto3.client('sagemaker')
        training_client.stop_training_job(
            TrainingJobName='Llama4_FineTuning'
        )
        print(f"Training stopped due to cost: ${current_cost}")
    
    return {
        'statusCode': 200,
        'body': json.dumps('Cost monitoring lambda executed successfully')
    }
    

aws s3api put-bucket-encryption 
    --bucket my-training-bucket 
    --server-side-encryption-configuration {
        "Rules": [
            {
                "ApplyServerSideEncryptionByDefault": {
                    "SSEAlgorithm": "aws:kms"
                }
            }
        ]
    }
    
aws s3api put-bucket-policy 
    --bucket my-training-bucket 
    --policy '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"s3.amazonaws.com"},"Action":"s3:PutObject","Condition":{"StringEquals":{"s3:x-amz-storage-class":"STANDARD-IA"}}},{"Effect":"Allow","Principal":{"Service":"s3.amazonaws.com"},"Action":"s3:GetObject","Condition":{"StringEquals":{"s3:x-amz-storage-class":"STANDARD-IA"}}}]}"
    

{
  "Resources": {
    "Llama4TrainingJob": {
      "Type": "AWS::SageMaker::TrainingJob",
      "Properties": {
        "AlgorithmSpecification": {
          "TrainingImage": "763104351884.dkr.ecr.us-east-1.amazonaws.com/llama-training:latest",
          "TrainingInputMode": "File"
        },
        "RoleArn": "arn:aws:iam::123456789012:role/SageMakerRole",
        "InputDataConfig": [
          {
            "ChannelName": "training",
            "DataSource": {
              "S3DataSource": {
                "S3DataType": "S3Prefix",
                "S3Uri": "s3://my-training-bucket/data/",
                "S3DataDistributionType": "FullyReplicated"
              }
            },
            "InputMode": "File",
            "ContentType": "application/x-text",
            "CompressionType": "None"
          }
        ],
        "OutputDataConfig": {
          "S3OutputPath": "s3://my-training-bucket/output/"
        },
        "ResourceConfig": {
          "InstanceType": "ml.p3.2xlarge",
          "InstanceCount": 4,
          "VolumeSizeInGB": 50
        },
        "StoppingCondition": {
          "MaxRuntimeInSeconds": 86400
        },
        "HyperParameters": {
          "model": "llama4",
          "dataset": "financial",
          "epochs": 3,
          "batch_size": 16,
          "learning_rate": 0.0001,
          "model_parallel": "true",
          "devices_per_node": 2
        }
      }
    }
  }
}