GGUF与llama.cpp实战：CPU本地部署大模型全指南

很多人一听到“本地部署大模型”，第一反应就是“我显卡不行”，然后直接放弃。这个反应我太熟悉了，因为我之前也一样。直到我真正动手试了一遍 GGUF + llama.cpp 的 CPU 推理方案，才意识到：在资源有限的机器上，大模型不是不能跑，而是需要换一种部署思路。

这篇文章是本地部署系列第二篇，专门把 GGUF/llama.cpp 这条轻量化部署路线讲透。不管你是只有一台老笔记本、不想让数据出内网，还是纯粹想搞明白量化、上下文、线程这些概念到底是怎么回事，这篇文章都能让你少走不少弯路。我会从原理讲到选型，再从实测调优讲到踩坑排查，全程用普通用户能直接照做的命令和参数，最后给出可以扩展的服务化玩法。

适合谁看：内存 8GB 以上、没有独立显卡、只有一张老旧显卡，或者单纯想低成本接触大模型的开发者和折腾爱好者。不适合谁看：指望 CPU 跑出云端 GPU 那种秒回体验的人。先把期望调低一点，CPU 推理的定位是“够用、可控、随时跑”，而不是“高性能、高吞吐”。

1. 为什么偏要在 CPU 上跑大模型

1.1 “没有 GPU 不是错”的底气从哪里来

先说一个很多人会忽略的事实：一个 70 亿参数规模的开源模型，经过 4bit 量化之后，体积只有 4GB 到 5GB 左右。这不是一个天文数字，一台普通办公电脑的 DDR4 内存都有 16GB 甚至 32GB。也就是说，除了一颗正常工作的 CPU，你不需要任何额外硬件，就已经满足了运行条件。

我自己的实测感受是：在一台八核 CPU、双通道内存的普通台式机上，跑 70 亿参数模型的 Q4_K_M 量化版，生成速度大约在每秒 8 到 15 个 token。换算成人话，就是每秒蹦出十几个字。这个速度确实比不上显卡，但用来做实验、调 prompt、验证想法、写点日常问答，完全能忍。

很多人不是机器不行，而是被“大模型必须用 GPU”的说法吓住了。实际跑起来之后你会发现，CPU 推理最大的门槛不在硬件，而在部署姿势。姿势对了，老机器一样能弯道超车。

1.2 哪类场景真的适合 CPU 推理

不是所有任务都适合用 CPU 跑。我的经验是，先分清场景再决定方案，比盲目上 GPU 更理性。下面这张表可以帮你快速判断：

一个容易被忽略的点是：CPU 方案没有显存溢出问题，也没有驱动兼容问题。你用一张老显卡跑大模型，反而可能被显存容量卡死，CPU 方案只要内存够，就能一直稳稳运行。对很多个体开发者和学生来说，这种“不怕跑崩”的确定性，比速度重要得多。

1.3 三个反直觉的事实

第一个反直觉点：大模型推理的瓶颈通常不在 CPU 计算能力，而在内存带宽。生成每个 token 时，模型都要把全部权重从内存里读一遍。70 亿参数的 Q4 量化模型，权重约 4GB 多，每生成一个字就得搬运 4GB 数据。所以内存通道数、频率这些指标，对推理速度的影响远超核心数。这也是为什么我看到有人给老电脑超频内存之后，token 速度直接涨了将近一倍——因为瓶颈根本不在 CPU 那颗芯片里。

第二个反直觉点：量化模型不仅体积小，速度反而更快。权重从 16bit 压缩到 4bit，等于每次搬运的数据量变成原来的四分之一。省下来的搬运时间，就是实打实的性能提升。所以同样一个模型，Q4 量化版通常比原始精度版本跑得更快。

第三个反直觉点：llama.cpp 的启动速度非常快。它直接把模型文件映射到内存，不需要像传统推理框架那样先加载 Python 运行环境、构建计算图，再等模型初始化。很多时候，命令敲下去几秒钟就能看到第一个字蹦出来。这种“开机即用”的感觉，是 CPU 部署很容易让人入坑的原因。

2. GGUF 和 llama.cpp 到底解决了什么问题

2.1 GGUF 究竟是一种什么格式

