企业官网建设流程全解析

• 人工智能
• 大模型
• 本地部署
• 推理引擎
• 模型推理服务
• 模型量化

本文围绕 docs/SECOND_GPU.md 展开，讲解 Strata 推理引擎的两类第二 GPU 使用方式：把最高三张副卡（CUDA1/2/3）填充为独立的 MoE 专家缓存，以及通过--peer-device在第二张卡上建立可自适应的 peer 专家层级。读完本文，你可以完整复现 Linux / Windows 下的多卡配置命令、理解专家分配策略（stripe 与 layer 两种放置模式）、掌握 peer 层级的全部命令行参数与互斥约束，并从源码层面理解跨卡数据流与位级一致性保证。

核心架构：谁拥有什么，副卡如何参与计算

Strata 的 CUDA0（主卡）始终承担固定职责：稠密层权重、KV/state 缓存、MTP（多 token 预测）层以及它原有的专家缓存。多卡扩展发生在 MoE 专家维度上：

• CUDA1、CUDA2、CUDA3 依次填充最多三个相互独立的专家缓存（即--gpu1-experts/--gpu2-experts/--gpu3-experts各自对应一张卡的槽位数）。
• 每个专家（expert）有且只有一个"owner"：CUDA0、某一张副卡、或 CPU 池（host 内存）。
• 副卡负责计算自己持有的专家行，同时 CPU 池并行计算剩余专家；结果通过私有 pinned host 缓冲区返回，之后 CUDA0 才继续该层的后续计算。
• GPU 端的 launch 可以相互重叠，但每一层会等待三张副卡全部完成，即各副卡之间是并发但层内同步的。

专家如何分配：profile 排名 + round robin + 全量补全

shipped 版本的 profile 会给出 8,000 个(layer, expert)对的排名。分配规则分两步：

1. 排名内分配：CUDA0 按--expert-cache auto拿走它常规的份额；若只启用 CUDA1，它拿走排名列表中紧随其后的剩余配对；若启用了 CUDA2/CUDA3，剩余已排名配对在副卡之间按 round robin 轮流分配。
2. 排名外补全：排名列表之后，按 expert-then-layer 的顺序把所有未排名配对也纳入同样的分配方式，直到填满新增的 VRAM。

这样做的效果与代价：所有副卡都能看到高频专家；但未被 profile 覆盖的专家可能几乎永远不会被路由到。为便于观测，启动日志会报告每张卡的槽位数量与 GiB 占用，每个请求会报告各副卡实际计算的专家条目数。

传输路径做了优化：远端输出在经 PCIe/USB4 回传前先做打包，请求日志会将本次传输的 MiB 数与"整行传输"做对比；输入与路由元数据使用 pinned host staging。这些手段降低了传输流量与 launch 开销，但不会释放系统内存中的专家 arena，也不显著改变 VRAM 占用。

--gpu-placement layer：整层放置的试验性模式

默认的stripe模式下，同一层可能由多张副卡同时服务，这会增加 USB4 设备切换与同步次数。可选的--gpu-placement layer把每一层整体交给恰好一张副卡（层号对启用卡数取模），该卡优先填入这些层中被路由最频繁的专家，再填未排名专家。约束与注意点：

• 三张副卡仍保留其请求的专家槽位数，CUDA0 主缓存与 CPU 回退路径照常工作；
• 日志会统计每张卡上"活跃的层 launch 数"，可把这种权衡与 tokens/second 一起度量；
• 该模式是试验性的——如果某一层需要超过单卡算力，可能反而更慢。

硬性前提

• 需要与--gpu1/2/3-experts对应的可见 CUDA 设备和 CUDA 启用版构建；
• 每张副卡至少保留 512 MiB 空闲；
• 各层级（tier）必须按顺序启用（先有 CUDA1 才能加 CUDA2/3）。

在 WDDM 环境（Windows、WSL2）下，host 专家 arena 的 CUDA 注册上限被限制在8 GiB，为 CUDA0 的上下文与 MTP 留出空间（可用环境变量STRATA_ARENA_PIN_GIB覆盖；Linux 下整个 arena 全部注册）。未注册的部分仍可被 CPU 池使用，但PCIe 专家路径只对已注册的层可用。没有副卡时，沿用原有的无上限注册行为。

配置操作：Linux 与 Windows 命令

在已有 Linux 安装上，先把补丁应用到源码树，然后运行：

./setup.sh --setup --gpu1-experts 5000 --gpu2-experts 5000 --gpu3-experts 5000

Windows 上，在安装目录的 PowerShell 中运行：

.\START-HERE.bat --setup --gpu1-experts 5000 --gpu2-experts 5000 --gpu3-experts 5000

切换 layer 放置模式：在 setup 命令后追加--gpu-placement layer即可测试层放置；想切回，用--gpu-placement stripe重跑同一命令。引擎重新构建后，还可以免重编译切换模式：编辑strata-iq3_xxs.json中的--expert-cache-remote-placement值（layer↔stripe）并重启服务。该参数缺省时默认为stripe——这一点在源码中可以直接确认：src/program/generate.cpp 中expert_cache_remote_placement的默认值即为"stripe"，且取值校验只允许stripe或layer（见 src/program/generate.cpp）。

调整槽位而不重编译：setup 过程中选择与当前安装相同的模型、规格、上下文与图像设置；setup 会重新编译引擎、更新其服务配置并启动，之后的每次启动都保留这些设置。若只想调槽位数，直接编辑保存在strata-iq3_xxs.json中--expert-cache-device1、--expert-cache-device2、--expert-cache-device3后面的数值，然后用.\run-iq3_xxs.bat重启即可。

正确的方法论：如何评测多卡收益

