katago在AutoDL几款GPU实例下benchmark测试

前几天误打误撞注册了AutoDL后果然有些停不下来，算上折扣，要比阿里云、腾讯云的gpu服务器更为合适，同时AutoDL是容器化实例，这样初始化在几秒内完成，而阿里云等初始化过程中的GPU驱动、框架搭建时间有些过于漫长了。如果把时间考虑在内，AutoDL性别比就更高了。

但AutoDL受实例限制，暂时无法编译TensorRT Backend版本，编译的是cuda11.2版本。在不同GPU实例下简单测试了一下katago的benchmark，权重为kata1-b40c256-s10359230464-d2525387336。

使用阿里云最低端的Tesla T4，4核cpu，15G内存服务器作为参考。

在使用sabaki对弈感觉速度尚可，但经过测试，NVIDIA RTX 3060 / 12GB的成绩与阿里云的Tesla T4比想象中要差不少。

作为TeslaT4的替代者，NVIDIA RTX A4000 / 16GB成绩相比TeslaT4略好一点，也符合AutoDL首页算力排名。AutoDL北京地区实例均使用RTX A4000。

NVIDIA RTX 3090 / 24GB成绩两倍于NVIDIA RTX A4000 / 16GB，同样符合算力排名。

最令人吃惊的是NVIDIA RTX 2080Ti / 11GB，成绩直逼阿里云TeslaV100 16G。katago测试过程中，

第一次测试居然认为成绩出现误差，提示“Optimal number of threads is fairly high, increasing the search limit and trying again.”自动重新测试了一遍。

不愧为显卡核弹。难怪黄厂长严令禁止数据商将游戏显卡用于数据服务器上。其价格居然还要低于NVIDIA RTX A4000 / 16GB，这也是性价比最高的GPU实例。

从使用阿里云GPU云服务器运行katago开始，就发现一个问题：那就是使用sabaki通过gtp协议调用katago，非常顺畅没有任何问题。而同样的运行参数，一旦使用lizzie调用，则卡顿现象十分严重，不得不反复通过暂停、重开，来获取数据。

开始以为是带宽的问题，后来即便将带宽提高到5M也没有丝毫效果。改用AutoDL服务器后，其带宽不需要指定，同样卡顿没有改善。

前几天通过网上学习ssh的时候，看到有文章提到不同ssh服务器，客户端获取的返回数据不一样。受此启发，想到同样GPU服务器，sabaki正常而lizzie存在问题，那说明应该是客户端获取服务器数据、转换的问题。lizzie最早是针对Leelazero的，在获取katago的gtp数据时，对部分数据不识别，或者识别转换效率低，所以导致卡顿，甚至不能正常显示。

于是查看katago的配置文件，感觉应该是logToStderr参数的问题。默认值是false，为了在sabaki观战时看到AI的计算情况，我将值改为TRUE，这样gtp日志输出到sabaki终端。但这样一来，lizzie可能对大量输入数据有些不知所措了。本机还好，一旦通过ssh获取，更是应接不暇了。

果然，将logToStderr值修改为false之后，再调用lizzie，一切正常，顺利完成旧文旧局：“未完”的一局（钱宇平vs小林光一），算是开了一个好头。

方法一

删除QQUpdateCenter这个文件，发现QQ确实不自动升级了，但却弹出修复窗体

有一个NetRepair程序，是用来修复的，删除它的话，就不能修复了！所以方法一就是：同时删除QQUpdateCenter和NetRepair文件。

方法二

限制QQUpdateCenter程序的执行。你首先要确保你的QQ安装在NTFS分区下，这样所有文件和文件夹就有了权限管理设置。

选中QQUpdateCenter.exe文件，将当前用户针对此文件的权限全部取消，这样这个程序就不能执行了！

---