listnodeptr

@neofacenew 赞一个，不过友情提示：每次新加载 txt2img 会导致系统反复加载 4GB 的模型从硬盘进内存再进显存，这个过程远超直接 inference 的时间（生成 10 秒钟，硬盘加载 45 秒），所以还是走 redis 香

因为电脑还有其他学习任务，后面不定期 GPU 开放分享，一般在周末白天分享，工作日随缘，睡觉时必定关机

@suanren 最低配置可以优化到 6GB 以下（前提删除安全检测模型，所有 batchsize 调成 1, 然后以 512 分辨率不能加），带着安全检测模型需要不到 10GB

老妈玩差不多了，各种马云扎克伯格英国女王 灵感快耗尽了，我更新 github 加上自己部署的 QQ 群地址了，有兴趣但是没有 GPU 的 V 友们可以进群玩耍了，免费分享不易，个人 GPU 资源紧张，大家稍微悠着点玩哈，本周都可以玩，计划下周一关闭 bot

@loadingimg 如果有条件能够上 TG 的人，直接加入他们官方的 discord 用就可以了，另外如果你指的是你懂得那种 bot ，没有计划做那种 bot 。。。囧

@c0xt30a 感谢老铁的关注，双击 666 ，等我找到允许放奇怪图片的图床后 用马云、川普给大家表演杂技，奥利给

@israinbow 这位同学你不要担心，我们一起努力做好 NSFW 检测共建河蟹社会，你看代码里的 x_checked_image, has_nsfw_concept = safety_checker(images=x_image, clip_input=safety_checker_input.pixel_values) ，之前没有这个检测的话，各种不和谐内容 AI 模型什么都敢乱画，多亏了这一行代码它巩固了我们人民的纯洁心灵，我们要保卫这个检测不被别有用心的人删掉，有这一行在，非常安全

@pabupa
前端校验密码强度即可，如果有黑客强行修改请求设置自己弱密码，那他要是被盗我们真的不管了，不过 99.9999%的用户都不会绕过前端限制为了设置弱密码，所以考虑风险可控，已经足够了

以及我们真的能够在服务端验证用户的密码强度（词典），但始终不会搞，为了黑客硬改请求设置弱密码然后被盗这个场景，去让研发加一堆功能是通不过需求评审的。。。

密码按照监管要求，必须散列后再提到服务器端，hash 是不可逆的，防的是网站服务器方拿到明文密码，当前大厂都是按照这个要求的，我举几个风险的例子

1. 公司 SRE 维护服务器时，可能从 nginx 上 dump 出明文密码，在大厂，那么多 SRE 谁要是随便操作失误一下拿到一堆用户明文密码，直接能拿出去卖了
2. 密码即使散列加密后也属于机密数据，不允许流转大数据分析平台，但我们始终需要一部分人在帐号中台去触及这些数据的存储备份传输分析维护，这些人创业初期是推心置腹的好兄弟来承担重任，后面公司上市后人员换了一波又一波，你怎么知道哪个时间点哪个 admin 不会看着明文密码动坏心思？哪天不知道啥网站啥地方漏密码了，你会怀疑自己公司每一个人么？
3. 监管有时候会来调查案子，某用户智商捉鸡别的网站被骗了，然后觉得是帐号被盗了，密码大概是泄露了网上明文能查到，然后有人联合用户造谣非说你网站被黑泄露的，好了请你协助调查一下明文密码是不是你公司网站泄露的？嗯？散列不能恢复？调查结束，辟谣就好了

正确解法就是强制要求前端加密（散列），不过不是骗鬼，是防止内鬼骗你