---

本地大模型搭建全流程（RTX 5060 + Ubuntu + KoboldCpp）

与 AI 协作搭建本地大模型的完整记录，已按主题整理。
环境：Windows 11 + RTX 5060 Laptop 8GB + VMware Ubuntu + KoboldCpp

一、整体架构

核心思路：模型推理放在 Windows（GPU 直通），Ubuntu 虚拟机作为远程客户端，两者通过 VMware VMnet8 跨网络访问。

Windows 11
├── RTX 5060 Laptop 8GB
│     └── KoboldCpp（GPU 推理引擎）
│           └── HTTP API 0.0.0.0:5001
│
└── VMnet8 网卡（192.168.107.1）
         │  VMware NAT 网关（192.168.107.2）
         ▼
Ubuntu VM（192.168.107.195）
         └── 远程访问测试（curl / wget）

数据流（已全部验证打通 ✅）：

Ubuntu VM（192.168.107.195）
  → VMware NAT
  → Windows（192.168.107.1）
  → KoboldCpp → RTX 5060

要点：

• 不需要改动 VMware 网络架构——Windows 在 VMnet8 上有明确 IP（192.168.107.1），直接用 IP 访问即可。
• Windows 上的 KoboldCpp 必须监听 0.0.0.0（不能只监听 127.0.0.1），并放行防火墙，否则 Ubuntu 访问不到。
• 这个案例本身就是"跨虚拟网络访问宿主机服务"的典型实验：Ubuntu → 路由 → VMware NAT → Windows。

二、环境信息

项目	值
宿主机	Windows 11
GPU	RTX 5060 Laptop，显存 8151 MiB ≈ 8GB
内存	32GB
硬盘	3TB
NVIDIA 驱动	610.74
CUDA Driver	13.3（UMD），无需安装 CUDA Toolkit
Ubuntu VM	192.168.107.195/24，网关 192.168.107.2（VMware NAT）
Windows VMnet8	192.168.107.1

三、网络验证（已完成 ✅）

目标链路：Ubuntu → VMware NAT → Windows VMnet8，最终到 Windows 上的推理引擎。

验证命令

# 1. Ubuntu 里 ping Windows 虚拟网卡
ping -c 4 192.168.107.1

# 2. Windows CMD 确认 VMnet8 地址
ipconfig    # 找 VMware Network Adapter VMnet8 → 192.168.107.1

# 3. 验证 HTTP 层（Windows 先启动临时服务）
#   Windows PowerShell：
python -m http.server 8080 --bind 0.0.0.0
#   Ubuntu 里：
wget -O- http://192.168.107.1:8080    # 或 curl

实测结果

• Ubuntu ping 192.168.107.1：4/4 通过，0% 丢包，延迟约 0.5ms，链路完全打通。

⚠️ 注意事项

• ICMP 通 ≠ TCP 端口通：Windows 防火墙可能放行 ping 但拦截具体端口。
• 若 HTTP 测试失败，依次检查：防火墙 → 监听地址 → 监听端口 → VMnet8 → 虚拟网络。

四、踩坑记录

4.1 UI 白屏 ≠ 模型没启动

• 白屏可能只是浏览器 UI 问题，模型可能已正常加载到 GPU、后端正常。
• 不要为了白屏反复双击 launch：每启动一次就会再加载一个模型进显存，多次之后 8GB 显存瞬间被占满。
• 判断方法：看启动终端输出 + nvidia-smi 显存占用。

五、安装 KoboldCpp

• 下载地址：KoboldCpp 官方 GitHub → Releases → Windows 的 CUDA 版本。
• 版本选择：驱动已是 CUDA 13.3，优先选 CUDA 13 版（如 koboldcpp_cu13.exe），不必迁就旧 CUDA。
• 本次实际版本：KoboldCpp v1.118.1，启动后正确识别 RTX 5060 Laptop GPU。

六、下载 GGUF 模型

第一轮只做环境验证，用 Qwen3-8B Q4_K_M（约 5.03GB），不要一上来就下大模型。

