Written with AI assistance from the source video. The video is the authority.
10:47Better Stack
Log in to leave a comment
No posts yet
你大概有过这种体验：看 YouTube 教程在终端输入模型安装命令后，屏幕直接卡死。搭载 8GB 或 16GB 内存的老款 MacBook 或入门级笔记本上本地 LLM 崩溃，原因并不是算力核心不够，真正的根源在于内存带宽极度狭窄的情况下，运行时试图读取超出极限的数据。只要测算设备带宽并调整上下文大小，即使在老旧设备上也能顺利跑起代码辅助模型。
最新的 macOS 和 Ubuntu 会阻止用户直接向系统 Python 中安装软件包。一旦执行 pip install 就会报出 PEP 668 错误（error: externally-managed-environment）并中止。如果嫌麻烦而强制加上破坏系统保护的参数（--break-system-packages），以后操作系统的基础工具紊乱了就只能重装。因此，我们应该使用支持独立虚拟环境隔离的 pipx 来安装诊断工具。
通过隔离部署由 Alex Jones 开发的开源诊断工具 llmfit，来提取我们自身的硬件规格。
`bash
brew install pipx
pipx ensurepath
pipx install llmfit
mkdir -p ~/local-ai-workspace/{configs,logs,scripts}
llmfit --json system > ~/local-ai-workspace/logs/system_specs.json
`
在终端完成这一流程后，无需触碰系统库，只需 1 分钟就能将设备的内存容量与内存总线信息整理到 system_specs.json 文件中。
本地大语言模型吐字的过程，本质上是观察前面生成的词元（Token）来推导下一个字并顺序输出的。每一步操作都需要从内存总线中完整读取模型数十亿个权重。也就是说，实际体验的速度不取决于 GPU 频率，而取决于内存带宽的数值。
每秒词元输出速度（TPS）可通过以下公式计算：
TPS approx rac{ ext{Memory Bandwidth (GB/s)}}{ ext{Model Weights Size (GB)} + ext{KV Cache per Step (GB)}} imes eta公式中的 代表运行时的有效带宽效率（MBU）值，通常在 0.65 左右。
如果在带宽约为 45GB/s 的普通 DDR4 台式机内存上直接运行经过 4 位量化的 7B 模型（约 4.5GB），其运算速度将停留在 。生成的文字一顿一顿的，用来辅助实际工作简直让人抓狂。相反，如果部署到拥有 288GB/s 带宽的 RTX 4060 8GB 显卡，或者带宽超过 100GB/s 的 M 系列统一内存上，则可以达到每秒 35 到 40 个词元，轻松超越实时的打字速度。
确认自己设备的配置后，可供选择的模型基本上分为两类：
Qwen2.5-Coder-7B-Instruct (Q4_K_M)。在 16GB 统一内存的 MacBook 或拥有 8GB VRAM 的独立显卡上可以跑出 35 TPS 以上的速度。Llama-3.2-3B-Instruct (Q4_K_M)。即便在低功耗笔记本的 DDR4 环境下也能节省内存，并稳定输出 15 TPS 左右的速度。好不容易把模型跑起来，可只要一问一答几次，进程就会悄无声息地关闭。终端里打印出的 Exit Code 137 意味着操作系统的内存管理内核（Linux 的 OOM-Killer 或 macOS 的 JetSam）因为内存不足而强制终止了进程（SIGKILL）。
如果使用的是外接 GPU，还会发生更让人头疼的无声 CPU 回退（Silent CPU Fallback）。当超出 VRAM 极限时，系统并不会直接杀死进程，而是将部分计算层转移到慢吞吞的系统内存中，此时 GPU 占用率会断崖式下跌，速度慢得像蜗牛一样降至每秒 1 个词元。
罪魁祸首是随着对话延长而不断蚕食内存的 KV（Key-Value）缓存。以 Llama-3 架构为例，如果将上下文开放到 32,768（32K）个词元，除了 4.5GB 的权重之外，仅缓存内存就会额外增加 4.0GB。这在 8GB 设备上是绝对会崩溃的结构。如果将长度限制在 4,096（4K）个词元，缓存容量就会缩减至 512MB，从而确保在 8GB 环境下也不会闪退。
以下是检查当前状态并固定上限的步骤：
首先在终端输入 ollama ps。如果 PROCESSOR 一栏显示的不是 100% GPU，而是像 30%/70% CPU/GPU 这样被拆分，说明 VRAM 已经溢出并被挤压到了低速内存中。
接下来创建配置文件来锁定上下文大小。打开 ~/local-ai-workspace/configs/Modelfile.coder 并写入以下内容：
`dockerfile
FROM qwen2.5-coder:7b
PARAMETER num_ctx 4096
PARAMETER temperature 0.2
`
在终端使用自定义模型进行构建：
`bash
ollama create custom-coder:7b -f ~/local-ai-workspace/configs/Modelfile.coder
`
构建结束后，macOS 用户可以在终端输入 sudo purge 来清理磁盘缓存，Windows 用户则通过 wsl --shutdown 来关闭闲置的 WSL 实例，从而确保至少腾出 2GB 以上的基础可用内存。
为了防止内部源代码或个人项目外泄，需要将模型服务端口绑定到本地回环（127.0.0.1）。
创建 ~/local-ai-workspace/scripts/serve_secure.sh 文件并写入以下代码：
`bash
#!/bin/bash
export OLLAMA_HOST="127.0.0.1:11434"
export OLLAMA_ORIGINS="http://127.0.0.1:*,http://localhost:*"
ollama serve > ~/local-ai-workspace/logs/ollama_runtime.log 2>&1 &
`
运行该脚本后，在终端输入 lsof -i :11434 | grep LISTEN，确认监听地址是否显示为 127.0.0.1:11434。如果看到了外部也可以访问的 0.0.0.0:11434，则必须立即关闭该进程。
集成工具采用 VS Code 插件 Continue.dev。打开其配置文件（~/.continue/config.json），将聊天模型与自动补全模型区分开来：
`json
{
"models": [
{
"title": "Local Qwen2.5-Coder (Chat)",
"provider": "ollama",
"model": "custom-coder:7b",
"apiBase": "http://127.0.0.1:11434"
},
{
"title": "Local Llama3.2 (Summary)",
"provider": "ollama",
"model": "llama3.2:3b",
"apiBase": "http://127.0.0.1:11434"
}
],
"tabAutocompleteModel": {
"title": "Local Autocomplete",
"provider": "ollama",
"model": "qwen2.5-coder:1.5b",
"apiBase": "http://127.0.0.1:11434"
},
"allowAnonymousTelemetry": false
}
`
问答功能分配给刚才限制了上下文的 7B 模型，而 Tab 自动补全则指定使用 1GB 大小的超轻量模型 qwen2.5-coder:1.5b。这样一来，自动补全的延迟就会消失。
验证过程需要在断网状态下进行。关闭 Wi-Fi 进入离线状态后，打开终端直接发送测试请求：
`bash
curl -s -X POST http://127.0.0.1:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "本地隔离网络测试",
"stream": false
}' | grep "response"
`
如果在断网环境下依然能返回正常的 JSON 响应，就说明不依赖外部云服务、完全安全运行在个人笔记本资源内的开发环境已经搭建完成了。