llama.cpp与GGUF：本地大模型裸机推理的核心原理与实战

1. 项目概述：为什么说 llama.cpp 是本地大模型的“裸引擎”

你有没有试过在自己笔记本上跑一个真正能对话、能推理、能写代码的大语言模型？不是调用某个网页接口，也不是连着云端API，而是完完全全——CPU在发热、风扇在转、显存占用条在跳动，模型就在你本地硬盘里加载、在你内存里推理、在你键盘敲下回车的0.3秒后，把答案吐到终端里。这种“亲手握住引擎”的实感，就是 llama.cpp 给我的第一印象。它不包装、不抽象、不隐藏——没有 Web UI 层，没有服务注册中心，没有模型网关路由，甚至默认连个 HTTP 接口都不开。它就是一个命令行程序，一个.so动态库，一段 C++ 代码编译出来的二进制文件。而支撑它高效运转的，正是 GGUF 这个专为本地推理设计的模型容器格式。标题里说它是“裸引擎”，一点没夸张：它剥离了所有云原生时代的中间件幻觉，只留下最原始的张量加载、量化调度、算子执行和内存管理这四根主梁。我第一次用它在一台 16GB 内存的旧 MacBook Air 上跑通llama-3-8b-instruct.Q4_K_M.gguf，全程没装 CUDA、没配 Docker、没碰 Python 环境，只靠 Homebrew 装了个llama.cpp，再拖一个 4.2GB 的 GGUF 文件进来，./main -m ./models/llama-3-8b-instruct.Q4_K_M.gguf -p "请用三句话解释量子纠缠"——回车之后，三行字就出来了。没有等待“模型正在加载中…”的 loading 动画，没有后台进程日志刷屏，只有终端光标安静地闪烁，然后文字一行行浮现。这种“所见即所得”的确定性，在当前满是抽象层的 AI 工具链里，反而成了最稀缺的生产力。它适合谁？适合那些厌倦了配置 YAML、调试端口冲突、排查 CUDA 版本兼容性的开发者；适合想在树莓派上部署轻量助手的极客；适合需要把模型嵌入 C++ 工业软件、又不想引入 Python 解释器依赖的嵌入式工程师；也适合教学场景下，让学生亲手看到“权重怎么从磁盘读进内存”“KV Cache 怎么随 token 增长而扩张”的一线教师。它解决的不是“能不能用”的问题，而是“能不能真正理解、控制、定制、嵌入”的问题——这才是“裸引擎”的真实含义。

2. 核心技术解构：GGUF 格式为何是 llama.cpp 的“唯一语言”

2.1 GGUF 不是简单的“模型压缩包”，而是一套内存映射协议

很多人初看 GGUF，会下意识把它等同于 PyTorch 的.pt或 Hugging Face 的safetensors——都是存权重的文件。但这是根本性误解。GGUF 的本质，是一份可直接 mmap（内存映射）的结构化二进制协议。它不依赖任何运行时解析器，不触发大量 malloc/new，不进行动态类型推导。当你执行llama_load_model_from_file("model.Q4_K_M.gguf")时，底层调用的是mmap()系统调用，把整个文件按页映射进虚拟地址空间。模型权重、元数据、张量描述符，全部以预对齐的二进制块形式躺在那里，CPU 指令指哪打哪，零拷贝、零解析、零 GC 压力。我做过对比实验：加载一个 7B 模型，PyTorch 方式平均耗时 2.8 秒（含 Python 对象构建、dtype 转换、GPU 传输），而 GGUF mmap 加载仅需 0.17 秒——快 16 倍，且内存峰值低 40%。这个差距不是优化技巧带来的，而是范式差异：一个是“先解析再构造”，一个是“直接寻址即用”。GGUF 文件头部固定 32 字节，包含 magic number0x55 0x47 0x47 0x55（UGGU ASCII 反写，设计者的小幽默），版本号，以及指向后续 section 的偏移量。紧接着是KV区（键值元数据区），存放模型名、作者、量化方式、RoPE 频率缩放因子等；然后是Tensor Info区，每项 64 字节，记录张量名、维度、数据类型、量化参数、文件内偏移与长度；最后才是真正的Tensor Data区，按顺序紧挨着存放所有张量的原始字节流。这种线性布局，让llama.cpp的加载器只需一次lseek()+read()就能定位任意张量，无需遍历、无需哈希查找。你可以把它想象成一本印刷好的工程手册：目录页（KV+Tensor Info）告诉你第 37 页讲“Wqkv 权重”，你直接翻到那一页（mmap offset），内容就在那里，白纸黑字，不增不减。

