Nicksxs's Blog

前几天看到一个挺夸张的结果：

FreeToken 在一台只有 8GB 显存的 RTX 4060 Laptop 上运行 Qwen3.6-35B-A3B，解码速度达到了 39.3 tok/s。

第一反应肯定是：35B 模型只算 4bit 权重，理论上也要 17.5GB 左右，8GB 显存怎么可能放得下？

后来翻了下 FreeToken 的论文、源码，又对比了下 llama.cpp，发现这个问题里最容易混淆的是两个完全不同的概念：

• 模型能不能全部放进显存
• 生成一个 token 时，到底需要计算多少参数

FreeToken 并没有把 35B 参数凭空塞进 8GB 显存里。它做的是把完整的 MoE 专家权重留在内存，把 GPU 显存变成一个会不断换入、换出的专家缓存，再让 CPU 和 GPU 一起处理缓存没有命中的专家。

先把结论用一句话说出来：

MoE 让“大模型每次只用一小部分参数”成为可能，FreeToken 解决的则是“这一小部分参数怎样及时出现在最合适的计算设备上”。

这篇就从这里展开。

先纠正一个容易混淆的模型

之前讨论的是 Qwen3.8-27B，但是 FreeToken 论文里 8GB 显存运行 35B 的案例其实是：

1

Qwen3.6-35B-A3B

这两个模型虽然数字接近，结构却完全不同。

Qwen3.8-27B 的官方模型卡明确写的是 Dense 模型。它有 64 层，每层的 FFN 都需要参与计算，没有“256 个专家只挑 8 个”这回事。

Qwen3.6-35B-A3B 则有 40 个 MoE 层，每层包含 256 个路由专家。一个 token 只会选择其中 8 个，再加上 1 个始终参与计算的共享专家。

名字里的：

1
2
3

35B-A3B
 │   └── 每个 token 大约激活 3B 参数
 └────── 模型一共仍然有 35B 参数

A3B 只是在说一次前向计算经过了多少参数，并不是模型文件只有 3B，也不是内存只需要保存 3B。

Dense 像是一整栋楼只有一条通道，每次都要从头走到尾。MoE 则像每层都有很多条支路，路由器会根据当前 token 选择其中几条。

这带来了两个结果：

• 计算量可以接近一个 3B 模型
• 完整的 35B 权重仍然必须放在某个地方

MoE 解决的是计算稀疏，并没有自动解决存储问题。FreeToken 真正处理的就是后半个问题。

35B 模型的内存账应该怎么算

先做一个很粗略的计算。假设不考虑量化元数据、对齐和少量高精度权重：

所以即使用 4bit，完整模型也明显超过 8GB。实际运行时还要额外留出：

• KV Cache
• 中间激活
• CUDA Graph 和算子工作区
• 视觉编码器或者其他非专家权重
• 桌面环境占用的显存

因此“8GB 运行 35B”绝对不能理解为“35B 的所有权重都常驻 8GB 显存”。

论文中的 4060 Laptop 机器实际有：

1
2
3
4

GPU: RTX 4060 Laptop，8GB VRAM
内存: 32GiB LPDDR5
PCIe: 4.0 x8
模型: Qwen3.6-35B-A3B NVFP4

NVFP4 把专家权重压缩到了接近 4bit，完整专家池主要放在 32GiB 系统内存中。显存里放的是：

1. 注意力、路由器、归一化等非专家权重
2. KV Cache 和运行时工作区
3. 一部分最近使用的专家

所以这其实是一个三级存储问题：

1
2
3
4
5

磁盘：保存模型文件
  ↓ 启动时读取
内存：保存完整专家池，是权重的 source of truth
  ↓ 按需搬运
显存：保存非专家权重、KV Cache 和热点专家

显存不再是模型的完整仓库，而是最快的一层缓存。

这跟操作系统的虚拟内存、CPU Cache 有一点像：完整数据在容量更大的慢速介质里，当前最可能使用的数据留在小而快的介质里。

不过模型推理有一个特别麻烦的地方：下一步会用到哪个专家，是运行到路由器之后才知道的。所以光有“缓存”两个字还不够，还需要解决命中、换入、并发和调度的问题。

FreeToken 的基本结构

FreeToken 把一个 MoE 模型拆成两部分：

非专家权重常驻 GPU

注意力层、Gated DeltaNet、路由器、共享专家等不会像路由专家那样从几百个里面选几个。它们每次都会使用，所以尽量常驻 GPU。

完整路由专家池常驻内存

所有层的全部专家都保留在 Host RAM 中。这一份是完整权重，也是最终兜底：

• GPU 缓存命中，直接在 GPU 上算
• GPU 缓存未命中，可以把专家搬进显存
• 如果不值得搬，也可以直接由 CPU 计算

因此 GPU 缓存大小只影响速度，不影响模型能不能算出正确结果。即使缓存是冷的，Host RAM 中仍然有完整专家。

剩余显存组成全局专家缓存

FreeToken 没有给每一层固定切一块显存，而是把专家缓存做成跨层共享的 slot pool。

一个 slot 保存的是某一层某一个专家需要的全部权重：

1

(layer_id, expert_id) -> gpu_slot

以 Qwen3.6-35B-A3B 为例：

1
2

40 层 × 每层 256 个专家
= 10240 个不同的 (layer, expert)

显存不需要有 10240 个 slot。假设当前只能放 600 个，就由所有层共同竞争这 600 个位置。最近使用过的专家留下，长时间没用的专家被淘汰。

这比“每层固定留 15 个专家”灵活，因为不同层、不同会话的热点分布并不平均。

生成阶段：专家缓存到底怎么工作

大模型推理通常分成两个阶段：

1
2

Prefill：一次处理完整输入，得到第一个输出 token
Decode：之后每轮只新增一个 token

这两个阶段虽然都经过 MoE 层，访问专家的模式却完全相反。先看 Decode。

假设某一层有 256 个专家，当前 token 被路由到了 8 个专家：

1

[17, 42, 58, 91, 103, 144, 201, 233]

FreeToken 会先查询每个专家是否在 GPU slot 中。

源码中的核心映射可以简化成：

1
2
3
4
5
6
7
8

# 正向表：某层某专家当前在哪个 GPU slot
slot_for_id[layer_id][expert_id] = slot_id

# 反向表：某个 slot 当前装的是谁
id_of_slot[slot_id] = layer_id * num_experts + expert_id

# LRU 时间戳
usage[slot_id] = current_step

一次查询之后会得到两组：

1
2

命中 H：已经在 GPU 中，可以立即计算
未命中 M：仍然只在内存中

命中的部分很好处理。真正有意思的是未命中。

传统想法通常有两个极端：

1
2

方案 A：未命中专家全部通过 PCIe 搬到 GPU
方案 B：未命中专家全部留在内存，由 CPU 计算

FreeToken 选择了第三种：

