企业官网建设流程全解析

16G 显卡跑 40GB 大模型这事，我一开始也觉得是痴人说梦，直到我把显卡坞接上笔记本、把模型量化文件拉下来那一刻，才发现这条路虽然窄，但真能走通。折腾了差不多一个周末，我总算让一台只有 16G 显存、平时只能打游戏的笔记本，在本机跑起了 40B 参数级别的大模型。这篇文章不是标题党式的炫耀，而是把整套实验的硬件选型、显存突破思路、部署流程、实测数据和踩坑记录全部摊开，给同样被显存卡住的朋友一条可以复现的路径。

这件事真正解决的需求很简单：我不想为了跑一个大模型就换掉整台电脑，也不想把私有数据传到云 GPU 上。显卡坞这种方案，恰好能让我用相对小的代价，给一台笔记本补上大模型本地部署最缺的那块拼图——显存容量。我会从最初的动机讲起，把每个关键选择的理由也一并说清楚。

1. 为什么我想用16G显卡硬啃40GB大模型：一个被显存限制逼出来的念头

1.1 16G显存玩家的尴尬处境

先交代一下背景。我主力机是一台前两年的游戏本，内置显卡是 16G 显存。这个配置放到今天看，打游戏、剪视频、跑 SD 绘图都还够用，唯独本地跑大模型这件事，总让我有种"差一口气"的感觉。大模型的显存需求是硬性指标：一个 40B 参数的模型，如果用 FP16 精度存储权重，每个参数要占 2 字节，算下来就是 80GB 显存，8 张 4090 才勉强塞下。就算用 INT8 量化，40GB 打底，INT4 量化后还是逼近 20GB 到 25GB。

这个数字对 16G 显存来说，确实是一道越不过去的墙。但问题就出在"墙"的位置上：现在大量优秀的开源模型，比如 Mixtral-8x7B、Qwen2.5 系列、Llama-3 系列的中大杯版本，参数规模恰好落在 30B 到 70B 这个区间。它们多多少少都能给出让人惊艳的对话质量，可显存门槛也卡在 16G 到 40G 的尴尬地带。我身边不少做本地部署的朋友，几乎都在这个瓶颈上纠结过：再买一张 24G 显存的卡要花大几千，换整机更是心疼，可 16G 又跑不动心仪的模型。

1.2 "40GB 大模型"到底指什么

在聊实验之前，我得先把标题里"40GB 大模型"这个概念拆清楚。它其实有两种常见理解：一种是参数规模 40B（400 亿参数）量级的模型，另一种是量化后的模型文件体积达到了 40GB 左右。我的实验里把这两种都覆盖了，但日常主力测试对象是 Mixtral-8x7B-Instruct，参数量约 46.7B，属于典型的 40B 级模型；它经过 GGUF Q4_K_M 量化后文件大约 26GB，虽然不是严格的 40GB，但参数量级和实际部署难度，已经能代表"40GB 大模型"这个标签。

我另外还做了一次极限压测，用的是 Llama-3-70B 的 Q4_K_M 量化版，GGUF 单文件将近 40GB，这算是字面意义上真正撞到 40GB 大关的模型。两种模型配合 16G 显存能跑出什么效果，是这次实验最核心的问题。

不同参数规模模型在常见精度下的显存需求，我简单整理了一张表：

注意，上面的权重体积还没算推理时动态增长的 KV Cache。所以结论很清楚：16G 显存要跑 40B 级模型，唯一现实路径就是"量化 + 分层卸载到系统内存"，这也是我后来真正采用的技术方案。

1.3 为什么我盯上了显卡坞

显卡坞，也就是 eGPU，本质上是把一张桌面显卡通过外接接口（雷电或 OCuLink）接到笔记本上。这玩意早期被玩家用来给轻薄本外接显卡打游戏，后来也有做渲染的同行用来扩展 CUDA 算力。但大模型推理这件事对显卡的需求很特别：它不要求极高的帧率或极端的浮点吞吐，而是要求"显存装得下模型、整数算力够跑推理、显存带宽不拉胯"。这三样东西，显卡坞恰好都能提供。