2.2 量化不是“降质妥协”，而是面向 CPU/GPU 的算力重分配

GGUF 支持的量化方案（Q4_K_M、Q5_K_S、Q6_K、Q8_0 等）常被误读为“牺牲精度换速度”。实际上，在 llama.cpp 场景下，它是对现代 CPU 缓存层级与向量指令集的一次精准适配。以最常用的Q4_K_M为例：它并非简单地把 FP16 权重截断为 4-bit 整数。其核心是K-quantization 分组量化——将每 256 个权重分为一组（K=256），每组独立计算一个 FP16 的 scale（缩放因子）和一个 FP16 的 bias（偏移），再用 4-bit 整数存储量化后的索引。这意味着：同一组内，数值分布被拉平到 [0,15]，但组间保留了原始的动态范围差异。实测表明，在 LLaMA-3-8B 上，Q4_K_M 相比 FP16，推理质量损失 <1.2%（用 AGIEval 评测），但内存占用从 16GB 降至 4.2GB，且在 Apple M2 芯片上，llama_batch_decode的 token/s 提升 3.1 倍。为什么？因为 M2 的 AMX 单元原生支持 4-bit dot product 指令，而 256 元素分组恰好填满其向量寄存器宽度。更关键的是缓存友好性：FP16 权重随机访问时，CPU L1 cache line（通常 64 字节）只能装下 32 个 FP16 数；而 Q4_K_M 下，同样 64 字节可装下 128 个量化权重 + 对应的 scale/bias 元数据，cache miss 率下降 57%。这不是“凑合用”，而是像赛车手根据弯道半径调整胎压——量化参数就是为你的硬件定制的胎压值。Q5_K_S则把分组缩小到 128，提升精度但略增开销；Q6_K用 6-bit 存储索引，平衡点更靠右；Q8_0几乎无损，但已失去大部分内存优势。选哪个？不是看“谁更准”，而是看你的目标设备：树莓派 5（4GB RAM）必须 Q4；M1 Mac（16GB）可选 Q5；Intel i9 + 64GB RAM 可上 Q6。我见过有人执着于 Q8_0，结果在 8GB 笔记本上加载失败——这不是模型不行，是你没读懂量化背后的硬件契约。

2.3 llama.cpp 的“裸”体现在四大不可替代的底层能力

所谓“裸引擎”，绝非功能简陋，而是将能力锚定在操作系统与硬件的交界面上。它的四大核心能力，是任何高级框架都难以绕开或替代的：

1. 跨平台零依赖推理引擎：llama.cpp编译产物是纯静态链接的二进制（Linux/macOS/Windows/ARM64/x86_64），不依赖 Python、不依赖 CUDA 驱动、不依赖 cuBLAS 库。我在一台刚重装系统的 Ubuntu 22.04 服务器上，只装了build-essential和cmake，git clone && make12 分钟后，./main就能跑起来。它用的是标准 C++11，所有 BLAS 计算（矩阵乘、Softmax）都手写 SIMD 汇编（AVX2/AVX512/NEON），并内置了针对不同 CPU 微架构的 runtime dispatch。这意味着：你给客户交付一个llama-cli二进制，附带一个 GGUF 模型，他双击就能用，不用教他装 conda、配环境变量、查驱动版本。

2. 细粒度内存控制与嵌入式友好：llama_context_params结构体暴露所有内存参数：n_ctx（上下文长度）、n_batch（批处理大小）、n_ubatch（微批大小）、seed（随机种子）、logits_all（是否返回所有 token logits）。最关键的是embedding和offload_kqv——前者允许你只加载 embedding 层做向量检索，后者让你把 K/V Cache 部分卸载到 GPU 显存（即使 CPU 内存不足）。我在一个工业质检系统里，用n_ctx=512+n_batch=8+offload_kqv=true，把 13B 模型稳稳压在 12GB 内存的嵌入式工控机上，实时分析产线图像描述文本。这种控制粒度，在 Transformers 库里要改源码才能实现。

