Fine-Tuning Qwen3-27B for C-to-Rust Code Translation: A Three-Stage Curriculum of Pretraining, Debugging-Aware SFT, and Task-Specific SFT

Pu Zhao; Changdi Yang; Yixiao Chen; Yi Gao; Yifan Cao; Haochen Zeng; Yanzhi Wang

Source-linked AI summary

Fine-Tuning Qwen3-27B for C-to-Rust Code Translation: A Three-Stage Curriculum of Pretraining, Debugging-Aware SFT, and Task-Specific SFT

Pu Zhao, Changdi Yang, Yixiao Chen, Yi Gao, Yifan Cao, Haochen Zeng, Yanzhi Wang

arXiv:2608.13681v1Aug 13, 2026cs.SEcs.AIcs.ET

TL;DR

Automated C-to-Rust translation could improve the safety of legacy systems, but general-purpose LLMs often lack idiomatic Rust and debugging capabilities. This paper specializes Qwen3-27B through a three-stage curriculum and achieves an 87.2% success rate under SACTOR evaluation.

Problem
Automated C-to-Rust translation matters for reducing memory-safety vulnerabilities in legacy systems, but manual migration is slow, expensive, and error-prone.
Method
The paper applies Rust-focused pretraining, debugging-aware SFT, and task-specific C2Rust SFT to Qwen3-27B, evaluated with SACTOR’s verification-driven framework.
Results
87.2% success rate: the fine-tuned 27B model outperforms MiniMax-M2.5 and GLM-5 despite their substantially larger parameter counts.
Takeaways & Limitations
On this benchmark, task-specific specialization can compensate for a substantial model-scale disadvantage in C-to-Rust translation.
Takeaways & Limitations
Stage 3 excludes full-codebase data, leaving the model without exposure to multi-file, cross-function structural complexity.

Abstract

from arXiv · show

Translating C code into safe, idiomatic Rust is a longstanding software-engineering goal because it can eliminate entire classes of memory-safety vulnerabilities while preserving the functional behavior of legacy systems. Large language models (LLMs) have shown promise for this task but typically underperform when applied off-the-shelf, since general-purpose pretraining rarely emphasizes idiomatic Rust generation, cross-language semantic equivalence, or the ability to reason about and repair compiler/runtime feedback. In this report we describe a three-stage fine-tuning curriculum applied to Qwen3-27B that is designed to progressively specialize the model for the C-to-Rust (C2Rust) translation task: (1) continued pretraining on Rust-centric corpora to strengthen the model's prior over idiomatic Rust syntax and standard-library usage; (2) supervised fine-tuning (SFT) on the microsoft/Verus_Training_Data dataset to instill debugging and self-repair behavior over Rust code; and (3) task-specific SFT on paired C/Rust solutions derived from LeetCode problems to teach direct semantic translation. We evaluate the resulting model using the agentic, static-analysis-guided verification framework of SACTOR, which performs structure-aware, two-phase (unidiomatic to idiomatic) translation with foreign-function-interface (FFI)-based end-to-end (E2E) testing. We report success rate, idiomaticity (Clippy lint counts, unsafe-code fraction), and failure-mode analyses, and compare our fine-tuned model against baseline Qwen3-27B and other LLMs evaluated under the same framework.

1 Introduction

The report targets safer, more idiomatic C-to-Rust translation by specializing Qwen3-27B through a three-stage curriculum. It evaluates the resulting model with SACTOR’s agentic, feedback-driven verification framework, achieving an 87.2% success rate.

Motivation: Rust’s ownership and borrowing model provides compile-time memory safety without garbage collection, addressing vulnerabilities inherent in C’s manual memory management.The motivation includes buffer overflows, use-after-free errors, and memory leaks in performance-critical and systems-level C software.
Three-stage curriculum: The curriculum specializes Qwen3-27B through Rust-focused continued pretraining, debugging-oriented SFT, and task-specific C/Rust SFT.The stages target Rust syntax and idioms, error interpretation and repair, and direct source-to-target translation mapping.
Evaluation: SACTOR evaluates translation with interface-preserving unidiomatic and refinement-based idiomatic phases, FFI-linked E2E tests, and structured compiler/test feedback.The framework permits up to N repair attempts during its iterative verification loop.
Results: 87.2% success rate: the 27B-parameter model outperforms MiniMax-M2.5 and GLM-5, despite those models having hundreds of billions of parameters.The evaluation reports success rate and idiomaticity metrics under SACTOR.

2 Related Work

Prior C-to-Rust work spans rule-based transliteration, prompting and feedback-guided LLM repair, agentic or project-level systems, and broader benchmarking and training approaches. SACTOR provides the closest evaluation precedent through structure-aware translation, static analysis, and FFI-based end-to-end verification.

