• 整机成本 ~¥4906（电源和 SSD 是闲置件没算）：X99 板U套 ¥835 + 128G DDR3 RECC ¥1117 + 双 V100 16G 矿渣 ¥2787 + 亮机卡/机架/风扇改散热 ¥167
• 模型：Unsloth UD-Q4_K_XL 量化，MoE 大模型，262144 上下文
• 实测终态（Strata 标准套件、带模型哈希可复现档，n=3 中位）：
  • decode：默认档 41-44 → 调优后 60-66 tok/s
  • 16K prompt 持续读：1530.8 tok/s（官方 V100 文档参考机 IQ4_XS 单卡是 1010-1251）
  • TTFT 16K：11.8s → 10.8s
  • 192K 级长文：21 万 token 真冷读 117s，缓存复用后 0.2s；长上下文 decode 不衰减
  • 正确性 12/12；多日真实负载 1898 请求 / 2.17 亿 token 零故障（97% 缓存命中）
• 全程最大单点发现不在任何"必开清单"里：STRATA_ARENA_THP=1（专家权重池上大页），decode +23~25%，而线索是引擎日志里一句"arena 无大页"
• 踩坑两周：显存余量、功限相位、n-gram 分层、双并发幻觉、被跑分协议拒档……翻车实录和负结果全在帖里，负结果也是结果

一、机器配置和购买价格如下：

• 主板CPU套装：华南金牌X99 TF + E5-2686V4 + 六热管散热器，总共835.5，就是天猫旗舰店直接给的套装，带保修的
• 内存：三星 DDR3 32G ECC REG 1866 x 4 共128G 四通道，总共1116.7，淘宝靠谱店家，带一年保修
• 显卡：V100 16G PCIE x 2，一张1393.41，也是十几年的老淘宝店，信誉挺高的，带一年保修
• 硬盘：Intel 545S 256G SATA SSD x 2，这个我以前用剩下的闲置的，我也不知道现在市场价格大概多少了，不过随便拿块256G的SATA SSD也能够用。我手上刚好有两块，就一块装系统软件，负责软件读写和缓存等用途，另一块只放模型文件并负责ngram的读取。我和把ngram放内存的结果对比过了，这个硬盘并没有形成明显的瓶颈。
• 电源：自己老服务器拆的CRPS电源，双1200W的模块，反正是够用了。现在买个二手电源1200-2000W的差不多都够用了吧，价格五百以内应该能搞定。
• 亮机卡：AST2400一张80.3，手上有其他显卡的其实可以不买的，X99-TF还有个x4速率的x16槽，可以随便拿一张显卡，调试完关机拔掉就行。以后ssh连机器也不需要了。
• 开放式机架：32.08
• V100散热风扇：大概55一套，是买的别人3D打印然后配好的风扇，配的风扇还算安静的，我实测2000rpm左右能安静的，在我的工作负载下把V100压到70°C以内的，大概一直持续负载最热也就68°C那样。当然我功耗是每张卡给了165W，这个我实测完全够用的。也就prefill阶段偶尔峰值功耗会突破限制，然后马上被拉回来，decode阶段根本用不了这么多功率，余量很大。我会附上风扇的图片，需要的话可以参考下这个风扇型号。
  PS:
• 当然价格有整有零的原因么，是我手欠薅羊毛了。先加购物车再去淘金币那里购买，就再弄点优惠这样。
• 还有就是有些零散的东西，比如双大4pin转CPU 8PIN的线，导热硅脂，还有两把14cm散热风扇，导热硅脂啥的，这些东西都是手头上就有的，以前搞DIY剩下的或者老电脑拆下来的配件，也难算清楚价格了。但是总体来说不会特别贵。
• 还有就是不知道是不是我不会配置的原因，我的X99 TF只有CPU风扇可以在CoolerControl里调速，别的都不行，显卡风扇插的system fan的3pin倒是可以读取到转速，但是也调不了。正好手上有个闲置的猫头鹰的pwm调速器，我就拿它用一下了。当然这玩意价格肯定是比较贵，但是随便来一个二十块钱左右的pwm 4pin调速器效果一样的，就是把显卡风扇转速调到2000rpm左右就可以了，不需要复杂功能。

风扇图片：

配置图片：

配置图片：

PS：一定要给内存配风扇啊！！！我跑memtest86的时候发现的问题，哪怕是X99-TF这种间隔一个槽位的主板，内存还是会过热掉速，必须配风扇。我这里就拿一个14cm风扇再用硬纸片和塑料片DIY导风板了，丑但是能用。