更关键的是，显卡坞能让我直接绕开笔记本"换不了内置显卡"的死结。我不需要换整机，只需要添置一个扩展坞加一张 16G 显存的显卡，就能把笔记本变成一台能跑中大模型的本地推理机。而且显卡坞还有一个隐藏优势：它是外置设备，显卡的热量和噪音都在机身外面，笔记本本体不会被烤成铁板。对长期跑模型的人来说，这点体感差别很大。

当然我也清楚，显卡坞不是银弹，它的 PCIe 带宽远不如显卡直插主板，这在我的实验中会造成明显的性能瓶颈。但"能不能跑"和"跑得多快"是两回事，这篇文章就是想把这两件事都量化出来。

2. 显卡坞与显卡选型：这套硬件怎么搭才不翻车

2.1 两种主流显卡坞方案：雷电和 OCuLink

做显卡坞实验，第一个要碰的问题是接口选择。市面上能买到的成品显卡坞大致分两类：雷电坞和 OCuLink 坞。它们和解 PCIe 设备外接时的带宽差距非常大，直接影响推理速度。

• 雷电3硬盘坞：PCIe 3.0 x4 通道，理论带宽 22Gbps，实际有效带宽大概 2.6GB/s 到 2.8GB/s。胜在通用性好，绝大多数笔记本都有雷电口，即插即用。
• 雷电4：名义上 40Gbps，但用于 PCIe 数据传输的部分实际有效带宽和雷电3 差别不大，约 3GB/s，主要是视频、USB 等其他协议共享了带宽。
• OCuLink（SFF-8611）：通常是 PCIe 4.0 x4，理论带宽 64Gbps，有效带宽 7GB/s 到 8GB/s。带宽是雷电的 2 到 3 倍，但需要笔记本或主板原生支持，很多游戏本没有这个口，要自己加转接卡。

从大模型推理的角度看，这个带宽差距会直接反映在混合推理速度上：因为模型权重不可能全部塞进 16G 显存，总有一部分要放在系统内存里、由 CPU 计算，GPU 和 CPU 之间每层都要交换激活值，这些数据都要走显卡坞这条"水管"。水管越粗，整体速度越快。我手上的这台笔记本没有原生 OCuLink 口，所以本次实验主力用的是雷电 4 显卡坞，另一个朋友借给我一套 OCuLink 方案做了二次对比。实测下来，两者的速度差异确实不小，后面数据部分会细说。

2.2 16G 显存显卡怎么挑

选哪张 16G 显存的显卡，也是这次实验的重点。市面上的选择其实不多，目标大致锁定在三类：新卡里的 RTX 4060 Ti 16G，中高端一点的 RTX 4080（16G），以及上一代的 RTX 3080/3080 Ti（二手居多）。我最后选的是 RTX 4060 Ti 16G，理由主要有三条。

第一，功耗。显卡坞外置供电是有上限的，很多雷电坞配备的电源只有 330W 到 500W。4060 Ti 的 TGP 只有 160W 到 180W，对显卡坞的供电压力小，稳定性高。4080 虽然性能更强，但功耗 320W，很多显卡坞要么带不动，要么在高负载下会触发电源保护，跑长任务反而掉链子。第二，显存容量达标。4060 Ti 16G 是 16G 显存方案里性价比最高的新卡，显存位宽 128bit，显存带宽约 288GB/s，听起来不高，但在"显存容量优先"的推理场景里，容量比带宽更关键。第三，CUDA 生态。大模型推理软件栈（llama.cpp、Ollama、Torch）对 NVIDIA 的支持最成熟，我没有精力去折腾其他平台的兼容性问题。

选卡的时候还有一个细节容易被忽略：尽量选公版或者双风扇短卡。显卡坞内部空间有限，长卡塞进去散热风道会堵，跑长上下文时显存温度一高，推理速度就会明显下降。我第一版用的就是一块三风扇长卡，后来换成双风扇短卡，温度直接降了七八度，速度也稳了不少。

2.3 接上显卡坞后，先确认它真的在干活

显卡坞装好后，不要急着跑模型。Windows 系统对 eGPU 的识别有时候不靠谱，尤其是笔记本自带独显和核显都开着的情况下，模型可能默认跑在了某个错误的 GPU 上。我在这一步的习惯是打开命令行，跑一句 nvidia-smi，确认外接显卡被系统正确枚举出来，显存容量识别为 16G，再往下走。

