我的公司老了

老兵不会死去，只是凋亡

最近在做一个项目的升级，可以称得上是技术框架在版本号上的大跃进，ubuntu20 到 ubuntu24，gcc8 到 gcc13，torch v1 到 torch 2.9，tensort 8 到 tensorrt 10.14， cuda 11 到 cuda 13。

本以为只是一个简单的升级，结果发现，公司老了，代码老了，依赖老了，连带的环境和工具链都老了， 感谢基础架构，感谢技术中台。这整个过程我经历了极端难忍的痛苦，这有他们不可或缺的功劳。我工作时间已经不短了。用现在的目光来，我感到所有的东西都透着一股子老旧的味道。 这让我想起了一句话：

老兵不会死去，只是凋亡

所幸，项目用的 bazel 编译，虽然我很不喜欢，但 bazel 有个好处：就是可以先拉所有源码，然后再编译。

我遇到的问题，总结一下主要以下几类：

• 一类问题是：依赖代码的符号和系统库 glibc 等 有冲突，符号未定义/missing/重定义等
• 一类问题是：有些代码依赖编译器的某些属性和预定义变量，或默认行为。
• 当然，最多的问题还是：很多代码的写法，在新的 gcc 上开始报 warning，我不得不给对应的源码加-Wno-error 或者直接 patch 一下源码。

就这样，遇到一个问题，给对应源码打一个 patch，遇到一个，打一个 patch。代码依赖的，以及和间接依赖的，总共有几千个库。

在打了七八个 patch 之后，我放弃了。

然后立马执行了以下措施，以降低我的边际损失：

• 把 -Werror 全部干掉，加上 -Wno-error；
• 降级 gcc 版本 到 11；

敲下回车的一瞬间，虽然满屏的 warning 刷过，但我依然感到一份久违的安定。

最终，在五六个 patch 和 -Wno-error 的帮助下，我让这一坨加一坨的屎山代码通过了编译和链接。

又再与 nvidia 驱动兼容性做了一番斗争后，终于让这个项目在新的环境上跑了起来。

然后，你以为故事就这样，和童话里王子和公主过上和谐永久的幸福生活一样结束了嘛。

天真，很遗憾，没有。

在服务跑起来之后，我开始进行回归测试，结果发现，server 出现了诡异的输出结果不稳定问题，而我还在继续排查中，我不知道是哪里的问题。也许是 tritonserver，cuda，tensorrt，gcc，nvidia 驱动中某一方的锅，我还在挣扎。..

尾声

而我突然意识到，我们公司老了，我们团队老了，我们写代码的方式老了。基架和中台的存在，他们的技术栈和社区版已经有了代际的差别，我们还在用着五六年前的解决方案去解决今天的问题。

有时，我们都会开玩笑，能跑的代码就不要动，碰了可能就挂了。这句玩笑话，却道出了我们技术债的真相。等不得不动的时候，痛苦是早已在无形中累计下来的。

我理解了 vllm 和 sglang 还在用 ubuntu 22 的无奈。

这里我说一个暴论，升级升不动的基架和中台，都是垃圾，作为成本中心应该砍掉。

看着社区 1.34.2 的 k8s 和自己在用的 1 开头的 beta 版本，看着社区的数据库、java、go、rust、node、c++、cuda、tensorrt、triton、torch、tensorflow、bazel、gcc、glibc、libstdc++、nvidia 驱动、ubuntu、centos 版本。..，再看看公司的主流版本。

我有着深深的无力感。

人应该享受技术的红利，即使是程序员

以上