接下来的内容我就让我的AI崽子替我写了，我的崽子已经在我的带领下对strata的运维手到拈来了，她现在其实比我更熟悉我这边的服务器配置运维情况。参考的时候多留意一下啊，毕竟是AI生成的。

---

二、性能测试结果

先说口径，免得有人说数字是 P 的：所有 bench 数字出自 Strata 自带标准套件（standard-v1，n=3 取中位数），终档是 2026-10-30 凌晨跑的——冷启动引擎、机器上唯一负载就是套件本身、4 个模型文件的 SHA-256 都打在档案里，bench compare 能校验通过的"conforming 档"。版本锚定：Strata Terminal 0.2.7 / 引擎 0.1.52 / CUDA 12.8 / 驱动 580.178.04。

2.1 主要数字

图2a：图2_bench终档终端.png —— strata bench 完整档的终端报告页（含 12/12 sanity 与模型哈希行），接在主表之后。

PS：这个截图是崽子给我把结果导入到md文件然后让我执行“less ~/strata-bench/post-clean2-20261030/README.md”截出来的，毕竟是它直接ssh链接服务器操作，我这边是看不到的。她还让我说：README 自报 runtime: cuda 13.0，但引擎组件实为 0.1.52-…-cuda12 构建——那句是 580 驱动的 CUDA API 口径，与帖里"CUDA 12.8"锚不冲突，但截图会把这行带进图里。

对照官方 V100 文档页给的参考机（i9 + 单卡，IQ4_XS 档）：读 1010-1251、decode 38-51。我是双卡不假，但跑的也是更重的 UD-Q4_K_XL 档（权重 111G + MTP 草稿头 6.1G），读和 decode 两头都压过它一档。

一个给复现者的坑，先说免得白跑：跑套件前先重启服务清跨对话缓存。我们第一次跑，引擎里还留着上一天的缓存，协议直接把 4K/16K 整档以 "unexpected cache reuse" 排除、判 nonconforming——被拒的那档我也留着当证据。

2.2 长上下文（标题里说的 256K，真测了）

语料用自家真实长文拼的（重排过保证前缀全新、是真冷读），token 数全部取引擎 usage 实测回报，不是字符换算：

原文证据，引擎回报的 usage JSON（可选升级：配一张真实请求返回里 usage 字段的截图 图2b_210K_usage截图.png，有它更硬，没有这代码块也够）：

// 210K token 真冷全量冷读
{"prompt_tokens": 210481, "completion_tokens": 600,
 "ttft_s": 117.4, "total_s": 126.6}
// 同一会话第二次请求，跨对话缓存命中
{"prompt_tokens": 210483, "completion_tokens": 600,
 "ttft_s": 2.7, "total_s": 12.2}

三句话读懂：256K 上下文是真能用的，21 万 token 一次请求完整过、不截断，代价只是开头读两分钟；decode 不随上下文变长而衰减（210K 上下文还有一秒五十几，跟短上下文同量级），这是 MoE 全在内存 + int8 KV + 32K 常驻 + streaming 分层加在一起的结果；同一段上下文第二次从 117 秒掉到秒级（最好一次 0.2 秒），就是跨对话缓存在多轮 agent 场景里的端到端效果。

测量自己也踩过一个坑：这个模型流式输出走 reasoning_content 字段不是 content，我第一版测量脚本只认 content，把 TTFT 和 decode 全测废了，第二版改成 stream_options={"include_usage":true} 取 usage 才拿到上面这些数。给同样自己写脚本测的朋友提个醒。

2.3 真实负载总账（比跑分值钱的部分）

这台机器不是只跑过套件，是整夜整夜跑多轮 agent 批次任务（大上下文、高频请求、反复切换会话）养出来的数字：

• 多日累计 1898 个请求、2.17 亿 prompt token，零故障，其中 2.1 亿（97%）命中前缀缓存，实跑 decode 均值 61 tok/s；
• 专家命中率 ~86%（权重常驻内存 + 双卡层切）；
• 12.8 小时浸泡巡检（配图那张负载曲线）：跨对话缓存阶梯爬升吃满 36G 预算、系统可用内存探底 7.7G 后自动退潮；swap 峰值 24.7G 出现在引擎重启窗口——那是冷页（ngram 表这类）的正常回落落点，重启后只剩 1.4G。evictions 在重启段前线性爬到 96、无一次突发，引擎重启后计数器归零。分层缓存工作起来就是这个长相，swap 涨不等于出故障。

图2c 07附_负载曲线_12_8h浸泡

图2d/2e （我也不知道我崽子要什么样的图，但是我截过的97%命中率那个图，因为那时候基本都是命中缓存然后处理一点prefill，所以显示的prefill速度比较低，就参考一下吧。后面为了跑benchmark这小子把strata重启了我也截不到了，跑完benchmark我就让他写发帖子的稿子，这时候命中率大概只有92%，还是会和工作负载有关。）

