slowgen

你们少了一个技术能力过硬的架构师，而且你们后端太菜了，不然的话让后端从 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 作为压缩保存的格式。

这个测试也太不严谨了。

开源模型的参数是有推荐的，不同的模型对于不同的任务场景，temperature 、top_p 、top_k 、min_p 、presence_penalty 、repetition_penalty 的数值都不同，你用网页版都不知道人家默认是针对什么场景配置的，做测试对比是要根据你自己的任务场景去设置的。

甚至是量化部署方案，比如同样 NVFP4 的量化，还要看用了什么数据集校准。

我就这么说吧，我本地部署的 MiniMax M2.7 （ nvidia 放出的 NVFP4 量化）和 Qwen 3.6 35B-A3B （ RedHatAI 放出的 NVFP4 量化）、Qwen 3.6 27B （ mlx-community 的 NVFP4 量化和 unsloth 的 UD + NVFP4 ），分别按照各模型文档的参数推荐来用对话模式按照你那一句话 prompt ，写出来的 html 都和你提到能上桌的模型都差不多。

@superkkk 跑原精度的不现实啊，nvfp4 量化后的基准和原精度差距不到 1%，nvfp4 还可以用上新的架构优势，prefill 速度大幅度提高，而且可以开的 KV Cache 也大得多，可以容纳更多的用户使用。

单用户上下文 3k 也不现实，龙虾一个初始会话都是 12k 左右起步。我现在基于闲置算力开了个小规模用的 API ，看平时的统计，基本上 10k 上下文涨到 100k 也就 40 个请求左右。如果过一段时间用户不请求了可能 KV Cache 就释放掉了，然后用户再请求过来的时候又要从头开始 prefill 了，也会有影响的。