另外，在显卡坞方案里，笔记本的内置独显和核显通常还处于激活状态，系统里会出现"多张显卡共存"的局面。这既是资源冗余，也是后续踩坑的主要来源，我会在后面的踩坑章节详细讲它那一箩筐问题。现在你只需要记住一个原则：跑所有大模型推理任务之前，先看清楚 nvidia-smi 里当前进程挂在哪个 GPU 上，别让 Windows 替你"智能"分配。

3. 让40GB模型装进16GB显存的底层思路：量化、分层卸载与内存换显存

3.1 先弄懂模型权重到底占了多少空间

很多人觉得模型大就大在层数多、参数多，其实对显存影响最直接的，是"精度 × 参数量"这个乘积。我们常说的 FP16 或 BF16，是指每个参数用 16 位二进制浮点数表示，1 个参数占 2 字节。于是：40B 参数 × 2 字节 = 80GB。而 16G 显存连零头都不够。这就是为什么哪怕买了 24G 显存显卡，面对 40B 级模型照样力不从心的根本原因。

量化就是把这个数字压下来。原理不复杂：浮点数本来是连续的，量化把它映射到有限的离散值上，比如 INT8 每个参数 1 字节，INT4 每个参数 0.5 字节甚至更少。损失是精度有所下降，收益是模型体积成倍缩小。对大模型推理来说，权重精度从 16bit 降到 4bit，回答质量损失通常在可接受范围内，尤其是对话、摘要、代码补全这类任务，主观感受差别不大。这几乎是本地部署领域默认的选择。

开源社区里，GGUF 格式是目前最主流的量化载体，配合 llama.cpp 生态使用。GGUF 提供多档量化等级，我挑几个最常见的列一下：

我的实验主力采用 Q4_K_M，原因很直接：在 16G 显存和系统内存带宽有限的双重约束下，Q4_K_M 是"体积、质量、速度"三者之间最平衡的点。再往上到 Q5_K_M，模型体积增加不少，推理时 CPU 层计算压力也变大，速度会明显变慢，而质量提升却未必感知得到。

3.2 分层卸载：显存不够时把模型拆开放

光量化还不够，26GB 的 Mixtral Q4 依然超过 16G 显存。这时候就要请出 llama.cpp 生态里的核心机制：GPU offload（分层卸载）。它的原理是，Transformer 模型本质上是一层层串行计算的，推理某一层时，只有这一层的权重需要待在显存里，其他层可以让出空间。所以我们可以把模型的前 N 层权重放进 GPU，剩下的层放在系统内存里由 CPU 计算，两层之间的激活值通过 PCIe 总线传输。

这个机制解释了我为什么非要折腾显卡坞：如果没有显卡坞，16G 显存只能放下大约 40% 的层；有了显卡坞，虽然还是放不下全部层，但 GPU 可以稳定承担前半程的计算，剩下的 CPU 承接后半程，两者协同把整个模型跑完。换句话说，显卡坞让我把 16G 显存和笔记本的 64G 系统内存"拼接"成了一个逻辑上的大显存池。

具体分配多少层给 GPU，是整场实验里最需要反复调优的参数。llama.cpp 里的参数名是 --n-gpu-layers（或缩写 -ngl），取值可以从 0 到模型总层数。取值 0 等于纯 CPU 推理，取值等于总层数则要求显存能装下整个模型。16G 显存下，目标不是把全部层塞进去，而是把——塞得下、又不会 OOM 的——最大层数找出来。一般来说，GPU 层数越高，速度越快；但接近显存上限时，随时可能触发 CUDA out of memory，所以我会留出 1GB 到 2GB 的显存余量给 KV Cache 和 CUDA context。这个余量到底留多少，后面第 5 章的实测表里能看到。

3.3 系统内存带宽是第二个隐藏瓶颈

既然有相当一部分层要放在系统内存里用 CPU 算，那么笔记本的系统内存带宽就成了第二大瓶颈。CPU 层推理时，每个 token 都要把权重从内存中读出来做矩阵乘法，内存带宽直接决定 CPU 层的计算速度。还是拿水管打比方：显存带宽是 GPU 那根粗水管，系统内存带宽就是 CPU 那根细水管；整体流速取决于最细的那根。

