官网逆向（网页 3.5 免费）、料卡支付、120 刀额度/2500 刀等额度号薅完额度就扔号不付账单，所以市面上很多卖 API 一块钱买一美元额度甚至更低。

看看我这边的 API：one.luee.net 国内直连，帮你解决网络问题，可以用 web 页面，第三方客户端使用更加灵活。

@gregy #18 那 stripe 这个可以宣告放弃了，我之前整 striipe 就挺麻烦，你注册美国公司一套下来，完事人家又说业务不允许，白浪费精力。

@Rh1 道理我都懂，只是我好奇的是，大家比较容易开到的银联卡都是内地和香港的银联卡，然后官网明确说我不对你这俩地区提供服务但是我允许你这俩地方的卡支付，是不是有种很奇怪的感觉？如果能有不是这俩地区发行的银联卡，那或许人家早就用正常 v m ae 卡订阅支付而不用这么费劲去给 openai 送钱了吧。

stripe 可以不用公司，我的 stripe 就是以个人身份注册的，不过你得看看你的业务类型在不在 stripe 允许的列表内，不然到头来还是白搭。

@alpha9318 网页后台

@dwzrlp 没有改善，4 的 API 要比 Plus 的 4 快一点，但是价格贵。

现在 PayPal 绑定需要美国非虚拟手机号才行了，想办法搞一个，不然你下次号都登不了。而且乐观点，现在你就绑 Apple ID 也不一定成功。你可以试试，如果成功了你就去买，然后开启 2fa ，代价就是以后登不上 PayPal ，但是不影响你在 App Store 消费。

@ryd994 我就是在 win server 上开存储开虚拟机，当然没钱买正版授权上淘宝买的序列号，勿喷。

@zhhmax 刚才忘了说，与其关注有 smart 实时通知，做好整个服务器的散热以及环境控制，这种即时同时在个人使用场景下其实也可有可无了，硬盘做好温控和避震，一块就能用好多年，做好阵列隔两散年主动换下其中一块盘整个阵列挂的几率大大降低了。

@ryd994 你说的这个确实没问题，回归一下实际的场景，楼主是找一个平台做一些 all in one 的事情，你说的是单个 nas 系统的事。zfs 有 snapshot ，hyperv 也有 snapshot 。我们再来考虑一下在具体实施后各个虚拟机的扩容以及迁移问题，硬盘直通给各个虚拟机，存文件后的剩余容量能否有效利用，以及后续扩容时的操作便利性。与其关心各个虚拟机的直通后硬盘监控以及备份扩容，那么让 Windows 去管理所有磁盘创建一个阵列，在后期的维护性上是否更省心呢？还有就是 smart ，nas 系统确实自带可以做到即时通知，不过在选购硬盘时就考虑好采用不同品牌硬盘或者同品牌不同批次创建好合适的阵列，那么硬盘出故障后，迟几分钟或者几天知道有何不可，不会有人搭建好 nas 从来不去系统看一眼就等系统监控发出邮件通知再去进系统查看吧。保护数据安全解耦和后期维护很重要，前期的方案也决定了后期维护的复杂度。

@jonsmith 这种方式确实简单，gpt 上 iOS 没多久站内就有人发了，不过后面看站内好多人都反馈这种方式最后翻车了，尚不清楚具体是什么原因。

@YICHUJIFA 用你的账号，我只需要第一次绑我的卡到你的号上操作时登陆一次你的账号。

再多说一句硬盘直通问题，我之前在家里的一台全 ssd 服务器上用 hyperv 开了六台服务器搭建过大数据集群，然后虚拟机的硬盘是用的虚拟硬盘，在虚拟机里测试文件读写速度和 win 里面测对应的那块硬盘读写速度没差。如果 win 上搞存储池的话虚拟硬盘可以随意移动备份还原只需要关注这个虚拟硬盘的备份恢复问题，如果把硬盘直通到虚拟机内部的话你要考虑硬盘故障后应急预案了，以及虚拟机内部的文件格式问题（比如说群晖的文件协议，增加了维护复杂度）在数据恢复方面引发的风险。

@dknagi esxi 在网络上的内容确实要比 hyperv 多，我们现在的需求 hyperv 和 esxi 其实差别不大，硬盘直通网卡直通这俩性能没有特别悬殊的差异。不过多说一句，如果你后面要引入显卡直通就得重新考虑了。

@rainbowStay 我们可以讨论更严谨一点，这个 kafka 如果连接的是两个不同的系统，那么你说的无法通过 ID 得到完整消息确实是个问题，保存 ID 的时候可以做到把这条失败的完整消息再保存到其他地方而不用再考虑重发问题。如果是上游的消息生产者也是自己内部系统，只能在消息队列中才能得知完整的消息内容而无法通过 ID 再从其他途径得到同样的内容在我个人看来是属于重大的设计缺陷，即便是这样，那也可以换个方式，新建一个队列把失败的消息放进去让消费原来消息队列的任务也监听一下这个队列就可以了，那么新的问题又来了，这样做到重发了，但是如果任务一直处理失败会不会放大数据量引发其他问题，比如说某段时间某批数据永远无法处理成功而一直重发会不会影响到其他批次正常消息的处理效率问题。

@rainbowStay 不用重发了，因为消息已经发成功了，有 ID 就能通过其他方式拿到完整消息的，要是消息再发一遍就重复了，这里和消费已经没关系了。楼主的异步处理消息的方式已经决定了不能再有重发消息的步骤，不然处理消息的那部分逻辑还得加上消息是否是处理失败的消息，增加代码复杂度。