AWS Builder Center: Learn, Build and Connect with builders in the AWS community
AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.
Fine-tune an Open-Weight Model on Amazon Bedrock to Generate EDA Tcl Scripts with Reinforcement Fine-Tuning
This article shows how to use reinforcement fine-tuning (RFT) on Amazon Bedrock to improve an open-weight model's ability to generate correct, tool-specific Tcl automation scripts for semiconductor and EDA workflows while keeping proprietary design methodology inside your own AWS account. It walks through the end-to-end workflow so an engineering team can go from concept to a measurable accuracy gain.
Semiconductor and Electronic Design Automation (EDA) customers drive their design tools (Synopsys, Cadence, Siemens) largely through Tcl (and Perl). General-purpose code models are strong at Python but noticeably weaker at tool-specific Tcl idioms — producing plausible-but-wrong scripts that, in a design flow, are worse than none.
Because Tcl correctness is programmatically verifiable ("does the script parse and run?"), this is a textbook fit for reinforcement fine-tuning (RFT), which AWS documentation explicitly recommends for "code generation using rule-based graders." This best practice shows how a TAM can help an EDA customer stand up an RFT job on Amazon Bedrock that improves an open-weight model's Tcl generation — while keeping proprietary design methodology inside the customer's own AWS account.
RFT for open-weight models (GPT-OSS and Qwen3-32B) became available on Amazon Bedrock in mid-February 2026.
Solution overview
The workflow: prepare a JSONL dataset of Tcl prompts → upload via the OpenAI-compatible Files API → launch an RFT job against an open-weight base model → Bedrock generates multiple candidate responses per prompt and scores each with your AWS Lambda reward function → GRPO optimizes the model toward higher reward → run inference on the fine-tuned model through the same OpenAI-compatible API.
Best Practice
-
Confirm scope and Region. RFT for open-weight models is available for
openai.gpt-oss-20bandqwen.qwen3-32b, both in US West (Oregon),us-west-2, via the OpenAI-compatible endpointbedrock-mantle.us-west-2.api.aws. Choose Qwen3-32B for broader code coverage (recommended here) or GPT-OSS-20B as the alternative. -
Prepare the training dataset. Bring prompts in JSONL, OpenAI chat-completion format, uploaded with purpose
fine-tune. Minimum 100 records (max 20,000); start with 100–200 and scale. Each example has amessagesarray (system + user prompt) and areference_answeryour reward function uses to score the response:{"messages":[{"role":"system","content":"You generate Tcl for <EDA tool>"}, {"role":"user","content":"Create a false path from clkA to clkB"}], "reference_answer":{"expected_commands":["set_false_path"]}} -
Upload the dataset with the Files API using the OpenAI SDK pointed at the Bedrock endpoint; capture the returned file ID.
from openai import OpenAI # OPENAI_BASE_URL -> bedrock-mantle.us-west-2.api.aws client = OpenAI() f = client.files.create(file=open("tcl_prompts.jsonl","rb"), purpose="fine-tune") training_file_id = f.id -
Define the reward function (the core of the workflow). RFT scores responses with a custom AWS Lambda grader. For an objective task like Tcl, implement a rule-based grader that: (a) checks the generated Tcl parses (e.g., a
tclshsyntax check), (b) optionally lints/dry-runs it, and (c) rewards use of the correct tool commands fromreference_answer. Return anaggregate_reward_scoreplus ametrics_list. Increase the Lambda timeout from the 3-second default toward the 15-minute maximum for heavier checks.
def lambda_handler(event, context): results = [] for item in event: tcl = item["messages"][-1]["content"] # assistant response ref = item.get("metadata", {}).get("reference_answer", {}) syntax_ok = tcl_parses(tcl) # e.g. `tclsh -n` cmd_score = command_overlap(tcl, ref) # expected commands present? score = 0.6 * float(syntax_ok) + 0.4 * cmd_score results.append({ "id": item["id"], "aggregate_reward_score": score, "metrics_list": [ {"name": "syntax_valid", "value": float(syntax_ok), "type": "Reward"}, {"name": "command_accuracy", "value": cmd_score, "type": "Metric"}, ], }) return results
-
Launch the RFT job using the OpenAI-compatible fine-tuning API, specifying the base model, the uploaded dataset file ID, and the reward function. Bedrock runs the training loop using Group Relative Policy Optimization (GRPO) — generating multiple responses per prompt and optimizing toward the reward.
-
Monitor training. Track job events, reward metrics, and checkpoints via the fine-tuning APIs. Watch for the warning signs the docs call out — rewards plateauing below 0.15, rising reward variance, or validation performance declining (overfitting).
-
Run inference and evaluate. Once complete, call the fine-tuned model directly through Bedrock's OpenAI-compatible Responses / Chat Completions APIs — no separate deployment step. Measure the percentage of generated Tcl scripts that pass a clean
tclshparse, base model vs. fine-tuned, to quantify the gain (docs cite up to ~66% average accuracy improvement across RFT use cases).
Data handling: Keep all example prompts and scripts generic — do not include a customer's proprietary Tcl, real project names, or account IDs. During RFT, customer data stays within the AWS governed environment and is not used to train base models.
References
- Language
- English
Relevant content
asked 3 years ago
asked a year ago