所以这次实验里，我特意把笔记本的内存配置从单通道 16GB 升级成了双通道 64GB DDR5，带宽从大约 40GB/s 翻到接近 80GB/s。别小看这个变化，同样跑 40B 级模型，单通道内存时 CPU 层速度会慢到不可用，双通道后才有资格谈论"可接受"。

另外，KV Cache 也会吃显存/内存。上下文越长，KV Cache 越大，而且它必须常驻在快速存储里。计算公式大约是这样的：KV Cache 体积 ∝ 层数 × 注意力头数 × 上下文长度 × 字节数。实操中我不用算那么细，只需要记住结论：上下文从 4096 提到 8192，显存占用会明显上涨，对应的 GPU 层数就得往下调。这是后续调参时最常见的连锁反应。

4. 实测部署全流程：从下载模型到跑通第一句话

4.1 环境与工具选择：Ollama 还是 llama.cpp

软件层面，我最初在 Ollama 和 llama.cpp 之间犹豫了一下。Ollama 的优势是开箱即用，一条命令就能把下载、量化加载、推理服务全部搞定，还自带 OpenAI 兼容 API 接口，适合快速验证；llama.cpp 则更底层，参数明细完全可控，适合调优和做压测。两者的推理内核其实是同一套（llama.cpp 的底层），所以性能差异不大，只差别在封装程度上。

最终的方案是两手都上：日常跑对话任务用 Ollama，方便我接一些脚本和 API 请求；做性能压测和分层参数实验时，用编译好的 llama.cpp 命令行工具，方便直接传 -ngl、-t、-c 等参数。如果你只是想复现"让 16G 显卡跑 40B 模型"，用 Ollama 就够了；如果你打算研究各项参数的边际收益，那一定得会 llama.cpp。

环境上，原生 Windows 就可以。llama.cpp 在 Windows 下有预编译的 CUDA 版本发布包，Ollama 也有 Windows 安装包，两者都不需要 WSL2。唯一要注意的是 NVIDIA 驱动版本要新一点，我建议至少 535 以上，避免 CUDA 运行时兼容性问题。

4.2 模型下载：GGUF 文件怎么拿

Ollama 的做法最简单，直接一句ollama pull就能从它的模型库拉取现成的量化模型。我用的命令是：

ollama pull mixtral:8x7b-instruct-q4_K_M

这条命令会把 Mixtral-8x7B 的 Q4_K_M 量化版拉到本地。Ollama 的模型库里备好了大量 GGUF 量化版本，省去了自己找量化文件的麻烦。如果你用的是 llama.cpp 命令行，那就要去 Hugging Face 社区的 GGUF 仓库下载对应文件，下载时注意看清文件名里的量化标记，别下错成 Q2 或者 Q8。这一步没什么技术含量，但最容易出错：文件名一个字符不对，模型效果天差地别。

下载完成后，用 Ollama 跑起来只需要一句：

ollama run mixtral:8x7b-instruct-q4_K_M

首次运行会加载模型并输出一个可交互的对话窗口。到这里，"能跑"这件事已经成为现实，接下来才是真正的调优。

4.3 关键参数调优：显存余量、层数、上下文和线程

要让模型跑得又快又稳，得理解四个关键参数：

• num_gpu（Ollama 环境变量OLLAMA_GPU_LAYERS，llama.cpp 参数-ngl）：放进 GPU 的层数。
• num_ctx（-c）：上下文长度，直接影响 KV Cache 大小。
• num_thread（-t）：CPU 线程数，影响 CPU 层计算速度。
• flash_attn：是否启用 Flash Attention 优化，可以减少 KV Cache 占用。

我给的初始配置是这样（Ollama 的 Modelfile 或 llama.cpp 命令行都适用）：

# llama.cpp 命令示例 llama-cli -m /path/to/mixtral-8x7b-instruct-q4_K_M.gguf \ -ngl 24 -c 4096 -t 8 --temp 0.7