Rule-based and static C-to-Rust translation: C2Rust performs AST-level transliteration that compiles but relies heavily on unsafe blocks and raw pointers, reducing readability and safety benefits.Subsequent static and rule-driven refinements target unidiomatic patterns left by transliteration.
Single-shot and prompting-based LLM translation: Prompting-based LLM systems combine few-shot or compiler-feedback repair with verification signals such as fuzzing, symbolic execution, and dynamic analysis.SafeTrans evaluates six LLMs across nearly 16,000 translation attempts and organizes repair around Rust error categories.
Verification- and feedback-guided translation: SACTOR uses a two-stage, structure-aware pipeline that refines unidiomatic translations and verifies them end-to-end through FFI linking with the original C program.The paper adopts SACTOR unmodified to compare its fine-tuned model with previously benchmarked LLMs.
Verification- and feedback-guided translation: AdaTrans builds an error-stratified generate-verify-repair loop, reporting a 95.51% compilation pass rate and 81.09% solve rate on 104 algorithmic problems.Its repair strategy distinguishes syntax, ownership, and behavioral failures using retrieval-augmented generation.
Agentic and multi-step translation systems: Other systems frame translation as multi-trajectory search or repository-scale generation, incrementally synthesizing and repairing project functions rather than translating isolated functions in one pass.Examples include Sim et al.’s search-based agent, AlphaTrans’s repository-level symbolic validation, and EvoC2Rust’s typed project skeletons.
Benchmarks and training approaches: Related work also supplies broader multilingual benchmarks, debugging-aware instruction tuning, code-specific continued pretraining, and diffusion-based code-generation alternatives.These lines of work motivate the paper’s benchmarking, debugging-training, and Rust-centric continued-pretraining choices while providing wider context beyond C-to-Rust translation.

3 Base Model

The study fine-tunes Qwen/Qwen3.5-27B directly as a text-only causal language model, preserving its released architecture and vocabulary. Training uses BF16 weights across three stages on eight NVIDIA B300 GPUs with DeepSpeed ZeRO-3.

Base checkpoint: Qwen/Qwen3.5-27B is the source checkpoint, released by Alibaba’s Qwen Team under the Apache 2.0 license.The checkpoint belongs to the Qwen3.5 family and differs from the earlier dense Qwen3 lineup.
Usage mode: The model is used in text-only mode throughout fine-tuning and inference, bypassing its attached vision encoder for C2Rust translation.All training data are text-only, with no image or video inputs at any stage.
Architecture: Its hybrid architecture combines Gated DeltaNet in three of every four layers with Gated Attention using grouped-query attention in the remaining layer.The attention layers use 24 query heads sharing 4 key/value heads and rotary position embeddings.
Training configuration: Fine-tuning applies directly to the released BF16 weights without architectural modifications, using the original layer structure, dimensions, and vocabulary.The tokenizer and vocabulary remain unchanged across all three training stages, with no added special tokens.
Distributed training: All three training stages run in BF16 on a single node containing 8 NVIDIA B300 GPUs, with DeepSpeed ZeRO Stage 3 partitioning parameters, gradients, and optimizer states.No FP8 or NVFP4 quantization is applied during training, and no tensor- or pipeline-parallel strategy is used.

4 Training Data and Curriculum

Table 3 provides an overview of the three-stage training curriculum, while detailed dataset statistics are presented in the following subsections.

Table 3 summarizes the three training stages.
Full dataset statistics appear in the following subsections.
The curriculum overview is presented as Table 3.

4.1 Stage 1: Rust-Focused Continued Pretraining

Stage 1 continued pretraining strengthens Qwen3.5-27B’s Rust command using a diverse corpus assembled from seven public Hugging Face datasets. The 1,673,289-example mixture combines synthetic instruction/code, fill-in-the-middle, competitive-programming, debugging, benchmark, and real-world Rust data.

Stage 1: Rust-Focused Continued Pretraining: Stage 1 uses seven complementary public Hugging Face sources rather than outputs from a single Rust-capable model.The sources span synthetic multi-task instruction/code data, fill-in-the-middle data, competitive programming, and other Rust-focused corpora.
Stage 1: Rust-Focused Continued Pretraining: 1,673,289 examples comprise the Stage 1 pretraining corpus.Table 4 reports each source’s retained Rust-relevant examples and output-file count.
Stage 1: Rust-Focused Continued Pretraining: The corpus combines broad Rust capabilities, including generation, completion, bug detection, refactoring, optimization, documentation, and testing.Strandset-Rust-v1 covers 15 task categories and uses real crates with automated compilation and ownership-correctness checks.
Stage 1: Rust-Focused Continued Pretraining: xCodeEval contributes 30,732 Rust program-synthesis examples and 8,778 Rust APR examples.The APR data pairs buggy Rust source with fixed Rust source and execution-outcome labels, adding debugging and repair signal.
Stage 1: Rust-Focused Continued Pretraining: starcoderdata’s Rust subset is the corpus’s largest component, providing broad exposure to naturalistic real-world Rust code style.The passage states that this source is expected to dominate total token count as well as example count.

4.2 Stage 2: Debugging-Aware SFT on Verus Training Data

Stage 2 uses Verus Training Data to teach targeted repair from structured verifier feedback rather than arbitrary runtime-bug fixing. This formal-verification focus is relevant but may introduce non-idiomatic proof-oriented habits requiring empirical checks.

