llama.cpp实战：从源码编译到本地大模型部署与性能调优

相信很多朋友都遇到过这样的场景：手里正好有一台配置还不错的笔记本，或者公司给配了台没独立显卡的办公机，看着网上铺天盖地的大模型应用，自己也手痒想跑个Llama 3、Mistral之类的开源模型玩玩，结果一查教程，全是Python环境、CUDA、PyTorch、几十GB的显存要求，瞬间就劝退了。llama.cpp就是为了解决这个痛点而生的。它是一个用纯C/C++实现的大语言模型推理引擎，目标很纯粹：让大模型不必依赖昂贵的GPU集群，在普通CPU、MacBook甚至树莓派上就能跑起来。这篇文章我就把llama.cpp从编译、模型准备到日常使用、参数调优的完整流程拆开揉碎讲一遍，争取让一个完全没接触过命令行的小白，也能照着操作把本地大模型跑起来。如果你是第一次接触这个工具，或者之前只是跟着网上的零散教程跑通过一次但没搞明白原理，这篇教程应该能帮你把整个技术链路彻底理清楚。

1. 为什么是llama.cpp：本地推理场景下的性能与门槛博弈

1.1 llama.cpp解决了什么核心问题

在llama.cpp出现之前，想在本地跑一个大语言模型，主流路线基本是Python + PyTorch/Hugging Face Transformers。这条路线有两个问题绕不开。一是依赖链太长，装CUDA、cuDNN、PyTorch，再配Python虚拟环境，每个环节都能出一堆幺蛾子，很多人光装环境就装了一整天。二是硬件门槛高，PyTorch生态天生为GPU优化设计，在没有独立显卡的机器上推理速度慢到让人怀疑人生，而且显存不够的时候连加载都加载不进去。

llama.cpp把这一切推倒重来。它用C/C++重写了模型加载和前向推理的全部逻辑，不依赖任何重型框架，所有的算子都是手写的，还针对x86和ARM架构分别做了汇编级别的优化。更重要的是，它把模型量化这件事做到了极致，通过将模型权重从16位浮点数压缩到8位、4位甚至更低，能把模型体积缩小数倍，推理速度反而更快。这就让“贫穷”硬件上的本地推理变成了一件真正可落地的事情。

我想强调的是，llama.cpp代表的是一种更轻量的技术路线：通过牺牲一点点精度来换取极低的部署成本和极高的运行效率。在很多人关心的离线、隐私场景里，这套方案的实用价值比单纯追求跑分要高得多。

1.2 量化原理与GGUF格式的前世今生

要理解llama.cpp，绕不开GGUF这个词。早期llama.cpp使用GGML格式存储量化模型，后来社区逐步演进成GGUF（GPT-Generated Unified Format），这是当前llama.cpp及衍生项目统一使用的模型容器格式。它的设计目标很明确：把模型权重和必要的元数据打包在一个文件里，做到单文件分发、加载即用。

GGUF与PyTorch生态中常见的safetensors格式最大的区别在于对量化的支持方式。safetensors是胖胖的FP16/FP32权重文件，推理时需要动态计算，占用的内存带宽大。GGUF则允许把权重预压缩成不同的位宽，比如4-bit量化后，原始权重中超过75%的冗余信息被提前“有损”去除。虽然精度有所下降，但因为需要读写的数据量大幅减少，在内存带宽受限的CPU平台上，性能提升是压倒性的。

这就好比你把一本厚书里的废话、重复章节全部删掉，只留干货，然后整本书装进口袋里带走——查阅速度反而更快，代价是书里有些细致的修辞细节没了。对于大多数日常问答、生成任务来说，这些细节损失人眼几乎感知不到。

1.3 不同硬件平台的表现差异

llama.cpp一个很大的优势是跨平台。它支持Windows、Linux、macOS，也能在FreeBSD、OpenBSD这类Unix系统上编译运行。具体到硬件，我把自己实测过的一些场景列出来供参考：

其实Apple Silicon的Mac之所以表现亮眼，除了llama.cpp对ARM架构有深度优化外，还利用了Apple统一的片上内存架构。CPU和GPU共享内存，大模型权重直接在CPU内存和GPU之间零拷贝传递，省掉了PCIe传输瓶颈。这也是为什么很多Mac用户把llama.cpp当成主力本地推理工具的原因。