这里的-ngl 24表示把 24 层模型放进 GPU。Mixtral 这类 40B 级模型的 transformer 层总数通常在 32 层左右，24 层意味着大约 75% 的层在 GPU 上，剩下 8 层在 CPU。16G 显存实际能承载多少层，要看两件事：一是模型每层权重的体积，二是 KV Cache 和 CUDA context 占用多少显存。我在实测中稳定跑过的最优值是 24 层，再往上加到 26 层时，虽然 4096 上下文下还能勉强启动，但稍微拉长上下文或者连续多轮对话就会触发 OOM。所以最终日常配置就定格在 -ngl 24、-c 4096。

线程数-t这里也有讲究。不要盲目开满，物理核心数才是有效上限。我的笔记本是 8 核 16 线程，实测-t 8反而比-t 16稳定，因为超线程对矩阵乘法这种密集计算帮助不大，反而可能导致线程调度开销增大、CPU 温度升高。

4.4 第一次跑通的瞬间

第一次真正跑通的场景我记得很清楚。模型加载了大约半分钟（主要是把 26GB 的量化权重从磁盘读进内存），然后控制台出现提示符，我打了句"你好，介绍一下你自己"。几秒的停顿之后，token 开始一个一个往外蹦，速度肉眼可见地慢，但确实是在连续输出。那个瞬间的成就感要超过在云 GPU 上跑跑几十亿参数模型的感觉——因为整个推理过程完全发生在我这台不到两万的笔记本上，没有任何外部依赖。

不过，"能跑"和"好用"之间还是有距离的。第一轮对话的速度大约在每秒 7 个 token 左右，也就是我说完一句话，它要停一会儿，然后像早年打字机一样慢慢回复。这种体验显然不是给追求流畅交互的人准备的，但对于本地私有化推理、后台批量处理、代码调试这些场景，已经完全够用了。

5. 实测性能数据：16G显卡坞到底能跑多快

5.1 不同显存分配下的速度对比

调参阶段我最关心的是"GPU 层数取多少，速度收益最明显"。所以我在 Mixtral-8x7B Q4_K_M 上做了一组对比实验，上下文固定 4096，CPU 线程固定 8，只改-ngl值。结果如下：

看到这个表，结论很清楚：GPU 层数从 16 提到 24，速度提升了约 67%，这是非常可观的边际收益；但从 24 再往上，收益就变得很有限，反而要承受 OOM 风险。原因在于，推理速度由 GPU 层和 CPU 层共同决定，而最慢的那一段才是瓶颈。当 GPU 已经承担了大部分层时，瓶颈逐渐从"CPU 层计算"转移到"GPU 与 CPU 之间激活值传输"以及"系统内存带宽"上，这时再加层数不过是拆东墙补西墙。

所以我把这条曲线的"拐点"当成了日常使用配置：-ngl 24 -c 4096 -t 8。用这套配置，7.2 t/s 的生成速度，配合首 token 延迟大约 3 到 5 秒，已经能支撑基本的对话和文档摘要任务。

5.2 70B极限压测：字面意义的40GB模型

为了对标题里的"40GB"有个交代，我还用 Llama-3-70B 的 Q4_K_M 量化版（文件约 39.6GB）做了极限测试。这个量级的模型，说实话已经不是 16G 显卡坞方案该碰的场景，但实验结果很有参考意义：

• 配-ngl 16时，生成速度只有大约 1.1 t/s，相当于每个字都像挤牙膏一样蹦出来，短对话还能忍，超过 200 个字就让人焦虑。
• 把-ngl降到 12，速度反而略低，因为更多层落在 CPU 上，系统内存带宽撑不住了。
• 把-ngl提高到 20，显存占用接近 16G 上限，上下文一长就 OOM，根本跑不完一段完整回复。

这说明一个硬道理：40GB 文件级别的模型，在 16G 显存 + 显卡坞的方案下，属于"能跑但不可用"；而 40B 参数级模型（如 Mixtral）的量化版，在 16G 显存 + 显卡坞的方案下，属于"慢速但可用"。如果你想日常用，请瞄准后者。

5.3 显卡坞带宽对速度的拖累到底有多大

