抡锤者

你这眼泪是从嘴角流下来的吧

@terry 老特的认可含金量好高的

补充几点，跟 @stxpnet 上面的结论互补： Layer Split 在你这套配置下基本没救：每个 token 的激活都要逐层过那条 3.6GB/s 的芯片组链路，等效带宽被最慢一环钳死，prefill 掉 78% 就是木桶效应。Helper + REO 的 82.5 t/s 已经是这套硬件的高点了，方向对了。 换 X570 + 5800X 不值：x8/x8（~16GB/s）确实能救 Layer Split，但 Helper 模式下 decode 的天花板是 CPU 内存带宽（DDR4 双通道 ~50GB/s），两者打平；同时你拿 13700K 的 prefill 单核优势换成 5800X，反而更弱。 别只把 5060Ti 当「第二段层」。它是 Blackwell、原生 NVFP4；4070TiS 是 Ada，没有。更划算的用法是当专用副卡：独立跑一个 NVFP4 量化模型 / 视觉 OCR·mmproj / 或当 MTP draft 卡，主卡专心 dense 推理。这些负载对芯片组 x4 不敏感，闲置就浪费了。 对比用端到端 wall-clock，别信 Strata 后台那个 PCIe 读数（瞬时虚高）。固定同 prompt、同 ctx、同 batch，单卡 vs Helper+REO 各跑几轮取中位。

大头就是两张 Pro 6000 96GB：单卡国内行情约 8~12 万元（看是否 Max-Q、行货/渠道、带不带保），双卡 16~24 万；其余 Z890 + Ultra5 225 + 256G DDR5 + 2TB + 电源约 1.5~2 万。整套大概 20~26 万元，显卡占 85% 以上。 两个容易漏的点： ① Pro 6000 Max-Q 单卡 TGP 300W，双卡加 CPU，1000W 虽能带但瞬态余量小，建议 1200~1300W ATX3.1。 ② Z890 的 CPU 通道要能拆 x8/x8 才能双卡对等，否则第二张会落到芯片组 x4，大模型装载和跨卡通信都吃亏。下单前先查主板手册的 bifurcation 支持。

要买就下吧，新的成本16k了