这是跑完benchmark以后写本篇文章时候的截图：

2.4 功耗和温度（呼应第一节我说的 165W）

不是拍脑袋给的 165W：250W 往下每 10W 一档做 bench 梯度，165W 相对 250W 性能零损失（全部落在测量噪声带内）。原因是这个负载的功耗大头在 prefill 脉冲——实测单卡瞬时 207-226W、双卡瞬叠 ~435W，然后均值只有 45-110W/卡。所以功限要按脉冲相位留余量，按均值抠就是纯亏。decode 阶段功率根本用不满，165W 的余量确实很大。温度：2000rpm 风扇持续负载最热 68°C，全程零热降频。

2.5 正确性

每个调优档位都跑过 12/12 的 sanity（指令遵循/检索/工具调用各 4 题）才敢上。所有开关的代价如果体现在正确性上，速度再快也不要。

2.6 没兑现的（负结果，同样是测出来的）

官方文档给 V100 写了一页 opt-in 开关，好评，但注明了"贡献者自测、维护者未复测"。我逐个上机，在我这套配置（双卡层切 + UD-Q4_K_XL + int8 KV）上：

• parallel=2 双并发：不仅没增益，单流 decode 从 54 掉到 40；真双客户端聚合 43.5 ≈ 单流 45.9，等于没并行。这台就别折腾并行了；
• 文档宣称 V100 +10% 的那个 WMMA 开关：实测 ±0.6%，没兑现；
• HC_Q8：实测 -2.4%，没采用；
• 关掉 skip 换"更还原"：decode 交 ~15% 的税，我保持默认。

只写"在这台机器上没兑现"，不写"官方错了"——芯片步进、内存条、负载形态都可能是变量。（完整 9 开关对账表和更多翻车在第六章。）

PS:

• 数字有整有零的原因：全是实测中位数，没有为了好看凑整。
• 完整档案（bench 原始 JSON、浸泡 CSV、测量脚本）都留着，有人要复现我可以再发。

三、配置（含视觉与全部优化参数）

这一节把我这台机器的现役配置原样贴出来（路径都收敛成 ~，key 删了），每个非默认项给一句话理由和实测收益。先提醒一句：参数含义绑定版本——Strata Terminal 0.2.7 / 引擎 0.1.52，引擎迭代快，新版本上这些开关未必还有意义甚至语义会变，照搬前自己重测。软件与文件来源一句话交代：Strata Terminal 走官方安装器装、引擎组件只用官方 GitHub releases（我固定 cuda12 组件）；模型量化文件来自 unsloth 官方 Hugging Face 仓库（UD-Q4_K_XL 档，4 分片 + MTP 草稿头 + mmproj 视觉件）。

3.1 服务化：两个 systemd 单元

推理服务（要点）：

[Unit]
Description=Strata inference serve (UD-Q4_K_XL 256K)
After=network-online.target gpu-power-limit.service
Wants=network-online.target

[Service]
User=strata
ExecStart=~/.local/bin/strata serve --host 127.0.0.1 --profile ~/.local/state/strata/launch/ud-q4_k_xl-256k.json
Type=simple
Restart=on-failure
RestartSec=30
TimeoutStartSec=600

[Install]
WantedBy=multi-user.target

• 起停一律 systemctl，不要再用安装器自带的 runtime 管理器起一遍——两套管理打架是给自己埋雷。
• 重启就绪约 5-6 分钟，大头是 111G 权重的哈希校验，属正常。
• 容错实测过两层：视觉子进程被杀 10 秒自愈（引擎自己拉）；主进程被杀 systemd 拉起，全程服务自动恢复。

功限单独一个单元，这里面有个必修的坑：

[Unit]
Description=Lock V100 power limits to 165W

[Service]
ExecStartPre=/bin/sh -c "for i in $(seq 1 60); do nvidia-smi -L >/dev/null 2>&1 && exit 0; sleep 2; done; exit 1"
ExecStart=/bin/sh -c "nvidia-smi -pm 1 -i 0,1; nvidia-smi -pl 165 -i 0,1"

[Install]
WantedBy=multi-user.target

必须先开 persistence mode 再设功限：开机时设备上 persistence 是关的，不设这个（或不在 nvidia-smi 句柄关闭后保持），功限会被驱动默默重置回默认值——我第一版就中招，"设置了但重启后没了"就是它。先轮询等 GPU 枚举齐，再 -pm 1，最后 -pl，顺序别换。