• 在 1 / 2 / 4 张 GPU 下跑相同请求，最好多次重复；
• 单看 VRAM 占用无法体现有效 offload——应比较每请求 CUDA1–3 计算计数与 tokens per second；
• 更多 GPU 上下文与同步可能拉低速度；
• Prompt prefill 仍完全走 CUDA0，副卡只服务 decode（含 MTP 验证）；
• 不需要 peer-to-peer 访问。

长上下文的陷阱：更长上下文会在 CUDA0 上预留更多 KV/state 内存，从而压缩它的自动专家缓存。在 64 GB 的 PC 上，setup.py 即使你选了 262K 也会把 IQ3_XXS 限制到 128K；副卡缓存仍然依赖 host 专家 arena。若要在 64 GB 机器上尝试 262K，改选 Q2_0 或 IQ2_XS，并确认加载后 CUDA0 仍有足够空闲 VRAM。长 prompt 与短 decode 请求应分开做基准测试。

正确性警告（沿用既有结论）：CUDA0 专家缓存 GPU 命中路径的输出与 cache-off 运行存在偏差——在生成 token 经过验证之前，性能数据只能视为试验性结果。

Peer 层级：--peer-device第二卡自适应专家缓存

与上面"三张副卡 + CPU 池"的实验性路线不同，peer 层级是在第二张卡上放置第二个自适应专家缓存，并且支持参与 prompt 路径：

• --peer-device N在 CUDA 设备 N 上建立第二层；它拿走的正是"排名在前、但 CUDA0 缓存未持有"的配对，装多少取决于剩余显存；
• peer 计算自己专家的行，既覆盖 decode 窗口，也覆盖 prompt 分块；激活值与结果经由 NVLink 或其他 P2P 路径交换；
• 层级在服务运行期间像主缓存一样自适应；
• 它是 CUDA1–3 缓存的替代方案，不是并列的第三层。

参数全解（源码已核对默认值）

上述默认值与 src/program/generate.cpp 的帮助文本一致。若 peer 缓冲放不下，src/prefill/prefill.cpp 会给出明确的排错提示："raise--peer-reserve-mibor lower--peer-prefill-rows"。

互斥约束与拒绝信息

--peer-device要求同时提供--expert-profile且专家缓存已启用、设备可见，否则拒绝启动。它与另外两个互斥：

• --layer-split（另一种第二 GPU 模式，二选一）；
• --expert-cache-device1..3（peer 层级本身就把专家缓存在该卡上了）。

拒绝时输出的信息为：

strata generate: --peer-device cannot be combined with --layer-split (use one or the other) strata generate: --peer-device cannot be combined with --expert-cache-device1..3 (the peer tier already caches experts there)

位级一致性保证

• 不带--peer-device时，二进制行为不变，输出与 release 版字节一致；
• 带--peer-device且同一专家集分布在两卡上时，在 exactness gate 下生成的 token 与单卡运行字节一致。

这一保证有明确的实现依据：从 include/strata/core/peer_experts.hpp 的注释可见，peer 与主卡 GPU 命中路径使用完全相同的 kernel（q8_1 激活 + native_expert_grouped），从相同的激活值出发，因此同一专家在任一卡上产生位级一致的行。

实现视角：peer 在 verify 图中的角色

include/strata/core/peer_experts.hpp 的头部注释给出了最清晰的架构说明：对 verify 图而言一切不变——每层由 pool 线程决定主卡计算哪些被路由专家（它的 VRAM 层级与 PCIe 份额），其余专家都是"CPU 行"，图从 mapped host 内存读取；peer 接管它持有的那些行：pool 线程在发布主卡 plan 后立即把 launch 发到 peer，CPU 同时计算剩余部分，peer 的行在同一 mapped 行上覆盖写回，然后 pool 才返回。自适应部分（adapt）把两卡都没持有、且被路由至少两次的最高频专家换入 peer 的最少使用槽位（按层保持槽位与其层 blob 大小匹配），拷贝走 peer 的 refill stream，换入的专家在apply_pending时变为驻留。

两个值得注意的工程细节：

• 直接回写：peer 的launch支持把行直接 scatter 写进 portable pinned host 行（out参数），省去"D2H 拷贝 + host memcpy"两步；STRATA_PEER_DIRECT=0可回退旧路径。
• cudaHostAllocPortable：mapped host 缓冲只有在启用 peer 时才追加该标志，因为此时会有第二个 CUDA 上下文写这些缓冲（set_peer_portable，见 include/strata/core/peer_experts.hpp）。

当前局限（文档明示的 follow-up）

• 启用 peer 时 prompt 路径保持 MMQ 路径；fused int8 prompt 路径尚未与 peer 的行组合；
• 层级大小目前是手动的（--peer-reserve-mib、--peer-slots）；小卡上的自动 sizing 依赖 issue #216 的 buffer lending，属于后续工作。

小结：两种路线怎么选

• 你有 2–4 张卡、想榨干 VRAM 且能接受试验性正确性风险：走--gpu1/2/3-experts+ （可选）--gpu-placement layer的路线，按上文命令在 setup 阶段配置，评测时盯住每请求 CUDA1–3 计数与 tokens/s。
• 你有 2 张支持 P2P 的卡、希望 peer 同时加速 decode 与 prompt 且保持位级一致：走--peer-device路线，用--peer-reserve-mib/--peer-slots手工控制容量，并注意与--layer-split、--expert-cache-device1..3的互斥关系。

两类模式都属于文档明确标注的实验/试验性能力，落地前请以本仓库 docs/SECOND_GPU.md 的警告为准：在生成 token 验证完成之前，性能结果都应视为实验数据。

• 人工智能
• 大模型
• 本地部署
• 推理引擎
• 模型推理服务
• 模型量化