1
2

一部分搬到 GPU
另一部分同时交给 CPU

具体执行顺序大致是：

1
2
3
4
5
6
7
8
9

1. 路由器给出逻辑 expert id
2. 在全局 LRU 缓存中查找 slot
3. 命中的专家直接改写为物理 slot id
4. 为需要搬运的 miss 选择 LRU victim
5. 先提交 CPU 专家计算
6. 同时通过 PCIe 把另一部分 miss 搬进 GPU slot
7. GPU 计算“原有 hit + 新填入的专家”
8. 等待 CPU 部分完成
9. 把 CPU 和 GPU 的部分结果相加

对应到源码，python/freetoken/layers/moe.py 中的 _decode_hybrid() 做的正是这件事。它先提交 CPU task，再调用 copy_missing() 和 GPU expert GEMM，最后：

1

return gpu_routed + cpu_routed

为什么可以直接相加？

一个标准 MoE 层的结果本来就是多个专家输出的加权和：

1

y = g1 × E1(x) + g2 × E2(x) + ... + gk × Ek(x)

把专家集合拆成 GPU 集合和 CPU 集合，只是改变了计算地点：

1
2
3
4

y_gpu = GPU 上专家的加权和
y_cpu = CPU 上专家的加权和

y = y_gpu + y_cpu

FreeToken 会保证一条路由只由一边计算一次。源码中，交给 CPU 的专家在 GPU 路径里权重会被置零，交给 GPU 的专家在 CPU 路径里会被标记成 -1 并跳过。

所以这里不是删掉几个专家，也不是近似计算。除了模型本身使用的量化精度，CPU/GPU 分流不会额外改变 MoE 的数学定义。

q*：为什么不是一半给 CPU、一半给 GPU

现在还剩一个问题：假设有 4 个专家没有命中，到底应该搬几个？

如果全部搬运，CPU 可能在旁边闲着。如果全部交给 CPU，PCIe 和 GPU 又会闲着。最合适的比例跟机器有关。

FreeToken 用两个实际测出来的带宽做决定：

1
2
3
4

B_P：内存通过 PCIe 向 GPU 搬专家的有效带宽
B_H：CPU 直接读取并计算专家时的有效内存带宽
m：这一层没有命中的专家数量
q：其中选择搬入 GPU 的数量

注意，PCIe DMA 和 CPU 计算都要从同一份内存中读专家权重。PCIe 正在以 B_P 读数据时，能留给 CPU 的大约是：

1

B_R = B_H - B_P

假设每个专家大小都是 S，两个并发分支的耗时近似为：

1
2

GPU 搬运分支：T_fill ≈ q × S / B_P
CPU 计算分支：T_cpu  ≈ (m - q) × S / (B_H - B_P)

两个任务是并行的，总时间取较慢的那个。要让硬件利用得最充分，就尽量让它们同时结束：

1

q × S / B_P ≈ (m - q) × S / (B_H - B_P)

两边约掉 S，整理一下：

1

q* ≈ m × B_P / B_H

这就是论文中的 q* policy。

这个推导默认 B_H > B_P，也就是 PCIe 占满以后还有一部分 Host 带宽能留给 CPU。实际执行时还会把 q 取整并限制在合法范围。对于 m > 0 的情况，可以把它理解成：

1

q = clamp(round(q*), 1, m)

当 B_H 接近或者低于 B_P 时，CPU 已经没有值得利用的剩余带宽，策略就退化成 q = m，把 miss 都送去 GPU；至少保留一次 fill，也能让冷缓存继续升温。

用论文里 4060 Laptop 的实测数据算一次：

1
2
3
4
5
6

B_P = 11.8 GB/s
B_H = 47.5 GB/s
m   = 4

q* ≈ 4 × 11.8 / 47.5
   ≈ 0.99

取整之后就是：

1
2

1 个专家通过 PCIe 搬进 GPU
3 个专家直接由 CPU 计算

这里有一个挺反直觉的地方：CPU 并不是因为算力特别强才参与，而是因为 Decode 的 batch 通常很小，专家 GEMV 更容易受内存带宽限制。CPU 计算那 3 个专家，实际上是在利用 PCIe 没有吃掉的剩余内存带宽。

如果换到另一台机器：

• PCIe 很快、CPU 内存带宽不高，q* 会接近 m，更适合多搬到 GPU
• 内存带宽明显高于 PCIe，CPU 可以承接更多 miss
• 专家本来就在缓存里，则根本不进入 q* 分流

所以 FreeToken 不靠显卡型号表拍脑袋。它提供：

1

ft bench bw

这个命令使用真实的专家搬运和 CPU MoE kernel 测量带宽，并把结果写到：

1

~/.cache/freetoken/benchbw.json

ft serve --moe-backend auto 会根据这份 profile 决定继续使用 offload，还是升级为 CPU/GPU 并行的 hybrid。

为什么 LRU 专家缓存会有效

如果每个 token 选中的专家完全随机，刚放进 GPU 的专家下一步就再也不用，那么缓存没有太大价值。

实际路由通常存在短期局部性。相邻 token 处在同一段语义、同一种语言或同一段代码中，路由到的专家经常重叠：

1
2
3

token t:     [17, 42, 58, 91, 103, 144, 201, 233]
token t + 1: [17, 42, 61, 91, 103, 144, 205, 233]
              ↑   ↑      ↑   ↑    ↑         ↑

第二个 token 中就有多个专家可以直接命中。

FreeToken 使用全局 LRU：

1
2
3
4

命中：更新 usage
未命中：找最久没有使用的 slot
换入：更新正向表和反向表
执行：把逻辑 expert id 改写为 slot id

源码里的实现还多做了一步：命中判断、miss 去重、q 的计算、victim 选择和 ID 改写都在 GPU kernel 中完成。

原因是 CUDA Graph 喜欢固定的控制流和固定形状。如果每一层都把 expert id 拷回 CPU，让 Python 决定淘汰谁，再通知 GPU，光同步就会非常昂贵。

FreeToken 的做法是：

1
2

控制流保持固定
变化的命中数、miss 数和 victim 都作为 GPU 上的数据

工作缓冲区大小固定，再用一个有效数量屏蔽没有使用的部分。这样动态 LRU 仍然可以被放进静态捕获的 CUDA Graph。

论文给出的路由回放结果也能看到这个差别。在相同缓存容量下，Qwen3.6 的 Decode miss rate：

1
2
3

FreeToken 全局 LRU：16%
KTransformers 预填充时更新的静态放置：41%
llama.cpp 路由无关的静态切分：62%

这个数字不是说 LRU 永远都会命中 84%，而是说明在论文的四类 agent workload 和指定缓存容量下，token 之间确实存在可以利用的路由局部性。

Prefill 为什么不能也按需加载

看完 Decode 很容易产生一个想法：Prefill 也让选中的专家按需进入缓存不就行了？

