@leeum 测试版还是有问题，结果不理想。

70b
单次请求：17~20s
并行 4 ，4 个请求，4 个成功，平均 30s
并行 6 ，6 个请求，6 个成功，平均 33s
并行 8 ，8 个请求，8 个成功，平均 41s
并行 9 ，9 个请求，9 个成功，平均 130s （确实如此）
并行 10 ，10 个请求，10 个成功，平均 142s
并行 11 ，11 个请求，11 个成功，平均 150s

8b
并行 8 ，8 个请求，8 个成功，平均 14s
并行 9 ，9 个请求，6 个成功，平均 25s
并行 10 ，10 个请求，10 个成功，平均 32s
并行 11 ，11 个请求，11 个成功，平均 34s
并行 12 ，返回异常

测试多了，还会出现“话痨”现象。正常回复在 40k 左右，“话痨”状态在 380k 以上

======

@imFu 我初学状态

ab -c 10 -n 10 -p ./testchat.json -T "application/json" -H 'Content-Type: application/json' http://localhost:11434/api/chat

testchat.json 中内容
```
{
"model": "llama3:70b",
"stream": true,
"frequency_penalty": 0,
"presence_penalty": 0,
"temperature": 0.6,
"top_p": 1,
"messages": [
{
"content": "安排一个南京的 2 天的旅游攻略，用中文回答",
"role": "user"
}
]
}
```

@ispinfx ollama 目前是单线程模型。
ab 工具测试 10 并发 10 请求，耗时 312 秒， 没有并发可言

给你个参考：
环境：双 3090 + nvlink + docker
命令：ollama run llama3:70b --verbose
刚刚好可以塞下。

ollama-1 | ggml_cuda_init: found 2 CUDA devices:
ollama-1 | Device 0: NVIDIA GeForce RTX 3090, compute capability 8.6, VMM: yes
ollama-1 | Device 1: NVIDIA GeForce RTX 3090, compute capability 8.6, VMM: yes
ollama-1 | llm_load_tensors: ggml ctx size = 0.83 MiB
ollama-1 | llm_load_tensors: offloading 80 repeating layers to GPU
ollama-1 | llm_load_tensors: offloading non-repeating layers to GPU
ollama-1 | llm_load_tensors: offloaded 81/81 layers to GPU
ollama-1 | llm_load_tensors: CPU buffer size = 563.62 MiB
ollama-1 | llm_load_tensors: CUDA0 buffer size = 18821.56 MiB
ollama-1 | llm_load_tensors: CUDA1 buffer size = 18725.42 MiB


测试三次结果：

total duration: 25.820168178s
load duration: 1.436783ms
prompt eval count: 14 token(s)
prompt eval duration: 483.796ms
prompt eval rate: 28.94 tokens/s
eval count: 448 token(s)
eval duration: 25.203697s
eval rate: 17.78 tokens/s


total duration: 30.486672187s
load duration: 1.454596ms
prompt eval count: 479 token(s)
prompt eval duration: 2.025687s
prompt eval rate: 236.46 tokens/s
eval count: 496 token(s)
eval duration: 28.322837s
eval rate: 17.51 tokens/s


total duration: 21.176605423s
load duration: 2.629646ms
prompt eval count: 529 token(s)
prompt eval duration: 2.325535s
prompt eval rate: 227.47 tokens/s
eval count: 324 token(s)
eval duration: 18.622355s
eval rate: 17.40 tokens/s

别来，本地人都挤的没地方去了 T_T

建议别剪，人言可畏

请参照高德地图角落点亮，把剩余的 81.1%点亮~

---
同南京人，我大榴莲都没去过 T_T

Toca Toca

@luomao
搞 IT 好为人师，但未必是人需要的。

交女性学代码这点有点发言权，除非与她个人强工作相关，其他都没有成功过。

与其冒着掉秃头风险调试 bug ，追剧看小说不是更有意思？！

小公司重构就用 golang ，性能好、省资源。
技术栈一旦确定下来就要有人维护，java 人那么多，招来就是工资倒挂，何苦？

服务器省资源用 debian ，能用 docker 用 docker 。
开发办公 ubuntu 足够，我就每两年装一次系统。

中元节产品发布上线

纯开发选啥平台都行，区别不大。

关于 Linux 的学习，可以尝试弄个 vps 搭个站，这个更有实践性。
ssh 、vi 、apt/yum 、ps 、top 、nginx 、docker 这些都是经常用到的。

能写单元测试写单元测试；
写不了细的，就当 api 测试写。

方案二：
基于方案一改良，把 left 和 right 的值换成 float 或 double ，不再递增只保证数值增加的。
新增元素，用两侧兄弟元素 right(leftNodeRight)与 left(rightNodeLeft)的值去计算新节点的 left 、right 。
left=(rightNodeLeft-leftNodeRight)/4+leftNodeRight
right=rightNodeLeft - (rightNodeLeft-leftNodeRight)/4

计算公式不一定，只要能保证有“足够空间”都可以，定时做好“空间”回收就行。