2. 环境准备与源码编译：从零构建llama.cpp

2.1 源码获取与依赖安装

llama.cpp的安装方式有几种，最简单的当然是直接用包管理器装别人编译好的release版本。不过我还是推荐自己编译，因为可以针对自己的CPU指令集专门优化，性能差距不是一点半点。

先说明依赖。llama.cpp本身依赖极少，源码编译只需要一个支持C++17的编译器。Windows上推荐用Visual Studio 2022或者MSYS2环境下的MinGW。Linux上安装gcc和g++即可。macOS需要Xcode Command Line Tools。用git拉取源码：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp

Linux和macOS下直接执行：

make -j4

这里的-j4表示用4个并行任务编译，如果CPU核多可以改成-j8甚至-j16，能显著加快编译速度。Windows下则推荐用CMake：

cmake -B build cmake --build build --config Release

需要注意的是，Windows下用MinGW编译虽然也能跑，但性能不如MSVC编译出来的版本稳定。如果只是临时体验，直接用官方release的exe文件省事很多。

如果手头有NVIDIA独立显卡，想启用CUDA加速编译，需要在编译前确保CUDA Toolkit已经装好。Linux下用make编译时指定：

make LLAMA_CUDA=1 -j8

CMake方式则需要在cmake时加入参数：

cmake -B build -DGGML_CUDA=ON

这里要提醒一个容易踩的坑：在首次编译时，如果系统同时装了多个CUDA版本，CMake很可能选错。最好在CMake命令里显式指定CUDA路径，例如-DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc。

2.2 模型权重的获取途径与版权提示

编译好了只是个空壳，真正重要的是模型权重文件。网上获取GGUF格式模型最方便的地方是Hugging Face，直接在模型搜索框里输入“GGUF”，就能看到海量社区转换好的模型。比如要找Llama 3的量化版，可以搜索“Meta-Llama-3-8B-Instruct-GGUF”。

下载模型建议用git lfs命令，避免浏览器下载大文件容易断线：

git lfs install git clone https://huggingface.co/TheBloke/Llama-2-7B-Chat-GGUF

如果你是本地的Python开发者，用huggingface_hub库下载更灵活：

from huggingface_hub import hf_hub_download model_path = hf_hub_download( repo_id="TheBloke/Llama-2-7B-Chat-GGUF", filename="llama-2-7b-chat.Q4_K_M.gguf" )

这里必须说一句，模型下载前一定要看模型卡（Model Card）上的许可协议。Meta家的Llama系列和Mistral都有各自的开源许可，个人学习使用一般没问题，如果要做商用，最好逐条阅读条款，避免给自己惹麻烦。

2.3 如果只有PyTorch权重如何转换

有时候你在Hugging Face上找不到现成的GGUF文件，或者你手里就是一个自己微调过的safetensors模型，那就需要自己转换。转换的步骤分两步：先把PyTorch权重导出成FP16的GGUF文件，再量化为低比特GGUF。

llama.cpp源码中自带转换脚本。假设你已经通过transformers把模型下载到了本地目录：

python3 convert_hf_to_gguf.py ./models/llama-3-8b-instruct \ --outfile ./models/llama-3-8b-instruct-fp16.gguf \ --outtype f16

转换脚本会根据config.json自动判断模型架构，不需要手动指定。转换完成后，再执行量化：

./llama-quantize ./models/llama-3-8b-instruct-fp16.gguf \ ./models/llama-3-8b-instruct-q4_k_m.gguf \ Q4_K_M

这里Q4_K_M是一种量化方案，后面的章节我会展开说。需要特别提醒的是，convert_hf_to_gguf.py这个脚本依赖Python和transformers库，如果代码库更新比较新，最好先pip install -r requirements.txt把依赖补齐。

3. GGUF模型格式与量化位深：选错参数性能天差地别

3.1 GGUF内部结构和元数据

GGUF文件不是一个单纯的权重二进制流，它内部有严格的元数据结构。文件开头是魔数“GGUF”标识版本号，接着是模型的超参数，包括层数、词表大小、上下文长度、嵌入维度等。然后才是权重张量数据，每个张量都要记录名称、类型、形状信息。