GGUF 是 llama.cpp 社区主导的一种模型打包格式，现在基本成了本地部署的事实标准。它把模型的权重、词表、超参数、采样配置、tokenizer 信息统一打成一个文件，还支持分片存储。对使用者来说，最直观的好处是：一个模型就是一个文件，拷贝到哪里都能跑，不需要额外准备一堆配置文件。

用生活里的例子类比，GGUF 就像把食材、调料、菜谱全部装进一个真空料理包里。你不需要自己搭配，拿出来按步骤加热就能吃。量化则是这个料理包的“压缩工艺”：原本每个权重是 16bit 或 32bit 的浮点数，占用的空间很大，量化后压缩成 4bit 或 5bit 的整数，体积大幅缩小。

量化不是无损的，它是把连续分布的权重值映射到有限的离散档位上。听起来很“暴力”，但实践下来，大部分任务里质量损失是可控的，尤其是 4bit 以上的量化，普通问答、代码生成、资料整理这类场景基本感觉不到明显的智力下降。这也是 GGUF 能流行起来的根本原因：用少量精度换体积和速度，这笔账在本地 CPU 部署里非常划算。

2.2 llama.cpp 为什么能做到轻量

llama.cpp 这个项目的核心吸引力在于“轻”。它是用 C/C++ 实现的推理引擎，不依赖 Python 运行时，也不需要安装一大堆第三方包。整个项目编译之后，就是几个可以直接执行的原生程序，传到任何同架构的系统上就能运行。

传统推理方案在 CPU 上跑之所以难受，是因为中间隔了太多层：Python 解释器、框架封装、动态图优化、算子调度。每一层都有开销，最后真正留给计算的资源其实不多。llama.cpp 选择全部自己来，针对 x86 的 AVX2、AVX512 指令集和 ARM 的 NEON 指令集做了深度优化，把“读权重、算注意力、采样输出”这一整条链路塞进了尽可能少的指令里。

轻量带来的另一个好处是透明度高。它没有把复杂逻辑藏在黑盒里，日志会直接告诉你模型加载了多少层、上下文缓存用了多少内存、每个阶段的耗时是多少秒。这对排查故障、调优参数来说，简直不要太友好。我自己调试的时候，基本都是靠它输出的那几行 verbose 日志定位问题的。

2.3 量化级别到底怎么选

GGUF 文件名里那串字母，比如 Q4_0、Q4_K_M、Q5_K_M，就是量化级别的标识。很多人第一次看到会发懵，我直接给你一张速查表，以 70 亿参数模型为例：

K 系列是“智能量化”的产物，原理很有意思：模型里不是所有层都同等重要，K 量化会对关键层用更高精度，对不那么重要的层用更低精度，整体达到一个“同样的体积下质量更好”的效果。所以 Q4_K_M 虽然在文件名上只比 Q4_0 多了一个 K_M，实际质量差距比很多人想象的要大。

我的建议非常直接：普通人默认选 Q4_K_M。如果内存特别吃紧，退到 Q4_0；如果内存充足、又在意输出质量，升到 Q5_K_M 或 Q6_K。不要一上来就追求 Q8_0 或 F16，因为 CPU 推理的速度和体积直接挂钩，尺寸越大，搬运权重越慢，体验反而可能更差。

3. 动手之前先算账：模型、内存与 CPU 怎么匹配

3.1 内存需求估算公式

部署之前先算内存账，这步省不了。否则你模型下到一半发现内存不够，前面的时间全白费。估算逻辑不复杂，主要是三部分：模型文件大小 + 上下文缓存 + 系统余量。

模型文件大小可以粗略算：一个 70 亿参数的模型，按每参数 4bit 均值算，理论上是 70 亿 × 4bit ÷ 8 ≈ 3.5GB。但 GGUF 里除了主体权重，还有词表、层的 norm 参数等会用更高精度存储，所以实际文件大约 4 到 5GB，直接看下载列表里的文件大小就行。

上下文缓存这部分，很多人会漏算。推理时模型会维护一个 KV cache，用来缓存已生成的上下文。它的体积跟上下文长度强相关，粗略计算是：2 × 层数 × KV 头数 × 头维度 × 上下文长度 × 每项字节数。拿一个常见的七十几亿参数模型举例，32 层、8 个 KV 头、每个头 128 维，用 fp16 缓存长度 4096 的上下文，算下来大约占用 500MB 到 1GB。