看到最新一期的老特说，老师说我眼泪掉下来，全程用CODEX部署，兄弟们说的多卡方案，包括deepseek等我都理解，但是目前我只能跑单卡，因为并发非常高，可能超过20个并发，而且是多人办公场景，不是一般问答， 所以智能TP1走单卡推理跑7副本的27B和一张卡单独OCR跑的paddle 1.6vl（ocr需求很大所以单独一张卡）一下是当前我的配置参数，希望有大神能指点一下： 以下是 2026-10-10 最后部署、读回并保存的配置。当前离开服务器局域网，没有重新连接服务器；以下不是实时状态。连接地址、账户、API 密钥和 GPU UUID 均已省略。 硬件与软件 Ubuntu 24.04.3，NVIDIA 驱动 580.178.04。 双路 AMD EPYC 7443，合计 96 逻辑 CPU；安装内存约 512GB。 8 × RTX 4090D 48GB 改装卡；每卡 nvidia-smi 显存总量 49140 MiB，requested/enforced 功耗上限均为 350W。 Docker Linux amd64 部署，每个 LLM 容器只绑定一张物理卡，shm_size=8gb。七份独立模型副本，TP=1；不是七卡 TP=7。 SGLang 0.5.21，固定源码 commit：e00930c5489053f26d86b179cee0d087f846acbb，固定镜像 CUDA 13.0.3。 上游镜像标识 lmsysorg/sglang:v0.5.21；实际固定来源为 docker.io/lmsysorg/sglang@sha256:b1259f3ea3275f66237c498ea388919729018bc9f01c3d638391e06e2cf3f469。本地加载标签为 llm-inference/sglang:prepared-20261003。 模型：cyankiwi/Qwen3.8-27B-AWQ-INT4；revision：6e134bae811fb5adac50ee042ae5f029ac6779aa。 checkpoint 实际为 compressed-tensors / pack-quantized，W4A16、INT4 权重、group size 32、非对称量化；运行 dtype=BF16。不能仅根据 AWQ 仓库名把加载参数改写成 awq 或 awq_marlin。 checkpoint 自带一层原生 MTP；draft 路径与主模型相同。相关 MTP 线性权重在 INT4 量化的 ignore 清单中，不能描述为全模型 INT4 或全模型 BF16。 卡片分配与关键差异 GPU0–5 是六个普通 128K 副本，通过网关分配请求。GPU6 是独立的 256K 服务，只有获管理员授权并在当前对话打开 256K 的账户使用；不加入普通网关轮询。GPU7 独立运行 OCR，不参与 LLM 的 TP 或 MTP。 参数 普通 GPU0–5 长上下文 GPU6 tensor-parallel-size 1 1 context-length 131072 262144 SGLANG_MAX_NEW_TOKENS_LIMIT 32768 65536 max-running-requests 4 1 max-total-tokens：配置目标 262144 262144 实际 KV token pool：代表卡运行读回 GPU0：186700 262144 mem-fraction-static 0.88 0.93 cuda-graph-max-bs-decode 4 1 max-mamba-cache-size 20 6 代表卡实际 KV 池显存 GPU0：11.395 GiB 16.000 GiB 代表卡短题期间常驻显存 GPU0：40631 MiB 42225 MiB 上下文是输入、思考和最终回答的合计预算。32K／64K 是最大输出预算，包含思考，并不保证每次都输出这么多。普通卡的 4 个运行槽位不代表能同时容纳 4 个完整 128K 请求；配置 max-total-tokens=262144 也不能替代实际分配的 token pool 数值。 普通 128K 实例实际启动参数 每个普通容器分别运行以下命令。LLM_API_KEY 为私有环境变量，这里没有给出其值。 export SGLANG_MAX_NEW_TOKENS_LIMIT=32768 python3 -m sglang.launch_server \ --model-path /models/Qwen3.8-27B-AWQ-INT4 \ --served-model-name Qwen3.8-27B-AWQ-INT4 \ --host 0.0.0.0 --port 30000 \ --tensor-parallel-size 1 \ --dtype bfloat16 \ --kv-cache-dtype auto \ --context-length 131072 \ --max-running-requests 4 \ --max-total-tokens 262144 \ --mem-fraction-static 0.88 \ --chunked-prefill-size 2048 \ --prefill-decode-interval 1 \ --cuda-graph-max-bs-decode 4 \ --max-mamba-cache-size 20 \ --mamba-ssm-dtype float32 \ --attention-backend triton \ --quantization compressed-tensors \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --log-level warning \ --api-key "$LLM_API_KEY" \ --enable-metrics \ --speculative-algorithm EAGLE \ --speculative-draft-model-path /models/Qwen3.8-27B-AWQ-INT4 \ --speculative-num-steps 1 \ --speculative-eagle-topk 1 \ --speculative-num-draft-tokens 2 \ --speculative-draft-attention-backend triton \ --mamba-radix-cache-strategy extra_buffer 其他容器环境：HF_HUB_OFFLINE=1、TRANSFORMERS_OFFLINE=1、HF_HOME=/cache/huggingface、OMP_NUM_THREADS=2、TOKENIZERS_PARALLELISM=false。模型目录只读挂载，各容器有独立缓存目录。 GPU6 的 256K 实例 与上面的普通启动参数相同，只有下面六项变化；其余参数，包括 served model name、主／draft 路径、精度和 MTP 参数都保持相同。该实例在独立容器中运行，不与普通实例占用同一卡。 SGLANG_MAX_NEW_TOKENS_LIMIT=65536 --context-length 262144 --max-running-requests 1 --mem-fraction-static 0.93 --cuda-graph-max-bs-decode 1 --max-mamba-cache-size 6 两类服务 kv-cache-dtype=auto 实际采用 BF16，Mamba SSM 状态为 float32，没有使用 FP8 KV。CUDA graph 没有禁用（运行读回 disable_cuda_graph=false）；LLM 未启用 mixed-chunk。GPU6 保存的 CUDA graph 分配记录包含 target verify 0.105GiB、draft extend 0.002GiB；1 step 下 draft decode 记录为 0。分配记录不能证明每一步都成功 replay，也不能把 draft decode=0 单独当成未启用 CUDA graph 的证据。 第八卡 OCR，仅供了解是否有资源干扰 GPU7 使用 SGLang 运行 PaddleOCR-VL-1.6-0.9B，TP1、BF16、context=16384、max-running-requests=32、max-queued-requests=128、max-total-tokens=524288、mem-fraction-static=0.68、chunked-prefill-size=8192、max-prefill-tokens=16384、enable-mixed-chunk、num-continuous-decode-steps=2、cuda-graph-max-bs-decode=32、attention-backend=triton、mm-attention-backend=triton_attn、mm-processor-worker-num=2。另有 4 个完整文档解析管线绑定同一 GPU7，文档级并发 4。OCR 没有启用本次 LLM 的 MTP。 测量方式与已观察现象 原网页用“字符数÷4”估计 token，中文速度因此明显低估。现已改为服务端真实累计 usage token 和单调时钟计量，包含思考、正文及工具参数；输出速度不包含首字等待和工具执行。不能拿旧网页的 20 多或 10 t/s 直接当作原生解码吞吐。 直接推理同题对照：关闭思考（reasoning_effort=none），temperature=0，max_tokens=2048，串行单请求，各卡 1 次预热后 3 次正式样本。每个请求使用不同 cache_salt，不清空缓存、不重启服务、不强制忽略 EOS。所有请求实际输入 118 tokens、输出 450 tokens，均正常 stop。 直接推理正式样本中位数 GPU0：128K GPU6：256K 首末真实累计 token 增量／输出窗口 62.453 t/s 62.485 t/s 套用旧字符／4估算 27.262 t/s 27.276 t/s 首段正文到达 68.9ms 71.1ms 同批采样最高核心温度 56℃ 60℃ Agent 全流程另有两条无工具、关闭思考的合成请求：普通实际输入 640／输出 428 tokens，网页 53.9 t/s；随后同一会话开启 256K，实际输入 1185／输出 467 tokens，网页 54.7 t/s。它们有不同输入和历史，不能当成严格同输入性能比较。服务端首段等待分别约 0.098 秒和 14.005 秒；这次 256K 的长等待尚未归因，不能据输出阶段吞吐宣称首字已经解决，也不能从单样本断言是 MTP 或 256K 参数导致。 此前独立 GPU0-MTP / GPU1-无MTP 对照，三种短题、每种 3 次正式样本、1024 token 上限：无 MTP 约 51 t/s，MTP 约 67–71 t/s，提升约 31%–40%；首个原始模型 chunk 增加约 7–12ms。该旧对照输出以 length 截断，不能证明完整回答质量相同，也不能替代长上下文性能结论。 用户体感：较强思考时正文首字等待更长。实际 Agent 请求可能带有系统提示、工具定义和工具返回，“空聊天窗口”不等于模型实际输入为空。曾观察到真实 Agent 输入 10894–19117 tokens；没有导出真实用户问答。 希望请教 对这个 compressed-tensors 非对称 W4A16 模型和改装 4090D 48GB，当前 Triton 后端、MTP 和缓存参数是否有可验证的优化空间？ 保持 128K／32K、256K／64K、350W 上限，以及目前 KV／SSM 精度时，哪些设置值得优先做单变量对照？ 如何进一步区分上述 256K Agent 首段约 14 秒是队列、预填充、编译／缓存还是应用侧等待？应追加采集哪些日志或指标？ 怎样进一步确认原生 MTP 接受率和 CUDA graph replay，而不把缓存容量、chunk 字符估算或思考结束时间误当成解码速度？

