不错的分享，我有几个改进意见，楼主可以参考：
1、数据缺失。比如最关键的prefill性能对比。以及双卡场景更有竞争力的27B模型性能。以及说模型的具体型号，以及使用的框架容器的具体信息。以及运行参数的取舍逻辑。

2、尽量不要让AI或者网络检索去“云”其他平台的性能数据。比如楼主下面对于N卡的对比，无论是价格、性能，都是失真的。本质上没什么信息增量。

这个双卡数据贴很有价值，kop wang 的两点意见我也认同：prefill 数据缺失、以及别拿"云"来的 N 卡数据做对比（二手价格和网上性能数字都失真，信息增量约等于 0）。我补一个 27B 双卡反而变慢的机制解释，这个现象有账可算：

27B-Q8 在 262K 上下文掉到 20 tps，主因大概率是 KV 缓存顶满 + 溢出到系统内存，不是双卡本身拖累。

按 27B 级密集模型（约 64 层、GQA 4 个 KV 头、head_dim 128）粗算：

• Q8 权重约 29GB；
• fp16 KV 每 token 约 128KB → 262K 上下文约 33GB；
• 合计约 62GB，贴着双卡 64GB 上限，再加上 CUDA 上下文/缓冲/碎片，实际大概率溢出 → 落到 DDR4 2400 系统内存，解码被约 38GB/s 的内存带宽卡住。

对一下你自己的数据：单卡 27B-Q8-128K 是 22-25 tps——128K 的 KV 只有约 16GB，权重 29GB + KV 16GB = 45GB，虽然也超单卡 32GB 会溢出，但溢出量小；262K 时 KV 翻倍到 33GB，溢出量大了不少，于是掉到 20 整。

验证/优化建议：

1. KV 量化到 q8：KV 从 33GB 降到约 17GB，双卡总占用约 46GB，每卡约 23GB，从容。理论上 262K 双卡能回到 35-40 tps 区间（解码每 token 要把全量 KV 读一遍，单卡读约 17GB ÷ 640GB/s ≈ 26ms/token → 上限约 38 tps）。
2. llama-server 启动日志或 /health 看 kv cache 是否全在 VRAM；n_past 反复归零是 spill 的典型特征。
3. 想要 kop wang 要的 27B 双卡对照数据：固定 27B-Q8，128K vs 262K × fp16 KV vs q8 KV 跑四组，双卡和上下文长度两个变量就拆开了。

35B-A3B 双卡能到 72 tps 反而说明互联没问题——MoE 每 token 只读激活专家权重，流量小，PCIe 3.0 ×8 的副卡喂得饱；密集模型才是真正考验 KV 预算的场景。

双卡跑分层pp大概多少，有没有用dflash？