3. C API 优先的设计哲学：llama.h头文件定义了 28 个核心函数，从llama_model_load、llama_new_context_with_model到llama_tokenize、llama_decode、llama_get_logits，全部是 C ABI 兼容的 plain function。这意味着它可以被 Go、Rust、C#、甚至 Fortran 直接dlopen调用。我们团队曾用 Zig 语言写了一个轻量级 HTTP 服务，@cImport("llama.h")后，50 行代码就实现了/v1/chat/completions兼容接口，性能比 Python FastAPI + Transformers 高 2.3 倍。没有 Python GIL 锁，没有对象生命周期管理，只有指针和整数——这才是“裸”的力量。

4. 可审计、可定制的推理流水线：llama.cpp的llama_decode函数内部，清晰拆分为llama_kv_cache_update→llama_eval_internal→llama_sample_top_p_top_k三步。你可以在任意环节插入 hook：比如在llama_kv_cache_update后，用自定义算法压缩 KV Cache；或在llama_sample_top_p_top_k前，注入领域词典约束输出 token。我帮某法律科技公司做的合同审查模块，就是在采样前加了一层legal_term_filter，强制模型只从 2000 个法律术语中选 token，准确率从 78% 提升至 94%。这种深度定制能力，在黑盒 API 或封装过深的框架里，要么做不到，要么要重写整个推理引擎。

3. 实操全流程：从 GGUF 获取到生产级部署的七步闭环

3.1 第一步：精准定位与验证 GGUF 模型（避坑重点）

别急着下载。GGUF 生态目前有三大来源，质量与可信度天差地别：

• Hugging Face 官方 GGUF Hub（推荐）：搜索llama.cpp+ 模型名，认准TheBloke、jaredwong、QuantFactory等高信誉组织上传的仓库。例如TheBloke/Llama-3-8B-Instruct-GGUF。关键看README.md里的Conversion details：是否注明量化工具（llama.cpp/convert.pyorllama-box）、量化参数（--qtype q4_k_m）、原始模型 commit hash。我曾因忽略 commit hash，下载了某仓库里未同步 LLaMA-3 官方 patch 的旧版权重，导致tokenizer.json编码错误，调试 3 小时才发现。

• llama.cpp 自带转换工具（可控但耗时）：如果你有原始 HF 格式模型（pytorch_model.bin+config.json+tokenizer.json），可用llama.cpp/convert-hf-to-gguf.py脚本。但注意：必须使用与llama.cpp主干版本严格匹配的脚本（如 v0.28.1 的代码，必须用 v0.28.1 的 convert 脚本），否则 GGUF header 版本不兼容。转换命令示例：

  python3 convert-hf-to-gguf.py /path/to/hf/model \ --outfile ./models/llama-3-8b.Q4_K_M.gguf \ --outtype q4_k_m \ --vocab-dir /path/to/hf/model

  --outtype参数必须与llama.cpp编译时启用的量化支持一致（make LLAMA_AVX=1 LLAMA_AVX2=1 LLAMA_CUBLAS=0）。

• 第三方网站（慎用！）：某些中文站点提供“一键 GGUF 下载”，但存在严重风险：文件被篡改（植入挖矿脚本）、量化参数虚假标注（标称 Q4 实为 Q2）、缺少tokenizer元数据。我测试过某网站下载的Qwen2-7B.Q4_K_M.gguf，用llama.cpp/gguf-dump查看，发现tokenizer.ggml字段为空，导致中文分词全乱。黄金法则：所有 GGUF 文件，下载后必须用gguf-dump验证：

  ./gguf-dump ./models/llama-3-8b.Q4_K_M.gguf | head -n 50

  关键检查项：llama.context_length是否为 8192、llama.tokenizer.ggml是否存在、llama.quantize.version是否为 2（当前主流）、general.name是否与预期一致。少一项，立刻弃用。

3.2 第二步：编译 llama.cpp —— 选择你的“引擎型号”

llama.cpp的 Makefile 是高度模块化的，编译选项直接决定你的引擎性能边界。不要无脑make，必须按目标平台精调：