这种设计的好处在于：加载模型时不需要去外部JSON文件里找配置，只需要读一个文件就能知道模型全貌，这也让GGUF非常适合轻量级的C/C++环境解析。如果熟悉ONNX，可以把GGUF理解成大模型领域的专用ONNX，只是更专注于推理效率。

llama.cpp内部对GGUF的读取做了内存映射（mmap），也就是不需要一次性把整个文件加载进内存，而是按需分页读取。这对于大模型来说特别关键——一个13B的Q4量化模型文件大约7GB，如果你内存只有16GB，一次性全量加载会非常吃力，而mmap方式能让系统按需换页，内存峰值可以控制在很低水平。

3.2 常见量化类型横向对比

量化类型是GGUF选择中最容易让人纠结的部分。llama.cpp支持的量化方式非常多，常见的有：

从实测经验来看，Q4_K_M是绝大多数人用得最舒服的档位。相比Q8_0，文件体积小了将近一半，推理速度更快，而回答质量的下滑在大多数场景下人眼几乎感知不到。如果你要跑的是代码生成或者数学推理，那么Q5_K_M或者Q6_K会更稳妥一些，毕竟这类任务对细节更敏感。

另外有一种叫“K-quants”的说法，Q4_K_M里的K指的就是这种改进型量化方法。它会对模型里不同张量按敏感程度自适应选择量化粒度，比早期的Q4_0老量化方法质量更高。

3.3 量化参数选择的决策逻辑

我见过不少新手上来直接拉一个最大的模型，然后发现内存不够，于是换更小的量化，结果还是不行，最后只能委屈用更小的模型。这里我给出一个自己常用的决策路径：

1. 看内存/显存容量。先估算可用内存容量，Q4量化后7B模型约4.4GB，13B模型约7.9GB，33B模型约19GB。保留操作系统和日常程序需要的内存，不能全部占满。
2. 看模型用途。闲聊、梗概生成对精度不敏感，无脑Q4_K_M。代码补全、结构化输出最好用Q5_K_M或Q6_K起步。
3. 看CPU性能。如果不支持AVX2指令集（比如一些老旧的CPU），量化推理速度会明显变慢。这种情况优先选Q5_K_M以下档位，减少显存带宽压力。

最终选型没有标准答案，但掌握了这个思路后，至少不会盲目乱选。

4. 命令行推理的核心参数与实操

4.1 基础运行语法与交互模式

编译完成后，你会得到多个可执行文件，其中核心的是llama-cli。进入交互式对话模式最基本的命令是：

./llama-cli -m ./models/llama-3-8b-instruct-q4_k_m.gguf -p "你好，介绍一下你自己" -n 512

简单解释一下参数，-m是指定模型文件路径，-p是初始提示词，-n是生成的最大token数。命令行会加载模型，然后直接打印生成结果。

使用-i参数可以进入交互模式，像聊天一样一边输入一边得到回复：

./llama-cli -m ./models/llama-3-8b-instruct-q4_k_m.gguf -i -n 512 --color

--color会在终端里显示不同的颜色来区分用户输入和AI回答，体验好很多。交互模式下输入/exit退出，输入/reset清空对话历史重新开始。如果输入多行内容，可以用\结尾表示换行，这个细节很少人提，但实际使用中很关键。

4.2 关键性能参数逐项拆解

llama-cli的参数非常多，但真正核心的就几个，我把它们拆开来讲。

第一是线程数-t。默认情况下llama.cpp会用满所有核心，这在很多低功耗笔记本上会导致整机卡顿。建议把线程数设为物理核心数减2。比如8核处理器，用-t 6效果比较好。开启超线程的CPU上，线程数设成物理核数就好，不需要继续往上加。

第二是GPU层数-ngl。如果你的机器有支持CUDA的NVIDIA显卡，用-ngl 999把尽可能多的层放在GPU上跑。显存不够时，-ngl自动缩减即可。对于Apple Silicon，-ngl 999同样适用，Metal加速会接管所有能接管的层。实测下来，-ngl每多加载一层，对延迟的改善都是立竿见影的。

第三是上下文长度-c。这个参数设得越大，模型能记住的对话历史就越长，但内存消耗也线性增长。一个token大概要消耗几KB到十几KB的内存，上下文从2048开到8192，额外占用可能增加几百MB，在内存紧张的时候要注意控制。默认是512，对话场景建议至少设置2048。

