我现在需要解决的问题很具体：在自己的本地开发机上，装一套真正可用的开源模型环境。

不是“能跑一次 demo”，也不是“拉一个最大的模型证明机器还行”，而是要能长期放在日常开发流里用：写代码、总结资料、做轻量数据分析、接本地 API、偶尔试多模态，还不能把机器拖得完全没法干活。

这篇会持续更新。第一版先记录选型判断：Ollama 跑在 Windows 还是 WSL，除了 Ollama 还有哪些更快的推理方式，以及这台机器到底适合装哪些模型。后面会继续追加真实安装、下载、显存占用、token 速度、上下文长度和实际任务表现。

当前机器

这台机器不是专门的 GPU 服务器，而是一台日常开发机：

项目	配置
宿主系统	Windows
WSL 系统	Ubuntu 26.04 LTS
GPU	NVIDIA GeForce RTX 4060 Laptop GPU
显存	8GB
宿主机内存	64GB
WSL 分配内存	32GB，系统内可见约 31GiB
主要用途	编程、WSL 开发、本地模型实验

这个配置的特点很清楚：CPU 和内存足够做日常开发，WSL 里给到 32GB 内存后，模型即使不能完全塞进显存，也还有相对充足的系统内存兜底；但 8GB 显存决定了它不是大模型工作站。模型选择要现实一点，4B 到 9B 是舒适区，12B 可以试，14B 以上就要接受明显变慢、部分层落到内存、上下文不能开太大的现实。

系统已经升到 Ubuntu 26.04 LTS，这对本地大模型工具链会更友好一些。新的基础系统意味着更新的 glibc、Python、编译器、系统库和包仓库，后续编译 llama.cpp、安装 CUDA 相关 Python 包、跑新版推理服务时，遇到旧系统依赖过老的概率会低一些。当然，真正决定推理速度的还是显卡、显存、量化格式和推理后端，系统版本只是把环境摩擦降下来。

Ollama 放在 Windows 还是 WSL

如果只是为了聊天、试模型，或者给 Windows 桌面应用提供本地 API，我更倾向于用 Windows 原生 Ollama。

原因很简单：少一层环境。Windows 版安装后就是后台服务，默认 API 在 http://localhost:11434，Windows 里的客户端、浏览器、Chatbox、Open WebUI、编辑器插件访问都自然。显卡驱动也在 Windows 侧，链路短一点，排错更直接。

但我平时的开发环境主要在 WSL。Python、Node、Rust、数据库客户端、脚本、benchmark、日志分析，大多数都在 Linux 里跑。这个时候把 Ollama 也放在 WSL 有一个好处：脚本调用、本地文件路径、自动化测试都在同一个环境里，少了 Windows 和 Linux 路径互转。

所以我的判断是：

场景	更合适的选择
桌面聊天、简单体验、Windows 客户端调用	Windows 原生 Ollama
WSL 内开发、Python 脚本、模型评测、和 Linux 工具链集成	WSL 里的 Ollama
同一时间跑多个模型服务	只保留一个主服务，避免抢显存

需要特别注意的是，不要 Windows 和 WSL 同时各跑一个 Ollama，然后都去加载模型。8GB 显存本来就紧，再让两个服务互相抢，很容易变成“每个都能启动，但每个都不好用”。

模型文件应该放在哪里

如果 WSL 的虚拟磁盘还在 C 盘，模型很快会把 C 盘吃满。一个 8B 量化模型几 GB，一个 12B 模型接近 8GB，多试几个版本就很夸张。

我更愿意把整个 WSL 实例放到 D 盘，或者新建 Ubuntu 发行版时就用 wsl --import 指定到 D 盘。这样模型缓存、项目依赖、Docker 镜像、向量索引都在同一个 ext4.vhdx 里，文件 IO 比直接放 /mnt/d/... 更自然。

这次实测只使用 WSL 里的 ~/.ollama/models，不复用 Windows 侧已有的 Ollama 模型缓存。这样做的好处是边界清楚：Windows 原生 Ollama 和 WSL Ollama 不会共享同一批模型文件，也不会因为版本、权限、路径或后台服务不同互相影响。