问题在于 Prefill 不是一次只处理一个 token，而是一次处理几千个 token。

对单个 token 来说：

1

256 个专家中只选 8 个

但是一批 8192 个 token 各选 8 个，取所有路由结果的并集后，几乎每个专家都会被碰到：

1
2
3
4
5
6

token 1    -> 8 个专家
token 2    -> 另外一些专家
...
token 8192 -> 另外一些专家

所有 token 的并集 -> 接近完整 256 个专家

也就是说，MoE 在 Decode 阶段是稀疏工作集，到了长 Prompt 的 Prefill 阶段却接近稠密工作集。

如果还逐个 miss、逐个搬运，会产生很多细碎传输，GPU 也会不断等 PCIe。

FreeToken 因此给 Prefill 设计了另一条路径：完整层双缓冲。

它从全局专家 slot pool 中借出能容纳两层完整专家的空间：

1
2

Buffer A：GPU 正在计算第 l 层
Buffer B：PCIe 同时传输第 l + 1 层

第 l 层算完后，两块 buffer 交换角色：

1
2

Buffer B：计算第 l + 1 层
Buffer A：传输第 l + 2 层

因为搬的是下一层完整专家，甚至不需要等下一层路由结果出来就可以提前开始传输。理想情况下，一层的计算时间被下一层的搬运时间完全覆盖。

这也解释了为什么至少要有两层专家大小的缓存才能开启 overlap。源码中 OffloadMoeCache 会直接检查：

1

cache_size >= 2 × num_experts

空间不足时不会硬撑，而是回退到按需 Prefill。

论文在 RTX 5090 上关闭双缓冲后，4K、8K、16K Prompt 的 Prefill 吞吐分别下降了 19%、25% 和 26%。Prompt 越长，完整专家池的搬运越无法忽略。

Agent 场景里还有一种重复：上下文被改写

普通聊天通常只是在历史后面追加内容，前缀 KV Cache 很容易复用。

Coding Agent 不一样。一次工具调用之后，框架可能会：

• 删除旧的 thinking
• 用占位符替换太老的工具输出
• 截断历史 observation
• 保留前半段，再改写中间某一块

Qwen3.6 这类混合架构不仅有完整注意力，还有 Gated DeltaNet 这样的递归状态。KV Cache 可以按 token 保存，递归层却把前缀压缩成一个不断演进的 state。

如果中间一块上下文被改了，修改点后面的 state 都失效。检查点又很少的话，只能从很早的位置重新 Prefill。

FreeToken 的做法是把有限的 recurrent-state checkpoint 放在更可能存活的语义边界：

1
2
3
4

一轮对话结束
thinking 结束
tool call 开始/结束
tool output 开始/结束

Agent 框架通常也是按这些完整区块删除内容，所以边界之前的前缀更可能保持不变。恢复时：

1
2
3

找到仍然有效的最深语义锚点
恢复对应的 KV / recurrent state
只重新计算变化后的后缀

这部分跟专家缓存解决的不是同一个问题：

FreeToken 把它们放进同一个 serving engine，是因为本地 Agent 的总等待时间同时受两边影响。只有 Decode 跑得快，但每次工具调用后重新 Prefill 一分钟，体验仍然不行。

显存还要在专家缓存和 KV Cache 之间动态分配

刚启动模型时上下文很短，可以把更多剩余显存用作专家缓存。对话越来越长后，KV Cache 会持续增长，而专家工作集没有同比增长。

静态切分很容易出现：

1
2
3

专家缓存很大，但 KV Cache 不够
或者
KV 预留太多，专家缓存命中率很低

FreeToken 把这两块都看成运行时资源。在 scheduler 没有待处理 Prefill、没有进行中的 Decode 时，到达一个 safe point，才执行 cache rebuild：

1
2
3
4
5

暂停接收新的计算批次
释放旧 CUDA Graph
重新分配专家 slot 和 KV page
重新捕获 CUDA Graph
继续服务

Host RAM 中的完整专家池不需要重新加载，所以不必重启进程或者再次读取整个模型。

可以通过：

1
2

ft ctl cache
ft ctl cache --moe 512 --kv 16k

查看和调整缓存。调整不是发生在某个 token 计算到一半的时候，而是排队等到 scheduler 完全空闲的安全点。

FTW 为什么能缩短启动时间

模型文件里的专家权重未必正好是运行时最方便的排列。FreeToken 会把不同模型的专家整理成少数几种 expert bank，并把：

1

flat_id = layer_id × num_experts + expert_id

作为每个 bank 的第一维。

同一个 flat_id 在 gate_up、down、scale 等 bank 中对应同一个完整专家。这样 GPU slot cache 和 CPU executor 共用一套逻辑 ID，不需要理解每种模型原始 checkpoint 的布局。

FTW 是 FreeToken 的 fast weight format。它不是新的量化算法，主要作用是预先把权重转换成运行时最终布局。

传统加载过程可能是：

1
2
3
4
5

申请巨大空缓冲区
把内存页 pin 住并清零
读取 checkpoint
重新排列专家
复制到最终位置

FreeToken 的路径是：

1
2

从磁盘直接读入最终 Host 布局
数据填充完成后再 pin

Pinned memory，也就是 page-locked memory，不会被操作系统随便换出，CUDA 可以对它进行更稳定的异步 DMA。但提前 pin 一个巨大的空缓冲区会触发页面分配和清零，随后又马上被模型数据覆盖，白做了一遍内存写入。

FTW 避免了这部分启动开销。GPU 专家缓存也不需要专门 warmup，第一次请求从冷缓存开始，沿用普通 miss 路径自然升温。

ft checkpoint 是可选步骤，FreeToken 也能直接读取支持的 Hugging Face checkpoint：

1
2
3
4

ft checkpoint \
  --model ~/models/Qwen3.6-35B-A3B \
  --out ~/models/Qwen3.6-35B-A3B-FTW \
  --moe-backend offload

从源码看这些模块怎么对应

把论文和代码对照起来，大致是下面这些位置：

其中最核心的 Decode 伪代码其实不复杂：

1
2
3
4
5
6
7
8
9
10
11
12

routes = router(hidden_states)

hits, misses = gpu_cache.lookup(routes)
to_gpu, to_cpu = split_by_bandwidth(misses)

cpu_task = cpu_executor.submit(to_cpu)
gpu_cache.fill(to_gpu)

gpu_output = gpu_experts(hits + to_gpu)
cpu_output = cpu_task.wait()

return gpu_output + cpu_output

真正难的是让 lookup、动态 miss 数、异步拷贝、CPU worker 和 CUDA Graph 同时成立，而且不能每层都把控制权交回 Python。

跟 llama.cpp 的部分卸载有什么区别

两者最表面的相同点都是：

1

显存不够，就让一部分权重留在内存

