记一次在嵌入式项目的代码质量和效率的横向评测(DeepSeek V4 Flash 0731、GPT 5.6 Luna Max)

前言

因为我是主要是做嵌入式开发的，我看比较少人测试这方面的，所以特意做了这次评测。

在嵌入式项目中, 代码质量和运行的速度十分重要, CPU比电脑运行慢很多，在这种情况如果代码写得不好，运行的效率就会放大，结果差很远，很多时候都要想辨法压到极限。

而且在实际开发中要多次查文档, build, 烧录和开发板交互操作, 这次测试可以考验有没有做好。

环境

1.统一使用 opencode

2.使用ESP32S3N16R8, SDK ESP-IDF 5.5.5

3.可以自由查阅的ESP文档

4.可以自由使用espidf内建的工具

参与测试的模型

1.opencode go 的DeepSeek V4 Flash 0731, 思考max

2.opencode zen 的DeepSeek V4 Flash 0731 free, 思考max (跟go付费版对比)

3.opencode go 的GPT 5.6 Luna, 思考max

4.opencode zen 的LongCat-2.0 Free, 思考max (反正免费顺便测)

测试方法

1.在同一个SDK和环境下写1024 点 Q15 定点 FFT的算法, 不能使用esp的FFT/DSP库

2.输出要和事先写好的PC 验证工具float648答案比较，SNR ≥ 35 dB 且最大误差 ≤ 128 LSB，两者都过才算 PASS

3.每个测试的模型要写2版code, v1版要先把算法写好正常正确能用, 验证通过后 commit 冻结, 再写自我优化的最终版 v2版, 比较 v1 与 v2 的运行速度

4.用我自建的 DevTool 量测速度，记录 avg / p50 / p99 / max（µs）。

5.记录v1 总用时, v2 总用时

6.撰写 contest_report.md（优化手段/正确性验证/速度表格/成本/心得）

7.最后由肥波5审计

提示词

model_prompt_zh.txt (7.8 KB)

各自完成后的报告

deepseekv4fash_contest_report.txt (8.0 KB)

deepseekv4fashfree_contest_report.txt (5.9 KB)

gpt_luna_contest_report.txt (5.7 KB)

longcat2_contest_report.txt (4.6 KB)

肥波的结论和审计成绩

模型	v1 SNR / max_err	v2 SNR / max_err	报告声称	相符
DeepSeek V4 Flash 0731	48.76 dB / 3.0	51.22 dB / 2.1	48.76/3.0、51.22/2.1
DeepSeek V4 Flash 0731 free	47.98 / 3.0	47.94 / 3.0	47.98/3.0、47.94/3.0
GPT 5.6 Luna	48.01 / 3.0	48.01 / 3.0	48.01/3.0、48.01/3.0
LongCat-2.0 Free	48.17 / 3.0	46.19 / 3.5	48.17/3.0、46.19/3.5

全部通过闸门(SNR ≥ 35 dB、max_err ≤ 128 LSB)。速度方面:GPT 留存了 perf 原始输出(6339/1945 µs,与报告逐字相符);两个 DeepSeek 未附 perf 原始档,仅报告自述。

成绩总表

感想

首先这个结果完全出乎我的意料的, 因为我一直以为GPT写算法是最好的, 但最后写出来的代码最拉, 写出来的算法速度也是最慢的, 但执行速度太快, 有降智的可能性

可以看出opencode是挺有良心的, deepseekv4 flash free版本速度和付费1M版本在写v1 code不会慢很多, 但可以看出200K上下文带来的负面影响, free版本刚做好v1就进行上下文压缩了, 导至后续写v2时要重新查文档花了好长时间, 最后效果也差了好多

体感deepseek v4 0731真的很聪明, 它在过程中不断的查文档和调用工具去模拟和实测, 甚至直接查看编译出来的汇编文件看实际的汇编指令, 跟我自己的实际工作流好像

至于LongCat这个模型犯规了, 它偷看了deepseek v4 flash free的工作区, 我及时阻止了, 但是我想不到这个美团的模型竟能完全完成任务, 也算是出乎我的意料的