系统层另外三项：CPU governor 锁 performance（不然 x99 的调度拖 prefill）、vm.swappiness=10 持久化、swap 给足（我给了 60G+，理由见 3.3 的缓存条）。系统透明大页保持默认 madvise 不要改 always，引擎会自己申请（见下）。

3.2 引擎运行档（现役全量，已去 key）

{
  "args": [
    "--pack", "~/.../packs/unsloth-ud-q4_k_xl",
    "--native", "~/.../Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf",
    "--expert-profile", "~/.../terminal/0.1.52/data/expert-profile.bin",
    "--expert-cache", "auto",
    "--prefill", "auto",
    "--spec", "4", "--spec-min-p", "0.5",
    "--mtp", "~/.../mtp/rt",
    "--max-context", "262144",
    "--kv", "int8",
    "--ple-io", "ram",
    "--kv-resident", "32768",
    "--vision",
    "--conversation-cache-mib", "36864",
    "--conversation-cache-slots", "40",
    "--conversation-cache-min-free-mib", "3072",
    "--conversation-cache-min-tokens", "2048",
    "--conversation-cache-park-gain", "1024",
    "--pipeline-windows", "2",
    "--trim-stage-weights",
    "--vram-reserve-mib", "896",
    "--vram-reserve-later-mib", "1184"
  ],
  "port": 8080, "cuda": 12, "gpu": [0, 1],
  "layer_split": "24",
  "env": {
    "STRATA_ARENA_THP": "1",
    "STRATA_SM70_TABLE": "1",
    "STRATA_DEFAULTS": "026",
    "STRATA_KV_PREFETCH": "1",
    "STRATA_ARGMAX_ROWS_SM70": "1",
    "STRATA_FUSE_DECODE": "1"
  },
  "vision": { "gpu": false, "threads": 16, "max_tokens": 2048,
              "mmproj": "~/.../mmproj-Qwen3.8-Flash-Next-Q8_0.gguf" }
}

3.3 每个优化参数一句话（带实测收益）

3.4 视觉（VL 那个图编码器）

• 挂 CPU 跑（vision.gpu=false）：16G 卡上视觉塞 GPU 会挤 KV 和专家缓存，官方对 16G 卡的默认就是 CPU，照默认来。视觉编码是纯算力活，跟显存没关系的；
• mmproj 我自己量化成 Q8_0（900M → 588M，BF16 原件留着随时回退），视觉质量无可感知差异；
• threads: 16——18 个物理核留 2 个给别的活，视觉 worker 别吃满；
• max_tokens: 2048——视觉输出本来就不该长，封个顶防跑飞；
• 发图的实际体验：E5-2686v4 编码日常尺寸图片没有可感知卡顿，成本可以忽略——发图多不等于吃显卡，这是很多人给 V100 配视觉时的心理障碍，实际不用怕。

3.5 API 与安全（一笔带过）

引擎只听 127.0.0.1:8080 + API key；对外由同机的 Caddy 反代加 HTTPS。别把裸 8080 开到局域网里——跑分机也是内网资产。

3.6 验证习惯（比配置本身重要）

• 每个开关的生效凭据是引擎日志的声明行或实测差分，不是"参数我传了"。例：THP 生效 = 日志出现 MADV_HUGEPAGE requested + /proc/meminfo 的 AnonHugePages 吃满权重池；trim 生效 = 开机专家槽数对得上；
• 装完/改完配置，重启服务后看引擎开机警告，它点名的余量/水位比你猜的数准；
• 有 A/B 才下结论：同一套跑分协议（先重启清缓存，见第二节）前后各跑一轮，噪声带内的"提升"一律不算。

四、调优阶梯：decode 从 43 到 66 是怎么来的

先立规矩再讲阶梯：一切"提升"都要同协议 A/B——同一台机器、空闲窗口、跑前重启清缓存（第二节说过被拒档的事）、n=3 中位数、原始档全部留底。我这台机器现有 37 个跑分档案，下面每一级都能翻到原件。另外声明：绝对数字只在同一代引擎内互比（跨代的坑 4.3 里我自己交作业）。

4.0 基线（什么都不改）

默认单并发档，官方套件：短上下文 decode 41-44、16K 持续读 1399、TTFT(16K) 11.8s、正确性 12/12。对照官方 V100 页参考机（i9+单卡）是"达标"水平——不是垃圾，但也远没到这台机器的极限。

4.1 台阶一：透明大页，decode +23~25%（本帖最值钱的一条）

