Per-Test Breakdown
Test Type Avg Tok/s Min Tok/s Max Tok/s
Short (~20 tokens) 199 197 201
Medium (~100 tokens) 207 205 208
Long (~150 tokens) 207 185 218

@木生火 说:

招本论坛5个用户帮我做压力测试。
注册地址http://123.125.174.5:3000 ，注册时用户名前缀加lcz，我好管理。
注册后，发账号到该帖下。然后我给前5个充值300$测试。测试有什么意见跟帖。

木兄找测试要不要单独发个主贴？ 我是看到最后才发现，别人可能不一定看见。

我也不懂测试，不然注册一个帮你跑跑了。

1. Dense 27B 双并发总 32~36 t/s 就是这个量级，物理上到顶了——dense 每个 token 都得把整份权重搬一遍，两路并发共享同一条带宽，总量能叠的非常有限。这不是配置问题，是「每 token 全量读权重」的 dense 宿命。

2. MoE 才是这批卡的并发主力，你的数字就是活证据：35B-A3B 每 token 只搬 active 那 3B（加共享层），2 并发 202 tok/s 已经贴着单卡带宽理论线；Ornith 181 同理。「小 active + 大总参」天生为多用户/并发而生。

3. 6 张卡「最大化价值」的分工建议：

   • MoE 卡（35B-A3B / Ornith）专门挂多用户 agent、API、批处理——1 张就能扛几十路并发，比把 6 张都堆同一模型划算得多；
   • Dense 27B 卡留给质量优先的单流长任务：长代码链、256K 全上下文推理，单用户场景 dense 的稳定性和指令跟随还是比 MoE 强；
   • 别复制多份同一 dense 模型——单卡已到带宽顶，加卡不加单流速度（27B Q8 单卡就够，tensor-split 没必要）；
   • llama.cpp 开 --parallel 让单卡并发吃满（MoE 卡收益尤其大），KV 用 q8，窗口按需设。

免费资源最大化 = 让每张卡跑它最擅长的负载，而不是六张卡都干同一件事。

• 模型: Qwen3.6-35B-A3B
• 架构: MoE
• 长输入并发2: 202 tok/s

• 模型: Ornith-1.0-35B
• 架构: MoE
• 长输入并发2: 181 tok/s
这是一次长并发2的测试速度，基本2并发能榨干出实际最高单显卡能力。
好在这些资源都是免费用的，就像怎么最大化用起来它们的价值。

1. 退回 llama.cpp 是对的。RTX 8000 是 Turing（CUDA 7.5），没有 BF16/FP8，vLLM/SGLang 这两年新 kernel 基本只伺候 Ampere 8.0+，老卡要么跑不动要么慢到没意义。llama.cpp 的 CUDA 后端对 7.5 还保持支持，这条路最稳。

2. 27B 用两张 48G 属于浪费。Qwen3.8-27B 的 Q8_0 权重约 29G，单卡还剩约 19G 给 KV（q8 KV 约 37KB/token），开几十万 token 上下文都够。除非跑 FP16/BF16（约 54.6G 才需要双卡），否则第二张卡的容量是闲着的——它的价值只剩 tensor-split 让 decode 吃双份带宽。

3. 两卡一组的正确用法 = 同机 tensor-split（llama.cpp 加 -ts 1,1）。RTX 8000 单卡 672GB/s，双卡 decode 带宽翻倍到约 1.34TB/s。35B 级（ornith1.0 / qwen3.6 都是这个量级）：

   • Q4 约 21G：单卡就绰绰有余；
   • Q8 约 37-38G：单卡也能带 128K 上下文；
   • FP16 约 70G：正好两张卡拆，接近无损。
     速度账按"权重字节数 ÷ 带宽"估：35B Q8 双卡理论约 27ms/token（约 36 t/s 上限），实际打五六折。你缺的不是容量是带宽和算力，别学 24G 卡用户抠量化——Q8 起步，质量优先。

4. 288G 总量够养主力档：比如 70B 级 Q8（约 74G）双卡跑当主服务、其余卡分跑 35B。前提是卡同机箱；三组若在分开的机器上，跨网络合并没意义，各管各的。

5. 公网 new-api 放多模型方向没问题，注意并发：llama-server 开 --parallel 多用户时 KV 按人头累加，用户一多就把默认上下文调到 32K 左右，别让几个长会话把显存吃爆——这是多用户场景最常见的崩法。

行情上要不要出卡是另一回事，单说"用"，这批卡当容量型本地服务还能打很久。