但“哪一部分留在内存”和“运行时怎么使用它”差别很大。

llama.cpp 的 -ngl 是静态层卸载

以一个 64 层 Dense 模型为例：

1
2

第 0～39 层：CPU
第 40～63 层：GPU

模型加载完成后，层的位置基本就固定了。每生成一个 token，仍然要依次经过全部 64 层：

1
2
3

CPU 计算前 40 层
传递中间激活
GPU 计算后 24 层

这里通常移动的是层与层之间较小的激活，不是每个 token 都把完整层权重搬来搬去。

这种方式非常适合 Dense 模型，因为 Dense 没有路由器，任何一层的 FFN 权重每个 token 都会使用。也就谈不上“缓存最近用到的专家”。

当前 llama.cpp 的参数是：

1
2
3

-ngl N
--gpu-layers N
--n-gpu-layers N

现在也可以使用 auto 或 all，让运行时自动拟合显存。

llama.cpp 也有专门的 MoE CPU 放置

如果模型是 MoE，当前 llama.cpp 还支持：

1
2

-cmoe
--cpu-moe

把全部 MoE 专家权重留在 CPU；或者：

1
2

-ncmoe N
--n-cpu-moe N

只把前 N 个 MoE 层的专家留在 CPU。

这已经比单纯的 -ngl 更接近 FreeToken：注意力等非专家部分可以继续在 GPU，而巨大的专家权重留在内存。

llama.cpp 当前的 scheduler 还能根据路由 ID，只处理被选中的 expert sub-row，而不是无条件复制所有专家。不过截至 2026 年 8 月 23 日，官方 master 的这条路径没有 FreeToken 那样跨 token 持久存在的 expert -> slot 映射。被选中的专家可以在一次 forward 中搬到 GPU tensor 的原始偏移位置，但下一次相同专家仍可能再次搬运。

llama.cpp 社区已经有 persistent expert cache 的 RFC 和 PR，例如 #20757 和 #26824，说明这个方向也正在快速演进。这里对比的是本文日期的官方 CLI 和 master 行为，不应该理解成 llama.cpp 永远不会有专家缓存。

FreeToken 优化的是动态专家工作集

FreeToken 的主要单位不是“第几层放在哪”，而是：

1

当前这个 (layer, expert) 应该在哪里执行

所以它们不是简单的“一个能卸载，一个不能卸载”。

llama.cpp 是通用、本地部署范围很广的推理引擎，Dense 模型、Apple Silicon 和各种后端都是它的优势。FreeToken 则把目标收得更窄，专门围绕“显存装不下完整 MoE 专家池”设计整个 serving stack。

那么 Qwen3.8-27B 在 4060 上应该用哪一种

回到最开始容易串在一起的问题。

Qwen3.8-27B 是 Dense 模型：

1
2

没有 256 选 8 的路由专家
每个 token 都要经过每层完整 FFN

27B 做 4bit 的理论权重大小约为：

1

27B × 0.5 byte = 13.5GB

再加量化元数据、KV Cache 和运行时开销，8GB 4060 无法让它全量常驻显存。

这时更合适的思路是：

1
2
3
4

GGUF 低比特量化
+ llama.cpp
+ 尽可能多的静态 GPU layer offload
+ 剩余层在 CPU / RAM 中执行

例如：

1
2
3
4

llama-server \
  -m Qwen3.8-27B-Q3_K_M.gguf \
  -ngl auto \
  -c 8192

具体能放多少层取决于 GGUF 大小、上下文长度、KV 精度、系统当前可用显存和 llama.cpp 版本。-ngl auto 比照搬别人机器上的固定层数更稳妥。

FreeToken 当前文档虽然支持 Qwen3.6-27B Dense，但 Dense 模型的 auto 会解析为 fused，也就是要求权重常驻 GPU，并不会启用 MoE offload/hybrid 这套专家机制。当前支持列表也还没有列出刚发布的 Qwen3.8-27B。

因此：

1
2
3
4
5

8GB 4060 + Qwen3.6-35B-A3B MoE
-> FreeToken 的专家缓存和 hybrid 很有意义

8GB 4060 + Qwen3.8-27B Dense
-> 更适合 llama.cpp 的量化和静态层卸载

两个模型参数接近，但运行路径不能混着解释。

实际怎么跑 FreeToken

当前开源 CLI 的要求是：

1
2
3
4
5

Linux x86_64
NVIDIA GPU
driver r580+
CUDA 13
Python 3.10+

所以它目前不是 M3 Pro 上 llama.cpp/Metal 的替代品。Mac 仍然更适合 llama.cpp 或 MLX。

安装：

1
2
3

uv venv
source .venv/bin/activate
uv pip install "freetoken[accel]"

先测一次这台机器的 CPU/PCIe 带宽：

1

ft bench bw --dtype nvfp4

然后启动论文中 8GB 机器使用的 NVFP4 模型：

1

ft serve --model nvidia/Qwen3.6-35B-A3B-NVFP4

只提供 --model 也可以，dtype、attention backend、MoE backend、专家缓存和 KV 容量会根据 checkpoint、显存和带宽 profile 自动推导。

想明确观察模式，可以分别测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 专家在内存，miss 全部搬到 GPU
ft serve \
  --model nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --moe-backend offload

# 专家在内存，miss 由 CPU 处理
ft serve \
  --model nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --moe-backend cpu

# GPU cache hit + PCIe fill + CPU overflow 并行
ft serve \
  --model nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --moe-backend hybrid

运行后可以查看：

1
2

ft ctl stats
ft ctl cache

对比时不要只测一句 hello。至少分别看：

• 冷启动后的第一轮
• 长 Prompt 的 TTFT
• 连续生成几百 token 后的 Decode
• 多轮工具调用后是否反复 Prefill

短 Prompt、冷缓存和长时间 Agent 会话测到的是三种不同状态。

这套方案的限制

看到 39.3 tok/s 很容易只记住“8GB 显存”，但这套方案还有几个前提。

内存仍然要装得下完整专家池

显存需求降低不等于总内存需求消失。论文里的 4060 Laptop 有 32GiB 内存，并且使用 NVFP4。只有 16GB 系统内存时，同一模型可能会进入 swap，速度会急剧下降，甚至无法稳定加载。

主要适用于 MoE

Dense 模型每个 token 都要读完整 FFN，没有小而稳定的专家工作集。FreeToken 的核心专家缓存不会把 27B Dense 变成 3B active。

性能受整机而不是只受 GPU 决定

需要同时看：

• Host RAM 带宽
• PCIe 代际和通道数
• CPU SIMD 能力
• 物理核心数
• 显存能留下多少专家 slot
• 实际路由的局部性

同一张 4060 放在不同笔记本里，内存和 PCIe 配置不同，q* 和速度也会不同。

39.3 tok/s 不是所有请求的固定速度

