14 May 2026

技术决策随笔

之前有人问起，如果现在重新设计过去做过的 GPU 调度系统，我会怎么做。当时的回答是：肯定不会从0开始再开发一个调度系统了，时间成本和维护成本都不划算。更好的做法是直接在社区里找一个能满足大致需求的方案，说不定连二次开发都不需要。于是就想随便写点东西，权当总结与思考吧。

功能

选择的技术框架是否满足核心需求，是否支持二次开发和未来扩展。以前选型往往只盯着当前的功能列表，后来才意识到，扩展性决定了系统能走多远。好的框架不会把你框死，而是在你需要自定义策略时，留有合理的切入点和插件机制。

性能

性能是否能支撑当下的规模，有什么性能瓶颈。除了吞吐和延迟这些直观指标，还要关注高负载下系统自身的资源消耗。如果框架本身比较重，可能业务还没到瓶颈，维护这套系统本身就变成了一个大问题。

成本

搭建这套系统的成本如何，学习曲线和开发时间都需要考虑，后期的维护成本同样不能忽略。引入一个新框架看似省事，但如果团队要花大量时间排查问题、阅读源码来填坑，隐性成本其实非常高。

社区和生态

社区活跃度如何，文档是否完善，生态的工具链是否齐全。遇到问题时，是否有足够多的参考案例和解答渠道，这直接影响到解决问题的效率。成熟的生态往往能大幅降低集成成本和踩坑概率。

团队能力

当前团队有多少人熟悉这个技术栈，多久能在团队里推广开，学习成本是否够低。技术决策不能脱离团队的实际状况，再好的工具如果没人会用、没人愿意维护，最后也只能闲置。

LEo at 00:12