Dataset and transferred capability: Each debugging instance pairs a Verus program rejected with an error report and a corrected version of the same program.The dataset targets incomplete or incorrect proofs, not arbitrary runtime logic bugs.
Dataset construction: VeruSyn addresses scarce verified-code data through self-synthesis, tutorial-based synthesis, and recorded coding-agent trajectories for complex verification tasks.The underlying corpus was motivated by fewer than 200K open-source Verus-verified lines and fewer than 1,000 stand-alone tasks.
Dataset and transferred capability: Stage 2 transfers the meta-skill of interpreting structured tool failures and producing targeted, minimal revisions instead of wholesale rewrites.Verus reports are treated as analogous to Rust compiler errors or failing end-to-end tests.
Limitation: Stage 2 may teach specification-style comments or proof-annotation-like constructs that conflict with idiomatic, spec-free application code.The paper states that this transfer should be checked empirically rather than assumed.

4.3 Stage 3: C2Rust Task-Specific SFT on the C2Rust-Moxin Dataset

Stage 3 directly targets C-to-Rust translation with the purpose-built C2Rust-Moxin dataset, combining function- and program-level aligned pairs while excluding project-level full-codebase data. Its granularities span isolated syntax and semantic conversion, complete runnable-program translation, and larger-scale migration analysis, though training omits multi-file structural complexity.

Dataset and training scope: C2Rust-Moxin is a large-scale paired C↔Rust dataset built specifically for learning, evaluating, and benchmarking C-to-Rust translation.The dataset is the central resource for the final task-specific SFT stage.
Dataset granularity: The dataset provides function-, program-, and project-level aligned pairs targeting progressively broader translation difficulty.Function pairs support syntax conversion and semantic equivalence; program pairs test complete runnable translations; project pairs support multi-file structural analysis.
Training-pair construction: Function-level examples pair a C solution with its corresponding Rust solution, optionally adding the problem statement as context.The examples come from LeetCode or LeetCode-CN problems with solutions in both languages.
Dataset and training scope: Stage 3 SFT combines function- and program-level pairs but excludes project-level full-codebase data.Training therefore covers short LeetCode-style translations and complete CLI or small-application translations, but not multi-file, cross-function structural complexity.

5 Evaluation Framework

The evaluation uses SACTOR’s structured, agentic pipeline to translate C into Rust and verify behavioral correctness through compilation and end-to-end execution. Success Rate is computed from programs that compile and pass all tests, averaged across five random seeds.

Evaluation criterion: Success requires compiled Rust output to reproduce the reference C program’s observable behavior on all associated test inputs, rather than match a textual Rust reference.The evaluation measures test-suite behavioral agreement, not formal semantic equivalence over all possible inputs.
SACTOR pipeline: SACTOR decomposes each C program into dependency-ordered translation units before generating interface-preserving Rust and refining it toward safer, more idiomatic code.The process includes ownership reconstruction and replacing raw pointers where possible.
Verification and repair: Generated implementations are verified through executable tests, with failed translations revised within a fixed repair budget.Each program permits up to six translation attempts; failure means no test-passing Rust implementation is obtained within that budget.
Benchmark: The benchmark contains 200 C programs, comprising 92 argv-based programs and 108 standard-input programs.Approximately 120 programs derive from IBM Project CodeNet, with the remainder constructed for the benchmark.
Metrics: The primary metric is program-level Success Rate, calculated from test-passing programs and reported as the arithmetic mean across five random seeds.Stochastic sampling motivates evaluating each model under five seeds before averaging the seed-level success rates.

6 Results

The three-stage curriculum raises C2Rust translation accuracy substantially over the unmodified Qwen3.5-27B baseline while preserving strong general coding performance, albeit with a modest SWE-bench decline.

C2Rust Translation: C2Rust accuracy rises from 72.30% to 87.20%, a 14.9 percentage-point gain at identical model size and inference cost.This comparison attributes the improvement to the training curriculum rather than increased model scale.
General Coding: 70.5% pass@1 on SWE-bench Verified exceeds GPT-OSS-120B at 62.0% and approaches GPT-5-mini and Qwen3.5-122B-A10B at 72.0% each.The benchmark evaluates general software-engineering ability on 500 human-validated real-world GitHub issues.
General Coding: SWE-bench Verified performance falls 1.9 points versus the unmodified base checkpoint, from 72.4% to 70.5%.The decline indicates a limited general-coding cost from specialization toward Rust and C2Rust translation.

7 Conclusion

The study applies a three-stage fine-tuning curriculum to Qwen3-27B for C-to-Rust translation and evaluates it with SACTOR’s agentic, verification-driven framework. Future work targets broader real-world C coverage and systematic ablation of the training stages.

Conclusion: The curriculum combines Rust-focused continued pretraining, debugging-aware SFT, and task-specific SFT for C-to-Rust translation.It is applied to Qwen3-27B.
Conclusion: The resulting model is evaluated using SACTOR’s agentic, verification-driven framework.SACTOR provides the evaluation framework referenced in the conclusion.
Conclusion: Future work will extend task-specific training beyond LeetCode-style problems to cover pointer-heavy, real-world C codebases.The paper also proposes systematically ablating each training stage.