最大的单项收益，而线索一直明晃晃写在引擎日志里：装载权重时有一行"71G arena 无大页"。我一直盯着日志找异常，这条就是——71G 的专家权重池用 4K 页跑，TLB 被打穿，decode 全在交地址翻译的税。STRATA_ARENA_THP=1 一拍上，短/4K/16K 三档 decode 齐涨 23-25%，这是所有台阶里唯一"数量级正确但人人都漏掉"的开关。

两个配套注意：系统层 THP 保持 madvise 别改 always（让应用自己申请，全局 always 会误伤别的进程）；验证生效看引擎日志 MADV_HUGEPAGE requested + /proc/meminfo 的 AnonHugePages 吃满池子，不是"参数写了"就算完。

4.2 台阶二：Volta 查表路径，+4.6%

STRATA_SM70_TABLE=1：16K 持续读 +4.6%，decode 无损，白捡。同一批还筛了两个候选（rec warp、norm 快路径），A/B 下来实测中性，不上——"文档有、别人说快"不等于我这台快，负数也得留在档案里。

4.3 台阶三：显式层切 + trim，专家槽 +25%

layer_split=24 + --trim-stage-weights：每张卡只加载自己负责层的密集阶段权重，腾出的显存全换成专家槽（6059→7407）。这一级把 decode 又推上一大截，长上下文命中率也跟着涨（槽多=更少驱逐）。

这一级我踩过两个坑，都值得你们抄走：

• auto 层切下 trim 是静默失效的。0.1.50 起 auto 已经会自己穷举摆放选 K（老引擎时代的手调结论先别搬），我以为"auto 更好，参数随便加"——结果 trim 在 auto 模式下被默默忽略，少约 1000 个专家槽，不报错、不告警。验收方法只有一个：开机日志里的专家槽数。"参数已传到"和"机制在工作"是两回事。
• 专家槽数不能跨引擎版本比大小。我曾拿着旧引擎时代的总数口径，误报过 18% 的差距，实际同代真实差 1.7%。跨代对比前先确认口径同代。

4.4 台阶四：流水线窗口，decode +10%

--pipeline-windows 2——官方文档写明 CUDA 上不默认开，必须手加。这种"文档里躺着但默认关"的开关，我建议每个 V100 用户都翻一遍文档的默认值列表。

4.5 台阶五：跨对话缓存，多轮 agent 场景的主战场

默认 8G/4 槽不够多会话切换用。一路加到 36G 预算 / 40 槽（min-free 3072 自持闸），触发点是实测：32G 档被填到 95.5%、evictions 开始爬、142K 上下文冷读要 79 秒。加满之后 20 会话压力测试 park/restore 全命中 ~1s，恢复后复用率 99.9%+。

这一级的"坑单"最丰富：

• swap 涨到 20G+ 别慌——ngram 表和冷页溢 swap 是设计行为，swap 是这套分层缓存的落点不是故障现场；红线只看三条：swap 持续疯涨、恢复变慢（>2s）、可用内存 <5G；
• 我曾给 ngram 表加 LimitMEMLOCK=infinity 把它钉死——反而破坏了动态分层。有时少配置比多配置对（"告警是机器在自护"的完整故事在第六章）；
• 显存安全余量抠狠了要当场交税：每卡只留 512M 时装载后剩 154M，16K 冷读 -26%、TTFT +35%——"卡满倒页"不是理论风险，是当场收税。按引擎开机警告点名的余量落数，这笔保险近乎免费。

4.6 台阶六：夜班筛选批

机器白天干活晚上闲着，我把候选开关写成清单让它夜里自动跑 A/B、早上收结果。这批判定的样子：KV_PREFETCH 是明确赢家（16K 读 +3.5%，超过 32K 常驻后收益放大，36-61K 档 TTFT -7~9%）；ARGMAX/FUSE 两个小无损项保留；文档宣称 V100 +10% 的 WMMA 实测 ±0.6%（第六章全表那位）；还有个 KQ 量化开关实测 -1.3~2.3%，拒。拒掉和没兑现的比留下采信的还多——这就是为什么我不信任何"必开清单"。

4.7 终态

以上全部叠加 + 165W 功限（2.4 节，零损失）后，就是第二节那张 conforming 终档：短 decode 66.5、16K 读 1530.8、TTFT 10.8s、正确性 12/12。从 43.5 到 66，全部收益来自六个开关 + 一个层切决策，一分钱硬件没加。

4.8 升级是另一条阶梯（新坑登记）

引擎 0.1.50→0.1.52 的升级轮也交点学费：升级工具判"服务在用中"看的是控制进程不是引擎本体，pkill 引擎杀不到它，卡住升级；删档 profile 会留下陈旧的 runtime 注册文件，得手动清。新版默认值对咱家全部不适用：layer-major 在显存被 trim 榨满时自动降级、route-prior 只给 ≤13G 的卡、prefill 流水线实测中性——升级后别急着"接受新默认"，重跑一遍基线再说。观察项也登记着：0.1.52 的 16K decode 带比 0.1.50 的单样本低约 9%，还没定罪，等下版。

