"能跑起来"和"能用"，
之间隔着一整个现实世界。
2025年初，技术方向确定后，团队进入了最高强度的工程阶段。这个阶段持续了将近七个月，经历了多次平台迭代，以及与之配套的完整模型重训练工作。
这篇文章讲的是这段时间里发生的事——不是工程日志，而是一次次判断背后的逻辑。
我们的第一阶段测试，选择了一套算力受限的入门级边缘平台。我们用它开始，不是因为认为它够用，而是因为这是验证基本推理路线最快、成本最低的方式。
在这个阶段，我们需要回答的第一个问题不是"性能如何"，而是"这套推理路线在原理上是否成立"。算法能否在受限算力下跑通？延迟的量级是什么？这些问题，不需要最优硬件，只需要能跑出数字的环境就足够。
第一次跑通的时候，推理速度远低于我们期望的水平。
但这不是失败——这告诉我们：这套路线的原理成立，性能瓶颈在哪里，下一步应该往哪里走。
为了突破软件推理的性能边界，我们在第一套平台上引入了专用的推理加速能力。这一步带来了明显的性能提升，让帧率和响应延迟进入了可接受范围。
适配这套加速能力，需要对模型进行完整的迁移和重训练工作——这不是简单的参数调整，而是一次从头开始的工程重建。
这套组合方案在实验室里表现出了明显的性能提升。帧率和延迟都进入了我们认为可以接受的范围。我们进行了相当长时间的反复验证，积累了大量测试数据。
做出迁移决策不容易。我们已经在前一套方案上投入了大量的训练时间和适配工作。但稳定性是不可妥协的底线：一个在真实猪场里每隔几天就需要重启一次的系统，不是一个可以交付的系统。
我们转向了一套对长期稳定运行有更高工程规格保障的平台——它在功耗和热管理上的设计更接近猪场的真实工况。代价是：之前的全部模型训练工作需要从零开始，重新完成针对新平台的迁移训练和验证。
入门级平台基础验证——确认推理路线在原理上成立，定位性能瓶颈所在。
引入专用加速能力，完成完整的模型迁移与适配验证。实验室性能通过，但长期连续运行中发现稳定性存在隐患。
以稳定性为第一优先级，完整重建模型训练与适配流程，在新平台上完成全量验证。
平台性能和长期运行稳定性确认满足部署需求。从工程验证转入实地部署阶段。
这段经历让我们对"硬件选型"这件事形成了一个新的判断：硬件的重要性不在于峰值性能，而在于在最差条件下的可靠性。对于一个需要长期部署在无人值守环境中的系统，稳定性是第一优先级，性能是第二。
而且，迭代的代价虽然高，但每一次从头来过都让我们对整个系统的理解更深了一层。每次重建完成后，我们对系统的薄弱环节在哪里、在什么条件下会出问题的认知都更清晰。这种理解，是在初始方案上渐进优化无法获得的。
第二次从头来过之后，团队里有人说了一句话让我们印象很深：
"现在我们知道这个东西为什么能跑，而不只是它在跑。"
这个区别，在后来的部署阶段非常重要。
硬件不是核心，稳定性才是。当平台真正跑通、性能验证完成之后，真正的挑战才刚刚开始——把它从实验室搬进真实的猪场。