本文章没有找到对应的语言版本

windows下llama.cpp试用

因为觉得ollama的资源调度实在过于拉胯，在L站上偶然得知关于ollama的负面信息：

Ollama 因违背开源原则、性能与诚信问题失去用户信任。

性能与技术缺陷：视频数据显示，llama.cpp 的推理速度比 Ollama 快 1.8 倍（161tokens 每秒 vs89tokens 每秒）；Ollama 自研基于 ggml 库的后端后，重新引入 llama.cpp 已解决的 bug，导致结构化输出、视觉模型故障，还不支持新的 GPT-OSS 模型。

同时得到替代工具推荐：视频推荐 llama.cpp、LM Studio、Jan、koboldcpp、ramalama 等工具，这些工具无锁定、社区驱动或开源本地优先。

于是果断选择转学习llama.cpp和lm studio

第一步是从github官方源拉取资源

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

llama.cpp支持多种硬件平台，可根据实际的硬件配置情况选择合适的编译参数进行编译，具体可以参考文档docs/build.md

接下来就要进入编译环节，这一点一开始让我犯了难

在 x64 Native Tools Command Prompt 中开启管理员权限操作

进入你llama.cpp所在的目录

方法一：使用 CMake 编译（现代、推荐）

创建构建目录并配置

根据你的硬件选择对应的命令：

  • 仅 CPU (通用):

    cmake -B build

  • NVIDIA GPU (CUDA):

    cmake -B build -DGGML_CUDA=ON

  • Apple Silicon (Metal):

    cmake -B build -DGGML_METAL=ON

  • AMD GPU (Vulkan):

    cmake -B build -DGGML_VULKAN=ON

执行编译

使用 -j 参数调用多核编译以加快速度（例如 -j 8 表示使用 8 个线程）：

cmake --build build --config Release -j

编译完成后，二进制文件通常位于 build/bin/ 目录下

方法二：使用 Make 编译（传统、简单）

编译

根据硬件选择指令：

  • 仅 CPU:

    make -j

  • NVIDIA GPU (CUDA):

    LLAMA_CUDA=1 make -j

  • Apple Silicon (Metal):

    make -j

(Metal 通常在 Mac 上默认开启)

编译完成后，二进制文件直接位于项目根目录下

然后问题就来了嗷，这时候有人就要问了，这么简单的东西，哪里让你犯难了啊？

我遇到的问题是这样的

CMake Error at ggml/CMakeLists.txt:9 (project):
No CMAKE_ASM_COMPILER could be found.

这里怀疑过很多问题，包括nvcc和asm

nvcc-version

查了

nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2025 NVIDIA Corporation
Built on Wed_Aug_20_13:58:20_Pacific_Daylight_Time_2025
Cuda compilation tools, release 13.0, V13.0.88
Build cuda_13.0.r13.0/compiler.36424714_0

至少nvcc就是有的

然后修改visual studio，因为asm这是linux的，windows系统本身不带，但是visual studio也可以安装上

当时问了gemma4:31b

它认为CUDA 对 MSVC 的版本依赖极其苛刻。 即使安装了最新的 CUDA 13.0，它可能还没有适配 VS 2026 (MSVC 19.50) 的编译器接口。当 nvcc 尝试调用 cl.exe (MSVC) 进行编译时，发现版本号不认识，导致初始化失败 ，cmake认为汇编环境asm不可用。

折腾了一下，还是不行，那就直接CPU吧，慢点就慢点？

结果。。。

image-20260419145907067

对，没错，成功把gemma4:31b干懵了，我也是头一回儿在AI身上感到明显的慌乱感

同时我们也确认了，visual studio编译组件没有缺失，CUDA Toolkit也没有；

gemma4经过深思熟虑之后认为这一切的核心矛盾点就是：这两货版本太新了，导致 CMake 内部的探测机制失效了——它不认识这个版本的 VS，所以它不知道去哪里找 Windows 默认的汇编器 ml64.exe

# 1. 先清理
rmdir /s /q build

# 2. 运行 cmake，手动指定 ASM 编译器
cmake -B build -DCMAKE_ASM_COMPILER="C:/Program Files/Microsoft Visual Studio/18/Community/VC/Tools/MSVC/14.50.35717/bin/Hostx64/x64/ml64.exe"

这个路径你要找你自己的实际路径啊

CPU验证是成功的，于是我寻思着，这波算成功了那我不又可以开启GPU加速了吗

# 1. 先清理
rmdir /s /q build

# 2. 运行 cmake，手动指定 ASM 编译器
cmake -B build -DGGML_CUDA=ON -DCMAKE_ASM_COMPILER="C:/Program Files/Microsoft Visual Studio/18/Community/VC/Tools/MSVC/14.50.35717/bin/Hostx64/x64/ml64.exe"

然后又炸了，嘻嘻，感觉自己要疯了哈哈

报错，CUDA Toolkit found，为什么紧接着又说 No CUDA toolset found

拿着回显丢gemma4:31b，经过一段时间的头脑风暴，它说：NVIDIA 的 CUDA 安装程序在安装时，会扫描电脑上的 Visual Studio 版本。如果它发现安装的是 Visual Studio 18 2026（一个极其前卫的版本），而 CUDA 13.0 的安装程序只认识 Visual Studio 2022 (v17)，它就会跳过为 VS 18 安装集成插件。

结果就是：CUDA 软件装好了，但它没有把“接头”安装到你的 Visual Studio 18 中。 CMake 找不到这个“接头”，所以报错。

所以我直接在官方下的预编译好的版本来用了，不然心太累了

2026年6月19日

因为前阵子电脑坏了，开始了重装系统之旅，还得把环境重新配置一遍

经过这次的尝试，NVIDIA已经推出更新的CUDA Toolkit了，然后这个时候开始意识到事情的不对劲，之前装的是vs2026，因为CUDA Toolkit版本不够，还识别不到vs2026，现在可以了，装了更新的CUDAToolkit的13.3版本，也是顺利搞定了

接着就是llama.cpp的使用了