企业官网建设流程全解析

1. 先搞清楚 27B 这个体量到底卡在哪

很多人一上来就问"27B 要几张卡"，这个问题本身就问偏了。27B 参数量的模型，真正决定你能不能跑起来、跑得爽的，不是卡的数量，而是显存带宽、显存容量、量化档位这三者之间的平衡。我见过太多人买了双卡结果发现单卡量化后反而更流畅，也见过有人死磕 FP16 结果 OOM 到怀疑人生。

先把账算清楚。27B 参数，如果按 FP16 存储，光权重就要 27 × 2 = 54GB。这还没算 KV Cache、激活值、框架本身的显存开销。实际部署时，FP16 下你至少需要 64GB 以上的显存才能比较从容，这意味着单张消费级卡基本没戏，得上专业卡或者多卡并联。

但量化就是另一回事了。量化的本质是用更低的精度存储权重，牺牲一点点精度换取大幅度的显存节省。常见的档位有这么几档：

这张表是我自己反复实测后整理的，不同量化工具的具体数值会有小幅浮动，但量级不会差太多。你可以把它当成选档位的基准线。

关键结论先给出来：如果你只有一张 24GB 的卡，Q5_K_M 是甜点档；如果只有 16GB，Q4_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 承担的计算越多，速度越快，但显存占用也越高。

怎么找到最优值？我的方法是二分法：

1. 先设-ngl 99，看能不能加载成功
2. 如果 OOM，减半到-ngl 50，再试
3. 逐步逼近，直到找到一个既不 OOM 又尽量大的值

实测下来，27B 的 Q5_K_M 在 24GB 卡上，-ngl通常能设到 45-55 之间（取决于具体模型层数）。剩下的层跑在 CPU 上，速度会降一些，但至少能跑。

提示：-ngl设得过高导致 OOM 时，llama.cpp 有时不会明确报错，而是直接崩溃或者卡住。所以调整这个参数时，建议一次只改 5-10，别一次跳太多。

3.3 批处理大小和并行数

如果你要做服务化部署，-b（batch 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_CUDA=ON 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 实测性能参考

在我的测试环境（单卡 24GB，Q5_K_M，8K 上下文，-ngl 50）下，大致性能是：

这个速度做本地问答完全够用，做轻量 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.7；Q5 以上可以到 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 单卡 16GB

Q4_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 这个体量的模型，量化档位的选择比硬件本身更能决定体验。同样的卡，选对档位和参数，能跑出完全不同的效果。与其纠结买什么卡，不如先把现有硬件的参数调明白。很多时候，你以为需要升级硬件，其实只是参数没配对。