第四是重复惩罚--repeat-penalty。默认值1.1，也就是如果模型反复用同一个词，这个词出现在后续文本中的概率会被压低。如果感觉生成的文字经常进入一段死循环，可以把重复惩罚调到1.15到1.3之间。反之如果觉得生成结果太跳脱，就调低一点。

4.3 多样本生成与输出控制技巧

llama.cpp支持一次生成多条候选回复，方便你选择最好的结果。用-n 256 --samplers top_k,top_p,temp配合使用：

./llama-cli -m ./models/llama-3-8b-instruct-q4_k_m.gguf \ -p "用一句话解释量子纠缠" \ -n 128 \ --temp 0.8 \ --top-k 40 \ --top-p 0.95 \ --repeat-penalty 1.1

其中--temp是温度系数，控制随机性，越大越天马行空，越小越严谨保守。--top-k限制候选词的数量，--top-p按概率累积截断候选集。这套组合是业界通用的采样策略，理解它有助于你调节模型输出风格。比如写文案可以开高温度，写代码建议把温度调到0.2以下。

5. 用llama.cpp搭建本地API服务

5.1 启动OpenAI兼容服务器的完整步骤

llama.cpp自带一个轻量级HTTP服务器，兼容OpenAI API的接口格式。这意味着你可以直接把它当成一个本地版GPT接口来用，配合各种基于OpenAI SDK开发的应用。

启动服务器非常简单：

./llama-server -m ./models/llama-3-8b-instruct-q4_k_m.gguf \ --host 127.0.0.1 \ --port 8080 \ -c 4096 \ -ngl 999 \ -t 6

启动成功后访问http://127.0.0.1:8080就能看到Web界面，原理是调用/completion接口。核心用法是兼容了OpenAI的/v1/chat/completions接口格式，所以你在任何支持自定义API地址的客户端里，把base_url设置为http://127.0.0.1:8080/v1即可。

5.2 用curl调用本地模型

用curl测试是最快的验证方法：

curl http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "llama-3-8b-instruct", "messages": [ {"role": "user", "content": "你好，你是谁？"} ], "temperature": 0.7, "max_tokens": 256 }'

返回的JSON结构和OpenAI完全一致，包含choices数组和usage信息。不同之处在于server端不校验API Key，任意key都能通过。如果你希望限制访问，可以在启动命令里加--api-key参数，请求时在Header中带上Authorization即可。

5.3 集成到各类Chatbox客户端的实操

这个本地API最大的意义在于，它能无缝接入你日常使用的任何OpenAI生态软件。比如你可以在Chatbox、NextChat这类聊天客户端里新增一个自定义API Provider，填上本地地址，就能获得一个完全离线、数据不离开你电脑的专属大模型聊天机器人。

我曾经在局域网里搭过一个llama-server，然后让同事用手机连到同一WiFi，通过电脑的局域网IP访问，几个人同时在一个模型上调参提问，体验跟用云端API没有本质区别，但数据完全可控。这一点在企业内部知识处理或隐私敏感的场合特别实用。

6. 模型部署实战：以Qwen2.5为例完整演示

6.1 从Hugging Face下载Qwen2.5 GGUF模型

为了让整个部署流程更具体，我直接以当前非常热门的Qwen2.5系列为例。Qwen2.5是由阿里通义实验室开源的中英双语大模型，社区转换的GGUF版本非常丰富。对于普通用户，我建议先尝试7B的Q4_K_M版本，不需要高端显卡，CPU也能跑得动。

下载命令：

git lfs install git clone https://huggingface.co/Qwen/Qwen2.5-7B-Instruct-GGUF

克隆完成后，进入目录，找到后缀为Q4_K_M.gguf的文件。如果网络传输比较慢，也可以单独用hf_hub_download只下载主模型文件：

from huggingface_hub import hf_hub_download hf_hub_download( repo_id="Qwen/Qwen2.5-7B-Instruct-GGUF", filename="qwen2.5-7b-instruct-q4_k_m.gguf", local_dir="./models" )

注意GGUF仓库里一般会放多个文件，除了各量化版本的模型文件外，还会有一个.gguf的索引文件。主要关心模型文件的体积是否匹配你的内存空间。