这是论文在指定 4060 Laptop、NVFP4 模型和 coding-agent workload 下测得的 Decode 吞吐。它不等于：

• 冷启动速度
• Prefill 速度
• 超长上下文下的平均响应速度
• 任意量化、任意机器都能得到的速度

缓存也有冷启动和工作集突变

刚启动时专家缓存是空的。如果话题、语言或者任务突然变化，路由热点也可能变化，短时间 miss 会增加。LRU 利用的是局部性，不是消灭所有 miss。

最后总结

现在再看“8GB 显存运行 35B”，可以把它拆成五步：

1
2
3
4
5

1. Qwen3.6-35B-A3B 是 MoE，每个 token 只激活约 3B
2. 完整的量化专家池放在 32GiB Host RAM，不是硬塞进 8GB VRAM
3. 剩余显存作为跨层共享的 LRU 专家 slot cache
4. Decode miss 按 q* 分给 PCIe+GPU 和 CPU，两条路径并发并精确合并
5. Prefill 改用完整层双缓冲，并通过语义状态缓存减少 Agent 重算

llama.cpp 的 -ngl 主要解决的是“完整层怎样静态分布到 CPU 和 GPU”，--cpu-moe 则进一步允许专家留在 CPU。FreeToken 在这个基础问题上继续往前走，把专家当成随 token 路由变化的动态工作集，并围绕它设计缓存、带宽分流、Prefill 和运行时显存管理。

所以 FreeToken 真正有意思的地方并不是一个神奇的“8GB 跑 35B”数字，而是它换了一个看待本地机器的方式：

1
2
3

GPU 不是唯一计算设备
显存也不是唯一模型内存
CPU、RAM、PCIe 和 GPU 可以组成一台统一的推理机器

但这条路成立的关键仍然是 MoE 的稀疏性。换成 Qwen3.8-27B 这样的 Dense 模型，还是要老老实实回到量化、层卸载和内存带宽这几个问题上。

参考资料

• FreeToken 论文：Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution
• FreeToken 源码
• FreeToken CLI 文档
• Qwen3.6-35B-A3B 官方模型卡
• Qwen3.8-27B 官方模型卡
• llama.cpp CLI 参数
• llama.cpp persistent expert cache 讨论

最近deepseek发布了harness，试用了一下结合deepseek-4-flash，用它尝试写一个php的现代版phpmyadmin，因为也是一个比较重要且有一点复杂度的应用
试了下除了数据展示有点问题，修了一轮就完成了，整体表现还是不错的
然后看了下它主打的是万物都是插件
这个概念还是比较复杂的，尝试让gpt老师帮我讲解下
DeepSeek Harness 就像一个“由很多小员工临时组成的公司”。
没有一个超级总经理包办所有事情：

• 一个员工负责问大模型；
• 一个员工负责读文件；
• 一个员工负责运行命令；
• 一个员工负责审批危险操作；
• 一个员工负责保存聊天记录；
• 一个员工负责显示网页界面。
  这些“员工”就是插件。
  需要什么员工，就把什么员工叫来；不需要了，就让它离开，并自动收拾自己留下的东西。

用一个真实请求走一遍

你对 DeepSeek Harness 说：

帮我读取 package.json，看看项目用了哪些依赖。
系统内部大致发生了这些事：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

你输入问题
   ↓
Agent Loop 插件：决定下一步做什么
   ↓
LLM 插件：把问题发给 DeepSeek
   ↓
DeepSeek 返回：我要调用 read_file
   ↓
权限插件：这个文件允许读吗？
   ↓
文件工具插件：读取 package.json
   ↓
日志插件：记录本次工具调用
   ↓
Agent Loop 插件：把文件内容再次交给 DeepSeek
   ↓
DeepSeek 生成最终回答
   ↓
Web UI 插件：把回答显示出来

关键点是：
上面每一个步骤都可以由不同插件负责。
比如你可以：

• 把 DeepSeek 换成其他模型；
• 把本地文件系统换成远程沙箱；
• 给文件读取前增加权限检查；
• 给模型调用增加重试；
• 给工具调用增加日志；
• 换掉整个 Agent Loop。
  其他部分不需要跟着重写。

为什么普通插件系统做不到这么灵活

普通软件的结构经常是：

1
2
3
4

固定核心程序
├── 插件位置 A
├── 插件位置 B
└── 插件位置 C

核心程序是老板，插件只能填几个预留位置。
DeepSeek Harness 更像：

1
2
3
4
5
6
7

极小的组装平台
├── Agent Loop 插件
├── 模型插件
├── 工具插件
├── 权限插件
├── 存储插件
└── UI 插件

连“核心 Agent 怎么循环运行”本身也是插件。
所以它不是：

一个 Agent，加上一些插件。
而是：
很多插件组合起来以后，才形成一个 Agent。

插件之间怎么找到对方

假设你写了一个天气工具插件。
它不能一启动就直接工作，因为它要先找到“工具管理器”。
所以它会声明：

1

我需要：tools 服务

代码里大概是：

1

export const inject = ['tools']

意思就是：

只有工具管理器存在时，才启动我。
系统启动时可能出现这种情况：

1
2
3
4
5
6

天气插件：我需要 tools
工具管理器：还没启动
天气插件：那我先等着

工具管理器启动
天气插件：条件满足，现在开始工作

如果工具管理器后来被替换：

1
2
3
4
5
6
7

旧工具管理器卸载
   ↓
天气插件也暂时卸载
   ↓
新工具管理器启动
   ↓
天气插件重新启动，并连接新管理器

这就是 DeepSeek Harness 很特别的地方：

插件依赖不是只在启动时检查一次，而是一直被系统关注。

ctx 到底是什么

插件启动时会拿到一个 ctx：

1
2
3

export function apply(ctx) {
  // 使用 ctx 做事
}

你可以把 ctx 理解成“公司总机”。
插件不知道其他插件住在哪里，只需要问总机：

1
2
3
4
5

ctx.tools       // 工具管理器
ctx.llm         // 模型管理器
ctx.sessions    // 会话管理器
ctx.fs          // 文件系统
ctx.sandbox     // 沙箱

比如天气插件说：

1

ctx.tools.register(weatherTool)

意思就是：

总机，请把我的天气能力登记到工具管理器里。
这样天气插件不需要自己找到 Agent Loop，也不需要直接修改模型提示词。工具管理器会负责把天气工具告诉模型。

插件卸载时，怎么避免留下垃圾

这是整个系统最值得理解的设计。
假设天气插件启动后做了三件事：

1
2
3

1. 注册 weather 工具
2. 监听工具调用事件
3. 启动一个定时器

如果只是粗暴地删除插件代码，可能留下：

