[Paper] TRACE：评估基于LLM的代码翻译执行效率

发布: 3天前 (2026年3月17日 GMT+8 21:05)

8 分钟阅读

原文: arXiv

Source: arXiv - 2603.16479v1

（请提供您希望翻译的具体文本内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。）

概述

论文 TRACE 引入了首个基准，用于衡量大型语言模型（LLM）在代码翻译过程中生成代码的执行效率。以往工作几乎只关注功能正确性，而 TRACE 表明，许多“正确”的翻译在速度或资源消耗上却显著更差——这在实际软件开发中是一个重要的差距。

TRACE benchmark: 1,000 个精心策划的翻译任务（C++、Java、Python），配备压力测试工具，可揭示对微小单元测试不可见的性能回归。
Comprehensive evaluation: 对 28 个公开可用的 LLM（包括 Claude‑4‑think、GPT‑4，以及开源模型如 Qwen2.5‑Coder‑14B‑Instruct）进行正确性和运行时效率的评估。
Empirical insights:
- 正确性 ≠ 效率 —— 表现最佳的正确性模型（Claude‑4‑think）在速度上仅位于中等水平。
- 23.5% 的功能正确翻译存在“显著低效”。
- 低效模式可细分为算法错误（约 12%）、语言结构不匹配（约 66%）和资源管理错误（约 22%）。
Prompt‑engineering analysis: 各种推理时的提示技巧（例如 chain‑of‑thought、“think‑before‑code”）仅带来有限的加速，表明当前 LLM 在效率意识方面仍有更深层的缺失。
Open‑source release: 基准、数据和评估脚本已公开发布，以鼓励以效率为重点的研究。

任务选择 – 作者收集了 1,000 个已知为 效率关键 的翻译场景（例如，对大数组进行排序、图遍历、内存密集型仿真）。每个任务包括一种语言的源实现和目标语言的翻译实现。
压力测试框架 – 对每个任务，确定性输入生成器会创建大规模输入，迫使算法的时间和内存使用达到极限。记录原始代码和翻译后代码的执行时间和峰值内存。
LLM 提示 – 每个模型收到相同的提示：源代码加上目标语言的简要描述。还会测试提示的变体（普通、思考链、“先思考后编码”）。
指标 –
- 正确性：功能单元测试的通过/失败。
- 效率：翻译后代码相对于原始基线的运行时间（和内存）比率。比率 > 1 表示变慢。
- 低效分类：对比率超过 2× 阈值的案例进行人工检查，归类根本原因。
统计分析 – 将结果按模型、语言对和提示风格聚合，以揭示系统性趋势。

低效普遍性：842 条正确翻译中有 23.5 % 的速度比原始慢 ≥2×。
根本原因分解：
- 算法错误（例如在可以使用 O(n log n) 的情况下使用 O(n²) 循环）– 11.9 %
- 语言结构不匹配（例如对数值数据使用 Python 列表而不是 array.array）– 66.4 %
- 资源管理不善（例如忘记关闭文件、过度对象分配）– 21.7 %
提示工程：“先思考后编码”提示平均提升约 6 % 的中位效率，但最佳与最差模型之间的差距仍然很大。
开源惊喜：较小的、针对编码调优的模型有时能生成更紧凑的循环或更符合语言习惯的结构，优于重量级商业大模型，从而实现更好的运行时性能。

Developer tooling: IDE 插件如果依赖 LLM 进行自动代码翻译，应在向用户建议代码片段之前加入 生成后分析步骤（例如运行压力测试框架）。
CI/CD pipelines: 为 LLM 生成的补丁添加轻量级性能回归检查，可捕获 23 % 本可能导致生产延迟或成本上升的情况。
Model selection: 当运行时效率是首要考虑时，团队可能更倾向于使用针对编码者调优的开源模型（例如 Qwen2.5‑Coder），即使它们在原始正确性上略有不足。
Prompt design: 虽然 “think‑before‑code” 有帮助，但有限的提升表明 训练数据 和 微调目标 必须明确奖励高效代码，而不仅仅是功能性输出。
Cost savings: 在计算时间直接等同于费用的云原生环境中，性能下降 2× 会导致运营支出翻倍。TRACE 提供了一种量化并避免此类隐藏成本的具体方法。

Source: …

TRACE 照亮了一个常被忽视的 LLM 辅助开发维度——生成代码的实际运行速度。通过提供一个具体的、基于压力测试的基准，它为开发者、工具构建者和研究者提供了超越“它能工作吗？”而是关注“它能高效工作吗？”的手段。