提示：编译前务必git checkout到稳定 tag（如v0.28.1），不要用main分支——它常含未测试的 experimental feature。编译成功后，./main --version应输出llama.cpp v0.28.1，且./main -h能正常显示帮助。若报错undefined reference to 'llama_*'，大概率是libllama.so未正确链接，检查make输出末尾是否有ar: creating libllama.a。

3.3 第三步：命令行推理 —— 掌握 7 个核心参数的物理意义

./main是最基础的交互式推理入口，但每个参数都是对硬件资源的直接索取：

1. -m /path/to/model.gguf：模型路径。必须绝对路径或相对路径，不能是 URL。GGUF 文件需与llama.cpp编译版本兼容（header version）。

2. -p "prompt"：初始提示词。注意：llama.cpp默认不加 system prompt，需手动拼接。例如 LLaMA-3 的标准格式：

   ./main -m ./models/llama-3-8b.Q4_K_M.gguf \ -p "<|begin_of_text|><|start_header_id|>system<|end_header_id|>\n\nYou are a helpful AI assistant.<|eot_id|><|start_header_id|>user<|end_header_id|>\n\nExplain quantum entanglement in three sentences.<|eot_id|><|start_header_id|>assistant<|end_header_id|>\n\n"

   <|eot_id|>是 LLaMA-3 的 EOS token，漏掉会导致模型不停生成。

3. -n 512：最大生成 token 数。不是“最多输出 512 字”，而是模型内部循环 decode 的最大步数。设太小（如 64）可能截断答案；设太大（如 2048）会显著增加内存占用（KV Cache 按n_ctx * n_batch扩张）。

4. -c 4096：上下文长度（n_ctx）。必须 ≤ 模型训练时的llama.context_length（用gguf-dump查）。设为 4096 比 2048 多占约 1.8GB 内存（KV Cache 占比超 70%），但能处理更长输入。经验法则：n_ctx = min(训练长度, 你实际需要的输入+输出总长)。

5. -b 512：批处理大小（n_batch）。控制每次 decode 的 token 数。增大可提升吞吐（GPU 利用率），但会线性增加内存峰值。在 CPU 上，-b 256通常是甜点；在 Metal GPU 上，-b 512更优。

6. -t 8：线程数（n_threads）。设为 CPU 物理核心数（lscpu | grep "CPU(s)"）。设太高（如 32 核设 64 线程）会因锁竞争反而降速；设太低（如 8 核设 2 线程）无法吃满算力。实测：M2 Max 12 核，设-t 12比-t 24快 18%。

7. --temp 0.7 --top-p 0.9 --repeat-penalty 1.1：采样参数。temp控制随机性（0.1=确定性，1.0=发散），top-p动态截断概率累积和（0.9=只从 top 90% token 中选），repeat-penalty抑制重复（>1.0 降低已出现 token 概率）。这些参数直接影响输出质量，需针对任务调优。写代码用temp=0.2，创意写作用temp=0.8。

注意：所有参数必须放在-p之前！./main -p "hi" -n 100会报错，正确是./main -n 100 -p "hi"。这是 C getopt 的解析规则，踩过坑的人都懂。

3.4 第四步：构建生产级服务 —— 从 CLI 到 HTTP API 的三重封装

命令行够用，但生产环境需要 API。llama.cpp官方提供了server子命令，但它是“最小可行服务”，需二次加固：

1. 启动基础服务：

   ./server -m ./models/llama-3-8b.Q4_K_M.gguf \ -c 4096 -b 512 -t 8 \ --port 8080 --host 0.0.0.0 \ --embedding # 启用 embedding endpoint

   此时curl http://localhost:8080/v1/models返回模型信息，curl http://localhost:8080/v1/chat/completions可 POST 请求。

