摘要2026-08-17 ~ 09-12我用 TraeAgent 模式 DeepSeek从零开发了一个纯 C11、零第三方运行时的 ARM 边缘 LLM 推理引擎。27 天里完成 29 次提交、11 页 Wiki、5 篇技术文档、90 篇教程并让一块15.6 GiB内存的 RK3588 开发板跑起17.66 GB的 Qwen3-30B-A3B服务峰值内存14.23 GB → 1.11 GB。本文是完整开发实录时间线、工作流、三个技术转折点、4 个被 AI 坑进文档的错误结论以及一份可直接复用的规则模板。关键词Trae、AI 编程、结对开发、RK3588、ARM、大模型推理、C11、边缘计算、mmap、量化推理适合读者正在用 AI 写正经工程的开发者 / 做边缘 AI 部署的工程师 / 对推理引擎感兴趣的同学目录一、先说结论这 27 天我做成了什么二、为什么我要手搓一个引擎三、27 天时间线复盘真实日期四、我具体是怎么用 Trae 的工作流五、三个技术转折点六、4 个被 AI 坑进文档的错误结论七、成果数据全部标注口径八、反思AI 结对把瓶颈搬到了哪里九、可直接复制的规则模板十、诚实边界一、先说结论这 27 天我做成了什么项结果周期27 天2026-08-17 ~ 09-12其中 23 天有文件改动成本约3000 元token 费一个月产物纯 C11 引擎单文件约0.8 MB818,872 字节v0 测点、28 个 C 文件、零第三方运行时看家本事逐层推理30B-A3B 服务峰值14.23 GB → 1.11 GB12.8×输出与全层档逐位一致落地RK3588Orange Pi 5 Plus15.6 GiB 内存纯 CPU跑起 17.66 GB 的 Qwen3-30B-A3B配套29 次提交 11 页 Wiki 5 篇技术文档 90 篇教程 一键复现脚本但今天我想讲的不是这些数字是过程。因为如果只看结果你会以为“AI 帮我把代码写了所以我很快”。真实的体感完全不是这样。二、为什么我要手搓一个引擎起因很简单我想在一块几百块的开发板上跑大模型。试过现成方案后撞上三堵墙第一堵是内存墙。主流 ARM 开发板只有 15.6 GiB 可用内存而一个 q4 量化的 30B MoE 模型权重文件就是17.66 GB——权重比内存还大。常规“全量加载常驻”路线直接出局实测全层档服务峰值 14.23 GB几乎顶满整块板。第二堵是体积墙。主流框架型方案Python 推理框架 加速栈动辄几 GB边缘设备的存储和内存都吃紧而且依赖链条长得没法审计。第三堵是成本墙。云端 API 按 token 计费账单随用量持续发生而我想做的场景产线问答、离线文档处理既高频又敏感既贵又不合规。想清楚之后我发现真正要破的不是“把权重压得更小”而是“取消权重必须同时驻留这个前提”。这个想法就是我后面 27 天全部工作的主线。三、27 天时间线复盘真实日期下面的日期来自我本地的 Trae 会话记录与 Git 提交记录两条线可以互相印证。日期做了什么08-17项目启动。定下三件事纯 C11、零第三方运行时、目标板 RK358808-18 ~ 08-28内核层攻坚手写 NEON 量化 GEMM/GEMV、VQF 权重格式、KV 缓存分页、连续批处理08-31服务层改造改为手动加载模式/admin/api/model/load解决边缘场景下模型切换的痛点09-01并发模型改造把vllm_batch.c里的轮询睡眠换成pthread_cond_t事件驱动09-05首次开源发布v0同时补上模型支持范围声明与口径说明09-06 ~ 09-10v1 大重构纯 VQF 运行时、逐层推理、KV v2 惰性分配、独立转换工具、attestation09-11v1.0 测试版发布09-12板端实测矩阵14 个 serve 配置点 一键复现脚本 Wiki 收口一个细节能说明 AI 结对最大的价值9 月 1 日那条改造——我在会话里只写了一句“把轮询睡眠换成事件驱动机制”它给出的是pthread_cond_wait(b-cv, b-cv_mu)的完整实现到今天我文档里记的还是这句话而代码在src/serve/vllm_batch.c:209原样躺着。这种“当时的记录 → 现在还在的代码”的一致性是 AI 结对最被低估的好处它让“我当时的想法”和“最后落地的实现”之间几乎没有损耗。四、我具体是怎么用 Trae 的工作流这一段是本文最实用的部分。我不是“打开对话问它怎么写代码”而是把它当成一个需要被约束的工程师。4.1 第一步把它当项目不是当搜索框在 Trae 里以独立项目打开工作目录我的项目目录名会出现在 Trae 的 MCP 配置目录里这说明它是以项目为单位管理的而不是临时会话。好处项目记忆会累积。我后面定的口径规则、踩坑记录它会一直带着。4.2 第二步先给规则再给任务这是最关键的一步。我不会直接说“帮我写个 KV 缓存”我会先把规则文件摆好见第九节模板。规则里最重要的三类数字口径规则什么数字必须标什么口径、不许跨口径混表自证日志规则任何优化必须打印一行能证明它生效的日志汇报格式规则说“改完了”必须给文件路径 行号4.3 第三步给它一条“上板”的通道这是我做得最对的一个决定。我给项目加了tools/rk_remote.py——一个 SSH 执行/上传工具。它就能自己完成“写脚本 → 传到板子 → 执行 → 读日志 → 改代码”的闭环。一句提醒Windows 侧写的.sh传到 Linux 后要先去 CRsed -i s/\r$//否则报not found——这个坑我踩过。4.4 第四步让它自己证明自己我要求每个功能都要有自证日志。比如启用逐层推理时引擎会打印[VQF-STREAM] enabled keep1 nl48 segs11 per-layer334.1MB data16847.2MB resident~808.4MB rss988kBdata16847.2MB是权重总量resident~808.4MB是实际常驻。有了这行日志“AI 说它生效了”这个问题就从信任问题变成了读日志问题。五、三个技术转折点转折点一把“量化 布局重排”从推理期挪到转换期最初的做法是常规流程启动时读权重 → 逐层量化 → 重排布局。结果 2B 模型在板端光加载就要20 多秒。后来我把量化与 8x8/4x4 布局重排全部固化到转换期推理时只需mmap 指针直挂。意外收获转换与推理共用同一套量化代码这直接消灭了“两套实现漂移”的风险也是后来“逐层档与全层档输出逐位一致”能成立的前提。转折点二发现“驱逐是免费的”逐层推理的核心是每层权重算完就madvise(MADV_DONTNEED)释放只留 keep 层常驻。为什么这个设计能成立因为映射是只读的页面是干净页——驱逐不需要回写。下次用到再从文件重建。所以它是时间换内存不是有损近似。这个认识一旦成立后面的一切就顺了权重常驻内存不再随模型体积线性增长。转折点三发现“最贵的优化”是一个环境变量我的 30B 多轮追问 prefill 原来是722 秒 / 822 秒——基本等于不可用。后来发现引擎里L3 驱逐与前缀复用默认是互斥的置上VLLM_L3_PREFIX_REUSE1让二者共存后同样的请求变成4.7 秒 / 3.2 秒。一个环境变量150 倍。这个坑的教训是“优化不生效”往往不是优化没用而是它被另一个机制静默关掉了。六、4 个被 AI 坑进文档的错误结论这一段是我写这篇文章的真正原因。AI 从没对我撒过谎。它只是特别擅长把错的结论写得像对的一样自信、一样完整、一样有条理。下面 4 个错误结论每一个都进过我的文档。坑一同一个数字我写了三遍三遍都对但都不一样我要写“逐层推理的 decode 代价”。AI 给了我37%我信了写进文档。后来自己核对发现同一指标在不同口径下是口径decode 代价冷页缓存 --threads 486%207 → 385 ms/tok冷页缓存 --threads 837%429 → 586 ms/tokserve 稳态热档34.6%458.4 → 617.2 ms/tok三个数字都是真的。37%没错86%也没错——它们只是问的不是同一个问题。如果我当初只写37%发出去我就是在用最漂亮的那个口径去描述一个跨口径的事实。这不是撒谎但比撒谎更糟——因为它看起来严谨还有数据支撑。七、成果数据全部标注口径本节所有数字均标注测量口径避免跨口径混用。指标数值口径引擎体积0.8 MB818,872 字节v0 测点单文件服务峰值内存14.23 GB → 1.11 GB30B-A3B全层档 vs 逐层档内存降幅12.8×同上decode 代价34.6%serve 稳态热档458.4 → 617.2 ms/tokprefill 耗时722 s → 4.7 s30B 多轮追问置VLLM_L3_PREFIX_REUSE1八、反思AI 结对把瓶颈搬到了哪里这 27 天下来我最大的感受是AI 结对并没有让“写代码”消失它只是把瓶颈从“写”搬到了“审”。以前我花时间写现在我花时间验证它写的是不是我要的。数字口径、日志自证、跨口径核对——这些原本是工程素养现在成了 AI 结对时代的核心技能。AI 负责把想法变成代码我负责把代码变成事实。九、可直接复制的规则模板下面是我在 Trae 项目里实际使用的规则模板可直接复制使用。# 项目规则 ## 1. 数字口径规则 - 任何数字必须标注测量口径环境、线程数、冷/热缓存、模型档位 - 禁止跨口径混表同一