1. 先搞清楚 27B 这个体量到底卡在哪很多人一上来就问27B 要几张卡这个问题本身就问偏了。27B 参数量的模型真正决定你能不能跑起来、跑得爽的不是卡的数量而是显存带宽、显存容量、量化档位这三者之间的平衡。我见过太多人买了双卡结果发现单卡量化后反而更流畅也见过有人死磕 FP16 结果 OOM 到怀疑人生。先把账算清楚。27B 参数如果按 FP16 存储光权重就要 27 × 2 54GB。这还没算 KV Cache、激活值、框架本身的显存开销。实际部署时FP16 下你至少需要 64GB 以上的显存才能比较从容这意味着单张消费级卡基本没戏得上专业卡或者多卡并联。但量化就是另一回事了。量化的本质是用更低的精度存储权重牺牲一点点精度换取大幅度的显存节省。常见的档位有这么几档量化档位每参数字节27B 权重显存精度损失适用场景FP162.0~54GB无精度敏感、多卡INT8 / Q81.0~27GB极小单卡 32G 可跑Q6_K~0.82~22GB很小单卡 24G 勉强Q5_K_M~0.68~18.5GB小单卡 24G 舒适Q4_K_M~0.56~15GB可接受单卡 16G 起步Q3_K_M~0.43~11.6GB明显显存紧张时Q2_K~0.33~9GB较大应急这张表是我自己反复实测后整理的不同量化工具的具体数值会有小幅浮动但量级不会差太多。你可以把它当成选档位的基准线。关键结论先给出来如果你只有一张 24GB 的卡Q5_K_M 是甜点档如果只有 16GBQ4_K_M 是底线如果连 12GB 都不到那 27B 这个体量对你来说就不太现实了建议换更小的模型。为什么 Q4_K_M 被这么多人推荐因为它在精度和显存之间找到了一个很好的平衡点。K_M 代表的是 K-quant 的 medium 版本它对模型里不同的层用了不同的量化策略——注意力层的权重保留得精细一些FFN 层压得狠一些。这种混合策略让 Q4_K_M 的实际表现往往接近 Q5但显存占用明显更低。1.1 显存之外你还得留出 KV Cache 的空间很多人算显存只算权重这是新手最容易踩的坑。KV Cache 的大小跟你的上下文长度直接相关公式大致是KV Cache ≈ 2 × 层数 × 注意力头数 × head_dim × 序列长度 × 精度字节27B 级别的模型层数通常在 40-60 层之间。如果你要跑 8K 上下文KV Cache 轻松吃掉 4-8GB。所以选量化档位的时候权重显存 KV Cache 框架开销才是你真正需要的总显存。我的经验是在权重显存的基础上至少再留 20%-30% 的余量给 KV Cache 和运行时开销。比如 Q5_K_M 权重占 18.5GB那你的卡最好有 24GB这样跑 4K-8K 上下文才稳。1.2 量化档位不是越低越好得看你的任务类型这里有个反直觉的点不是所有任务都对量化敏感。做文本分类、信息抽取这类任务Q4 和 Q8 的差距你基本感觉不到因为这类任务对模型的精细表达能力要求不高。做代码生成、数学推理量化损失就会被放大Q4 下模型可能开始犯一些低级错误Q5 以上会明显更稳。做长文写作、创意生成Q5_K_M 和 Q6_K 的差异主要体现在用词的丰富度上Q4 有时候会显得词穷。所以选档位之前先问自己我主要拿这个模型干什么如果只是做个内部问答机器人Q4_K_M 完全够用如果要做代码助手建议至少 Q5_K_M。2. 量化工具怎么挑GGUF 还是 GPTQ确定了档位接下来是选量化格式和工具。目前主流就两条路线GGUF配合 llama.cpp 系和GPTQ/AWQ配合 transformers 系。这两条路线的选择直接决定了你后面的部署方式。GGUF 的优势在于部署极其简单一个文件搞定CPU 和 GPU 混合推理都支持llama.cpp、ollama、LM Studio 这些工具都能直接吃。缺点是纯 GPU 推理时吞吐量不如 GPTQ 优化得好。GPTQ/AWQ 的优势在于和 transformers 生态无缝集成vLLM、TGI 这些高性能推理框架对它的支持更好适合做服务化部署。缺点是你得自己处理模型加载、显存分配这些细节。我的建议很直接个人本地玩、单机部署、追求省心→ GGUF要做 API 服务、要高并发、要多卡→ GPTQ 或 AWQ对于 27B 这个体量如果你只有单卡我强烈建议走 GGUF 路线。原因很简单llama.cpp 对显存的管理非常聪明它可以把一部分层放在 GPU 上一部分放在 CPU 上甚至支持把 KV Cache 放到 CPU 内存里。这意味着你 16GB 的卡也能跑起来 Q5 的 27B只是速度会慢一些。2.1 自己量化还是下现成的这是个很实际的问题。自己量化需要原始 FP16 权重54GB 下载量、足够的磁盘空间、量化脚本、以及可能几个小时的等待时间。下现成的则省事得多社区里通常有人已经量化好了各种档位。我的做法是先下现成的 Q4_K_M 试跑确认模型能力符合预期后再决定要不要自己量化更高档位。因为量化这个过程本身不产生价值它只是格式转换。除非你有特殊需求比如要特定的量化配置否则没必要自己从头做。如果确实要自己量化GGUF 的流程大致是# 1. 准备 FP16 原始权重转成 GGUF 格式 python convert_hf_to_gguf.py ./model-fp16 --outfile model-f16.gguf --outtype f16 # 2. 执行量化以 Q5_K_M 为例 ./llama-quantize model-f16.gguf model-Q5_K_M.gguf Q5_K_M # 3. 验证量化结果 ./llama-cli -m model-Q5_K_M.gguf -p 测试一下 -n 32这里有个细节convert 脚本的版本要和 llama.cpp 的版本匹配。我踩过一次坑用旧版脚本转出来的 GGUF 在新版 llama.cpp 里加载报错折腾了半天才发现是版本问题。所以建议直接从 llama.cpp 仓库拉最新代码自己编译保证工具链一致。2.2 量化时的线程数和内存注意事项自己量化的时候llama-quantize默认会用满所有 CPU 核心。如果你的机器同时还在跑别的任务建议用--threads参数限制一下不然会把系统卡死。另外量化过程需要把整个 FP16 模型读进内存所以内存至少要 64GB否则会频繁 swap慢到你想砸键盘。还有一点量化输出的文件会占用和输入差不多大的磁盘空间Q5 大约 19GB确保你的磁盘有足够余量。3. 终端配置别只盯着显卡这几个参数才是关键终端配置这个词容易被理解成买什么显卡但实际上模型跑起来之后的体验很大程度上取决于你怎么配置运行参数。同样的硬件参数调得好和调得差速度能差一倍以上。3.1 上下文长度够用就好别贪大上下文长度context length是影响显存和速度的最大变量之一。很多人一上来就设 32K结果发现显存爆了或者速度慢得没法用。我的建议是按实际需求设日常问答、短文本处理 → 4K 足够长文档摘要、多轮对话 → 8K代码库分析、超长文本 → 16K 以上在 llama.cpp 里上下文长度通过-c参数控制。注意这个值是总上下文包括你的输入和模型输出。如果你设了 8K输入占了 6K那模型最多只能再生成 2K。./llama-server -m model-Q5_K_M.gguf -c 8192 -ngl 99这里的-ngl 99表示把所有层都放到 GPU 上。如果你的显存不够可以调小这个值比如-ngl 35让一部分层留在 CPU 上。3.2 GPU 层数-ngl显存和速度的调节旋钮-ngl是 llama.cpp 里最重要的参数之一。它决定了有多少层模型跑在 GPU 上。值越大GPU 承担的计算越多速度越快但显存占用也越高。怎么找到最优值我的方法是二分法先设-ngl 99看能不能加载成功如果 OOM减半到-ngl 50再试逐步逼近直到找到一个既不 OOM 又尽量大的值实测下来27B 的 Q5_K_M 在 24GB 卡上-ngl通常能设到 45-55 之间取决于具体模型层数。剩下的层跑在 CPU 上速度会降一些但至少能跑。提示-ngl设得过高导致 OOM 时llama.cpp 有时不会明确报错而是直接崩溃或者卡住。所以调整这个参数时建议一次只改 5-10别一次跳太多。3.3 批处理大小和并行数如果你要做服务化部署-bbatch size和-np并行请求数这两个参数很关键。-b控制单次处理的 token 数默认 512。调大能提升吞吐但吃显存。-np控制同时处理多少个请求。每个请求都会占用独立的 KV Cache 空间。对于单卡 24GB 跑 27B Q5我的经验是-b 256 -np 2比较稳。如果你想支持更多并发就得降量化档位或者加卡。3.4 一个容易被忽略的参数--no-mmap--no-mmap这个参数默认是关闭的意思是 llama.cpp 会用内存映射的方式加载模型文件。这在大多数情况下是好事加载快、内存占用低。但在某些文件系统上比如网络挂载的存储mmap 会导致加载异常慢。如果你发现模型加载时间长得离谱可以试试加上--no-mmap强制把模型读进内存。代价是启动时占用更多内存但加载速度会稳定很多。4. 从零到跑通的完整实操链路前面讲了原理和参数这一节把整个流程串起来给你一条可以直接照着走的路径。我假设你的场景是单卡 24GB想跑 27B 模型做本地问答或轻量服务。4.1 环境准备编译 llama.cpp第一步是拿到 llama.cpp。不要用系统包管理器里的版本那些往往太旧。直接从源码编译git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 如果有 NVIDIA 卡开启 CUDA 支持 cmake -B build -DGGML_CUDAON cmake --build build --config Release -j $(nproc)编译完成后build/bin/目录下会有llama-server、llama-cli、llama-quantize等可执行文件。编译时如果报 CUDA 相关的错八成是 CUDA Toolkit 版本和驱动不匹配。用nvcc --version和nvidia-smi对比一下确保大版本一致。4.2 下载模型选对文件很关键在模型仓库里同一个模型通常有几十个量化文件。你要找的是文件名里带Q5_K_M或Q4_K_M的那个.gguf文件。注意区分带-00001-of-00003这种后缀的是分片文件需要全部下载单个大文件的是完整文件下载一个就行分片文件下载后不用手动合并llama.cpp 会自动识别。但所有分片必须放在同一目录下且文件名不能改。4.3 启动服务并验证下载完成后用llama-server启动./build/bin/llama-server \ -m /path/to/model-Q5_K_M.gguf \ -c 8192 \ -ngl 50 \ -b 256 \ --host 0.0.0.0 \ --port 8080启动后终端会打印加载日志包括用了多少显存、多少层在 GPU 上。看到server is listening就说明成功了。然后用 curl 测一下curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { messages: [{role: user, content: 用一句话解释什么是量化}], temperature: 0.7 }如果返回了合理的回答说明整条链路通了。4.4 实测性能参考在我的测试环境单卡 24GBQ5_K_M8K 上下文-ngl 50下大致性能是指标数值加载时间约 25 秒显存占用约 21GB生成速度18-25 token/s首 token 延迟0.8-1.5 秒这个速度做本地问答完全够用做轻量 API 服务也能撑住几个并发。如果你追求更高速度要么降量化档位要么上更强的卡。5. 那些文档里不会写的踩坑经验这一节是我自己折腾过程中攒下来的网上教程基本不会提但每一个都能让你少走几小时弯路。5.1 显存够和稳是两回事你可能算出来 Q5_K_M 权重 18.5GB卡有 24GB觉得稳了。但实际跑起来随着上下文增长KV Cache 会不断膨胀跑到后面可能就 OOM 了。我的做法是按峰值需求选档位而不是按初始需求。如果你打算跑 8K 上下文就按 8K 时的总显存来算。宁可档位低一点跑得稳也不要档位高一点跑一半崩掉。5.2 温度参数对量化模型的影响被低估了量化后的模型输出分布会有轻微偏移。这时候如果 temperature 设得太高比如 1.0 以上模型容易胡言乱语因为量化损失被高温放大了。我的经验是量化档位越低temperature 越要保守。Q4 的模型temperature 建议 0.5-0.7Q5 以上可以到 0.7-0.9。top_p 也建议从默认的 0.9 降到 0.85 左右减少采样到低概率 token 的机会。5.3 别忽视 prompt 模板27B 这个级别的模型基本都有自己推荐的 prompt 模板。用错模板模型表现会明显下降甚至答非所问。llama.cpp 的llama-server支持--chat-template参数指定模板。如果你不确定用哪个可以先不加这个参数让框架自动推断。但如果你发现模型回答格式很奇怪八成就是模板不对。5.4 磁盘 IO 也会成为瓶颈模型文件 19GB每次启动都要从磁盘读。如果你用的是机械硬盘加载时间可能长达几分钟。换成 SSD 后加载时间能降到 20-30 秒。另外如果你的模型放在网络存储上--no-mmap几乎是必须的否则加载会慢到无法忍受。5.5 多轮对话时记得管理上下文llama.cpp 默认不会自动截断上下文。如果对话轮数多了总 token 数超过-c设定的值服务会报错或者行为异常。解决办法有两个一是客户端自己维护对话历史超过长度就丢弃最早的几轮二是用--context-shift之类的参数让框架自动处理。我倾向于第一种因为控制权在自己手里行为可预期。6. 不同硬件档位的配置方案最后给你几套现成的配置方案按硬件档位分。你可以直接对照自己的机器抄。6.1 单卡 24GB如 3090/4090这是最主流的配置。推荐 Q5_K_M-ngl设 45-55上下文 8K。./llama-server -m model-Q5_K_M.gguf -c 8192 -ngl 50 -b 256如果觉得速度不够可以降到 Q4_K_M-ngl能设到 60 以上速度提升明显。6.2 单卡 16GBQ4_K_M 是底线-ngl设 35-45上下文建议 4K。./llama-server -m model-Q4_K_M.gguf -c 4096 -ngl 40 -b 128这个配置下速度会慢一些大概 10-15 token/s但日常用没问题。6.3 双卡 24GB×2可以上 Q6_K 甚至 Q8-ngl 99全放 GPU上下文 16K。./llama-server -m model-Q6_K.gguf -c 16384 -ngl 99 -b 512 -np 4这个配置基本能当小型服务用了并发几个请求不在话下。6.4 只有 CPU 和大内存如果你没有像样的显卡但有 64GB 以上内存也能跑只是慢。用 Q4_K_M-ngl 0全靠 CPU。./llama-server -m model-Q4_K_M.gguf -c 4096 -ngl 0 -t 16-t 16表示用 16 个线程。速度大概 2-5 token/s适合不赶时间的场景。我个人在实际操作中的体会是27B 这个体量的模型量化档位的选择比硬件本身更能决定体验。同样的卡选对档位和参数能跑出完全不同的效果。与其纠结买什么卡不如先把现有硬件的参数调明白。很多时候你以为需要升级硬件其实只是参数没配对。
1. 先搞清楚 27B 这个体量到底卡在哪很多人一上来就问27B 要几张卡这个问题本身就问偏了。27B 参数量的模型真正决定你能不能跑起来、跑得爽的不是卡的数量而是显存带宽、显存容量、量化档位这三者之间的平衡。我见过太多人买了双卡结果发现单卡量化后反而更流畅也见过有人死磕 FP16 结果 OOM 到怀疑人生。先把账算清楚。27B 参数如果按 FP16 存储光权重就要 27 × 2 54GB。这还没算 KV Cache、激活值、框架本身的显存开销。实际部署时FP16 下你至少需要 64GB 以上的显存才能比较从容这意味着单张消费级卡基本没戏得上专业卡或者多卡并联。但量化就是另一回事了。量化的本质是用更低的精度存储权重牺牲一点点精度换取大幅度的显存节省。常见的档位有这么几档量化档位每参数字节27B 权重显存精度损失适用场景FP162.0~54GB无精度敏感、多卡INT8 / Q81.0~27GB极小单卡 32G 可跑Q6_K~0.82~22GB很小单卡 24G 勉强Q5_K_M~0.68~18.5GB小单卡 24G 舒适Q4_K_M~0.56~15GB可接受单卡 16G 起步Q3_K_M~0.43~11.6GB明显显存紧张时Q2_K~0.33~9GB较大应急这张表是我自己反复实测后整理的不同量化工具的具体数值会有小幅浮动但量级不会差太多。你可以把它当成选档位的基准线。关键结论先给出来如果你只有一张 24GB 的卡Q5_K_M 是甜点档如果只有 16GBQ4_K_M 是底线如果连 12GB 都不到那 27B 这个体量对你来说就不太现实了建议换更小的模型。为什么 Q4_K_M 被这么多人推荐因为它在精度和显存之间找到了一个很好的平衡点。K_M 代表的是 K-quant 的 medium 版本它对模型里不同的层用了不同的量化策略——注意力层的权重保留得精细一些FFN 层压得狠一些。这种混合策略让 Q4_K_M 的实际表现往往接近 Q5但显存占用明显更低。1.1 显存之外你还得留出 KV Cache 的空间很多人算显存只算权重这是新手最容易踩的坑。KV Cache 的大小跟你的上下文长度直接相关公式大致是KV Cache ≈ 2 × 层数 × 注意力头数 × head_dim × 序列长度 × 精度字节27B 级别的模型层数通常在 40-60 层之间。如果你要跑 8K 上下文KV Cache 轻松吃掉 4-8GB。所以选量化档位的时候权重显存 KV Cache 框架开销才是你真正需要的总显存。我的经验是在权重显存的基础上至少再留 20%-30% 的余量给 KV Cache 和运行时开销。比如 Q5_K_M 权重占 18.5GB那你的卡最好有 24GB这样跑 4K-8K 上下文才稳。1.2 量化档位不是越低越好得看你的任务类型这里有个反直觉的点不是所有任务都对量化敏感。做文本分类、信息抽取这类任务Q4 和 Q8 的差距你基本感觉不到因为这类任务对模型的精细表达能力要求不高。做代码生成、数学推理量化损失就会被放大Q4 下模型可能开始犯一些低级错误Q5 以上会明显更稳。做长文写作、创意生成Q5_K_M 和 Q6_K 的差异主要体现在用词的丰富度上Q4 有时候会显得词穷。所以选档位之前先问自己我主要拿这个模型干什么如果只是做个内部问答机器人Q4_K_M 完全够用如果要做代码助手建议至少 Q5_K_M。2. 量化工具怎么挑GGUF 还是 GPTQ确定了档位接下来是选量化格式和工具。目前主流就两条路线GGUF配合 llama.cpp 系和GPTQ/AWQ配合 transformers 系。这两条路线的选择直接决定了你后面的部署方式。GGUF 的优势在于部署极其简单一个文件搞定CPU 和 GPU 混合推理都支持llama.cpp、ollama、LM Studio 这些工具都能直接吃。缺点是纯 GPU 推理时吞吐量不如 GPTQ 优化得好。GPTQ/AWQ 的优势在于和 transformers 生态无缝集成vLLM、TGI 这些高性能推理框架对它的支持更好适合做服务化部署。缺点是你得自己处理模型加载、显存分配这些细节。我的建议很直接个人本地玩、单机部署、追求省心→ GGUF要做 API 服务、要高并发、要多卡→ GPTQ 或 AWQ对于 27B 这个体量如果你只有单卡我强烈建议走 GGUF 路线。原因很简单llama.cpp 对显存的管理非常聪明它可以把一部分层放在 GPU 上一部分放在 CPU 上甚至支持把 KV Cache 放到 CPU 内存里。这意味着你 16GB 的卡也能跑起来 Q5 的 27B只是速度会慢一些。2.1 自己量化还是下现成的这是个很实际的问题。自己量化需要原始 FP16 权重54GB 下载量、足够的磁盘空间、量化脚本、以及可能几个小时的等待时间。下现成的则省事得多社区里通常有人已经量化好了各种档位。我的做法是先下现成的 Q4_K_M 试跑确认模型能力符合预期后再决定要不要自己量化更高档位。因为量化这个过程本身不产生价值它只是格式转换。除非你有特殊需求比如要特定的量化配置否则没必要自己从头做。如果确实要自己量化GGUF 的流程大致是# 1. 准备 FP16 原始权重转成 GGUF 格式 python convert_hf_to_gguf.py ./model-fp16 --outfile model-f16.gguf --outtype f16 # 2. 执行量化以 Q5_K_M 为例 ./llama-quantize model-f16.gguf model-Q5_K_M.gguf Q5_K_M # 3. 验证量化结果 ./llama-cli -m model-Q5_K_M.gguf -p 测试一下 -n 32这里有个细节convert 脚本的版本要和 llama.cpp 的版本匹配。我踩过一次坑用旧版脚本转出来的 GGUF 在新版 llama.cpp 里加载报错折腾了半天才发现是版本问题。所以建议直接从 llama.cpp 仓库拉最新代码自己编译保证工具链一致。2.2 量化时的线程数和内存注意事项自己量化的时候llama-quantize默认会用满所有 CPU 核心。如果你的机器同时还在跑别的任务建议用--threads参数限制一下不然会把系统卡死。另外量化过程需要把整个 FP16 模型读进内存所以内存至少要 64GB否则会频繁 swap慢到你想砸键盘。还有一点量化输出的文件会占用和输入差不多大的磁盘空间Q5 大约 19GB确保你的磁盘有足够余量。3. 终端配置别只盯着显卡这几个参数才是关键终端配置这个词容易被理解成买什么显卡但实际上模型跑起来之后的体验很大程度上取决于你怎么配置运行参数。同样的硬件参数调得好和调得差速度能差一倍以上。3.1 上下文长度够用就好别贪大上下文长度context length是影响显存和速度的最大变量之一。很多人一上来就设 32K结果发现显存爆了或者速度慢得没法用。我的建议是按实际需求设日常问答、短文本处理 → 4K 足够长文档摘要、多轮对话 → 8K代码库分析、超长文本 → 16K 以上在 llama.cpp 里上下文长度通过-c参数控制。注意这个值是总上下文包括你的输入和模型输出。如果你设了 8K输入占了 6K那模型最多只能再生成 2K。./llama-server -m model-Q5_K_M.gguf -c 8192 -ngl 99这里的-ngl 99表示把所有层都放到 GPU 上。如果你的显存不够可以调小这个值比如-ngl 35让一部分层留在 CPU 上。3.2 GPU 层数-ngl显存和速度的调节旋钮-ngl是 llama.cpp 里最重要的参数之一。它决定了有多少层模型跑在 GPU 上。值越大GPU 承担的计算越多速度越快但显存占用也越高。怎么找到最优值我的方法是二分法先设-ngl 99看能不能加载成功如果 OOM减半到-ngl 50再试逐步逼近直到找到一个既不 OOM 又尽量大的值实测下来27B 的 Q5_K_M 在 24GB 卡上-ngl通常能设到 45-55 之间取决于具体模型层数。剩下的层跑在 CPU 上速度会降一些但至少能跑。提示-ngl设得过高导致 OOM 时llama.cpp 有时不会明确报错而是直接崩溃或者卡住。所以调整这个参数时建议一次只改 5-10别一次跳太多。3.3 批处理大小和并行数如果你要做服务化部署-bbatch size和-np并行请求数这两个参数很关键。-b控制单次处理的 token 数默认 512。调大能提升吞吐但吃显存。-np控制同时处理多少个请求。每个请求都会占用独立的 KV Cache 空间。对于单卡 24GB 跑 27B Q5我的经验是-b 256 -np 2比较稳。如果你想支持更多并发就得降量化档位或者加卡。3.4 一个容易被忽略的参数--no-mmap--no-mmap这个参数默认是关闭的意思是 llama.cpp 会用内存映射的方式加载模型文件。这在大多数情况下是好事加载快、内存占用低。但在某些文件系统上比如网络挂载的存储mmap 会导致加载异常慢。如果你发现模型加载时间长得离谱可以试试加上--no-mmap强制把模型读进内存。代价是启动时占用更多内存但加载速度会稳定很多。4. 从零到跑通的完整实操链路前面讲了原理和参数这一节把整个流程串起来给你一条可以直接照着走的路径。我假设你的场景是单卡 24GB想跑 27B 模型做本地问答或轻量服务。4.1 环境准备编译 llama.cpp第一步是拿到 llama.cpp。不要用系统包管理器里的版本那些往往太旧。直接从源码编译git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 如果有 NVIDIA 卡开启 CUDA 支持 cmake -B build -DGGML_CUDAON cmake --build build --config Release -j $(nproc)编译完成后build/bin/目录下会有llama-server、llama-cli、llama-quantize等可执行文件。编译时如果报 CUDA 相关的错八成是 CUDA Toolkit 版本和驱动不匹配。用nvcc --version和nvidia-smi对比一下确保大版本一致。4.2 下载模型选对文件很关键在模型仓库里同一个模型通常有几十个量化文件。你要找的是文件名里带Q5_K_M或Q4_K_M的那个.gguf文件。注意区分带-00001-of-00003这种后缀的是分片文件需要全部下载单个大文件的是完整文件下载一个就行分片文件下载后不用手动合并llama.cpp 会自动识别。但所有分片必须放在同一目录下且文件名不能改。4.3 启动服务并验证下载完成后用llama-server启动./build/bin/llama-server \ -m /path/to/model-Q5_K_M.gguf \ -c 8192 \ -ngl 50 \ -b 256 \ --host 0.0.0.0 \ --port 8080启动后终端会打印加载日志包括用了多少显存、多少层在 GPU 上。看到server is listening就说明成功了。然后用 curl 测一下curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { messages: [{role: user, content: 用一句话解释什么是量化}], temperature: 0.7 }如果返回了合理的回答说明整条链路通了。4.4 实测性能参考在我的测试环境单卡 24GBQ5_K_M8K 上下文-ngl 50下大致性能是指标数值加载时间约 25 秒显存占用约 21GB生成速度18-25 token/s首 token 延迟0.8-1.5 秒这个速度做本地问答完全够用做轻量 API 服务也能撑住几个并发。如果你追求更高速度要么降量化档位要么上更强的卡。5. 那些文档里不会写的踩坑经验这一节是我自己折腾过程中攒下来的网上教程基本不会提但每一个都能让你少走几小时弯路。5.1 显存够和稳是两回事你可能算出来 Q5_K_M 权重 18.5GB卡有 24GB觉得稳了。但实际跑起来随着上下文增长KV Cache 会不断膨胀跑到后面可能就 OOM 了。我的做法是按峰值需求选档位而不是按初始需求。如果你打算跑 8K 上下文就按 8K 时的总显存来算。宁可档位低一点跑得稳也不要档位高一点跑一半崩掉。5.2 温度参数对量化模型的影响被低估了量化后的模型输出分布会有轻微偏移。这时候如果 temperature 设得太高比如 1.0 以上模型容易胡言乱语因为量化损失被高温放大了。我的经验是量化档位越低temperature 越要保守。Q4 的模型temperature 建议 0.5-0.7Q5 以上可以到 0.7-0.9。top_p 也建议从默认的 0.9 降到 0.85 左右减少采样到低概率 token 的机会。5.3 别忽视 prompt 模板27B 这个级别的模型基本都有自己推荐的 prompt 模板。用错模板模型表现会明显下降甚至答非所问。llama.cpp 的llama-server支持--chat-template参数指定模板。如果你不确定用哪个可以先不加这个参数让框架自动推断。但如果你发现模型回答格式很奇怪八成就是模板不对。5.4 磁盘 IO 也会成为瓶颈模型文件 19GB每次启动都要从磁盘读。如果你用的是机械硬盘加载时间可能长达几分钟。换成 SSD 后加载时间能降到 20-30 秒。另外如果你的模型放在网络存储上--no-mmap几乎是必须的否则加载会慢到无法忍受。5.5 多轮对话时记得管理上下文llama.cpp 默认不会自动截断上下文。如果对话轮数多了总 token 数超过-c设定的值服务会报错或者行为异常。解决办法有两个一是客户端自己维护对话历史超过长度就丢弃最早的几轮二是用--context-shift之类的参数让框架自动处理。我倾向于第一种因为控制权在自己手里行为可预期。6. 不同硬件档位的配置方案最后给你几套现成的配置方案按硬件档位分。你可以直接对照自己的机器抄。6.1 单卡 24GB如 3090/4090这是最主流的配置。推荐 Q5_K_M-ngl设 45-55上下文 8K。./llama-server -m model-Q5_K_M.gguf -c 8192 -ngl 50 -b 256如果觉得速度不够可以降到 Q4_K_M-ngl能设到 60 以上速度提升明显。6.2 单卡 16GBQ4_K_M 是底线-ngl设 35-45上下文建议 4K。./llama-server -m model-Q4_K_M.gguf -c 4096 -ngl 40 -b 128这个配置下速度会慢一些大概 10-15 token/s但日常用没问题。6.3 双卡 24GB×2可以上 Q6_K 甚至 Q8-ngl 99全放 GPU上下文 16K。./llama-server -m model-Q6_K.gguf -c 16384 -ngl 99 -b 512 -np 4这个配置基本能当小型服务用了并发几个请求不在话下。6.4 只有 CPU 和大内存如果你没有像样的显卡但有 64GB 以上内存也能跑只是慢。用 Q4_K_M-ngl 0全靠 CPU。./llama-server -m model-Q4_K_M.gguf -c 4096 -ngl 0 -t 16-t 16表示用 16 个线程。速度大概 2-5 token/s适合不赶时间的场景。我个人在实际操作中的体会是27B 这个体量的模型量化档位的选择比硬件本身更能决定体验。同样的卡选对档位和参数能跑出完全不同的效果。与其纠结买什么卡不如先把现有硬件的参数调明白。很多时候你以为需要升级硬件其实只是参数没配对。