6.2 加载模型并测试中文对话效果

模型下载好后，直接用llama-cli加载：

./llama-cli -m ./models/qwen2.5-7b-instruct-q4_k_m.gguf \ -c 4096 \ -t 8 \ --temp 0.7 \ -p "写一段关于机器学习的通俗解释"

Qwen系列对中文比较友好，回答质量明显好于同参数级别的英文原版模型直出中文。如果机器内存比较大，可以尝试14B的Q5_K_M，整体效果会再上一个台阶。

我个人的使用建议是：在你拿不准该选什么量化档位时，直接下载Q4_K_M版本先跑通全流程，确认一切都正常后，再根据实际需求和资源换更高精度版本。这样能最大程度减少折腾成本。

6.3 将Qwen模型作为本地API后端使用

如果你已经启动了一个llama-server指向Qwen2.5模型，那么可以非常方便地在任何支持OpenAI接口的工具里使用。

这里分享一个我在使用中很实用的场景：我做了一个自动化工作的脚本，需要定期从一批文本中提取结构化信息。原来调用云端API，既担心隐私，又要付钱。后来改成脚本直接请求本地llama-server，延迟更低，部分重复性任务的返回结果还更稳定。设置也很简单：

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8080/v1", api_key="EMPTY" ) response = client.chat.completions.create( model="qwen2.5-7b-instruct", messages=[ {"role": "system", "content": "你是信息抽取助手，只输出JSON。"}, {"role": "user", "content": "从下面文本中提取人名和公司名：张三在百度工作三年。"} ], temperature=0.1 ) print(response.choices[0].message.content)

这个例子展示了llama.cpp作为本地推理底座，配合OpenAI SDK做程序化应用是多么顺畅。Python生态里所有跟OpenAI兼容的工具，几乎都能直接无缝对接本地llama-server。

7. 常见问题排查与优化建议

7.1 内存不足与模型加载失败

这是新手上路最常遇到的问题。报错信息一般是failed to allocate memory或者cannot load model。排查思路是先搞清楚自己的内存到底够不够。Q4量化的7B模型，模型权重大约4.4GB，但推理期间还需要KV Cache、临时激活值等内存空间，实际峰值占用往往是权重体积的1.5倍甚至更多。

如果你只有8GB内存，跑7B模型会很勉强，这种情况下有几个选择：第一，换Q2_K这种更极端的量化；第二，换更小参数的模型，比如1.5B、3B级别的；第三，加-c 512减小上下文长度，牺牲记忆能力换稳定性。

7.2 推理速度过慢

推理速度慢，先别急着怪模型。在CPU环境，速度和线程数、内存带宽关系最大。你用-t把线程拉满不一定更快，因为CPU核心之间的数据同步和内存带宽争抢反而会拖慢速度。CPU场景下建议先把-t设成物理核心数，实际测试中，4核到8核之间，提升线程数效果明显，超过16线程后收益非常有限。

另外，模型放机械硬盘和放固态硬盘，加载时间差别巨大。推理时llama.cpp用mmap按需读取权重，如果文件在机械硬盘上，频繁访问权重会造成明显IO瓶颈。把模型放在NVMe固态上，体验能提升一个档次。

7.3 模型输出乱码或反复重复

输出乱码最常见的原因是词表不匹配。检查一下你下载的是不是原本就是GGUF格式，而不是直接用PyTorch格式强行加载。另一个原因是lora微调模型和基础模型混用，导致embedding层长度不一致。

模型输出陷入死循环、一直重复某句话，这可能和上下文窗口不足有关。模型生成过程中，早期信息被“挤”出上下文窗口，它就忘记了前面说过什么，于是开始兜圈子。解决方法是调大-c参数，或者用/reset清空历史重新开始。

7.4 GPU层数参数设置调优

如果在NVIDIA显卡上跑，-ngl设多少是经典难题。显存小的情况下，-ngl过高会导致内存溢出，正合适时又经常模型加载失败。我的参数调试办法是二分法：先设置一个比较高的值比如99，如果失败就减半再试，直到找到一个既能加载又不会把显存占满的临界值。这个值每次可以写成配置文件里复用，省得每次启动都手动调。