为了判断显卡坞到底"拖累"了多少性能，我把同一张显卡从雷电 4 坞里拆下来，装进朋友的台式机，跑了一个小时对比。同样的模型、同样的参数、同样的上下文长度，台式机直插 PCIe x16 时速度大约 9.4 t/s，而我用雷电 4 显卡坞只有 7.2 t/s。差距约 23%。

这 2 t/s 的差值，主要就是 PCIe 带宽换来的代价。如果把雷电 4 换成 OCuLink 方案（有效带宽接近 8GB/s，约为雷电 4 的 2.5 倍），速度立刻回到了约 9.0 t/s。所以如果你有条件，比如笔记本带 OCuLink 口，或者愿意 DIY 转接板，显卡坞的性能损失会小很多。

我个人的判断是：对"能跑与否"来说，显卡坞的带宽损失无关紧要；对"体验好不好"来说，带宽确实重要。雷电 4 坞属于"刚够用"，OCuLink 属于"体验更佳"。具体投入多少，取决于你愿意为 1 到 2 t/s 的速度提升多掏多少钱。

5.4 上下文长度对性能的影响

另一个容易被忽略的变量是上下文窗口。我把同一套最优配置（-ngl 24）在不同-c值下跑了一遍 Mixtral：

KV Cache 越大，留给权重的显存就越少，等于变相要求降低-ngl，而降低-ngl又会拖慢速度。所以上下文 8192 以上时，我用的是第二套配置：-ngl 20 -c 8192，速度虽降到 5.4 t/s，但整体更稳。日常使用我建议就保持在 4096 到 8192 之间，别贪长。

6. 踩坑实录：显卡坞跑大模型最容易翻车的几个地方

6.1 混合显卡陷阱：程序到底跑在哪张卡上

第一个坑是我踩得最狠的。笔记本通常有核显和独显，接上显卡坞又多了一张外接显卡。Windows 的 WDDM 模型会对多 GPU 做渲染负载均衡，可大模型推理不是靠 Windows 的图形调度来选卡的，它依赖 CUDA 运行时去枚举设备。结果就是，同一套命令，一会儿跑到内置独显上，一会儿跑到外接显卡上，甚至可能跑到核显上（虽然核显没有 CUDA 能力，理论上不会，但在某些驱动异常时会识别出错）。

排查链路是这样的：先在 nvidia-smi 里看进程列表，发现推理进程占用的 GPU UUID 不是显卡坞那一张。然后查 Ollama/llama.cpp 的日志，发现它枚举到了多张显卡，选卡逻辑并不总是挑外接显卡。最终我通过设置 CUDA 环境变量把推理进程锁定到显卡坞上的 GPU，才彻底解决。具体做法是：

set CUDA_VISIBLE_DEVICES=1

这个数字 1 不是固定的，需要先跑nvidia-smi看显卡坞对应的编号。设置后，进程只会看到那一张显卡，不会再乱跑。如果你用 Ollama，还需要在服务启动脚本里加上这个环境变量，确保后台服务继承。

6.2 OOM 的假象：显存明明没满，却报 out of memory

第二个坑，是我盯着 nvidia-smi 看了一个小时才反应过来的：明明显存显示还剩 1.5GB，Ollama 却报了 CUDA out of memory。原因是，nvidia-smi 显示的只是"当前占用"，而 CUDA 运行时会预先申请显存池和 context，它需要的是"剩余显存中可连续分配的大块空间"，碎片化会导致明明有空间却申请不到大块内存。

排查思路是这样的：先把上下文长度降下来，比如从 8192 降到 4096，释放 KV Cache 对显存的挤占；再把-ngl降两层，留出更多显存余量；如果还报错，就检查显存里是否有残留的僵尸 CUDA 进程，可以用taskkill /F /IM ollama.exe重启整个推理服务，把显存彻底清空。这里要养成一个好习惯：不要用nvidia-smi的"剩余显存"作为是否 OOM 的判断依据，要用"进程实际申请的显存 + 3GB 安全余量"来估算。

6.3 显卡坞热插拔导致驱动假死

显卡坞支持热插拔，这个"支持"指的是硬件层面允许，不代表推理软件能扛得住。我有一次图省事，在模型加载过程中直接把雷电坞线拔了，结果整个 NVIDIA 驱动直接假死，所有 CUDA 进程崩溃，重启驱动还不行，只能重启电脑。如果是 Windows 下，重则蓝屏，轻则设备管理器里出现一个感叹号，外接显卡彻底消失。

