@老虎会游泳，OK

{
   "id":"chatcmpl-abc123",
   "object":"chat.completion",
   "created":1677858242,
   "model":"gpt-3.5-turbo-0301",
   "usage":{
      "prompt_tokens":13,
      "completion_tokens":7,
      "total_tokens":20
   },
   "choices":[
      {
         "message":{
            "role":"assistant",
            "content":"\n\nThis is a test!"
         },
         "finish_reason":"stop",
         "index":0
      }
   ]
}

@老虎会游泳，这个usage对象应该是当次调用消耗的tokens吧？

@Curtion，@老虎会游泳，多谢，看到了

@Curtion，似乎还不是时候。具有从对话中学习的能力的 chatgpt api 还在开发中吧？

https://community.openai.com/t/openai-api-vs-chatgpt/49943

@老虎会游泳，观察很久了，感觉你这种让大家都能体验ChatGPT想法有点逆天（很酷）。新的ChatGPT网页可以理解为OpenAI限制了单个账号的并发能力，是否可以让更多OpenAI账号参与进来，提升并发能力？

我有一个很初步的想法：做一个开放的 ChatGPT 接口系统。

该系统可以分为两个模块。一个模块负责维护应用层的用户会话并实现通用的聊天api（REST 或者 WebSocket ），可以暂且称为 chat-server；另一个模块负责和ChatGPT网页、chat-server模块交互，暂且称为chat-agent（即为老虎你现在在做的油猴脚本）。
每个拥有 OpenAI 的账号都可以运行chat-agent，chat-server拥有所有agent的信息，可以在收到新会话时分配给不同的agent去处理。

如果可以的话，你可以制定相关协议，由大伙一块去实现。我使用Go，非常愿意实现chat-server。

@无名啊，SSD随机读写也比顺序读写慢，虽然少了机械臂移动的时间。

我这里说的慢倒也不是随机和顺序读写的问题(可能有一定关系)。我不太了解文件系统，但根据经验来看复制大量小文件时会更慢，可能有一部分时间花在了从文件系统查找文件吧。

更重要的是块拷贝更可靠，它不用关注上层文件体统的实现，原来什么样，迁移后就什么样。

如果我十分了解文件系统和分区表，那我可以尽情订制拷贝计划

当然了我们现在可以讨论直接从上层拷贝文件的问题，只要能符合我的预期就行

@无名啊，是否会漏掉一些文件系统属性的拷贝，不了解文件系统这一块，而且可以肯定的是会很慢，不能完全利用硬盘最高的顺序读写速度。整块拷贝应该是最可靠的，现在就是看看能不能在块拷贝的基础上极限提速

@老虎会游泳，在缩小分区之前能不能得到一个缩小预估时长？或者有没有软件能看到文件系统数据在分区内的分布？最好是非GUI的终端工具

666哇

玩儿玩儿的话，那自然不容易的。