我覺得是96GB，並且未來預期升至128GB，
因為我目前是64GB，IQ3_S + 256K系統內存只剩7~9GB浮動
當然這是case by case，不過有些耳聞IQ4是比較夠用的，未來能保留升級空間也好
況且如果你是想一起執行dsh或hermes等agent，那勢必還得留出20~30GB剩餘浮動內存好
H
he wanga
@he wanga
-
64GB vs 96GB跑Strata Flash-Next -
Strata Qwen3.8-Flash-Next双小显存卡4070 + 3080实测：IQ3_XXS在128K上下文 2337 tok/s / 解码 ~75 tok/s(0) 前言
最近本地AI的流行，让小弟我在这几个月也成为论坛潜水中的一员。看到大家使用各种大VRAM显卡跑得风生水起，很是羡慕
刚好最近Strata架构让小VRAM GPU也能重获新生, 我手边也有额外的游戏显卡能玩玩LLM
顺便浮出水面一下，让有类似硬件的坛友能参考这个配置下能跑出甚么速度
文章中的 Tuning 流程是我和 codex 讨论了很久后设计的，大部分操作也是由 codex gpt 6.1 sol 通过 SSH 连接 Linux 自动执行的
但这是我第一次调优LLM，我也不算懂行，所以如果想让 Agent 按照文中的 Tuning 流程设置，请先判断是否适合自己的机器本文目标放在IQ_S量化版本，128K上下文，除了在优化这个配置外，也额外延伸了几个探讨议题
(1) 3080副卡有用吗？对prefill或decode速度加成多少？
(2) 可以把功耗限制设到多低，并得到跟原本差不多的速度？
(3) 不同量化版本，上下文，VRAM和RAM的使用量是多少？每个人的情况可能不同，以我的情况来说，可以直接跳到第 (8) 节看看我的总结
另外特别感谢前人发过的30, 40系列跑Strata的文章，因为有你们我才有勇气来搞这个项目跟添置一些硬件零件
另外，我原先是使用繁体，考虑到论坛里的大陆坛友比较多，请AI帮忙把文章转成了简体，并调整为大陆常用的表达。如果还有不太自然的地方，还请见谅。(1) 环境介绍
硬件配置大多是由我现有游戏机零件组成，补了32gb的DDR4, 以及从我老婆那儿“抢”来了她的4070当主推理引擎：
硬件 型号／规格 CPU Intel Core i7-13700K 主板 MSI MAG Z690 TOMAHAWK WIFI DDR4 内存 DDR4 16GB*4=64GB 3200MHz 显卡1 ASUS TUF RTX 4070，12GB显存 显卡2 EVGA RTX 3080 XC3，10GB显存 电源 1200W 4070位于CPU直连的PCIe 5.0 x16插槽 (实际只有4.0)，3080使用PCIe 3.0 x4连接。 后续调优以这个硬件固定为前提。
这台主机的CPU、内存、显存与存储资源都专用于LLM后端。计划通过局域网内的其他设备使用 Web Chat 或 agent，让64GB内存和两张显卡的资源尽量留给模型
本文的调优决策与命令发送也在另一台电脑使用codex ssh完成。软件环境如下：
项目 版本／配置 操作系统 Ubuntu 24.04 LTS，原生Linux NVIDIA驱动 595.91.07 Strata推理引擎 0.1.41 调优过程都沿用固定的Strata版本，测试期间不更新框架，以免版本变动影响比较。
Strata近几版有针对Multi GPU提速，有跑多卡的坛友们记得赶快去更新一下(2) 目标模型和上下文窗口
实测前的主要目标如下：
目标模型 上下文窗口 Vision Qwen3.8-Flash-Next IQ3_S 128K ON 先以这个组合作为起点，完成单卡、双卡与参数调优，确认速度和64GB内存是否足以支撑使用需求。
后续测试方向依速度与内存余量调整：
- 若IQ3_S速度太慢，或内存余量不足，就往IQ3_XXS测试，确认换量化后能否改善速度与内存占用。
- 若速度与内存仍有余量，就往256K上下文窗口测试，确认更长文本输入是否能稳定完成，以及Prefill、Decode和功耗的变化。
结果先剧透了，IQ3_S能顺利开启256K上下文 + Vision，而且速度还不错
AI线：以下文章内容的测试流程与结果整理由AI产生。不太习惯AI文风的坛友，可以先跳到 (8) 结论。
(3) Benchmark方法
速度测试都是统一使用 Strata repository 收录的 community benchmark harness（
bench/results/2026-09-30-community-rtx-5090/benchmark.py），由另一台电脑通过 SSH 发送命令，在 Linux 主机上调用本机 Strata API。整个测试串行执行，一次一个请求。输入使用 harness 的合成 Python 程序文本，固定模型、量化与输入内容，设置
temperature=0、reasoning_effort=none、流式输出，并固定生成 256 tokens。每轮记录 prefill、decode、TTFT 与总耗时，同时保存设置、原始 request／response、引擎 log，以及 GPU 和主机资源记录。以下表格的Prefill、Decode单位均为tok/s，TTFT单位为秒。
研究流程分成几个阶段：
- 建立单卡、双卡基准：各测 4096、32768、128000 个输入 tokens，每个长度跑三次取中位数。先留下未校准起点，再比较加卡后的变化。
- 搜索设置与功耗区间：后续每个候选跑一次相同的 128000-token 测试，逐阶段比较分层、trim、prefill、校准与 power limit。官方 calibration 有自己的内部测试流程，完成后再用这份长文本输入验证。
- 验证最终配置：选定 K38 calibrated、双卡各150W后，再测32768、65536、128000个输入 tokens，各一次，确认不同长度下的速度与能耗。
- 测试其他配置：沿用同一套测法和特殊config，另列模型与上下文矩阵, 测试其他配置下的速度和功耗
每个测试配置先确认模型 ready，再预热；预热不列入成绩。正式请求核对实际输入与输出 token 数，并确认reused=0。功耗扫描与最终验证每个条件都使用新启动的 backend，避免前一轮的 prompt cache 影响比较。
(4) 单卡 v.s. 双卡，加入3080是否必要
先留下未校准的单 4070 起点，再加入 3080，重新让 setup 配置双卡。初始比较维持两卡各自 80% 的功耗上限：4070 为 160W，双卡时另加 3080 的 272W。
输入长度 单4070 Prefill 双卡 Prefill 单4070 Decode 双卡 Decode 4096 900 848 27.75 35.17 32768 1187 1511 28.10 35.98 128000 1205 1691 27.36 35.63 在 128K，加入 3080 后，读取约快四成，生成约快三成；TTFT从 106.3 秒降到 75.8 秒。但 4K 的读取反而略慢。
实测结论是：单 4070 可以跑；如果已经有 3080，又常读取长文档或希望答案生成快一点，值得一起用。
(5) Fine tune出最佳性能
这里的 Fine tune 是推理设置调优，没有重新训练模型权重。调优流程是先找分工，再调显存使用方式，最后校准；每一步都拿同一份长文本输入验证。
每次进入下一阶段，都先保存上一阶段的设置，让新候选有明确对照，也能退回已验证的起点。没有改善的实验仍留下记录，避免下次又重走一次。这次最有用的经验，是先把「这轮要回答什么」缩小：分层时比较分工，校准时验证整组参数，降功耗时固定模型设置。这样结果才能累积成一套日常可用的配置。
先分层，再把显存空间用好
K 是两卡的分层位置。模型有48层，K38代表4070跑前38层、3080跑后10层。不是把模型裁成38层，也不是K越大越快；分法会影响计算负担、缓存与读取缓冲空间。
接着开启
STRATA_STAGE_TRIM=1：每张卡只载入自己负责层的 dense weights，省下显存给 expert cache，完整模型仍由两张卡执行。trim on 下共测了九个K，当时K38读取较快、K36生成较快，先保留两个候选。固定K36后，再测读取分块大小。
prefill auto实际选到8192，约1985 tok/s；改成1024、2048、4096，约剩371、697、1234 tok/s，生成却仍在45左右。因此保留auto。pipeline虽确实启用，这轮没有收益；split-own auto没有真正启用，也不把它当成有效加速结果。校准之后，再回到长文本输入验证
对K36、K38各自跑官方 calibration，找CPU／GPU expert分流、MTP草稿门槛与缓存更新设置，再各跑一次128K。
候选 校准前 Prefill 校准后 Prefill 校准前 Decode 校准后 Decode K36＋trim on 1985 1985 45.11 57.63 K38＋trim on 2280 2275 42.24 58.86 K38的生成约快39%，读取几乎不变。校准后K38读取比K36快约15%，生成只领先约2%；两组都只验证一次，最后选K38作为本轮基准，不宣称它一定稳定胜出。
这一步也改变了原先的候选排序。未校准时，K36比较适合重视生成速度的方向；校准后，K38在这次长文本输入验证两项都领先。因此，不把某一步的第一名当成永久答案：先留下候选，等后续设置完成，再用同样的工作负载回查。校准同时改了多个参数，这轮也没有把它们逐项拆开测，不能指定是哪一个参数带来全部提升。
本轮采用设置 值与用途 GPU顺序／ layer_split4070 → 3080／ 38STRATA_STAGE_TRIM／--expert-cache1／auto，保留空间给专家缓存--prefillauto，本轮实际8192CPU workers 预设15，校准后保留 --pcie-frac0.2，未缓存experts送GPU的分流比例--spec／--spec-min-p4／0.7，MTP草稿深度与门槛--adapt-every／--adapt-swaps／--adapt-decay1／160／0.97，自适应缓存更新设置--kv／--max-contextint8／131072Vision 开启，放4070 从单卡约27到调好双卡约59 tok/s，是加卡、分层、trim与校准的合并成果。单4070起点没有校准，不能把整个倍增都算在3080身上。
(6) 一半的瓦数，99%的性能
先说清楚：这里「一半的瓦数」指功耗上限，不是实际耗电或电费减半；「性能」指这份工作负载的推理速度。
速度调好后，先恢复4070／3080上限为200／340W，再只降低3080，找速度开始掉落的位置。
3080上限（4070固定200W） Prefill Decode 两GPU每次请求能耗 340W 2335 58.94 5.399Wh 170W 2322 58.94 5.063Wh 136W 2305 58.60 4.901Wh 100W 1744 54.51 5.187Wh 3080上限340→170W，读取保留99.44%、生成约99.99%。 这就是章名最直接的例子。不过3080实测平均功耗是159.7→137.7W，两GPU请求能耗只少约6.2%；原本就没有一直吃到340W。
降到100W时，读取明显拖慢，整笔请求跑更久，能耗反而比136W高。接着固定3080为150W，测4070的200→100W：100W仍保留约99.6%生成速度，但读取只剩约66.8%，请求能耗反而增加约6.2%。只看生成tok/s，会漏掉读取长文档的成本。
4070粗测的均衡候选落在160W附近，最后选两卡各150W，再验证不同输入长度：
输入tokens Prefill Decode TTFT 两GPU每次请求能耗 32768 1797 58.95 18.3秒 1.458Wh 65536 2138 58.61 30.7秒 2.468Wh 128000 2259 58.76 56.7秒 4.514Wh 最终上限合计300W，是原本540W的约56%，接近一半。相对同一轮K38校准、双卡额定上限基准，128K 生成保留约99.7%、读取约96.7%，GPU请求能耗少约16.4%。这不是最低能耗记录，是本轮选定并验证的折中。
换成等待时间看，这份128K的TTFT约从54.9秒变成56.7秒，生成速度几乎维持。这份配置用少量额外读取时间，交换较低的GPU能耗。不过若工作每天都在重新读大文件，或回答特别长，取舍可能不同；应先比较整笔请求的耗时与能耗，再决定是否继续降瓦数。
功耗每200ms取样，但来源是约1秒平均的GPU板卡读值，再积分估算请求能耗；不含CPU、电源损耗、载入与待机。各条件只测一次，小差距可能含量测与热状态影响，读成「速度接近、能耗有下降」比较合适。
(7) 不同量化模型、上下文的比较
固定 K38、trim on、prefill auto、KV int8、Vision与MTP开启，双卡各150W，版本也保持不变。这次不重新搜索K或功耗，而是比较原版IQ3_S、IQ3_XXS在64K／128K／256K的表现，另外加入一组Abliterated IQ3_S／128K，共七组配置。
以下一次列出七组正式配置的21笔请求结果。
配置 Prompt Prefill tok/s Decode tok/s TTFT s 总GPU平均 W 总GPU峰值 Org-IQ3_S-128k 4096 716.77 56.33 5.74 201.17 236.30 Org-IQ3_S-128k 32768 1801.73 62.00 18.23 240.33 289.25 Org-IQ3_S-128k 128000 2247.54 60.49 57.04 267.66 291.93 Org-IQ3_S-256k 4096 684.19 55.13 6.01 194.67 230.58 Org-IQ3_S-256k 32768 1597.74 59.17 20.55 240.48 282.44 Org-IQ3_S-256k 256000 1939.30 56.43 132.13 271.46 289.93 Org-IQ3_S-64k 4096 733.80 58.48 5.61 201.99 243.13 Org-IQ3_S-64k 32768 1843.84 67.85 17.81 241.82 290.54 Org-IQ3_S-64k 64000 2117.42 70.34 30.28 257.54 290.72 Org-IQ3_XXS-128k 4096 836.29 65.25 4.92 205.41 246.62 Org-IQ3_XXS-128k 32768 1994.47 78.96 16.47 248.76 294.68 Org-IQ3_XXS-128k 128000 2337.60 75.21 54.83 269.86 297.26 Org-IQ3_XXS-256k 4096 796.61 62.88 5.17 203.53 236.79 Org-IQ3_XXS-256k 32768 1827.40 68.88 17.97 246.08 292.90 Org-IQ3_XXS-256k 256000 2222.27 57.58 115.35 276.36 296.49 Org-IQ3_XXS-64k 4096 854.72 74.01 4.81 207.90 262.84 Org-IQ3_XXS-64k 32768 2018.33 80.11 16.27 249.84 294.12 Org-IQ3_XXS-64k 64000 2259.45 79.14 28.39 262.34 296.18 Abliterated-IQ3_S-128k 4096 715.66 58.98 5.75 199.52 238.20 Abliterated-IQ3_S-128k 32768 1796.52 59.18 18.29 240.19 293.60 Abliterated-IQ3_S-128k 128000 2205.69 61.72 58.11 267.63 293.37 (Abliterated是我个人额外加测，因为之后可能有无审查模型的需求)
IQ3_S沿用Part 1最终设置；IQ3_XXS切换对应模型资产后，先测继承设置，再跑官方calibration与长文本输入验证，最后让三种上下文共用这份校准基准，不逐窗口重新调优。
IQ3_XXS正式比较采用验证后的设置：
pcie-frac 0.2、spec 4、spec-min-p 0.7、adaptive1／160／0.97；CPU workers由引擎自动配置。跨量化比较的是各自的已验证配置，不把结果归因于单一参数。每组都测共同的4096、32768个输入tokens，再依窗口测64000、128000或256000。总context上限分别是
65536、131072、262144，保留模板与256-token输出的空间。每个长度一次，预热排除，正式请求均确认reused=0；七组共21笔正式请求全部完成。长文本输入：128K收益明显，256K主要改善读取
下面每个窗口使用不同的长文本输入，应比较相同窗口与输入长度的两种量化；不能把64K与256K的等待时间当成相同工作量的速度对照。
模型 Context／实际输入 Prefill Decode TTFT 总GPU平均 W 总GPU峰值 W IQ3_S 64K／64000 2117 70.34 30.3秒 257.5 290.7 IQ3_XXS 64K／64000 2259 79.14 28.4秒 262.3 296.2 IQ3_S 128K／128000 2248 60.49 57.0秒 267.7 291.9 IQ3_XXS 128K／128000 2338 75.21 54.8秒 269.9 297.3 IQ3_S 256K／256000 1939 56.43 132.1秒 271.5 289.9 IQ3_XXS 256K／256000 2222 57.58 115.3秒 276.4 296.5 Abliterated IQ3_S 128K／128000 2206 61.72 58.1秒 267.6 293.4 128K长文本输入下，IQ3_XXS生成约快24%，读取约快4%；到了256K，生成差距只剩约2%，较有感的是TTFT少约17秒。换量化的收益会随负载改变，不能把某一组的提升比例套用到所有情境。
资源记录也显示，128K配置的最低可用系统内存，IQ3_S约7.5GiB、IQ3_XXS约14.5GiB。对这台64GB主机，XXS留下较多内存余量。不过这轮没有做回答品质评测，速度与可用内存的优势，不等于已证明两种量化的回答品质相同。
Abliterated版本：速度接近原版
Abliterated组沿用相同IQ3_S权重与pack，只加入projection vector：strength
1.0、layer range4–44、modeproject、directionper-layer，每笔正式请求都核对projection已启用。128K长文本输入下，原版／Abliterated的读取为2248／2206 tok/s，生成60.49／61.72 tok/s，TTFT57.0／58.1秒。共同32K输入的生成则为62.00／59.18 tok/s，没有一致的速度胜出方向；这轮可说速度接近，未测拒答行为或回答品质。
双卡功耗也没有因换成XXS而大幅下降：128K请求平均合计约268W／270W，256K约271W／276W（IQ3_S／XXS）。XXS的收益主要表现在完成速度；这些是GPU板卡功耗，并非整机用电。
本轮选择方向是：速度优先可考虑IQ3_XXS；窗口依实际需求选，32K输入测试以64K配置较快，需要更长内容再开128K或256K。 IQ3_S与Abliterated则按模型需求选择。所有配置各长度只有一次结果，小幅差异仍需重测确认；这次已建立可用的速度与资源对照，品质比较留待另行评测。
AI结束线：以下内容开始是人类写的了
(8) 我的小总结
(1) 这套4070＋3080、64GB内存的配置，可以达成IQ3_S/128K的目标，速度Prefill: 2248 tok/s, Decode: 60.49 tok/s。
(2) IQ3_XXS 128K上下文的速度下，Prompt为128k，速度也还可以 Prefill: 2338 tok/s, Decode: 75.21 tok/s
(3) 虽说单4070能跑，但有副卡值得试试。初始128K Decode约从27提升到36 tok/s，但我没有测过单卡直接调优。
(4) 功耗限制可以调得很低也保留同样速度 (4070 200->150W, 3080 340W->150W)，噪音低了不少
(5) 跟codex讨论，根据Log目前的bottleneck在哪里。主要还是在副卡的显存其实有点可惜，如果当初是买12GB版本的3080可能会提升不少。还有PCIE 3.0 x4的问题吧，
不过如果3080能加到20GB，反而PCIE 3.0 x4的影响就会变小了，因为主要运算就都会搬去显存。
可惜台湾这边比较少店家在帮忙改卡，大多有的也都是直接卖了，不然我也是很想改一下希望能帮助到有类似配置的朋友，两张小显存卡能跑到256k上下文，128k能有75 decode速度，已经谢天谢地了
我也算是刚入门本地LLM的一员了，有什么使用技巧，还请大家多多指教。接下来还有好多工作要做呢，还得先接入Codex。（随手用一些Dummy文本试了一下web chat）
-
RTX 4070 12GB + RTX 3060 12GB：Windows 跑 Strata / Qwen3.8 Flash-Next，Linux 跑 Qwen3.8 27B 与 Flash-Next，SGLang、vLLM、Strata 配置及实测 -
RTX 4070 12GB + RTX 3060 12GB：Windows 跑 Strata / Qwen3.8 Flash-Next，Linux 跑 Qwen3.8 27B 与 Flash-Next，SGLang、vLLM、Strata 配置及实测