2. 添加反向代理与 TLS（Nginx 示例）：

   server { listen 443 ssl; server_name api.yourdomain.com; ssl_certificate /etc/ssl/certs/fullchain.pem; ssl_certificate_key /etc/ssl/private/privkey.pem; location /v1/ { proxy_pass http://127.0.0.1:8080/v1/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10M; # 防大 payload 攻击 } }

   关键加固点：client_max_body_size限制请求体，X-Forwarded-For透传真实 IP 用于限流。

3. 集成限流与鉴权（用 Lua 脚本）： 在 Nginx 配置中加入：

   # 限流：每 IP 每分钟 60 次 limit_req_zone $binary_remote_addr zone=api:10m rate=1r/s; limit_req zone=api burst=60 nodelay; # JWT 鉴权（需安装 lua-resty-jwt） access_by_lua_block { local jwt_obj = require("resty.jwt") local jwt = jwt_obj:new() local token = ngx.req.get_headers()["Authorization"] if not token or not string.match(token, "Bearer ") then ngx.exit(401) end local res, err = jwt:verify_jwt_obj(token:sub(8), {secret = "your-secret"}) if not res.valid then ngx.exit(403) end }

   这样，llama.cpp server本身不处理安全，由 Nginx 拦截非法请求，保持引擎纯粹。

3.5 第五步：性能压测与瓶颈定位 —— 用真实数据说话

别信宣传文案，用ab（Apache Bench）或hey做真刀真枪压测：

# 测试并发 100，总请求数 1000 hey -n 1000 -c 100 -m POST \ -H "Content-Type: application/json" \ -d '{"model":"llama-3-8b","messages":[{"role":"user","content":"Hello"}],"max_tokens":128}' \ https://api.yourdomain.com/v1/chat/completions

关键指标看三项：

• P95 延迟：95% 请求的响应时间。目标：≤ 2000ms（首 token + 全部生成）。
• 吞吐（RPS）：每秒完成请求数。目标：≥ 5 RPS（100 并发下）。
• 错误率：HTTP 5xx 比例。目标：0%。

若 P95 > 3000ms，按此顺序排查：

1. CPU 使用率：htop看是否单核 100%。若是，说明n_threads设置过低或模型太大，需调高-t或换更小模型。
2. 内存交换（swap）：free -h看SwapUsed是否 > 0。若是，说明n_ctx或-b设太大，触发内存交换，性能断崖下跌。立即减小参数。
3. GPU 利用率（Metal）：Activity Monitor→ GPU History，看 Metal Engine 是否持续 > 80%。若低于 50%，说明 CPU 预处理（tokenize、logits sampling）成为瓶颈，需优化 prompt 长度或升级 CPU。

我曾在一个客户现场，压测发现 P95 达 8s。htop显示 CPU 仅 40%，iostat -x 1却发现%util99%——原来是 NVMe SSD 读取 GGUF 文件成为瓶颈！解决方案：用mmap预加载（./server --mlock参数锁定内存，避免 page fault 触发磁盘 IO），P95 降至 1.2s。

3.6 第六步：日志与可观测性 —— 让“裸引擎”不再黑盒

llama.cpp server默认日志极简（只输出启动信息）。生产环境必须补全：

• 启用详细日志：启动时加--log-format json --log-level 2（level 2=INFO，3=DEBUG）。日志自动包含request_id、model、prompt_len、completion_len、duration_ms、tokens_per_second。

• 接入 Prometheus：用prometheus_client（Python）或prom-client（Node.js）写一个 exporter，定期抓取llama.cpp的/metrics端点（需自行实现，官方未提供）。关键指标：

  • llama_inference_duration_seconds（直方图）
  • llama_tokens_generated_total（计数器）
  • llama_kv_cache_used_bytes（Gauge）

• 错误追踪：在 Nginx 日志中，用log_format记录upstream_response_time和upstream_status：

  log_format llama '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' 'rt=$request_time uct="$upstream_connect_time" ' 'uht="$upstream_header_time" urt="$upstream_response_time"';

  当upstream_response_time异常高，而request_time接近它，说明瓶颈在llama.cpp；若request_time远大于upstream_response_time，则是网络或客户端问题。

3.7 第七步：模型热更新与灰度发布 —— 零停机切换的实践

生产环境不能停服更新模型。llama.cpp server支持SIGUSR1信号重载模型：

1. 准备新模型：将新 GGUF 文件（如llama-3-8b-v2.Q5_K_S.gguf）放到指定目录，确保权限可读。
2. 发送信号：

   # 获取 server 进程 PID ps aux | grep "llama.cpp/server" | grep -v grep | awk '{print $2}' # 发送重载信号（假设 PID=12345） kill -USR1 12345

3. 验证：curl http://localhost:8080/v1/models查看updated_at时间戳是否刷新；用strace -p 12345 -e trace=openat确认新文件被openat调用。

注意：热更新期间，旧请求继续用旧模型，新请求用新模型，无缝切换。但需确保新旧模型 tokenizer 兼容（同源模型），否则分词错误。我们做法是：每次更新前，用llama-tokenize工具对同一 prompt 生成 token ids，比对是否一致，不一致则拒绝更新。

4. 常见问题与实战排障：那些文档里不会写的细节

4.1 “Segmentation fault (core dumped)” —— 内存越界的无声杀手

这是llama.cpp最令人头疼的错误，不报具体行号，只给你一个 core dump。90% 的原因是KV Cache 内存溢出。典型场景：

• 错误操作：-c 8192 -b 1024启动，然后发一个 8000 token 的 prompt +max_tokens=1024。KV Cache 需要(8000+1024)*n_embd*2字节（n_embd=4096 for 8B），远超 16GB 内存。

• 排查步骤：

  1. ulimit -c unlimited开启 core dump；
  2. 复现错误，得到core.xxx；
  3. gdb ./server core.xxx，输入bt看栈顶——通常停在llama_kv_cache_init或llama_kv_cache_update；
  4. info registers查rdi,rsi寄存器值，确认是malloc失败还是memset越界。

• 解决方案：不是加内存，而是收缩参数。-c和-b是平方关系影响内存，优先调小-b（如从 1024→256），其次-c（8192→4096）。终极方案：用--memory-f32启动，强制用 float32 存 KV Cache（更省内存但稍慢）。

4.2 “Failed to load model: unknown tensor name” —— GGUF 元数据错位

当你用非官方渠道下载的 GGUF，或自己转换时参数错误，常遇到此错。llama.cpp在llama_load_tensors阶段，会校验每个张量名是否在预定义列表中（如output.weight,layers.0.attention.wq.weight）。若模型结构微调过（如 LoRA 合并后新增lora_A张量），或转换脚本 bug 导致张量名拼写错误（wq写成w_q），就会失败。

• 诊断命令：

  ./gguf-dump ./model.gguf | grep "tensor name" | head -20

  对比官方模型（如 TheBloke 的同名模型）的 tensor name 列表。常见错误：tok_embeddings.weightvsembed_tokens.weight（Llama-2 vs Llama-3 命名差异）。

• 修复方法：用llama.cpp/gguf-split工具提取 tensor info 区，用 hex editor 手动修正（高危！），或用 Pythongguf库重写：

  import gguf gguf_file = gguf.GGUFReader("./bad.gguf") for tensor in gguf_file.tensors: if tensor.name == "w_q.weight": tensor.name = "wq.weight" # 修正命名 gguf_file.write("./fixed.gguf")

4.3 “No module named 'llama_cpp'" —— Python 绑定的陷阱

很多教程教用pip install llama-cpp-python，但它本质是llama.cpp的 Python 封装，不是独立实现。常见坑：

• 版本错配：llama-cpp-python==2.3.0依赖llama.cppv0.27，但你本地编译的是 v0.28，llama_cpp.Llama初始化会 segfault。
• CUDA 冲突：pip install llama-cpp-python --no-deps后，手动pip install torch，若 torch 是 CUDA 版，会与llama-cpp-python的 CPU-only llama.cpp 冲突。
• 正确姿势：生产环境禁用 pip 安装，改用llama.cpp的 C API + ctypes。Python 侧只做 HTTP client：

  import requests def llama_chat(prompt): resp = requests.post("http://localhost:8080/v1/chat/completions", json={ "model": "llama-3-8b", "messages": [{"role":"user", "content": prompt}], "max_tokens": 256 }) return resp.json()["choices"][0]["message"]["content"]

  简单、稳定、无依赖冲突。

4.4 中文乱码与分词失效 —— tokenizer 的隐性战场

llama.cpp对 tokenizer 的支持是“尽力而为”。LLaMA 系列原生 tokenizer 是 byte-level BPE，对中文不友好。常见现象：./main -p "你好"输出 `` 或空格。

• 根源：GGUF 文件中的tokenizer.ggml元数据缺失或损坏，或llama.cpp编译时未启用LLAMA_TOKENIZER（默认开启，但某些精简版关闭）。
• 验证：./llama-tokenize -m ./model.gguf -p "你好"，若输出1 29871 29966（正常），则 tokenizer OK；若输出 `1 2