• 下载地址：Qwen/Qwen3-8B-GGUF（Hugging Face）
• 文件：Qwen3-8B-Q4_K_M.gguf
• 存放目录：D:\AI\Models\

量化版本对比（8GB 显存视角）

版本	大小	评价
Q4_K_M	5.03 GB	★★★★★ 最稳，第一轮首选
Q5_K_M	5.85 GB	★★★★☆ 可跑，但更吃显存
Q6_K	6.73 GB	★★★☆☆ 逼近显存极限
Q8_0	8.71 GB	❌ 文件已超 8GB 显存，第一轮不要

提示：Qwen3-8B 只是"点火塞"。跑通链路后，如需更强的对话/推理能力，建议换 12B/14B 更大模型（Q4/Q5 量化），而不是一直用 8B。

七、KoboldCpp 参数配置（v1.118.1 实测）

参数表

参数	设置	说明
Backend	Use CUDA	已自动识别 RTX 5060 Laptop GPU
GPU ID	0	单卡保持 0
Use MMQ	☑ 保持	—
GPU Layers	-1	自动分配，无需手动填 99
Use MMAP	☐ 不勾	第一轮求稳
FlashAttention	☑ 保持	长上下文有价值
Context Size	8192	从默认 12288 下调，给显存留余量（KV Cache 也吃显存）
ContextShift	☑ 保持	长对话有用
Launch Browser	☑ 保持	启动后自动打开 Web UI
Remote Tunnel	☐ 关闭	不需要暴露公网
Force AutoFit / Use Jinja	☐ 关闭	第一轮全部保持关闭
Port	5001	—
Host	0.0.0.0	⚠️ 必须！只监听 127.0.0.1 时 Ubuntu 访问不到

启动步骤（按顺序，一层验证完再进下一层）

1. 选择 GGUF 模型文件（D:\AI\Models\Qwen3-8B-Q4_K_M.gguf）
2. 按上表配置参数
3. 点 Launch / Start，观察控制台输出（应有 CUDA / RTX 5060 / offloading layers）
4. 另开 PowerShell 运行 nvidia-smi -l 1（每秒刷新）：
   • 显存应从 ~1531 MiB 涨到 5000~7000+ MiB（/ 8151 MiB）
   • 生成文字时 GPU-Util 明显上升 → 证明 GPU 真在推理，而不是 CPU 在跑
5. Windows 浏览器打开 http://127.0.0.1:5001，先本地测试模型能否正常对话
6. Ubuntu 里 wget -O- http://192.168.107.1:5001，验证跨网络可达
7. 不要一次性做十件事，每层确认通过再继续

八、停止 / 卸载模型（释放显存）

8.1 KoboldCpp（本次实际使用方式）

• 直接关闭启动终端窗口（点 ×），或终端内按 Ctrl + C
• 关闭后：KoboldCpp 后端停止 → 模型从显存卸载 → 显存释放（浏览器页面失效属正常）

8.2 关掉终端后显存仍未释放

nvidia-smi                    # 查看占用进程
taskkill /IM koboldcpp.exe /F # 按实际进程名执行，不要照抄

8.3 如果用的是 Ollama（备选）

ollama ps            # 查看当前加载的模型
ollama stop qwen3:8b # 只卸载模型、释放 GPU 显存，服务保留（推荐）
taskkill /IM ollama.exe /F   # 需要整个服务关闭时
# 终端对话中直接 Ctrl + C 终止当前推理

九、性能记录与后续调优

实测数据

• 推理速度：42.28 t/s（Generated: 26/350 in 0.61s）——消费级 GPU 表现不错
• 当时参数：n_ctx 8192、n_predict 350、temperature 1、top_p 0.95

结论

感觉"模型效果不尽如人意"，主要不是电脑慢，而是 8B 模型本身的能力上限 + 参数/上下文设置问题。

下一步调优方向

1. 先把 KoboldCpp + Qwen3-8B 的正确参数搞明白：思考模式（thinking）、上下文长度、GPU offload
2. 上下文长度渐进测试：8192 → 12288 → 16384
3. 链路稳定后，如需更强对话能力，换 12B/14B 更大模型（Q4/Q5 量化）