llama.cpp部署全记录
llama.cpp 部署全记录：从源码编译到 35B MoE 模型 120K 上下文调优
2026-06-16 · 作者：侠心论码 编制：小芸
硬件：i7-8700H, 32GB RAM, GTX 1060 6GB, 混合存储（SSD + HDD）
目标：在贫民级显卡上流畅运行 Qwen3.6-35B-A3B 并支持超长上下文
—
目录
- 环境与背景
- 编译 llama.cpp：从官方二进制到源码自编译
- 模型文件的选择与处理
- MVP 阶段：从闪退到跑通
- 超大上下文的陷阱与破解
- 内存优化的三重奏
- mmap 深度理解与分片迷思
- MoE 模型的特殊优化
- Gemma-4-E4B：意外的小惊喜
- 最终部署架构
- 经验总结与避坑清单
1. 环境与背景
硬件配置
| 组件 | 规格 | 备注 |
|---|---|---|
| CPU | i7-8700H @ 3.70GHz | 6 核 12 线程 |
| RAM | 32 GB DDR4 | — |
| GPU | GTX 1060 6GB | 6GB VRAM，计算能力 6.1 |
| 系统盘 C | SSD 275 GB | 系统 + 编译工具 |
| 数据盘 D | HDD 1 TB | 模型文件 |
| 扩展盘 E | SSD 256 GB | KV 缓存卸载 |
模型信息
主力模型：Qwen3.6-35B-A3B
- 架构：MoE（Mixture of Experts），35B 总参数，3B 活跃参数
- 作者：HauhauCS
- 版本：Uncensored + Aggressive 微调
- 两种量化：Q4_K_M（21.2 GB）和 MXFP4（21.7 GB）
辅助模型：Gemma-4-E4B
- 4B 总参数（小模型）
- Q4_K_M 量化后仅 5.3 GB
- CPU 即可流畅运行
关键限制
GTX 1060 只有 6GB VRAM，这意味着 任何 35B 模型都无法完全放入 GPU。llama.cpp 的 --n-gpu-layers 只能将部分层卸载到 GPU，大部分推理仍在 CPU 上进行。这给优化带来了独特的挑战。
2. 编译 llama.c从官方二进制到源码自编译
2.1 为什么需要自编译
一开始我们用了官方预编译的 llama-b9415-bin-win-cuda-12.4-x64 包，但它缺少两个关键特性：
--kv-backend ssd：将 KV 缓存卸载到 SSD，大幅降低长上下文内存占用- 最新的 multibackend 架构改进
虽然最终我们走了另一条路（见后文），但自编译过程本身踩了不少坑，值得记录。
2.2 CMake 配置
最终成功的编译脚本（build_llama.bat）：
@echo off
chcp 437 > nul
title 🔨 编译 llama.cpp (CUDA 12.8 + Server + UI)
set SRC=D:\llama.cpp
set BUILD=%SRC%\build2
if exist "%BUILD%" rmdir /s /q "%BUILD%"
mkdir "%BUILD%"
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvars64.bat"
cd /d "%BUILD%"
cmake -G "Visual Studio 16 2019" -A x64 ^
-DCMAKE_BUILD_TYPE=Release ^
-DGGML_CUDA=ON ^
-DCMAKE_CUDA_ARCHITECTURES=61-real ^
-DBUILD_SHARED_LIBS=ON ^
-S "%SRC%" -B "%BUILD%"
if %errorlevel% neq 0 (
echo [X] CMake 配置失败
pause
exit /b %errorlevel%
)
cmake --build . --config Release --target llama-server -- /m:2
if %errorlevel% neq 0 (
echo [X] 编译失败
pause
exit /b %errorlevel%
)
echo [OK] 编译完成！
pause
2.3 踩坑实录
🕳️ 坑 1：编译出来只有 9KB？
第一次运行 llama-server.exe 的 --help 时：
C:\> dir llama-server.exe
9,728 bytes ← 怎么可能？！
原因：llama.cpp 使用分离架构：llama-server.exe 只是一个 9KB 的加载器/存根，实际代码在 llama-server-impl.dll（~13 MB）和 llama.dll（~98 MB）中。这是 CMake 的 BUILD_SHARED_LIBS=ON 的产物。
验证：用 dumpbin /dependents 查看依赖链：
llama-server.exe
├── llama-server-impl.dll ← 真正的服务器逻辑（13 MB）
│ ├── llama.dll ← 核心推理引擎（98 MB）
│ └── ggml-cuda.dll ← GPU 加速层
└── VCRUNTIME140.dll
教训：不要只看 exe 大小，检查同目录的 DLL 是否完整。
🕳️ 坑 2：NVCC 编译了 10 年
第一次编译时等了 30 分钟还没完成，检查发现 NVCC 正在为所有支持的 CUDA 架构生成代码：
sm_50, sm_52, sm_53, sm_60, sm_61, sm_62, sm_70, …, sm_120a
原因：CMake 默认 CMAKE_CUDA_ARCHITECTURES="50-real;52-real;…;120a"，而 GTX 1060（计算能力 6.1）只需要 sm_61。
解决：指定单架构：
-DCMAKE_CUDA_ARCHITECTURES=61-real
编译时间从 30 分钟+ 缩短到 5 分钟。
注意：变量名是 CMAKE_CUDA_ARCHITECTURES，不是 GGML_CUDA_ARCHITECTURES。前者是 CMake 标准变量，后者是旧版 llama.cpp 的自定义变量。
🕳️ 坑 3：编译成功后运行报 0xC0000135
Server exited with code -1073741511 (0xC0000135 = STATUS_DLL_NOT_FOUND)
原因：Llama-server 依赖 CUDA 运行时 DLL（cudart64_12.dll、cublas64_12.dll 等），但这些 DLL 不在可执行文件目录或 PATH 中。
解决：从 CUDA Toolkit 的 bin\ 目录复制以下 DLL 到服务器目录：
| DLL | 用途 |
|---|---|
cudart64_12.dll |
CUDA Runtime |
cublas64_12.dll |
BLAS 加速 |
cublasLt64_12.dll |
BLAS Light |
cufft64_11.dll |
FFT |
curand64_10.dll |
随机数生成 |
cusolver64_11.dll |
线性求解器 |
cusparse64_12.dll |
稀疏矩阵 |
🕳️ 坑 4：--kv-backend 未编译进去
编译完成后发现 --help 没有 --kv-backend 选项。
原因：需要 --kv-backend 支持的最新代码（在 ggml 组织的最新 main 分支中），并且需要在 CMake 中启用 LLAMA_KV_BACKEND_SSD=ON 或类似选项。
备选方案：绕过 --kv-backend，改用 --slot-save-path + --cache-ram 实现类似效果（见第 5 节）。
3. 模型文件的选择与处理
3.1 模型来源
所有模型来自 HuggingFace 用户 HauhauCS，他的微调版本以"精神稳定、道德约束少"著称：
| 模型 | 格式 | 大小 | 作用 |
|---|---|---|---|
Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive-Q4_K_M.gguf |
GGUF | 21.2 GB | 主力 Q4_K_M |
Qwen3.6-35B-A3B-MXFP4_MOE.gguf |
GGUF | 21.7 GB | 主力 MXFP4 |
mmproj-Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive-f16.gguf |
MMPROJ | 1.9 GB | Qwen 视觉投影 |
mmproj-F16.gguf |
MMPROJ | 858 MB | MXFP4 视觉投影 |
Gemma-4-E4B-Uncensored-HauhauCS-Aggressive-Q4_K_M.gguf |
GGUF | 5.3 GB | 轻量模型 |
mmproj-Gemma-4-E4B-Uncensored-HauhauCS-Aggressive-f16.gguf |
MMPROJ | 990 MB | Gemma 视觉投影 |
3.2 分片（Sharding）—— 不必要的弯路
一开始我们以为分片能降低内存占用，用 llama-gguf-split 将 21GB 模型分成 6 个分片：
llama-gguf-split --split-max-size 4000M model.gguf Qwen-shard.gguf
结果：分片后 6 个文件：
Qwen-shard.gguf-00001-of-00006.gguf 4.0 GB
Qwen-shard.gguf-00002-of-00006.gguf 4.0 GB
Qwen-shard.gguf-00003-of-00006.gguf 4.0 GB
Qwen-shard.gguf-00004-of-00006.gguf 4.0 GB
Qwen-shard.gguf-00005-of-00006.gguf 4.0 GB
Qwen-shard.gguf-00006-of-00006.gguf 1.4 GB
后续发现：单文件 mmap 的内存占用和分片一模一样（~6.7 GB vs ~6 GB），甚至更快。分片不降内存，mmap 才是关键（详细分析见第 7 节）。
保留分片文件的唯一好处：便于增量下载、校验和大文件管理。
3.3 最终目录结构
D:\Llama\
├── bin\ ← 服务器二进制 + 所有 CUDA DLL
│ ├── llama-server.exe
│ ├── llama-gguf-split.exe
│ └── *17 个 DLL*
├── models\
│ ├── MXFP\ ← MXFP4 模型
│ │ ├── Qwen3.6-35B-A3B-MXFP4_MOE.gguf (21.7 GB)
│ │ └── mmproj-F16.gguf (858 MB)
│ ├── Qwen\ ← Q4_K_M 模型
│ │ ├── Qwen3.6-35B-A3B-Uncensored-...Q4_K_M.gguf (21.2 GB)
│ │ └── mmproj-...-f16.gguf (1.9 GB)
│ └── Gemma-4-E4B\ ← Gemma 模型
│ ├── Gemma-4-E4B-...-Q4_K_M.gguf (5.3 GB)
│ └── mmproj-...-f16.gguf (990 MB)
4. MVP 阶段：从闪退到跑通
4.1 第一版启动脚本
llama-server.exe ^
-m model.gguf ^
--port 8080 ^
--ctx-size 4096 ^
--n-gpu-layers 999 ^
--n-cpu-moe 999
双击 → 闪退。
原因：--n-gpu-layers 999 试图将 999 层卸载到 GPU，但 GTX 1060 只有 6GB VRAM，根本无法容纳 35B 模型的层权重，进程直接退出。
修复：去掉 --n-gpu-layers（不传入 = 全部跑 CPU）。
4.2 第一版能跑的脚本
llama-server.exe ^
-m model.gguf ^
--host 127.0.0.1 --port 8080 ^
--ctx-size 4096 ^
-t 8 ^
--no-warmup
跑起来了！但是 ctx-size 4096 只能处理极短对话。
5. 超大上下文的陷阱与破解
5.1 第一次尝试：直接加 ctx-size
--ctx-size 131072 (128K)
结果：内存飙到 25 GB，系统几乎卡死。
原因：KV 缓存是上下文长度的平方级增长：
每个 token 的 KV 缓存 = 2 (K+V) × 2 (Q4_0 量化) × 80 (layers) × 4096 (dim) ≈ 2.6 MB
128K tokens → 2.6 MB × 131072 ≈ 340 GB ？？？
不对，上面的计算夸大了。实际计算：
KV cache size = 2 (K+V) × (quant_bytes) × n_layers × n_embd
对于 Qwen3.6-35B-A3B，n_layers ≈ 80, n_embd ≈ 4096 (每个 MoE layer 的实际维度和路由相关)
每个 token 在 Q4_0 下 ≈ 2 × 0.5 bytes × 80 × 4096 ≈ 320 KB
128K tokens → 320 KB × 131072 ≈ 40 GB
这仍然远超 32GB。更何况模型权重本身还有 ~6-21 GB。25 GB 的物理内存就已经是极限了。
5.2 KV 缓存量化压缩
--cache-type-k q4_0
--cache-type-v q4_0
这行参数将 KV 缓存从默认的 fp16（2 字节/值）压缩到 q4_0（0.5 字节/值），内存占用降至原来的 1/4。
压缩后，128K 上下文的 KV 缓存从 ~40 GB 降到 ~10 GB。
5.3 KV 缓存卸载到 SSD
--slot-save-path E:\llama-slots
--cache-ram 512
这两行是真正的魔法：
--slot-save-path：将 KV 缓存保存到指定的 SSD 分区--cache-ram 512：物理内存中只保留 512 MB 的活跃 KV 缓存，其余卸载到 SSD
结果：128K 上下文的 KV 缓存虚拟空间分配 40 GB，但物理内存只占 ~512 MB。推理速度会有少量下降（SSD 访问延迟），但对于非实时场景完全可接受。
5.4 最终 120K 成功配置
--ctx-size 131072
--cache-type-k q4_0
--cache-type-v q4_0
--slot-save-path E:\llama-slots
--cache-ram 512
物理内存占用：从 25 GB → ~6.7 GB。
5.5 为什么最终只用了 120K 而非模型原生 131072？
Qwen3.6-35B-A3B 的原生 n_ctx_train 是 131072（128K），但在启动时有警告：
n_ctx_seq (131072) <= n_ctx_train (131072) — 正好符合限制
我们实际上使用了 131072（120K+）。日志中显示的 32768 是 n_ctx_seq（默认的序列上下文），它被 --ctx-size 覆盖。验证：实际推理时 API 的 max_tokens 可以达到 131072 - prompt 长度。
6. 内存优化的三重奏
6.1 区分两类内存
在排查内存问题时，关键是区分两个完全独立的内存维度：
权重内存 = f(模型大小, mmap 使用方式)
KV 缓存 = f(ctx_size, cache_type, cache_ram)
| 类别 | 依赖因素 | 优化手段 |
|---|---|---|
| 权重 | 模型大小、量化格式、mmap | 量化（Q4_K_M/MXFP4）、mmap |
| KV 缓存 | 上下文长度、量化类型、卸载策略 | Q4_0 量化、SSD 卸载、cache-ram 限制 |
两个维度互不依赖，可以分别优化。
6.2 三重优化组合
┌─────────────────────────────────────┐
│ 物理内存 32 GB │
├─────────────────┬───────────────────┤
│ 权重 (mmap) │ KV 缓存 │
│ ~6 GB 常驻 │ ~512 MB 活跃 │
│ ~15 GB 按需调入 │ ~40 GB 虚拟(SSD) │
└─────────────────┴───────────────────┘
第一重 —— mmap： 模型权重通过 --mmap 按需加载到物理内存。即使 21 GB 模型，物理内存也只保留频繁访问的 ~6 GB。
第二重 —— KV 量化： --cache-type-k/v q4_0 将 KV 缓存压缩 4 倍。
第三重 —— SSD 卸载： --slot-save-path + --cache-ram 将大部分 KV 缓存移至 SSD，物理内存只留热点。
三者协同，使得 32GB 系统跑 35B@120K 成为可能。
7. mmap 深度理解与分片迷思
7.1 实验数据
| 方案 | ctx-size | 物理内存 | 生成速度 |
|---|---|---|---|
| 单文件 + 无 mmap | 4K | ~25 GB | 差 |
| 分片 + mmap | 4K | ~6 GB | ~8 t/s |
| 单文件 + mmap | 120K | ~6.7 GB | ~6 t/s |
| 分片 + mmap | 120K | ~6.7 GB | ~5.5 t/s |
关键发现：单文件 mmap 的分片版在物理内存占用上几乎相同，单文件甚至更快。
7.2 mmap 的工作原理
虚拟地址空间： 21 GB（整个文件映射）
实际物理内存： ~6 GB（只包含被访问的页面）
│
mmap 文件 → 虚拟地址映射 → 页面按需调入 → 自动管理
当模型加载时，llama.cpp 使用 mmap() 将整个 21GB 的 .gguf 文件映射到虚拟地址空间。操作系统此时仅分配虚拟地址，不分配物理内存。只有当代码实际读取某个页面时，才会触发 page fault，OS 按需从磁盘加载该页面到物理内存。
MoE 模型的稀疏性（每步只激活 ~3B / 35B 的专家）决定了：在任何时刻，只有约 1/10 的权重被访问。所以物理内存自然只保留活跃的 ~6 GB。
7.3 分片的真正影响
分片（llama-gguf-split -m 4000M）只是将一个大的 .gguf 文件切分成多个物理文件，对 mmap 行为没有本质改变。
| 维度 | 单文件 | 分片 |
|---|---|---|
| 物理内存占用 | ~6.7 GB | ~6 GB |
| 加载速度 | 更快（单文件顺序读） | 稍慢（多文件切换） |
| 文件管理 | 一个 21 GB 文件 | 6 个文件 |
| 增量下载 | 无法 | 可以 |
| 校验完整性 | 一次校验 | 逐个校验 |
结论：内存优化源自 mmap，而非分片。分片的优势在于管理（增量下载、校验）而非内存。
8. MoE 模型的特殊优化
8.1 为什么 MoE 天生省内存
MoE（Mixture of Experts）模型每次推理只激活部分专家：
Qwen3.6-35B-A3B
├── 共享层（always active）：~3B 参数
├── 路由器（always active）：少量参数
└── 60 个专家（per step top-k=6）：~3B 参数
─────────────────────────────────
每次推理活跃参数：~3B（总 35B 的 1/10）
这意味着物理内存中大部分权重处于低温状态，OS 会自动将它们换出到磁盘。
8.2 CPU+GPU 混合推理
GTX 1060 6GB 只能容纳部分层，我们采用了：
--n-gpu-layers 999 ← 尽量卸载到 GPU（但会被 VRAM 限制）
--n-cpu-moe 999 ← 所有 MoE 专家在 CPU 推理
实际效果：GPU 仅承担了约 20% 的计算量（嵌入层 + 共享层的前几层），MoE 专家的计算全部在 CPU 上。配合 -t 8（8 线程），CPU 推理速度在 4-8 t/s 之间。
8.3 MXFP4 vs Q4_K_M 对比
| 量化 | 文件大小 | 物理内存 | 速度 | 质量 |
|---|---|---|---|---|
| Q4_K_M | 21.2 GB | ~6.7 GB | ~8 t/s 🏆 | 参考基准 |
| MXFP4 | 21.7 GB | ~6.7 GB | ~5 t/s | 相近 |
建议：默认用 Q4_K_M（更快），MXFP4 留给对精度有要求的场景（但在我们的测试中质量差异不明显）。
9. Gemma-4-E4B：意外的小惊喜
在搞定两个 35B 模型后，顺手部署了第三个模型——Gemma-4-E4B，结果发现它表现惊艳。
9.1 参数
| 属性 | 值 |
|---|---|
| 模型参数 | 4B total（4-E4B） |
| GGUF 大小 | 5.3 GB |
| 物理内存 | ~3.4 GB |
| Prompt 速度 | 38 t/s |
| 生成速度 | 25 t/s |
| 上下文 | 32K（单文件限制，可扩展到 120K） |
9.2 为什么这么快
- 模型本身只有 4B 参数（约是 35B 的 1/9）
- 完全在 CPU 上运行，无需 GPU 数据传输
- mmap 加载后大部分权重常驻物理内存（5.3 GB 对 32 GB 来说小菜一碟）
9.3 适用场景
Gemma-4-E4B 适合：
- 快速摘要、翻译等轻量任务
- 作为第二模型并行服务（与 35B 共享资源）
- 测试和开发阶段的快速迭代
10. 最终部署架构
┌──────────────────────────────────────────────┐
│ 桌面启动脚本 │
│ │
│ run_qwen_full_mxfp.bat → :8080 Qwen MXFP4 │
│ run_qwen_full_q4.bat → :8081 Qwen Q4_K_M│
│ run_gemma4.bat → :8082 Gemma-4-E4B│
└──────────────────────┬───────────────────────┘
│
┌──────────────────────▼───────────────────────┐
│ D:\Llama\bin\llama-server.exe │
│ (统一二进制 + CUDA DLL) │
└─────────────┬────────────────────┬────────────┘
│ │
┌─────────▼─────────┐ ┌──────▼──────┐
│ D 盘 (HDD) │ │ E 盘 (SSD) │
│ 模型文件 (mmap) │ │ KV 缓存 │
│ ~50 GB 三模型 │ │ (slot-save) │
└───────────────────┘ └─────────────┘
三个服务的详细配置
| 脚本 | 模型 | 端口 | 文件大小 | 物理内存 | 生成速度 | 用途 |
|---|---|---|---|---|---|---|
run_qwen_full_mxfp.bat |
Qwen 35B MXFP4 | 8080 🏆 | 21.7 GB | ~6.7 GB | 5 t/s | 默认 |
run_qwen_full_q4.bat |
Qwen 35B Q4_K_M | 8081 | 21.2 GB | ~6.7 GB | 8 t/s 🏆 | 高速 |
run_gemma4.bat |
Gemma-4-E4B | 8082 | 5.3 GB | ~3.4 GB | 38 t/s 🚀 | 轻量 |
同时运行三个服务
所有服务共享同一台机器的 32GB 物理内存。三个同时运行时：
- Qwen MXFP4：~6.7 GB
- Qwen Q4_K_M：~6.7 GB
- Gemma-4-E4B：~3.4 GB
- 总计：~17 GB（32 GB 绰绰有余）
三个服务互不冲突，可同时对外提供 API。
11. 经验总结与避坑清单
🏆 成功关键
- mmap + MoE 稀疏性是降内存的核心，不是分片
- KV 缓存量化 + SSD 卸载让 120K 上下文在 32GB 机器上成为可能
- 逐步增大 ctx-size（4K → 32K → 120K），每次验证内存和速度
- 最小化编译：只编译需要的目标，指定目标 GPU 架构
🕳️ 踩坑清单
| # | 坑 | 症状 | 原因 | 解决 |
|---|---|---|---|---|
| 1 | exe 只有 9KB | 以为编译失败 | llama-server 是 DLL 加载器 | 检查 llama-server-impl.dll |
| 2 | NVCC 编译超慢 | 等了 30 分钟 | CMake 默认编译所有架构 | -DCMAKE_CUDA_ARCHITECTURES=61-real |
| 3 | 0xC0000135 运行报错 | 程序无法启动 | CUDA DLL 不在路径 | 复制 CUDA DLL 到 bin 目录 |
| 4 | 内存 25 GB 爆满 | 系统卡死 | ctx-size 400K 无优化 | 降 ctx + KV 量化 + SSD 卸载 |
| 5 | 分片后内存没降 | 以为分片能省内存 | mmap 才是关键 | 理解 mmap 按需加载机制 |
| 6 | 闪退 | 双击后窗口消失 | --n-gpu-layers 999 超 VRAM |
去掉或设合理值 |
| 7 | --kv-backend 不可用 |
编译不包含此选项 | 功能在 trunk 但默认未启用 | 改用 slot-save-path |
💡 思维模型
内存优化的分层思维：
第 1 层：权重内存 ← mmap + 量化
第 2 层：KV 缓存 ← 量化 + 卸载
第 3 层：计算加速 ← GPU 卸载 + 线程
每个层次独立优化，不要混为一谈。
编译问题排查顺序：
1. 检查 CMake 配置成功（是否有错误警告）
2. 检查编译目标是否正确（指定 target 名）
3. 检查编译产物大小和依赖 DLL
4. 检查运行时的 PATH 和环境变量
5. 逐步增加命令行参数，定位问题参数
排查闪退的正确方法：
- 不在 cmd 中双击 .bat，而是先打开 cmd 窗口，再手动执行命令
- 这样闪退时可以看到错误消息
- 或者把
pause放在 .bat 末尾防止窗口关闭
附录：完整启动脚本
run_qwen_full_mxfp.bat（默认 MXFP4 服务）
@echo off
chcp 437 > nul
title Qwen MXFP4 :8080
set SERVER=D:\Llama\bin\llama-server.exe
set MODEL=D:\Llama\models\MXFP\Qwen3.6-35B-A3B-MXFP4_MOE.gguf
set MMPROJ=D:\Llama\models\MXFP\mmproj-F16.gguf
set SLOTS=E:\llama-slots
if not exist "%MODEL%" echo [X] Model missing & pause & exit /b 1
if not exist "%MMPROJ%" echo [X] mmproj missing & pause & exit /b 1
if not exist "%SERVER%" echo [X] Server missing & pause & exit /b 1
if not exist "%SLOTS%" mkdir "%SLOTS%" 2>nul
cls
echo Qwen3.6-35B-A3B-MXFP4 (120K ctx)
echo Port : 8080 * OpenClaw default
echo Ctx : 131072 (120K+)
echo RAM : ~6-8 GB
echo KV : E:\llama-slots
echo.
"%SERVER%" ^
-m "%MODEL%" ^
--mmproj "%MMPROJ%" ^
--host 127.0.0.1 --port 8080 ^
--n-gpu-layers 999 --n-cpu-moe 999 ^
-t 8 --ctx-size 131072 ^
-np 2 --batch-size 512 --ubatch-size 256 ^
--cache-type-k q4_0 --cache-type-v q4_0 ^
--cache-ram 512 --slot-save-path "%SLOTS%" ^
--reasoning on --no-warmup --prio 2 ^
--temp 0.30 --top-k 60 --top-p 0.80 --min-p 0.15 ^
--repeat-penalty 1.15,1.12 --repeat-last-n 512 ^
--alias "Qwen3.6-35B-MXFP4" ^
--timeout 300 --flash-attn auto ^
--ui --metrics
pause
run_qwen_full_q4.bat（Q4_K_M 高速服务）
与 MXFP4 基本相同，区别在端口 8081 和模型路径指向 Qwen 目录。
run_gemma4.bat（轻量 Gemma 服务）
与上面基本相同，区别在端口 8082 和模型路径指向 Gemma-4-E4B 目录。
结束语
这个项目从最初的"双击闪退"到最终三个模型同时稳定服务 120K 上下文，经历了大约 48 小时的密集踩坑。最大的收获不是技术参数本身，而是建立了排查复杂系统问题的思维框架：分层思考、逐个验证、对比实验、理解原理。
希望这篇记录能给同样在有限硬件上折腾大模型的你一些帮助。如果你有任何问题，欢迎在评论区讨论。
最后更新：2026-06-16
环境：llama.cpp build b9415+, CUDA 12.8, VS 2019 Build Tools, Windows 10
更多推荐
9
0- 0
已为社区贡献5条内容
所有评论(0)