@terry 我现在一想起来当初那个蓝宝石7900xtx 全新未拆封， 4900， 我没买， 我就直掐大腿。

@Hao-Chen 1，可行，总之就是省内存的钱。服务器主板可以用很久，价格合适就行。2，建议你可以研究下海淘，JD，天猫，拼夕夕有的店铺发海外的。X99的板子国内华南金牌和精粤等产品质量十分稳定。

@鍾子揚 说: 目前分配還行~有點極限QQ~~ 所以又買了1600W等新4T ssd到一起換上去~主盤1TB半年健康度剩下90%~ [image: image.jpeg] 我有一个一模一样的电源

@terry 狠踩一脚

现在Strata更新支持了越来越多的老显卡，然后双卡也快很多，快更新试试

Spark 虽然显存带宽不行，但网络和计算很强 现在看来MAC 更适合个人单任务慢慢跑 Spark 组集群 更适合小团队来用。

@terry 这个就是上次说有黑罩子的那个。这个是外面： [image: image.jpeg] [image: image.jpeg] 这个是里面： diding顶上和侧边加了几个风扇，温度最高是80，以前跑llama.cpp 负载高的时候会跑到80 ， 现在换 vllm ，或是strata ，都是70左右： [image: image.jpeg]

@johnnybegood 也會有點擔心。不過來都來了，等到上機後見真章

@懒人烘培 说: 2G还可再战几年 戰起來

原来也在考虑9700，看来声音确实是有些大

先看你板子给的通道。X870E 这代 CPU 侧只有 24 条 lane：x16（给显卡）+ x4（一般给第一个 M.2）+ x4（给芯片组），所以那几个 x4 大多不是「独占」的。 7900XTX 插 5.0 x16 没问题，别动。 那个 4.0 x4 槽和 M.2 转出来的 4.0 x4，单条带宽是一个量级（满速约 7.8GB/s）；但走芯片组的 x4 要跟所有 M.2/USB/SATA 共享一条 DMI 4.0 x4，两块 3090 都挂芯片组侧会互相抢。是哪个槽走 CPU、哪个走芯片组，查主板手册的 block diagram 最准。 3.0 x4（约 3.5GB/s）只建议放副卡，别把要参与通信的那块放上去。 对双 3090 跑 AI 的实际影响，取决于你怎么用： 层切分（llama.cpp --split-mode layer，或各卡各跑一个模型）：每 token 卡间几乎不过数据，x4 完全够，4.0 和 3.0 差别很小。 张量并行 TP=2（两卡合力算一个模型）：每层都要 all-reduce，x4 会明显拖慢，3.0 x4 更差；3090 的 NVLink 桥现在又贵又难买，没桥就只能走 PCIe。 所以结论：如果只是要 48G 容量跑大模型 + ComfyUI，方案一（延长线接 4.0 x4 + 3.0 x4）就够，别为通道过度纠结；真要上 TP，尽量把两块都放到 CPU 直连的 x4 上，别都塞芯片组。 另外两点：双 3090 满载约 700W，先核电源与风道；ComfyUI 双卡不叠加显存，出片主要吃单卡 24G。

我很少跑几秒的哦。。。。现在都是45s 单条以上。。。。虽然效果不怎么完美，等我得空我再优化

咦，这是回档了？之前修改加了注，怎么现在刷新又看不到了？