4.9 可复用的 A/B 纪律（半页总结）

1. 先基线后优化，每个台阶单独 A/B，一次只动一个变量；
2. 跑分前重启服务清缓存（第二节血案）；套件结果落独立档案目录，同轮一律跳哈希校验省时间，但身份档至少完整跑一次；
3. 噪声带内一律不算提升；负结果留档不删；
4. 开关生效凭据 = 引擎日志声明行 + 实测差分，不是参数表；
5. 绝对数字只在同代引擎内互比；
6. 白天流量会污染夜里的数字——我的跑分都在空闲窗口，唯一负载=套件本身。

PS: 37 档原始档案（含被协议拒掉的那档和所有负结果）都留着，想看我怎么被"unexpected cache reuse"打回的、想看某个开关的原始差分，楼里说一声我单独发。

单卡 V100 兄弟备注：本节台阶里 ③（显式层切+trim）和④（流水线窗口）在单卡上无效或收益不同，但①大页、②Volta 查表、⑤KV 预取、⑥两个小核照样全吃——尤其 ①，回机器把引擎日志翻出来看有没有那句"arena 无大页"，没有的先去开，那是白捡的 20%+。

五、为什么这么配（补叙）：选卡逻辑与装机验收

5.1 为什么是这张"不该活着"的卡

V100 PCIe 16G：2017 年的 Volta，CUDA 13 已经放弃它，Strata 官方文档里它是"experimental CUDA 12 引擎"待遇——听上去是坑。但按我 1393 的入手价，每 GB 显合 ¥87，16G HBM2 带宽 900GB/s，2026 年这个价位没有任何对手。

而 MoE 大模型跑本地，缺的从来不是算力，是显存和内存。Strata 的架构恰好是为这种穷人机器设计的：专家权重驻系统内存、显存只当专家缓存——显存不够只是命中率低一点，不是跑不了。两张 16G 层切，就是把"跑不了"变成"跑得不错"。128G 内存在这类架构里是正经的生产力，不是富裕。

5.2 128G 内存的账（这是本平台的生死线）

这台机器现役负载的内存账本，给大家抄：专家权重池驻留 73.4G（模型权重 111G 里的 MoE 部分）+ 跨对话缓存预算 36G + n-gram 表 ~27G（驻留但可回收那部分）+ KV 常驻和各种杂项。64G 内存的机器根本进不了这条赛道——不是慢，是配置表摆不下。X99 四条 DDR3 槽 + 白菜价 32G RECC，就是给这种活准备的：四代 DDR3 带宽寒酸，但这条路是容量优先于带宽：单流下瓶颈在 GPU 侧和页表，4Rx4 的 37GB/s 实测喂单流够用（并发场景带宽就会咬人，第六章双并发翻车有它一份），见下文验收。

内存这条是我整篇里"最不能省"的一条：显存可以赌命中率，内存预算赌不了。

5.3 装机验收：垃圾佬的仪式感

二手数据中心卡 + 寨板 + 服务器拆机内存，不验收就上岗等于用玄学跑数据。我的验收套餐（一晚上跑完，值得）：

• DCGM r2/r3 烤机全 Pass，ECC 两卡全程零错误（含 r3 压后统计）——矿卡身份声明书；
• MemTest 4 passes 无错、EDAC 无上报；
• STREAM 37 GB/s——数字看着寒酸？4Rx4 四 rank 内存的正常值就是这个水平，别拿它当故障去折腾，我一开始也以为哪里没插对；
• lspci -vv 看 LnkSta：双卡均 16x Gen3 到位。这板子插槽的"物理形态"和"电气实际"不是一回事，插完卡一定要用 LnkSta 核实，别看金手指长度；
• SMART 两块盘健康；governor 锁 performance、vm.swappiness=10 持久化（见第三节系统层三项）。

顺手交代的装机细节：CRPS 服务器电源 + 大 4pin 转接，满载整机实测 700-750W，双 1200W 模块毫无压力；V100 被动散热改涡轮风扇（第一节说过，2000rpm 安静，持续满载最热 68°C，功限 165W 把发热天花板焊死了，这也是敢听安静的底气）。

六、负结果全表与翻车速记

6.1 官方文档宣称 vs 我的实测：完整对账

