slowgen

从 CTO 角度来说难度可能不大，比如用绞杀者模式逐步替换 API ，结合流量镜像方案把生产流量同时导入测试环境的新老系统看数据对比来验证防止翻车等，手段很多。

如果是从培养你角度让你直接参考 https://typescript-is-like-csharp.chrlschn.dev/pages/intro-and-motivation.html 这种方便 TypeScript 熟练工快速学习 C# 的文档两天就能上手读懂项目，渐进式重构问题也不大。

但是选择的方案这么激进，对你来说难度就很大了，起码出一个风险应对方案来，除非业务规模很小，项目也不大。

同样是选择 AI 方案，还不如先让 AI 把当前系统优化好。

最好确认是什么蛇，我之前在农村路骑车的时候碰到一条好大的蛇，作死上去拍了点视频，发群里了才知道是剧毒的银环蛇

你们少了一个技术能力过硬的架构师，而且你们后端太菜了，不然的话让后端从 PHP 转 Node 没毛病很顺利的。

我以前带团队就是从 PHP 转 Node 的，把语言特性、相似函数、相似库、各 Web 框架相似性等细节全部拉出来对比讲透，不用 3 天大家就可以开干了，然后过程中跟进代码和 review 就完事了。有 AI 之后更方便，现在技术栈我都换了几轮了。

用渐进式重构方案，一部分接口替换完之后流量重定向到新代码，要是有问题就把流量切回去，都是一套工程化体系的东西，要是基建水平不行那还得把基建搞好。

说白了你们后端的连 AI 都比不过，原地踏步，一潭死水，不过也不奇怪，毕竟现在还在坚守用 PHP 的公司绝大部分也就这样了，就连百度早在多年前就禁止新项目使用 PHP 了。

别买小米，24 小时开机的坏了 2 个了，都是过保就坏

提供一个思路：找有垃圾分类而且底商有钱大妈这种菜市的小区，员工有概率在晚上 10 点半拖着卖不出的菜连包装都不拆丢进厨余垃圾桶里，捡到就是零成本

预算鸡肋不如买 api ，而且你低估了 Mac Studio 在跑大模型这件事上是极致性价比，官方翻新的 Mac Studio 库存已经 3 个月没补过货了，坐等 M5 Ultra 是最好的选择，因为曾经的 prefill 短板已经不短了。

跑大模型不是说你现在部署了之后就不动了，非要选择方案，当前性价比最高的是 DFlash + Qwen3.6 27B 方案，人家在单张 3090 上优化到极致跑的，直接抄作业就行。

但是，如果 2 个月之后出了一个开源模型，能力比你现在跑的模型提升 20%～ 30%，部分能力追平 Opus 4.7 ，体积在 40 ～ 60B 这个尺寸，你手头的硬件跑不动了，升级空间也没了，你怎么想。
很遗憾，现在的模型就是月更，你无法预计到下一个月有什么模型出现，它们的能力又达到了什么程度。

而且从已有的信息来看，你对模型类型（ Dense / Moe 和显存带宽 or 内存带宽的关系是如何影响到 token/s 的）、prefill 速度取决于什么、模型尺寸和不同的量化方案（ Q4_K_M/Q4_K_X_L/NVFP4/MXFP4/Q5/Q6/Q8/FP8 的差异）和上下文大小对于显存占用是如何计算的，这些信息你都没有任何概念。
更别说评估你的任务需要注意模型 benchmark 分数的哪几项指标，同时这些指标在能选的模型里哪个最好。

当你解了之后，你的结论就回到了我这条评论的第一句话了。

@mewking 就是这个啊 https://huggingface.co/unsloth/Qwen3.6-27B-UD-MLX-NVFP4
从命名风格来说 UD 就是动态量化，带 MLX 的就是用 Apple 的 MLX 跑的，NVFP4 作为压缩保存的格式。