如果长期要放很多模型，最干净的做法仍然是把 WSL 发行版本身迁到空间更大的磁盘，让 ~/.ollama/models 留在 Linux 文件系统里，而不是把高频读写的模型目录直接挂到 Windows 文件系统路径下。

除了 Ollama，还有哪些选择

Ollama 的优势是省事。缺点也很明显：封装层比较厚，很多细节不容易控制。等到需要压榨性能、调上下文、调 GPU offload、测试不同量化文件时，就要看更底层的方案。

llama.cpp

如果目标是单机本地推理，llama.cpp 仍然是最值得认真看的工具。它支持 GGUF，CUDA 路径成熟，参数控制细，适合一边试模型一边观察显存、速度和上下文长度。

我后续会把它作为性能基准：同一个 GGUF 模型，Ollama 跑一轮，llama.cpp server 再跑一轮，看差距到底有多大。

LM Studio

LM Studio 更适合桌面体验。它有 GUI，可以下载模型、调整运行参数，也能开 OpenAI-compatible API。对 Windows 用户来说，它比自己编译 llama.cpp 友好得多。

如果不想先研究一堆命令，LM Studio 是很好的第二选择。它也适合用来快速判断某个 GGUF 模型是不是值得继续折腾。

ExLlamaV2 / TabbyAPI

如果使用 EXL2 或 GPTQ 量化，ExLlamaV2 这类方案在单用户生成速度上通常很强。但它对模型格式和部署方式更挑，不如 GGUF + Ollama / llama.cpp 省心。

我会把它放在后面评估。先把主力模型跑通，再考虑是不是值得为速度切格式。

vLLM

vLLM 适合多并发、高吞吐 API 服务。问题是这台机器只有 8GB 显存，很多 vLLM 擅长的场景并不适合它。

如果是 24GB、48GB 或多卡机器，vLLM 很值得投入；在这台开发机上，它不是第一优先级。

简单排序：

目标	推荐
最快跑起来	Ollama
Windows 桌面体验	LM Studio
单机性能和可控性	llama.cpp
EXL2/GPTQ 高速推理	ExLlamaV2 / TabbyAPI
多并发服务	vLLM

这台机器适合哪些模型

8GB 显存的现实限制是：不要一上来追 30B、70B。能跑和好用是两回事。

我现在会按下面这个顺序测试。

优先级	模型	用途	预期
P0	Qwen3 8B	中文、代码、日常问答	最可能成为主力模型
P0	Qwen3 4B	轻量任务、摘要、分类、脚本辅助	速度快，适合常驻
P1	Gemma 4 E4B	多模态轻量实验	用来验证图片、音频、视频抽帧链路
P1	Gemma 4 12B	高质量多模态、复杂任务	能跑，但可能慢
P1	DeepSeek-R1-Distill-Qwen 7B/8B	推理类任务	适合专项测试，不一定适合默认聊天
P2	Qwen3 14B	更强中文和推理	只能低量化尝试，可能不够舒服
P2	Llama 3.1/3.2 8B	英文通用、生态对比	稳定，但中文未必最好

如果只装一个，我会先装 Qwen3 8B。它最可能在中文、代码、普通问答之间取得平衡。

如果要同时保留一个轻量工具模型，我会加 Qwen3 4B。这类模型不一定最聪明，但日常做摘要、改写、简单代码辅助，响应速度更重要。

如果目标是多模态，就从 Gemma 4 E4B 开始，而不是直接冲 gemma4:12b。12B 模型更有吸引力，但本机 8GB 显存会让它在很多场景下不够轻快。

第一阶段实际安装

第一阶段不追求一次装全，只做能形成判断的最小闭环。这里记录的是这次真实安装的过程，而不是整理过的“理想命令”。

先确认环境：

nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv,noheader
cat /etc/os-release
free -h

这台机器在 WSL 里能看到 RTX 4060 Laptop GPU，显存 8188 MiB，NVIDIA 驱动版本是 572.83。WSL 系统是 Ubuntu 26.04 LTS，可见内存约 31GiB，交换分区 8GiB。

Ollama 官方 Linux 安装脚本默认会写入 /usr/local/bin 并创建 systemd 服务，这一步需要 root 权限。为了先把实验跑起来，我这次没有改系统目录，而是安装到当前用户目录：