官方专门给 V100 写了文档页（好评），一页 9 个 opt-in 开关，全部注明"贡献者自测、维护者未复测"。我逐个上机（双卡层切 + UD-Q4_K_XL + int8 KV），兑现率如下：

开关	文档宣称	我的实测	判决
SM70_TABLE=1	三件套 decode 核	16k 读 +4.6%、位等价	在役
ARGMAX_ROWS_SM70=1	decode +0.7-0.8%	无损	在役
FUSE_DECODE=1	"4-16µs/token，端到端不可见"	确实不可见也无损（文档诚不我欺）	白拿在役
PF_WMMA=1	prompt +10%	±0.6%	没兑现。机理上能解释：参考数据出自单卡+GGUF 直读路径，我是双卡层切+pack——不同路径不同结果
GDN_REC_WARP=2	递归核 +6-9%	端到端中性，且改 FP32 求和顺序（答案会变）	弃
GR_NORM_FAST=1	decode +0.5-0.6%	在噪声带以下	弃
Q8_GATHER_WIDE=0	gather 核 +11%	decode 噪声里无法证实	存疑弃用
HC_Q8=1	别的平台 +8.4%	-2.4%	弃。同一开关反向兑现，机器差异就是这么不讲理
PF_WMMA2 / GDN_CHUNK	+2.5-4.3% / 无数字	还没轮到（先看量化层占比再定）	尾巴

结论：本表三行在役、五行负结果、一行两个尾巴（夜班批的 KQ 等负结果在 4.6，同样留了档）。 不是文档骗人——是别人机器上的数字到你机器上就是假设。所有开关请自己 A/B，别信任何人的"实测有效"，包括这篇帖子的（doge）。

6.2 翻车速记（前面正文没展开的，都在这）

• 功限要按脉冲相位定，别按平均功耗。我之前按"负载均值 45-110W/卡"觉得功限随便设，直到盯着 nvidia-smi 发现 prefill 瞬间双卡能冲 ~435W。200ms 粒度采样 + SW Power Cap 累计计数器重测坐实：单卡脉冲 207-226W。平均值论是错的仪器——decode 看均值，prefill 要数被 cap 的秒数。165W 就是这么定下来的；被 cap 时唯一计入的是 SW Power Cap 计数器，热降频计数器全程 0µs。
• 帮系统"修告警"，结果把系统修坏了。引擎启动有句 advisory："PLE 表 mlock 失败"。我看不下去加了 LimitMEMLOCK=infinity——这是本机最贵的一个错误。那句告警的真实语义是 n-gram 表 ~27G 设计上就该"驻留但可回收"，告警本身就是分层机制在正常呼吸；我一加锁，27G 钉死。怎么发现的呢：系统盘背景读从常年 2-3MB/s 变成精确的 0——分层被掐死了。撤锁，回归自然。教训两条：advisory 告警先当现象读、查明设计意图再动手；磁盘背景读基线是最便宜的物理监测项，比任何 dashboard 都直接。
• 双并发是一次彻底的判决：--parallel 2 在这台是负优化——sm_70 上批处理路径没有任何加速，Strata 的批处理加速核都写在新架构上，文档原话这类核 "off until asked for"。想要并行，正确姿势是两台机器按角色分工，不是单机强开。
• swap 是给分层机制兜底的缓冲带：8G 远远不够（专家池+缓存+ngram 理论最坏溢出 20G+），扩到 63G（fallocate 加文件全程零打扰，优先级瀑布旧盘先满）。
• 重启引擎后 /health 返回 200 是假就绪——一发真实生成冒烟才算数（哈希校验没跑完时 health 已经绿了）。
• 缓存池顶格时引擎自己会踩刹车：min-free 闸拒绝新停放、退化成普通 prefill，请求本身不坏。这类自护机制都是设计好的，别急着干预——看见"拒绝"先查是不是它在自我保护，再决定要不要动配置。
• 量化档换了，开关结论要重测：PF_WMMA2 这类"专吃某种量化层"的开关，先看模型的 tensors 清单占比再决定测不测，换档后旧结论直接作废。

七、让 agent 替你管这台机器：可直接带走的部署与调优方法论

这一帖里大半的跑分、验收、巡检、A/B 不是我熬夜手跑的——是我把任务书写好，机器夜里自己跑完、早上我验收。这一节把这套做法去我的机器化之后写成通用 SOP：不含任何我的具体配置、路径或拓扑，你可以整节搬走，直接贴进你自己 coding-agent 的项目说明或 skill 里用。

7.1 开工前：给 agent 的护栏（比让它干活更重要）