另外，混跑模式下（部分层在GPU、部分层在CPU），模型输出速度其实会受制于CPU-GPU之间的数据传输带宽。如果瓶颈在PCIe带宽上，即便GPU能很快算出结果，等待数据同步的时间也无法忽视。

7.5 高阶玩法：LoRA微调模型的加载与测试

llama.cpp经过几个版本的迭代，现在也支持加载LoRA微调后的模型。LoRA是一种参数高效的微调方案，它不是在原模型基础上增加参数量，而是在注意力层的权重旁边增加两个低秩矩阵。运行推理时需要同时加载底座模型和LoRA矩阵。

启动命令大致长这样：

./llama-cli -m ./models/base.gguf \ --lora ./models/lora-adapters.gguf \ -p "测试问题"

前提是LoRA适配器也要转换成GGUF支持的格式。目前社区里专门的GGUF版LoRA工具还比较少，但llama.cpp官方转换脚本已经覆盖了这一需求。如果你是模型微调玩家，这个功能非常值得关注。

8. 从跑通到好用：性能调优与使用习惯建议

8.1 性能监控手段与合理预期

跑推理时不要一味凭感觉调整参数，要学会用监控工具看数据。Linux下用htop看CPU和内存占用，Windows下用任务管理器观察GPU利用率。模型加载的时候观察内存占用峰值，推理时观察CPU各核心的繁忙程度。如果CPU占用率一直很低，说明瓶颈可能在内存带宽或者IO，加多少线程都没用。

对纯CPU的机器，不同尺寸模型的速度预期我给一个大致范围：7B Q4约4~8 token/s，13B Q4约2~4 token/s，33B Q4基本就1 token/s左右。这个速度用来日常对话还算能接受，但用来写长代码或长文章就比较折磨了。想提升体验，优先考虑Apple Silicon或者一块二手NVIDIA显卡。

8.2 让交互式对话更舒服的配置模板

每次启动都敲一长串参数太累了，我习惯把常用参数写进一个shell脚本里。这里给出一个我日常使用的模板：

#!/bin/bash MODEL="./models/qwen2.5-7b-instruct-q4_k_m.gguf" THREADS=8 CONTEXT=4096 GPU_LAYERS=999 ./llama-cli -m "$MODEL" -t $THREADS -c $CONTEXT -ngl $GPU_LAYERS --temp 0.7 --repeat-penalty 1.1 -i

把这段保存在chat.sh里，以后每次运行只需要bash chat.sh。如果你在Windows PowerShell里，可以改成对应的.ps1脚本，核心语法类似。

8.3 多模型快速切换与模型管理

本地模型文件动辄数GB，多下几个模型磁盘空间会很紧张。我的习惯是只保留一个主力模型（比如Qwen2.5 7B Q4_K_M）和一个小模型（比如1.5B级别的Q2），一个负责高质量回答，一个负责日常快速测试。真正跑量的时候再下载大模型，用完就删。

另外，llama.cpp的server模式支持不停进程切换模型吗？目前不能。如果需要在多个模型间切换，建议用不同的端口分别启动两个server进程，每个进程加载一个模型，这样互不干扰。

9. 谈谈个人实践中的几个心得

llama.cpp用久了，最深刻的感受是它的更新速度非常快。几乎每隔几天就有新特性加入，底层算子也在不断优化。今天你可能看到一个QVK缓存优化，明天又看到新的量化格式上线。想跟上节奏，最简单的做法是定期git pull拉取最新代码并重新编译，一般更新都是增量式的，对已有使用影响很小。

还有一个容易忽视的点：模型文件放在哪个目录、文件名怎么命名，看起来是小事，但模型一多就很容易乱。我自己的目录结构是models/{系列名}/{型号}.gguf，同时配合下载时保留仓库里的README文件，方便后续查看模型说明。

最后想说的是，本地模型和云端API的体验差异，更多体现在响应速度、数据隐私、离线可用性上。llama.cpp经过这么长时间的发展，已经从一个极客玩具变成了一个真正具备生产力的工具。如果你还没有在本地完整跑通过一次，真心建议按这篇文章的步骤走一遍。从源码编译到模型下载，从命令行对话到API服务，整个过程走完，你对大模型推理链路的理解绝对会上一个台阶。