所以一个 16GB 内存的机器，跑 7B Q4_K_M + 4096 上下文是绰绰有余的，总共也就吃掉 6GB 左右。8GB 内存的机器能跑，但会比较紧张，建议把上下文降到 2048，同时关掉其他大型应用。如果是 130 亿参数规模的 Q4 模型，单文件大约 8.5GB，加缓存后 16GB 内存属于“能跑但危险”的档位，32GB 才稳。

3.2 CPU 性能怎么匹配

内存带宽决定速度，但 CPU 核心数决定“能不能跑得动”。我自己画了一张经验表，按照不同硬件的实际水准做了个划分，方便你对号入座：

这里要再次强调：表格里的速度参考值不只是依赖核心数，更依赖内存通道和频率。单通道内存跑 7B，速度直接会跌掉三到四成。如果你的机器是四核配单通道内存，别硬上 13B 模型，老老实实从 1B 到 7B 起步，先把流程跑通。

3.3 选哪个模型和版本

选模型的第一个原则：优先选带 GGUF 版本的对话模型，不要自己从原始权重手动转换。社区里有很多已经转好的 GGUF 文件，文件名会明确标注量化级别。你只需要找到和自己硬件匹配的那一档，下载即可。这个过程比大多数人想象中简单，根本不用碰转换脚本。

第二个原则：解读文件名。看到xxx-7b-q4_k_m.gguf这类名字，前半部分是模型系列和参数规模，后半部分就是量化标识。不认识的量化后缀，就按我前面那张表对照，选 Q4_K_M 起步基本不会出错。

第三个原则：先小后大。第一次跑通流程时，先用一个最小的模型把命令、参数、网络环境都验证一遍，再换目标模型。很多人急着直接下 13B，结果下载了几个小时，运行时报内存不足，体验非常挫败。我建议你先跑一个 1B 或 4B 的模型，确认整条链路没问题，再去追求更聪明的效果。

下载方面提醒一句：这些模型文件动辄好几个 GB，下载过程容易中断。下载完之后最好用文件校验值确认一下完整性，不然加载时报错会让人一头雾水。校验方法后面踩坑部分我再展开。

4. 从零到跑通：编译部署全流程

4.1 获取 llama.cpp：下载 Release 还是源码编译

拿到 llama.cpp 有两条路：一是直接用官方发布的预编译包，二是自己编译。我的建议是，Windows 用户优先用预编译包，省事、稳定，开箱即用。Linux 和 mac 用户，如果没有特殊要求，也建议先用预编译包把流程跑通。

如果后续发现性能不理想，或者想用最新的特性，再尝试自己编译。源码编译的逻辑很简单，就是把仓库拉下来，用 CMake 构建。需要注意一个参数：-DLLAMA_NATIVE=ON，它的意思是让编译器针对本机 CPU 的特性做原生优化，启用当前 CPU 支持的高级指令集。这个参数对推理速度的影响非常明显，如果你发现自己的跑分比同类配置低一截，八成是这一步没做好：

git clone <源码仓库地址> cd llama.cpp cmake -B build -DLLAMA_NATIVE=ON -DCMAKE_BUILD_TYPE=Release cmake --build build -j$(nproc)

编译完成之后，所有可执行文件都在build/bin/目录下。我最常用的就是两个：llama-cli用来做命令行对话，llama-server用来启动一个本地 API 服务。

4.2 最小对话命令：llama-cli

第一次跑通对话，建议用最小命令，不要加一堆花里胡哨的参数。把模型路径换成你的实际文件路径：

llama-cli -m ./models/my-model-7b-q4_k_m.gguf -p "用一句话解释什么是量化" -n 256 -t 8

命令拆开看就四件事：-m指定模型文件，-p输入提示词，-n限制最多生成 256 个 token，-t指定用 8 个线程。线程数这里先别较真，设置成和你 CPU 物理核心数差不多就行，后面调优部分再细说。

正常情况下，几秒钟后终端里会开始蹦字，输出一句关于量化的解释。如果你看到一堆乱码或者奇怪的符号，先别慌——很大概率是模型词表和你提示词的编码不匹配，或者量化文件本身有问题。换一个带中文对话能力的模型重新测试往往就能解决。

第一次跑通这个命令，你的本地部署计划等于成功了一半。因为最繁琐的环节：模型下载、格式识别、推理链路，都已经打通了。接下来所有进阶玩法都建立在这一步之上。

