抡锤者

@Thanaots 做了什么可以来分享，频道好我可以推广下。以后论坛可以分享下用户的高质量内容，优秀频道也会做专业展示。

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

看到最新一期的老特说，老师说我眼泪掉下来，全程用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 字符估算或思考结束时间误当成解码速度？

4090 24g可以官保。不动是很好的选择。 现在本地模型的方案 进步飞快。24G也完全够用了。 Strata/单卡4090 24g minmaxH3 顶内存就完事了。内存最拉的情况都有五年保固，有的还是终身的。

60 和 168 的差距，八成不在参数，而在专家有没有全部驻进显存。 168 那个成绩的前提是 IQ3_XXS 把全部专家缓存进了 48G 显存，decode 全程读显存；普通 24G 卡装不下全部专家，Strata 会把一部分专家放系统内存或按需走 PCIe，decode 就从"读显存"退化成"读内存 + 拷贝"，掉到 60 t/s 很正常。 先确认三件事： 你的卡是 24G（普通 4090/3090）还是 48G？这是主要变量； 用的哪个量化，IQ3_XXS 和 IQ4_XS 全专家体积差一截； 专家缓存上限 / GPU 专家数设了多少，是不是一大半留在 CPU。 用 benchlocal 或 zxbench 打一组 pp/tg 分曲线，同时看显存占用和 PCIe 流量：显存没吃满、PCIe 有持续读，基本就能定位是专家没进显存。 想追 168：要么减量化/减上下文让专家塞得下，要么加一张卡专门放专家；只调参数从 60 跳到 168 不太现实。

@terry 好

@terry 我怕漏液才用風冷

@_折騰_ 加油，期待你的新帖子。

不能等等那个DGX Station吗？不是284GB vram

先 单卡 逐个烤鸡下。

@williamlouis said: 双卡。单卡故障了维修不影响公司运营。 R9700 32G 雙卡 真的是比較有保障, 萬一其中一張故障了, 還是能撐住基本服務需求

房地产的蓄水池已经报废了，股市这个临时缓存蓄水池最终要把水转出来。ai产业，是最新的蓄水池。一旦产生政策性的意向。必然要把他推到产业化赚外汇的新资金蓄水池。所以这个不是临时风口和炒作。何况地球上两大国都在竞赛中。必然要让他和房地产一样持续跑上10年。普通人没办法在蓄水池中取食。这个才是我们的强烈无力感。

当你不买的时候他每天都在涨价 , 你一但买了绝逼第二天就暴跌 , 老黄和东哥都商量好了就要坑我这万把块钱

@bily-j 24G 和 48G 的 4090 是同一颗 AD102，纯算力一样，「单步速度」在模型能全量放下的前提下几乎相同。williamlouis 说的 48G 快，快在读得进，不是算得快。 分水岭是显存容量： H3（FL2VA/Ref2VA 这套）权重加文本编码器、VAE、latent 和 KV，720p/1MP 一开就顶到 30G 以上。24G 卡必须 offload，权重或 VAE 反复往返系统内存、走 PCIe，单步被带宽吃掉，实测常见慢 2 到 5 倍，分辨率或帧数越高越明显。 48G 是加显存版本，核心不变，但能全量驻留，吞吐正常；代价是供电和显存散热更吃紧。 所以结论：能全量加载时两者速度接近，48G 不会更快；一旦超过 24G（H3 基本必超），24G 明显慢且更容易 OOM、抽卡失败。 自己判断很简单：nvidia-smi 看是不是稳定在 22 到 23G、显存利用率是否满；若 system RAM 占用飙升、GPU 利用率抖动，就是在 offload。48G 魔改卡跑长视频还要盯温度。