谢谢楼上各位，我先研究下。root 不是必须的。

@jorneyr 印象中 []uint8 会被当成字符串，需要声明成 []uint16 ，然后需要用到 uint8 和 []uint8 时得来回转换格式。

因为有 __setitem__ 方法。提供 dict.get 方法是因为 __getitem__ 在 key 不存在时会抛出异常。

一分钱，3 人 aa 收款应该怎么分配金额最合理

@julyclyde 你先看看 descriptor 的作用吧。简单来说，如果一个类（ Client ）的属性（ getMe ）是 descriptor ，那么在访问这个类的实例（ c ）的同名属性（ getMe ）时，访问的实际是这个 descriptor 的 __get__() 方法。
getMe = functools.partialmethod(callAPI, "getMe") 正是给类定义了一个 descriptor ，而它的 __get__() 方法里返回了一个 callable 。
而 return functools.partialmethod(self.callAPI, APIname) 这个实现虽然返了 descriptor ，但它不是类的属性，因此访问时并不会调用 __get__()。

partial 实现很简单，它的 __call__() 方法将新老参数合并在一起调用原函数。
因此 c.getMe() -> c. __getattr__('getMe') -> functools.partial(self.callAPI, 'getMe') -> self.callAPI('getMe')

partialmethod 是一个没有定义 __call__() 方法的 descriptor ，而它的 __get__ 方法主要实现是调用 partial()。
因此 functools.partialmethod(self.callAPI, APIname) 返回的是一个不能调用的 partialmethod 对象。
而 getMe = functools.partialmethod(callAPI, "getMe") 是给 Client 类定义了一个叫 'getMe' 的 descriptor 。此时，c.getMe() -> functools.partialmethod(callAPI, "getMe").__get__(c, Client) -> Client.callAPI(c, "getMe")。

先用 LLM 标注一部分，比如 1 万条，人工校对一下。然后用 bert 类的模型，例如 roberta 加几层预测标签来训练。

这玩意是个体力活，有多少人工，就有多少智能

不看进程不看 sy/wa 之类的，咋分析啊

@kenvix 算错了，800 GB 。

zap 挺慢的，基本没啥奇技淫巧
https://github.com/keakon/golog/?tab=readme-ov-file#result

@afxcn 正常的机器跑不起来，半精度 405B 需要超过 8TB 显存，100 多张 A100 80G ，大概 1 千万人民币吧。

@DIMOJANG numpy 是有的

单纯是因为 cv2 没有写 docstring ，只是转发到 c 的接口而已。

双 4090 用 vllm 部署 qwen2:72b-int4 ，最低大概要 42GB 显存。占满 48GB 显存的情况下，32 并发下大概每秒 300 tokens 。
用 ollama 部署，大概要 40GB 显存。2 并发大概每秒 30 tokens ，再增加并发性能反而下降。
但是具体到单个请求，只有 15 tokens/s 的样子，大概是 gpt-4o 的 1/4 。

友情提醒，最好换个框架，不然每秒几十个订单可能就扛不住了。

然后通知是什么场景呢？用户刷卡时，pos 机发到 server 端，处理完通知么？这个不是秒级就完成了么，还需要轮询？

这 2 者作用不一样啊，CORS 是跨域的安全设置，你没跨域使用 xhr 、fetch 时不受影响。

计算挺奇怪的，60 万用户全在一分钟内访问，这是主动发起的，还是定时任务啊？

平时还能有 1000 qps ，他们是有多闲，每 10 分钟都会查询一次…

说实话你这问题靠扩容没法解决，比如 8:59 时还是 1000 qps ，假设 1 台机器刚好。9:00 突然到 1 万 qps ，立刻再起 9 台机器，启动要半分钟，同步数据几分钟，然后发现 qps 回到 1000 了，它们又可以下线了。

就是问 3 个模型，然后让一个模型根据 3 个回答来汇总成一个回答
https://github.com/win4r/MoA/blob/main/utils.py#L154

@cinlen https://huggingface.co/spaces/hf-accelerate/model-memory-usage