mkdir -p ~/.cache/local-llm ~/.local/ollama ~/.local/bin ~/.ollama/logs
wget -c --progress=dot:giga \
  https://github.com/ollama/ollama/releases/download/v0.30.10/ollama-linux-amd64.tar.zst \
  -O ~/.cache/local-llm/ollama-linux-amd64-v0.30.10.tar.zst
tar --zstd -xf ~/.cache/local-llm/ollama-linux-amd64-v0.30.10.tar.zst -C ~/.local/ollama
ln -sf ~/.local/ollama/bin/ollama ~/.local/bin/ollama
ollama --version

这里有一个很实际的坑：Ollama 新版 Linux 包已经是 .tar.zst，如果还按旧的 .tgz 地址手工下载，会遇到 404。官方安装脚本能自动处理这个变化，手工安装时就要自己确认 release asset。

这次安装的是 ollama version is 0.30.10。下载包约 1.3GB，走 GitHub release，实际速度大约 1.6MB/s，用时 13 分 35 秒。后续大模型文件更大，网络质量会直接决定安装体验。

然后用当前用户启动 Ollama 服务：

setsid env \
  PATH="$HOME/.local/ollama/bin:$PATH" \
  OLLAMA_HOST=127.0.0.1:11434 \
  OLLAMA_MODELS="$HOME/.ollama/models" \
  OLLAMA_NO_CLOUD=true \
  OLLAMA_DEBUG=INFO \
  ~/.local/bin/ollama serve > ~/.ollama/logs/ollama-serve.log 2>&1 < /dev/null &

服务启动后，可以先用 curl http://127.0.0.1:11434/api/tags 确认 API 可访问；日志里能看到它识别到了两条推理后端：

CUDA0 NVIDIA GeForce RTX 4060 Laptop GPU, total 8.0 GiB, available 6.9 GiB
Vulkan0 Microsoft Direct3D12 (NVIDIA GeForce RTX 4060 Laptop GPU), total 7.8 GiB, available 7.0 GiB

这说明 Ollama 在 WSL 里已经能用 NVIDIA GPU，不需要先为了 Ollama 单独安装 CUDA Toolkit。nvcc 不存在不影响 Ollama；它影响的是自己编译 CUDA 版 llama.cpp。

llama.cpp 这边先做了 CPU 版构建：

mkdir -p ~/opt
git clone --depth 1 https://github.com/ggml-org/llama.cpp.git ~/opt/llama.cpp
cmake -S ~/opt/llama.cpp -B ~/opt/llama.cpp/build-cpu -DCMAKE_BUILD_TYPE=Release
cmake --build ~/opt/llama.cpp/build-cpu --config Release -j"$(nproc)"

第一次完整 clone 在慢网络下中断了，改成 --depth 1 后正常。构建使用的是 gcc 15.2.0、cmake 4.2.3，生成的二进制在：

~/opt/llama.cpp/build-cpu/bin/

构建日志里可以看到 Qwen3 和 Gemma4 的模型结构已经包含进去，但这只是 CPU 版。后续如果要用 llama.cpp 做公平性能对比，需要补 CUDA 版构建，或者直接用合适的预编译 CUDA 包。

这次计划拉的 Ollama 模型从小到大是：

ollama pull qwen3:4b
ollama pull gemma4:e4b
ollama pull qwen3:8b
ollama pull gemma4:12b

qwen3:4b 的模型 blob 大约 2.5GB。当前下载速度约 2MB/s，属于“能下，但不快”。这里不使用 D 盘上的旧 Ollama 缓存，WSL 里的模型只放在 ~/.ollama/models，避免 Windows 原生 Ollama 和 WSL Ollama 互相影响。

Qwen3 4B 简单测试

qwen3:4b 已经完成下载：

NAME        ID              SIZE
qwen3:4b    359d7dd4bcda    2.5 GB

第一次调用时，Ollama 需要把模型加载到 GPU，冷启动大约 12.3 秒。模型热起来之后，再次调用的加载时间降到 0.13 到 0.16 秒。用一个 120 到 160 token 的中文短任务测试，生成速度大约在 38 到 43 tokens/s，显存占用约 2.7GB 到 2.8GB。