• 一个无法调用的 weather 工具；
• 一个永远存在的事件监听器；
• 一个一直运行的定时器。
  DeepSeek Harness 要求插件在创建东西时，同时登记“怎么撤销”。
  可以理解成：

  1 2 3 4 5 6 7 8

  创建 weather 工具 同时记下：卸载时删除 weather 工具 添加事件监听器 同时记下：卸载时移除监听器 启动定时器 同时记下：卸载时停止定时器

  于是卸载插件时，系统会自动倒着清理：

  1 2 3

  停止定时器 移除监听器 删除 weather 工具

  所以热更新才比较可靠。
  修改天气插件代码后，系统可以：

  1 2 3 4 5

  完整清理旧天气插件 ↓ 重新加载新代码 ↓ 重新注册新天气工具

  而不是让新旧两套东西同时残留。
  这个“创建时顺便记录撤销方法”的机制，技术上叫 effect。

Fiber 又是什么

现在再引入 Fiber 就很容易了。
Fiber 可以理解成：

某个插件这一次运行的“工作档案”。
里面记录着：

• 这个插件是谁；
• 它在等哪些服务；
• 它现在有没有启动；
• 它注册过什么东西；
• 卸载时要清理什么；
• 它是否启动失败。
  一个插件大致会经历

  1 2 3 4 5 6 7 8 9

  等待条件 ↓ 正在启动 ↓ 正常运行 ↓ 正在清理 ↓ 已经卸载

  对应的技术名称是：

  1 2 3 4 5

  PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED

  所以 Fiber 不是线程，也不是子进程。
  它只是插件的一份“生命周期档案”。

插件怎么插手系统流程

有些插件提供能力，比如文件系统。
另一些插件不提供新能力，只想在某个流程中插一脚。
例如权限插件想在执行 Bash 前检查命令：

1
2
3
4
5
6

模型请求执行 rm ...
   ↓
权限插件检查
   ↓
允许：继续执行
拒绝：直接返回错误

这个过程很像高速公路收费站：

1
2
3
4
5
6

请求
 → 审批站
 → 权限站
 → 超时站
 → 日志站
 → 真正执行

每一站都可以：

• 检查请求；
• 修改请求；
• 记录请求；
• 放行；
• 拒绝继续。
  在代码里，放行通常是调用：

  1

  next()

  不调用 next()，就表示到此为止。
  这就是它所谓的 waterfall。本质上就是一条可插拔的中间件链。

Bundle 和 Profile 又是什么

这里最容易被名词绕晕。

Plugin 是员工

真正执行工作的代码。

Bundle 是部门安装包

一个 Bundle 可能一次带来很多插件，例如：

1
2
3
4
5
6

Web Bundle
├── Web 服务器插件
├── 浏览器通信插件
├── 聊天界面插件
├── 设置页面插件
└── Web 启动插件

Profile 是公司组织方案
比如：

1
2
3

web Profile
├── 基础 Bundle
└── Web Bundle

而：

1
2
3

headless Profile
├── 基础 Bundle
└── 命令行 Bundle

因此：

1

dsh --profile web

可以理解成：

按照 Web 这套组织方案，把对应部门和员工全部组装起来。

安装一个插件时发生什么

执行：

1

dsh plugin --profile web add some-plugin

大致等于：

1
2
3
4
5

1. 用 pnpm 下载 npm 包
2. 查看这个包有没有声明自己是 DSH Bundle
3. 找到它携带的插件配置
4. 把它加入 web Profile
5. 下次启动时加载其中的插件

大概是这么个逻辑

之前也偶尔用户pi agent这个工具，当然这个还是个很庞大的系统，我也只能一点点学
首先是工具系统，默认的核心工具主要是四个 read,write,edit,bash

read 主要是读取文件