从那以后我给自己立了一条规矩：任何涉及显卡坞的插拔操作，必须先退出大模型推理进程、再右键安全弹出显卡坞、然后断电。你以为省下的 30 秒，实际付出的代价是 10 分钟重启和可能损坏的驱动状态，不划算。

6.4 量化等级的选择反复：不要贪高也不要太低

我第一次下载时图新鲜，直接拉了个 Q8_0 量化版，32GB 文件。加载倒是成功，但速度只有 2.8 t/s，CPU 层比重太大，完全没法聊天。后来换成 Q2_K，速度快倒是快了（超过 10 t/s），但回出来的答案错别字多、逻辑混乱，质量明显不能接受。来回试了三次，才意识到一个朴素的结论：对 16G 显存 + 显卡坞这种配置，Q4_K_M 几乎是唯一合理的起点，别再折腾其他档位。速度不满意，优先降上下文、调线程，再不行就升级硬件；质量不满意，优先看提示词工程，别轻易升量化档。

还有一个细节：llama.cpp 里的--temp参数也会影响回答质量。如果跑量化模型感觉输出发散，试试把温度调低到 0.5 到 0.6，代价是多样性下降，但稳定性好很多。这不算 bug，属于大模型推理的基本操作习惯。

7. 实验结论：这套方案适合谁，不适合谁

7.1 16G 显卡坞不是魔法，但它把"不可能"变成"慢速可用"

跑完整个实验，我对这套方案的评价是：它没有把 40GB 大模型变成流畅的原生体验，但它确实让普通玩家在不动整机的前提下，摸到了 40B 级模型的底部能力。7 t/s 的生成速度，足够支撑私有化聊天、文档总结、代码生成辅助、批量离线推理这些非交互密集型场景。我的日常用法是把它接进本地 API 服务，配合脚本做日志摘要和情报整理，慢一点无所谓，关键是数据全程不出本机。

但我也必须诚实：如果你想要的是一边和模型聊天一边等它流畅回复的"ChatGPT 式体验"，这套方案达不到。7 t/s 和 30 t/s 之间的差距，是肉眼可见的等待感差异。另外，Llama-3-70B 这种真正 40GB 文件的模型，在这套方案下只能算"能开机"级别，不适合作为主力模型。

7.2 给同样配置的人三条优化建议

如果你准备复刻这个实验，我给三点最实用的建议。

第一，内存升级优先于显卡升级。在 16G 显存固定不变的前提下，笔记本的系统内存从单通道 16GB 换到双通道 64GB，对 CPU offload 推理速度的提升，比把显卡从 4060 Ti 换成 4070 Ti 更明显。内存带宽决定了 CPU 层的速度上限，别忽视它。

第二，显卡坞接口的优先级是 OCuLink > 雷电 4 > 雷电 3。如果预算有限，宁可买二手 OCuLink 坞加转接卡，也不要选雷电 3 的便宜坞，那个 2.6GB/s 的实际带宽会把你逼疯。当然，前提是笔记本有对应的改装条件。

第三，所有参数调整按照"量化等级（固定 Q4_K_M）→ 上下文长度（从 4096 开始）→ GPU 层数（往最大不 OOM 逼近）→ CPU 线程数（用物理核心数）"的顺序来。这个顺序能让你在最短时间内找到一个稳定可用的配置，而不是像我一样反复横跳。

7.3 一点个人体会

折腾这个实验之前，我以为大模型本地化最大的障碍是钱，买不起大显存显卡。跑完之后我意识到，最大的障碍其实是观念——总觉得显存不够就跑不了，其实"量化 + 分层卸载 + 显卡坞"这套组合拳，已经把这个门槛压到了很多普通玩家的伸手范围内。16G 显存跑 40GB 大模型，不是神话，但确实是一个值得记录的、被软件优化和硬件扩展共同推倒的墙。

现在这台笔记本还插着显卡坞，里面跑着一个 Mixtral，开着 OpenAI 兼容端口，安安静静地处理我白天留下的日志。它不快，但我私有，这就够了。