4.3 跑一个本地 API：llama-server

命令行对话只是开胃菜，真正实用的是llama-server。它会起一个本地服务，对外提供兼容常见 HTTP API 的接口，这样你就可以用任何语言写调用代码，甚至让其他本机工具直接对话。

启动命令同样很朴素：

llama-server -m ./models/my-model-7b-q4_k_m.gguf --host 127.0.0.1 --port 8080 -c 4096 -t 8

这里多了一个-c 4096，代表上下文长度是 4096 个 token。建议第一次就把上下文设到一个能用的水平，默认几百个 token 的配置聊几句话就会“失忆”，体验很差。启动成功后，浏览器打开http://127.0.0.1:8080，能看到一个简单的网页聊天界面，可以直接和模型对话。

这一版服务内置了网页端，对初学者特别友好，不需要额外部署任何前端项目。等你把基本流程跑熟之后，再考虑用第三方界面，或者自己写脚本调接口。

4.4 第三方前端怎么接

到了这步，你手里的本地服务已经是一个标准接口了。现在市面上很多常见的开源聊天前端，都支持把 API 地址指向本地端口。配置时只需要把默认地址改写成http://127.0.0.1:8080，模型名称填你部署时的名称，基本就能直接对话。

这里有个小技巧：用第三方前端的好处不是聊天界面好看，而是你能拿到工具调用、多轮会话管理这些能力。自己写一套会话管理代码其实挺花时间的，直接复用现成的开源前端，可以把精力全部集中在模型本身的应用开发上。

5. 压榨 CPU 性能的调优姿势

5.1 线程不是越多越好

很多人一看-t参数就以为自己电脑有 16 个线程，应该填 16。实际跑下来你就会发现：线程数量超过物理核心数之后，速度不升反降。原因很简单，超线程只是把物理核的闲置资源“假装”成另一个核，但推理任务本身是密集计算型任务，大量线程同时抢资源会导致调度开销暴涨，反而拖慢速度。

我自己的实测数据，在八核十六线程的机器上跑同一个 7B 模型：

看到没有，最优值正好是物理核心数 8，再往上全是负收益。所以调参第一步，先查清楚你的 CPU 物理核数，别被设备管理器里的“16 线程”忽悠了。如果你用的是 Linux，可以用lscpu查看Core(s) per socket这一行。

还有一个容易忽略的问题：后台运行的杀毒软件、浏览器、网盘客户端会抢占 CPU 核心。跑推理测试的时候，尽量关掉不必要的后台程序，多线程推理对这种干扰非常敏感。

5.2 上下文长度与 KV cache 的取舍

上下文长度是性能调优里最容易踩坑的地方。不少人喜欢把-c直接拉满，比如 8192 甚至 32768，觉得上下文越长越厉害。但代价是：KV cache 内存占用线性增长，推理时每一层都要反复读写这些缓存，速度明显下降。

正确的思路是“够用就好”。日常问答、资料总结，4096 已经足够覆盖绝大多数场景。如果你只是想测试模型能不能记住很长的内容，再考虑 8192。内存吃紧的机器，先把-c降到 2048 试试，往往速度和稳定性都会改善不少。

这里还要提一个内存相关的关键参数：--mlock。默认情况下 llama.cpp 会把模型文件映射到虚拟内存，操作系统可能随时把一部分数据交换到磁盘，一旦发生磁盘交换，推理速度会直接跌到崩溃级别。加上--mlock可以把模型锁在物理内存里，防止被换出。特别是主机同时跑着其他应用时，这个参数能有效稳定速度。

5.3 采样参数：决定体验，不决定速度

--temp、--top-p、--repeat-penalty这些参数不影响速度，但直接影响输出质量。很多人第一次跑模型，默认参数下中文大量重复，就以为是模型太笨，其实是采样器在“放飞自我”。

我常用的一组稳妥参数如下：

--temp 0.7 --top-p 0.9 --repeat-penalty 1.1

temp控制随机性，0.7 是创造力和稳定性的平衡点；top-p限制候选 token 的范围，0.9 比较中庸；repeat-penalty对重复 token 做抑制，1.1 能有效减少“哈哈哈……”、“好的好的……”这种死循环。遇到输出重复严重时，优先调高repeat-penalty，而不是盲目降低temp。

5.4 真正影响速度的隐藏参数