输入结构式这样

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "path": "src/app.ts",
  "offset": 1,
  "limit": 200
}
- path：相对或绝对路径
- offset：从第几行开始，1 开始计数
- limit：最多读取多少行
内部的原理大致是
```text
解析路径
→ 检查文件是否可读
→ 判断是文本还是图片
→ 读取内容
→ 按 offset/limit 截取
→ 限制输出大小
→ 返回给模型

对于文本，Pi 将文件按照 UTF-8 解码并拆分为行。默认最多返回前 2000 行或 50KB，哪个先达到就按哪个截断，并告诉模型下一次应该使用哪个 offset 继续读取。

1

[Showing lines 1-2000 of 3540. Use offset=2001 to continue.]

write 创建文件或完整覆盖

输入

1
2
3
4

{
  "path": "src/Hello.php",
  "content": "<?php\n\necho \"hello\";\n"
}

主要原理

1
2
3
4
5

解析目标路径
→ 创建不存在的父目录
→ 进入该文件的 mutation queue
→ 完整写入 content
→ 返回写入结果

如果文件已经存在，则完整覆盖。它不是“追加”，也不是“局部修改”。
Pi 会针对同一个文件建立 mutation queue，防止多个并行工具同时修改同一个文件导致内容互相覆盖：

1
2
3
4
5

write A ──────┐
              ├→ 同一个文件顺序执行
edit  A ──────┘

write B ─────────→ 不同文件可以独立处理

edit 精确替换已有代码

这是四个工具中设计最讲究的一个。
输入
当前 Pi 支持一次提交多个互不重叠的修改：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "path": "src/UserService.php",
  "edits": [
    {
      "oldText": "public function find($id)",
      "newText": "public function find(int $id): ?User"
    },
    {
      "oldText": "return $this->users[$id];",
      "newText": "return $this->users[$id] ?? null;"
    }
  ]
}

内部原理

1
2
3
4
5
6
7
8
9

读取原文件
→ 去掉 BOM
→ 将 CRLF/CR 统一成 LF
→ 在原始文件中寻找每个 oldText
→ 检查每段是否唯一、是否重叠
→ 执行全部替换
→ 恢复原来的换行符和 BOM
→ 写回文件
→ 生成 diff 和 unified patch

关键要求是：oldText 必须精确匹配，而且在原文件里唯一。
例如文件中有两个：

1

return null;

模型如果只提交：

1
2
3
4

{
  "oldText": "return null;",
  "newText": "throw new RuntimeException();"
}

工具会拒绝，因为不知道应该修改哪一个。
模型必须提供足够的上下文：

1
2
3
4

{
  "oldText": "public function load(): ?User\n{\n    return null;\n}",
  "newText": "public function load(): ?User\n{\n    return $this->repository->first();\n}"
}

为什么采用精确替换

• 它相当于一种轻量级“乐观锁”：
• 模型看到文件版本 A
• 模型根据 A 生成 oldText
• 如果调用工具前文件被改成版本 B
• oldText 匹配失败
• 工具拒绝覆盖，要求模型重新读取
  这比让模型直接按行号修改更安全，因为文件新增一行后，行号可能全部偏移。
  执行成功后，Pi 同时生成：
• 面向终端显示的彩色 diff
• 标准 unified patch
• 第一处变化的行号

bash 给模型提供“手脚”

输入

1
2
3
4

{
  "command": "php -l src/UserService.php && php tests/run.php",
  "timeout": 30
}

原理：

1
2
3
4
5
6
7

找到当前平台的 Shell
→ 在工作目录启动子进程
→ 注入环境变量
→ 同时监听 stdout/stderr
→ 实时把输出推送到 TUI
→ 等待退出码
→ 将结果返回给模型

它可以完成：

• rg、find、ls 搜索项目
• 运行测试
• 调用编译器
• 执行 Git 命令
• 安装依赖
• 启动构建脚本
• 执行任意系统程序
• 输出处理
  与 read 保留“开头”不同，bash 更适合保留“结尾”。
  因为测试、编译和日志输出的错误通常在末尾。因此 Pi 保留最后 2000 行或最后 50KB。如果发生截断，完整输出会另外保存到临时文件。

四个工具如何协作

假设用户说：
给项目增加一个 /health 接口并运行测试。

模型可能按下面的流程工作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

1. bash
   rg "Route|router" src

2. read
   读取找到的路由文件

3. edit
   精确插入 /health 路由

4. write
   创建新的 HealthController.php

5. bash
   php -l ... && php tests/run.php

6. read
   如果测试失败，读取相关源文件

7. edit
   修复问题

8. bash
   再次运行测试

这就是 Coding Agent 的核心闭环：

1
2
3
4
5

观察（read/bash）
→ 决策（LLM）
→ 修改（edit/write）
→ 验证（bash）
→ 再观察

大致学一下这个工具的工具逻辑

之前就比较好奇，命令行一般输出都是往后追加，好像不知道怎么做覆盖更新，但是很多比较厉害的shell脚本都有那种进度条，甚至整个重绘
所以就来看下，怎么在命令行里输出个会变的进度条，
比如我在命令行中输出两行

1
2
3

echo "111\n";
echo "222\n";
exit;

最简单就是这样子，那如果想把111改成222呢
我们发现”\n”是换行，那”\r”其实是原地移动到行首
可以再看下

1
2
3
4

echo "111\r";
usleep(1000*1000);
echo "222\n";
exit;

加了sleep是因为闪太快了看不到，这样就能看到这一行就重新刷新了
然后就可以看下进度条可以怎么输出了

1
2
3
4
5
6

for ($i = 0; $i <= 50; $i++) {
    printf("progress: [%-50s] %d%%\r", str_repeat('#',$i), $i * 2);
    usleep(1000 * 100);
}
echo "\n";
echo "Done.\n";

首先是解释下这段的含义

1
2
3
4
5

"progress: [%-50s] %d%%\r"
           └──┬──┘  │ │  └─ 回到当前行开头
              │     │ └──── 输出一个真正的 %
              │     └────── 输出整数
              └──────────── 输出宽度为 50 的字符串

感觉又变成了一个视觉游戏，以为是逐渐的在往后画
其实是一直在刷新这个进度条
首先是定义一个长度是50个字符的输出，用空格补全，然后会输出对应百分比，比如2%
就对应的是一个井号，然后用”\r”回到行首重绘
实际的就是第一次画一个#号，第二次画两个#号
这里最大的重点就是要让部分字符看着在变，部分看着不变，才能形成这种视觉假象
比如这里的50个字符长度，还有对应的”%”符号
否则就会变成一直在跳的了
对应的动的部分就是#号的增加，对应百分比数值也在往上涨
不过这里有点小问题，不知道有没有发现，它的数字没有定义位数
那么在达到100%的时候其实是有一点跳跃的

那如果想要改多行怎么办呢
就需要用ANSI 控制序列让光标向上移动若干行

1
2
3

任务 A：[########          ] 40%
任务 B：[############      ] 60%
总进度：[##########        ] 50%

光标此时位于这三行下面。下一次刷新前，先让光标向上移动三行：

1

ESC [ 3 A

在php中可以写成

1

echo "\033[3A";

最简单的就是

1
2
3
4
5
6

echo "111\n";
echo "222\n";
echo "333\n";
echo "\033[3A";
usleep(1000*1000);
echo "444\n";

这样就会把前面的111,222,333给干掉，重新输出444
来个像样点的脚本就是

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

<?php

function progressBar(int $percent, int $width = 30): string
{
    $percent = max(0, min(100, $percent));
    $filled = (int) floor($percent * $width / 100);

    return sprintf(
        "[%-{$width}s] %3d%%",
        str_repeat('#', $filled),
        $percent
    );
}

$lineCount = 3;

for ($i = 0; $i <= 100; $i++) {
    $taskA = $i;
    $taskB = min(100, $i * 2);
    $total = (int) (($taskA + $taskB) / 2);

    // 第一次输出前不需要移动光标
    if ($i > 0) {
        printf("\033[%dA", $lineCount);
    }

    $lines = [
        "任务 A：" . progressBar($taskA),
        "任务 B：" . progressBar($taskB),
        "总进度：" . progressBar($total),
    ];

    foreach ($lines as $line) {
        // 回到行首并清除当前整行
        echo "\r\033[2K";
        echo $line;
        echo PHP_EOL;
    }

    fflush(STDOUT);
    usleep(100000);
}

这里的符号代表的含义

1

echo "\033[3A";

发送给终端的实际含义是：

1

ESC + [3A

也就是“光标向上移动三行”。
还是比较神奇的东西
以前一直没搞明白，刚好这次想到了
现在很多想claude code，包括opencode，pi等都是搞成了命令行的
这个大概就是这些命令行工具的基础
像opencode是使用的

1
2
3

@opentui/core
@opentui/solid
solid-js

pi则是使用

1
2

@earendil-works/pi-tui
其他的框架还有

1
2
3
4
5
6
7
8
9
10
11
12

use Symfony\Component\Console\Output\ConsoleOutput;

$output = new ConsoleOutput();
$section = $output->section();

$section->writeln("任务 A：10%\n任务 B：20%\n任务 C：30%");

sleep(1);

$section->overwrite(
    "任务 A：40%\n任务 B：50%\n任务 C：60%"
);

最近给一台联想 G400 重装 Windows 7。本来以为只是做个启动盘、装好系统就结束了，实际操作时却遇到了驱动缺失、旧版 IE 无法打开部分网站、Windows Update 报错，以及显卡驱动依赖 .NET Framework 等一连串问题。这里把完整过程和用到的资料整理一下，方便以后再遇到类似的老电脑时查阅。

先提醒一句：Windows 7 已于 2020 年 1 月 14 日结束支持，不再获得常规安全更新；Chrome 109 也早已停止更新。因此，这套方案更适合需要兼容老软件或老硬件的场景，不建议把它作为长期联网、登录重要账号或进行支付操作的主力系统。

一、安装前的准备

1. 下载 Windows 7 SP1 镜像

我使用的是 Windows 7 SP1 原版镜像，可以从 MSDN，我告诉你 查找。

需要注意的是，这个网站不是微软官方网站，而是第三方原版软件信息收录站。下载时应选择与授权和硬件相符的版本，并核对镜像的 SHA-1 等校验值，避免使用被二次修改、捆绑软件或来源不明的镜像。

联想 G400 通常可以安装 64 位系统。如果机器内存很小，或者有必须使用 32 位系统的老软件，再根据实际情况选择 x86 版本。后面下载补丁和驱动时，系统架构也必须保持一致。

2. 提前下载驱动

Windows 7 对很多硬件并不能做到安装后自动识别，最麻烦的情况是系统装好了，却因为有线网卡和无线网卡都没有驱动而无法联网。因此，重装前最好先从 联想 G400 驱动下载页面 下载对应版本的驱动，放到另一个 U 盘中。

建议至少准备这些驱动：

• 芯片组驱动；
• 有线网卡和无线网卡驱动；
• 核芯显卡和独立显卡驱动；
• 声卡、触控板、读卡器等驱动。

G400 有不同的硬件配置，最好根据机器背面的具体型号或主机编号查找，不要只看系列名称。网卡驱动尤其可以多准备一个可能的版本，以免装完系统后完全无法联网。

3. 提前下载补丁和常用软件

为了避免装好系统后才发现网站打不开，建议把下面这些内容也提前放进 U 盘：

• .NET Framework 4 独立安装包；
• IE11 安装包；
• 本文后面提到的 Windows 7 补丁；
• Chrome 109 离线安装包；
• 已下载好的联想官方驱动。

二、制作启动 U 盘并安装系统

我使用 UltraISO 将 Windows 7 SP1 镜像写入 U 盘。操作前一定要确认目标盘符，因为写入过程会清空 U 盘中的原有数据。

制作完成后，从联想 G400 的启动菜单中选择 U 盘，按照安装向导完成系统安装即可。如果进入安装界面后出现键盘、鼠标或 U 盘突然无法使用的情况，可以先换到 USB 2.0 接口再试；Windows 7 安装环境对 USB 3.0 的原生支持并不完善。

分区或格式化系统盘前，务必确认重要文件已经备份。安装完成后也不要急着联网，先把基础驱动和补丁装好。

三、安装驱动和 .NET Framework 4

驱动建议按下面的顺序安装：

1. 芯片组驱动；
2. 有线网卡或无线网卡驱动；
3. 核芯显卡和独立显卡驱动；
4. 声卡、触控板、读卡器等其他驱动。

这次安装显卡驱动时，安装程序提示缺少 .NET Framework 4。可以从微软官方下载 .NET Framework 4 独立安装程序，安装并重启后，再继续安装显卡驱动。

驱动全部安装完成后，可以打开“设备管理器”，检查是否还存在带黄色感叹号的设备。

四、先安装 Windows 7 汇总补丁

刚装好的 Windows 7 SP1 与现在的网络环境相差太远，直接使用 Windows Update 往往会失败。可以先手动安装微软的便利汇总补丁 KB3125574，它包含了 Windows 7 SP1 发布之后到 2016 年 4 月之间的大部分更新。

这里有一个容易遗漏的前置条件：安装 KB3125574 之前，必须先安装 2015 年 4 月的服务堆栈更新 KB3020369。

推荐顺序如下：

1. 在 Microsoft Update Catalog 中下载并安装 KB3020369，然后重启；
2. 下载并安装 KB3125574，然后再次重启。

下载时要认准 Windows 7，并根据当前系统选择 x86 或 x64 包，不要误下成 Windows Server 2008 R2 版本。安装 KB3125574 还需要给系统盘预留至少 4 GB 可用空间。

如果提示“此更新不适用于你的计算机”，优先检查以下几项：

• 当前系统是否已经是 Windows 7 SP1；
• 下载的补丁架构是否与系统一致；
• 前置补丁是否已经安装；
• 该补丁是否已经安装，或被更新的补丁取代。

五、安装 IE11

系统补丁安装完成后，可以安装微软提供的 Windows 7 版 IE11（64 位）。IE11 本身也已经停止支持，这里安装它主要是为了改善老系统的网页兼容性，并补齐部分旧软件依赖，不建议把它当作日常浏览器。

如果刚装好 Windows 7 时打不开补丁目录或下载页面，可以在另一台正常联网的电脑上先把安装包下载好，再通过 U 盘复制过去。不要为了打开网站而关闭证书校验或安装来源不明的所谓“证书修复包”。

六、解决 Windows Update 的 80072EFE 错误

如果运行 Windows Update 时出现 80072EFE，可以参考这篇 Reddit 讨论，手动安装下面三个补丁：

1. KB4490628：2019 年 3 月服务堆栈更新；
2. KB4474419：SHA-2 代码签名支持更新；
3. KB3138612：Windows Update Client 更新。

建议按上面的顺序逐个安装。遇到提示需要重启时就先重启，再继续安装下一个；三个补丁安装完毕后，再次重启并运行 Windows Update。

如果 Windows Update 仍然失败，可以先确认系统时间、时区是否正确，并检查有线或无线网络是否稳定。由于 Windows 7 已结束支持，即使更新功能恢复，也不能把它理解为系统重新获得了完整、持续的安全支持。

七、浏览器选择

Windows 7 能使用的最后一个 Chrome 大版本是 Chrome 109，后续版本已经不再支持 Windows 7。如果确实需要，可以安装 109 版本，但它已经不能获得新的功能和安全修复。

因此，Chrome 109 只适合临时访问普通网页或兼容老系统，不要用它登录网银、邮箱等重要账号。离线安装包也应尽量从可信渠道取得，并核对数字签名，不建议随便从软件站下载所谓的“绿色版”或“特别版”。

八、完整安装顺序

最后把这次的操作顺序汇总一下：

1. 备份原系统中的重要数据；
2. 下载 Windows 7 SP1 镜像并用 UltraISO 制作启动 U 盘；
3. 提前准备联想 G400 驱动、系统补丁和离线安装软件；
4. 安装 Windows 7 SP1；
5. 安装芯片组和网卡驱动；
6. 安装 .NET Framework 4，再安装显卡及其他驱动；
7. 依次安装 KB3020369 和 KB3125574；
8. 安装 IE11；
9. 遇到 80072EFE 时，依次安装 KB4490628、KB4474419 和 KB3138612；
10. 根据需要安装 Chrome 109，并尽量减少这台机器的联网用途。

这次最深的感受是，给老电脑装 Windows 7，真正花时间的并不是系统安装本身，而是提前准备驱动、补齐系统组件和解决更新问题。把驱动和补丁都提前放进 U 盘，整个过程会省心很多。

参考资料

• Windows 7 安装与更新问题讨论
• Windows 7 更新相关整理
• Microsoft Update Catalog
• Google Chrome 浏览器系统要求