这组数据说明 Qwen3 4B 在这台 RTX 4060 Laptop 8GB 机器上是很轻松的。它适合常驻，用来做摘要、分类、短文本改写、轻量代码解释都不会太拖机器。

但它也暴露了一个很实际的问题：当前 Ollama 里的 qwen3:4b 模板会在 assistant 最后一轮自动插入 <think>，默认接口返回里可能把内容放进 thinking 字段，或者在设置 think: false 后仍把推理痕迹混进正文。也就是说，模型已经跑通，速度也不错，但如果要把它作为日常助手直接接到自己的工具里，还需要进一步处理“不要输出思考过程”的模板问题，或者换一个更适合直接输出的 instruct/no-thinking 版本。

这一点不能忽略。很多本地模型测起来 token/s 很漂亮，但一接到真实应用里，输出格式、系统提示词、模板和停止词才是真正影响体验的地方。

llama.cpp 第一轮对比

Ollama 下载下来的大 blob 头部是标准 GGUF：

4747 5546 ... GGUF

所以它可以直接被 llama.cpp 识别。当前先构建的是 CPU 版，不是 CUDA 版，因此这轮只能当作“CPU 基准”，不能当成公平的性能对比。

llama-bench 的结果是：

qwen3 4B Q4_K - Medium, CPU, 16 threads
prompt processing: 4.54 tokens/s
text generation:   12.42 tokens/s

和 Ollama 走 GPU 的 38 到 43 tokens/s 相比，CPU 版明显不适合做日常主路径。不过这个结果也有用：同一个模型文件可以被 llama.cpp 读取，后续只要补上 CUDA 版 llama.cpp，就能继续做更公平的后端对比。

Gemma 4 E4B 下载情况

gemma4:e4b 的 manifest 已经能正常获取，但模型文件不是想象中的轻量小包，而是 9.6GB。按当前 2MB/s 左右的下载速度，完整下载、校验、写 manifest 用了一个多小时。

这也再次提醒了一件事：多模态模型不能只看名字里的参数规模。视觉、音频、投影层、tokenizer 和量化方式都会让最终下载体积变大。对 8GB 显存的本地开发机来说，Gemma 4 E4B 仍然值得测，但它已经不是“随手拉一个小模型”的体量了。

完成后模型列表如下：

NAME          ID              SIZE
gemma4:e4b    c6eb396dbd59    9.6 GB

文本冷启动加载约 14.4 秒，热启动后加载降到 0.7 秒左右。短文本生成速度约 54 到 56 tokens/s，热起来后显存占用约 3.1GB。

Gemma 4 E4B 在 Ollama 里也有一个输出格式坑：默认 generate 调用能生成 token，但中文回答经常被 parser 过滤成空 response。加 raw: true 后，纯文本中文回答正常：

本地多模态模型非常适合进行离线、隐私敏感的图像识别和语音转录等基础处理。

图片输入不能和 raw: true 一起用，否则会报 Failed to tokenize prompt。改用 /api/chat，并加上 think: false 后，图片理解可以正常返回中文正文。用本文封面图测试时，它能识别出“开发者、多屏、AI、CUDA、高性能计算”等主题，说明多模态链路是通的；默认不加 think: false 时，内容会跑到 thinking 字段里，正文为空。

所以对 Gemma 4 E4B 的第一阶段结论是：模型能跑，多模态能用，速度不错，但接入应用时必须明确处理 think / parser / raw 模式，否则很容易拿到空正文。

Qwen3 8B 简单测试

qwen3:8b 的下载文件是 5.2GB：

NAME        ID              SIZE
qwen3:8b    500a1f067a9f    5.2 GB

第一次调用冷加载约 16.8 秒，热启动后加载约 0.2 秒。默认调用仍然会把内容放到 thinking，而不是 response；加 think: false 后，可以正常得到中文答案。

实测同一个中文短任务：

模型	模式	冷/热	生成速度	现象
Qwen3 4B	默认	热	约 42 tok/s	输出容易进 thinking
Qwen3 4B	think:false	热	约 43 tok/s	仍可能出现推理痕迹，需要继续调模板
Qwen3 8B	默认	冷	约 21.9 tok/s	response 为空，thinking 很长
Qwen3 8B	think:false	热	约 25.7 tok/s	中文正文正常