有几个参数不太显眼，但对 CPU 推理的实际性能影响很大，官方文档往往一笔带过。

第一个是--batch-size。它控制预填充阶段一次性处理多少个 prompt token。默认值偏小，如果 prompt 很长，比如几千字的文档摘要，预填充阶段会非常慢。把--batch-size提高到 1024 或 2048，通常能让长篇输入的首字延迟明显下降。注意，这是预填充阶段的优化，对生成阶段帮助不大。

第二个是--flash-attn。名字叫 Flash Attention，常被误解为 GPU 专属。实际上它在 CPU 版本里也有作用，主要是减少 KV cache 的占用和部分计算量。如果你的版本支持，建议加上，内存紧张时能省出不少缓存空间。

第三个是双通道内存的检查。前面已经反复提到内存带宽的重要，这里再提一个具体操作：开机任务管理器里看内存插槽数，如果明明插了两根内存条，却显示“单通道”，多半是插错位置了。你不需要换任何硬件，只调整插槽顺序，推理速度就可能提升两三成，这是我见过性价比最高的“免费升级”。

调优参数组合我的习惯是：

6. 实操踩坑全记录：从下载失败到输出乱码的排查链路

6.1 模型文件下载不完整导致加载失败

这个坑我踩过不止一次。症状是：运行llama-cli时，日志走到一半弹出failed to load model之类的报错，然后直接退出。第一次遇到时，我下意识排查模型路径、权限，甚至重装了一遍程序，最后发现纯粹是文件下载不完整。

几个 GB 的文件，用浏览器直接下载特别容易在中间断掉，但浏览器有时会显示下载成功。解决办法是：下载后做一次完整性校验。模型托管页一般都会给出对应的 SHA256 值，下载后用下面的命令核对：

sha256sum ./models/my-model-7b-q4_k_m.gguf

把得到的哈希值和页面上的比对，一致才说明文件完好。如果对不上，需要重新下载，并且建议改用支持断点续传的多线程下载工具，而不是浏览器单线程下载。

从这里可以总结一套排查思路：先确认文件完整 → 再确认命令参数 → 最后怀疑量化级别。很多人一上来就怀疑模型本身有问题，其实 GGUF 文件经不起折腾的部分就是传输损坏，其他环节出问题的概率很低。

6.2 内存不足导致进程被杀

症状更直接：运行一段时间后，终端弹出Killed或者直接没有响应，后台看模型进程已经消失。这种多半是内存不够用，系统触发 OOM 保护把进程干掉了。

排查链路两步走。第一步，看物理内存还剩多少；第二步，算一下当前模型加上下文的实际占用。以 7B Q4_K_M + 4096 上下文为例，大约需要 5 到 6GB 内存。如果你的机器只剩 3GB 可用，那就不是“能不能跑”的问题，而是“会被杀”的问题。

解决方案按优先级排列：换更小的量化文件，比如 Q4_0；把上下文从-c 4096降到-c 2048；关掉浏览器和其他常驻程序；最后再考虑换更小规模的模型。想省事的话，Linux 下可以先跑free -h，Windows 下直接看任务管理器，做到心里有数再开跑。

6.3 中文乱码、重复、答非所问的连锁反应

如果模型输出的是乱码，最常见的原因不是模型坏了，而是你用了没有中文词表的模型，或者提示词编码不对。解决办法是换一个明确支持中文的对话模型，然后先用中文测试提示词验证词表。

如果输出是正常中文但反复重复同一句话，那就是采样参数的问题。模型在低重复惩罚下容易陷入局部循环，输出“好的好的好的……”这种情况。处理方案是提高--repeat-penalty，比如从默认的 1.0 调到 1.15，同时把--top-p降到 0.9。如果还是重复，再逐步加大惩罚值。

还有一种常见情况是“答非所问”——你问东，它答西。这个问题通常不是 bug，而是模型没有遵循角色的指令。检查你是否给了足够的系统提示词，或者换用经过指令微调的对话模型版本。原始基础模型在对话任务上表现确实会差一截，这不是 CPU 方案的锅。

6.4 速度异常慢的完整排查链路

如果你觉得自己电脑配置不差，但推理速度远低于预期，按下面这个顺序排查，基本能定位问题。

