拓冰网站优化 
两台 128 GB 的 MacBook，一根 Thunderbolt 5 直连，同一个 GGUF、同一次运行。六万多 token 的长 prompt，prefill 吞吐从单机 353.62 t/s 涨到 654.79 t/s，1.85 倍；紧接着的 generation，从单机 30.59 t/s 掉到 24.67 t/s，倒退 19.4%。同一个进程里的前后两个阶段，一个接近翻倍，一个亏掉两成。奇怪的不是有快有慢，而是它们走的是同一条链路、同一批权重。第一反应是查网络：带宽不够？TCP 参数没调？激活值该压一压？这三条路我都走过，走到底才发现方向反了——decode 慢下来的那部分，跟网络关系很小，per-token 遥测把这个账算得明明白白。真正决定一套跨节点推理系统能不能加速的，是一个跟机器数量、跟链路带宽都无关的量——它叫 M：同一时刻能填进流水线的、互不依赖的 micro-batch 数量。prefill 的 prompt 按 4096 切块，M 能到 16，流水线填得满，跨机并行才成立；decode 的每个 token 都得等上一个走完全部层，M 恒等于 1，流水线永远填不满，加机器只加空转。这条路我们一路走到 DwarfStar 引擎的ds4_distributed.c：从--layers怎么在加载期就把权重张量切开，到 coordinator 用一次回溯搜索拼出跨机路由，到 prefill 流水线那两个后台线程各自在等什么，再到 decode 路径上那个无论如何绕不开的同步往返。中间会崩三次：一次路由拼不全，一次 chunk 调小反而更慢，还有一次是一个被重启的 work 同一套 C/C++ 引擎，两个相反的数字：分布式推理的真相写在依赖结构里
两台 128 GB 的 MacBook，一根 Thunderbolt 5 直连，同一个 GGUF、同一次运行。六万多 token 的长 prompt，prefill 吞吐从单机 353.62 t/s 涨到 654.79 t/s，1.85 倍；紧接着的 generation，从单机 30.59 t/s 掉到 24.67 t/s，倒退 19.4%。同一个进程里的前后两个阶段，一个接近翻倍，一个亏掉两成。奇怪的不是有快有慢，而是它们走的是同一条链路、同一批权重。第一反应是查网络：带宽不够？TCP 参数没调？激活值该压一压？这三条路我都走过，走到底才发现方向反了——decode 慢下来的那部分，跟网络关系很小，per-token 遥测把这个账算得明明白白。真正决定一套跨节点推理系统能不能加速的，是一个跟机器数量、跟链路带宽都无关的量——它叫 M：同一时刻能填进流水线的、互不依赖的 micro-batch 数量。prefill 的 prompt 按 4096 切块，M 能到 16，流水线填得满，跨机并行才成立；decode 的每个 token 都得等上一个走完全部层，M 恒等于 1，流水线永远填不满，加机器只加空转。这条路我们一路走到 DwarfStar 引擎的ds4_distributed.c：从--layers怎么在加载期就把权重张量切开，到 coordinator 用一次回溯搜索拼出跨机路由，到 prefill 流水线那两个后台线程各自在等什么，再到 decode 路径上那个无论如何绕不开的同步往返。中间会崩三次：一次路由拼不全，一次 chunk 调小反而更慢，还有一次是一个被重启的 work