SSang

哦，酒馆的话，decode 速度可能就还蛮重要的，特别是那些用 html 的本。

统一回复一下：

1. --parallel ，这个会直接平均分配你的上下文窗口，需要考虑清楚，如果你的上下文已经不够了，不建议开
2. 我认为 256k 是能让主 Agent 达到生产可用的基线，可以根据实际情况降低一点，但不能太少。
3. v100 的 kv 用 q8_0 ，prefill 速度降低将近 10 倍，我觉得已经不可用于生产了（ q4 劣化是不可避免的，社区普遍认为会损失 20% 左右智商，而 q8 一般被认为是几乎不损失）
4. dflash, mtp, ngram 这些投机解码技术实际上很吃场景，如果用过小米的那个 ultraspeed 就知道了，最开始几轮都能达到 1000toks/s ，但随着上下文增加或任务变得复杂，采纳率会大幅降低，最后也拉不开太大差距了。还有资源的可以考虑开一开（所以目前我都不太研究投机解码技术，而且实际干活的时候我更关心 prefill 我的场景，prefill 基本要占用总耗时的 80%）。
5. turbo 量化看起来是社区版本，一猫的那个我之前也有关注，我可能等过段时间有空了，再研究研究吧，现在他稳定跑着我有点找不到时间停机测试（我的用量还蛮大的）。


> PS：我这里的达到生产可用指的是能作为主 Agent ，执行一般复杂的任务（即实现某个功能/调研某个产品/输出某个分析等的 AgentLoop ，而不是简单的修改/整理文件工作或 Chat ），并且不会有长时间的等待（常规任务 Prefill 最多不能超过 30s ，或者至少 500tok/s 左右； Decode 至少 10tok/s 吧）。

> 如果你只是想要玩一玩 Chat ，或者作为 Subagent 执行一些简单任务，比如搜索，整理文件，提交代码，生成 Changelog 等，则一般 32-64k 已经非常足够（通常 Agent 的初始上下文会有 4-16k ，简单任务一般不会超过 32k ）。玩酒馆的话一般还是建议至少 128k 以上的上下文。写代码我觉得至少 200k 吧，不然就一直在压缩。

不对，我重新又试了一下，关掉 `--split-mode tensor` prefill 速度其实也是 600tok/s 。

他除了能让我两张卡同时跑满之外，没有任何提升（笑哭），甚至还有些许下降我觉得。估计是 PCIe 拖累了。

我发现了一个新的参数 `--split-mode tensor` 之前我用 row 一直报错 not support split buffers ，我以为不能并行，但是用 tensor 又能并行了，很神奇。

然后没有 nvlink 的话可能要加环境变量 NCCL_P2P_DISABLE=1 。

开了这个之后我的 prefill 速度大概到了 600tok/s 了

@ljian6530 T4 我觉得，不然你拿去玩 Minimax H3 吧（狗头），kvq4 这个 prefill 速度，没有优化的空间了。你就算 8 卡速度 x4 ，也才 280tok/s

@zzutmebwd 有些过于富有了，只能说玩 V100 的都是穷人

@strobber16 主要不是显存不够，是 prefill 太慢了

@paranoiagu 他这个是用来跑原生 tensor 模型的，好像最少也得 64G 显存吧。玩不起，32G 还是老老实实 gguf 吧

@catazshadow 噢噢，就是直接 pcie 拆分 4 卡的是吧。确实 pcie 也听够了，我之前搞过一个 pcie x1 拆分 4 卡的，当时也测不出有什么差距，但后来不知道被我丢哪去了。