第一，确认线程数。-t有没有设置成物理核心数？前面说的“线程越多越慢”是真实存在的坑。第二，确认编译优化。如果你是源码编译，-DLLAMA_NATIVE=ON打开了吗？预编译包也要确认自己下载的是针对当前架构的版本。第三，确认内存通道。任务管理器看是不是双通道，系统是不是把内存条插错了位置。第四，确认后台负载。是不是有浏览器、同步盘、杀毒软件在抢 CPU 和内存带宽。

如果上面四项都正常，速度还是慢，那可能就是硬件本身的瓶颈，比如笔记本的散热限制、或者内存频率只有 2133MHz。这时就不要硬追求速度了，换成更小的量化模型，效果立竿见影。

7. 从命令行玩具到日常工具：服务化部署与扩展玩法

7.1 用 llama-server 提供标准接口

走到这一步，你的本地模型已经不只是命令行玩具了。llama-server起的服务默认监听在127.0.0.1:8080，随便用一个 HTTP 请求就能调用。下面是一个最简单的调用示例：

curl -s http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"my-model-7b-q4_k_m","messages":[{"role":"user","content":"你好，介绍一下你自己"}]}'

返回的 JSON 结构和常见的云服务接口格式一致，包含choices、message、content这些字段。这意味着你之前写的任何调用云模型的项目，都可以把接口地址改一下直接指向本地。我在一个内部小工具里试过，改动量基本就是改一个 base_url 配置。

如果想让局域网内其他设备也用这个服务，把--host改成0.0.0.0即可。但要提醒一句：这样会有安全风险，这个服务默认没有鉴权，别人拿到地址就能调用。用在可信内网没问题，远程暴露还是要自己套一层鉴权。

7.2 再进一步：给模型配上本地知识库

本地部署的第二大价值，是能和你的私人文档打通，做一个不吃隐私的本地知识库。传统做法需要调用云端的模型接口做向量化，但 llama.cpp 也支持 embedding 模型推理，你完全可以把向量化这步也留在本地。

具体玩法不复杂：先用文本切块工具把文档切成小段，再用本地 embedding 接口把每段转成向量，存入向量数据库。查询时，先转出问题向量，检索最相关的文档片段，再连同问题一起交给大模型生成答案。整条链路都是本地跑的，文档不出机器，适合处理合同、笔记、内部资料这类内容。

我提醒一句：7B 量级的模型做知识库问答，效果只能说“够用”。复杂推理、长文档精读还是会露怯。但用来做个人笔记检索、公司内部 FAQ 这种轻量场景，已经能带来实际价值了。关键是整条链路的学习成本很低，周末花几个小时就能搭出来。

7.3 如果有一块老旧显卡：CPU+GPU 混合推理

有人问说“我有老显卡但显存只有 4GB，是不是完全没用？”其实不完全是。llama.cpp 提供了一个-ngl参数，意思是把模型的前 N 层交给 GPU 计算，剩下的层继续由 CPU 承担。

比如跑一个 7B 模型，显存 4GB 的情况下，可以尝试-ngl 20左右，让一部分层跑在 GPU 上。显存不够的部分，模型会自动把权重留在内存里让 CPU 算。这种做法不会发挥显卡全部实力，但通常能让速度比纯 CPU 高出一些，而且不会出现显卡跑不动就崩的问题。

要注意看启动日志。它会明确告诉你有多少层被卸载到 GPU 上，每秒生成速度是多少。如果-ngl设置得太大，显存不够会直接报错，此时减少层数就行。这个混合模式的优势在于“有多少显存都能用起来”，不会浪费已有硬件。

7.4 写在最后：我的真实体会

玩了一圈 CPU 推理之后，我对“本地部署”这件事的看法有了很大变化。CPU 跑大模型确实慢，但它给了我一种 GPU 方案给不了的心安：模型是我自己的，数据不出机器，断网也能用，想改采样参数、换量化版本、定制接口，全部都可以动手折腾。

我现在的新习惯是：接到一个新任务，先拿小的量化模型跑通流程，再根据结果决定要不要换更大的模型。这条路线最大的成本不是机器，而是耐心。我的建议是，内存 16GB 以上的机器，从 7B 的 Q4_K_M 开始起步；内存小一些的，先跑 1B 到 4B，一样能把部署、调优、服务化这一套流程练熟。等哪天你发现自己在调--repeat-penalty比调模型还熟练的时候，你已经比很多嘴上谈大模型、实际一行命令都没跑过的人走得更远了。