目的：直接调用这个模型的免费额度，Opencode是默认安装。

直接给它服务器上SSH指令的用户名和密码，连接我的Ubuntu服务器（当前运行SGLang架构的Qwen3.8 27B FP8）。让它“探查服务器的软硬件情况，并就当前Qwen3.8 27B模型使用提出评估意见”

模型探查了CPU、GPU、PCIe 拓扑（GPU0 x16 / GPU1 x4）、内存架构与插槽数等，开始提出初步评估。评估意见初步怀疑因为我另一张GPU的PCIe插槽速度不足，可能MTP反而会拖慢推理，建议我做3个对照实验测试：

SGLang FP8（8099，TP2）——三个零成本实验优先做：

1. --no-mtp A/B：MTP 投机解码让每步前向翻倍，而 TP2 的 all-reduce 正好被 GPU1 的 x4 弱链路卡脖子——投机收益可能被链路延迟吃掉，实测见分晓
2. NCCL_P2P_DISABLE=1 对照：PHB 拓扑下强制共享内存中转有时反超
3. chunked-prefill 2048→4096：KV 余量充足（注释自证 64K 池仅 ~2GB/卡），大分块摊薄 all-reduce 固定延迟

测试结果是MTP开启能提速80%左右，另两个还没测试。

又要求其针对三大推理架构llama,vLLM和SGlang进一步评估优化可能。

结论：

1. SGLang 留任主力：混合架构补丁资产不可复制；RadixAttention 对编码代理循环（重发系统提示+清单的每轮迭代）收益远大于通用吞吐差距；FP8+131K 质量档唯一来源。弱链路之弊靠第十节 S1–S3 实验对冲。
2. llama.cpp 当辅助：唯一免疫 x4 弱链路的架构；Q4/Q5 GGUF 可单卡容身，与 SGLang 错峰共存。缺 RadixAttention 与投机解码，上限低于 FP8 档。
3. vLLM 退役：高并发吞吐优势（并发≤4 用不上）与多卡扩展性（被 x4 锁死）双双失效；int4 场景可由 GGUF 平替。仅当未来部署 vLLM 独占支持的模型时临时启用。

版本背景：llama.cpp 日更构建 b10537（2026-08-21）；

后续继续由模型自己写的脚本一轮一轮筛选参数。结束后我来通报结果。