一，如果说必须支持国产计算卡，除了 X 疼，不还有 hwj 等多家计算卡吗？搞得好像只有滑家有计算卡，只能说滑家政企关系太牛，忽悠到领导下指令，让很多企业花了真金实银去买 X 疼垃圾卡当摆设在仓库里吃灰，而滑家拿低能高价的垃圾玩意吃撑了爱国税。

二、X 疼计算卡以前的技术架构落后，写算子特费劲，具体见知乎分析文章，连滑家自己的工程师都得写到掉头发，加之不开放软件生态，不愿培育技术生态（毕竟靠政企关系就能轻松卖出去，管它好不好用），所谓驻场工程师支持本质上是拿客户支付的钱去培育滑家不成熟的私有技术生态，谁买 X 疼计算卡认真用就是自找麻烦，一家 AI 公司就被它坑死了。

三、在这种形势下，与其用各种途径偷偷用 N 卡，毫不费力写 CUDA ，还有一系列 DSL 和辅助工具如 Triton 、ThunderKitten 、TileLang ，也不应该费钱费时去支持垃圾计算卡。

```python
sum(lists, [])
```

继续写代码

@testonly 我就特别希望腾讯快点死掉，腾讯这家公司作恶太多，不是刻意低调就能原谅的

@mycs999 狗日的腾讯，祝愿腾讯早日破产倒闭！

今天旧版都用不了，只能用最新的 6.9 版，连 6.8 版也不让用。狗日的腾讯，就是这么爱恶心人。

对 Claude 写的不评价，对 ChatGPT 写的说点看法。

单例模式在这里应该是没用的，你可以把 print 的内容改为输出到日志（ logging.info ），然后在日志里查看是否不断创建 SingletonModel 。

解决方案之一是利用 RPC：在后台启动一个常驻的数据处理服务，负责接收请求、数据处理和返回结果； Flask 负责把客户端请求转发到常驻服务，再把返回来的结果发给客户端。

需要注意的是，RPC 有多种执行模式，你要避免不断 fork 进程或 spawn 线程去处理数据，这样内存占用也有可能不断膨胀，而要直接调用数据处理的入口函数，这时候单例模式就能起作用。

@AS4694lAS4808 Facebook 旗下的 Instagram 服务后端就是基于 Django ，一堆工具链也都基于 Python 。Instagram 这么多年坚守 Python 平台，针对 Python 的不足做了很多优化，有不少成果反馈到 CPython 项目本身，Py3.8 的一个新特性就是他家贡献的，至于即将推出的 No-GIL 也是 Instagram 的员工搞出来的。