qwen3:8b 热起来后显存占用约 4.9GB。对 8GB 显存的机器来说，这个体量仍然比较舒服；但如果同时开浏览器、IDE、多个模型服务，就要注意显存回收。

从第一轮看，Qwen3 8B 更适合作为日常主力，Qwen3 4B 更适合常驻做轻任务。两者共同的问题是：本地接入时不能只看模型名字和速度，必须确认 Ollama 模板、think 参数和返回字段是否符合自己的应用预期。

Gemma 4 12B 下载情况

gemma4:12b 已完成下载并注册，最终显示大小是 7.6GB：

NAME          ID              SIZE
gemma4:12b    4eb23ef187e2    7.6 GB

它比 gemma4:e4b 小一些，但运行时明显更重。纯文本冷加载约 43 秒，默认模式仍然会生成 token 但返回空正文；raw: true 可以拿到中文回答，但会带出 <|channel>thought 这类通道标记，需要在应用层清理或继续调整模板。

热启动后，纯文本生成速度约 8.8 tokens/s；图片输入通过 /api/chat 加 think: false 可以正常返回中文正文，速度约 8.7 tokens/s。图片理解质量不错，能识别出 WSL、GPU 监控、CUDA、AI Pipeline 和技术教程场景，但 40 秒级别的图片回答延迟已经不适合当日常轻量助手。

显存方面，Gemma 4 12B 文本热状态下约占 5.8GB。它可以跑，但这台 8GB 显存的开发机上，12B 更适合专项测试和高质量多模态尝鲜，不适合常驻。

第一轮安装结果

到这里，第一轮计划里的四个模型都已经安装到 WSL 内的 ~/.ollama/models：

NAME          SIZE
qwen3:4b      2.5 GB
qwen3:8b      5.2 GB
gemma4:e4b    9.6 GB
gemma4:12b    7.6 GB

加上 Ollama 和模型缓存，~/.ollama/models 目录约 24GB。这个数字比单看参数量要大得多，后续如果继续试模型，磁盘规划必须提前做好。

第一轮很粗，但已经能形成几个判断：

模型	适合程度	第一印象
Qwen3 4B	适合常驻轻任务	快，但要处理 thinking/template 问题
Qwen3 8B	最适合作为日常主力	质量和速度更均衡，think:false 后可用
Gemma 4 E4B	适合多模态实验	图片链路可用，速度好，但默认 parser 容易空正文
Gemma 4 12B	适合专项测试	能跑，图像理解更稳，但速度明显慢

llama.cpp 目前已经完成 CPU 版构建，并用 Qwen3 4B 的同一份 GGUF blob 跑过 llama-bench。CPU 版生成约 12.4 tokens/s，和 Ollama 走 GPU 的 38 到 43 tokens/s 不在一个层级。下一篇要补的是 CUDA 版 llama.cpp，否则不能算公平对比。

后续测试安排

这篇文章先把安装链路跑通，简单测试会先用 qwen3:4b 做中文问答、代码、摘要和结构化输出。第二篇再做几个模型的详细对比，包括 Qwen3 4B、Qwen3 8B、Gemma 4 E4B、Gemma 4 12B 的加载时间、显存占用、输出速度、回答质量，以及 Gemma 的多模态输入测试。第三篇会从真实使用场景出发，不只看 benchmark，而是看本地模型到底能不能提高日常开发和资料处理的效率。

当前结论

对这台机器来说，最现实的默认组合是：

日常主力：Qwen3 8B
轻量工具：Qwen3 4B
多模态实验：Gemma 4 E4B
高质量尝鲜：Gemma 4 12B
性能基准：llama.cpp + GGUF
省心入口：Ollama

真正要长期使用，本地模型部署不是“装一个模型”这么简单。它更像是在自己的机器上建立一个小型模型工作台：模型文件放哪里，API 怎么暴露，谁占显存，哪个模型适合写代码，哪个模型适合总结，哪个模型只是 benchmark 好看但日常不好用，都要用真实任务跑一遍。

这篇文章后面会继续补实测，不急着下最终结论。