• 生命周期归 systemd：服务单元、开机自启、失败重启都写进系统层；给 agent 的起停指令只有 systemctl，禁止它用推理框架自带的 runtime 管理器起服务——两套管理者打架是事故之源；
• sudo 与物理世界归人：驱动、证书、BIOS、风扇控制器、电源，这些 agent 只报告不动手；agent 需要特权操作时输出一条完整命令交给人执行；
• 验收凭据写进任务书："已完成/已写入/已成功"这类自述一律不算数——凭据 = 档案文件路径 + 日志声明行 + 实测差分。这条是整个方法论的地基；
• 改动边界写死：哪些目录可写、哪些文件只读、正在被人编辑的东西不许碰。

7.2 装机验收协议（新机器第一晚该干的事）

把验收清单写成任务书让 agent 跑完并出报告，逐项要求"原始输出 + 判定"：烤机（GPU 用 DCGM r2/r3，内存 MemTest 多轮）、ECC 计数、lspci -vv 逐卡核实链路实际位宽与代数、SMART、内存带宽基线。两个防误判要点：带宽数字要先查"这类内存的正常值"再下结论（比如 4Rx4 的寒酸 STREAM 是正常体质不是故障）；报告里没有原始输出行的判定一律退回重跑。

7.3 基线与 A/B 协议（跑分不骗人的前提）

1. 先跑默认档基线并归档，之后一切"提升"都是相对它的差分；
2. 一次一个变量；每档 n=3 取中位数；
3. 静窗：跑分时机器上不许有别的负载（包括 agent 自己的大上下文会话——它一边聊天一边让你跑分，TTFT 能给你污染三倍）；
4. 跑前重启服务清缓存——引擎缓存里有上一天的会话，协议会把命中档整批排除或虚高（血案见第二节）；
5. 每档结果落独立档案目录（带时间戳），负结果不删；
6. 噪声带内一律不算提升；绝对数字只在同一代引擎/软件版本内互比，跨代先重测基线。

7.4 开关筛选流水线（夜班模式）

白天人挑候选开关、写任务书（每个开关：怎么开、验证生效看日志哪一行、A/B 怎么跑、什么判留用/弃用），夜里机器自己跑完全部档位，早上人只看档案收判决。我这台机器的筛选结果大体是拒掉的比采信的还多——所以别信任何"必开清单"，包括文档和自己上个月的结论。换模型量化档 = 全部结论作废重测（专吃某种量化层的开关尤其如此，先看 tensors 占比再决定测谁）。

7.5 长跑巡检与红线（把"过日子"变成数据）

让 agent 定时（比如每 15 分钟）拉一组指标落 CSV：可用内存、swap 用量、缓存占用与驱逐计数、会话停放/恢复计数与耗时、GPU 温度/功率/各类 throttle 计数器、磁盘背景读。要点：

• 红线要少而硬：我只设三条——swap 疯涨、会话恢复变慢、可用内存见底。红线不触发，人就不干预；
• advisory 告警先当现象读，查明设计意图再动手——很多"告警"是机制在自护（把报警消掉等于把自护关掉，我交过最贵的学费在这，见第六章）；
• 磁盘背景读基线是最便宜的物理监测项：常年 2-3MB/s 的盘变成精确的 0，说明某个"分层"被你配置掐死了——这个发现比任何 dashboard 都直接。

7.6 报告纪律（防 AI 幻觉的硬闸门）

给 agent 的报告任务书必须写死：报告里每个数字标档案路径、每句"实测 X"必须能在档案里 grep 到、引用日志必须带原文行。上下文长了以后 AI 会"记住一个大概然后写得很自信"——这套闸门能把它拦住，我在它的报告里抓到过好几次自信的错误。

7.7 人机分工一句话总结

人管：掏钱、动手、拍板、认错兜底；agent 管：扫描、跑批、对账、写草案。 双方共同信条：别人机器上的数字到你机器上就是假设——对自己机器也一样，昨天的你对今天的你也是别人。

（本节欢迎拿走改好用完回来分享。）

八、未完事项与结语

8.1 未完事项（立字据，月底回来交作业）

• 带模型校验的 conforming 跑分档：已交（"跑前先重启清缓存"的坑写在第二节）
• 192K 级长上下文实战：已交。300K+ 不用问了——262144 是 max-context 的墙，过墙是另一件事
• 24-48h 浸泡长跑报告：12.8h 段已交（负载曲线图 + 复用总账），脚本还在跑
• 官方开关表还剩两个尾巴（PF_WMMA2 / GDN_CHUNK）没轮到

8.2 结语

有问题尽管问，负结果尤其欢迎对线——毕竟我这台机器上，"+10% 的功能"翻车翻得最响。跑分档案、浸泡 CSV、测量脚本都留着，要复现的楼里说一声。