企业官网建设流程全解析

拿LangChain + llama.cpp + llama-cpp-python这套组合做本地推理，最开始我把它理解错了——我以为是三个能互相替代的东西，于是花了整整两天在“选哪个”上打转，装完一圈之后才发现，它们根本不在同一个层级上：一个负责在 CPU 和显卡上把 token 一个接一个算出来，一个负责把这个 C++ 内核包装成 Python 能调的对象，最后一个负责把“问一句答一句”升级成“带模板、带记忆、带工具”的流程。这三层各管一段，串起来才是一条完整的本地大模型工程链路。这篇笔记记录的正是这条链路的第一段：把环境装对、把模型理解透、把最小推理跑通、再把它接进编排框架里。如果你手上有一台显存不算宽裕的机器，又想在完全离线的条件下跑一个能用的对话模型，下面这些内容大致就是你要走的那条路，包括我踩过的每一个坑。

1. 三层栈的分工：谁在算 token，谁在调度流程

很多人第一次接触这套组合时，会把 LangChain 当成“推理引擎”，把 llama-cpp-python 当成“llama.cpp 的 Python 版本”，结果在排查性能问题时方向完全跑偏。我建议在动手之前先把这三层的位置在自己脑子里摆正，后面所有关于速度、内存、参数的困惑都会迎刃而解。这一章不写代码，但它决定了你后面每一行代码该往哪写。

1.1 llama.cpp 在整条链路上的位置

llama.cpp 是一个用 C++ 写的推理内核，它只干一件事：把一堆权重矩阵加载进内存，接收一串 token id，做前向计算，吐出下一个 token 的概率分布。它不关心你的问题是中文还是英文，不关心对话历史怎么拼接，也不关心你是不是在做 RAG。它对接的是最底层的东西：内存分配、SIMD 指令、GPU 后端、量化矩阵的乘法实现。

我之所以强调这一点，是因为 llama.cpp 的性能特征几乎全部来自它的实现细节：它用 mmap 把模型文件映射进地址空间，所以加载一个 4GB 的 GGUF 文件几乎是瞬间完成的，真正慢的是第一次读取页的时候；它用内存对齐的量化块做矩阵乘法，所以量化档位直接决定了单次前向计算的耗时；它把 KV cache 组织成连续的大块内存，所以上下文长度一开大，内存占用就是线性往上顶。你在上层遇到的“加载慢”“爆内存”“首 token 卡住”，根子基本都在这一层。

还有一个容易忽略的事实：llama.cpp 本身是个命令行程序，main、server这些可执行文件才是它的原生产物。llama-cpp-python 编译的时候，实际上是把 llama.cpp 的源码当成一个静态库一起编进去，所以你在 Python 里调用的东西，和命令行跑的东西，是同一份计算内核。这个认知很关键——命令行上验证不通过的模型文件，在 Python 里一样跑不起来；命令行上速度正常的，Python 里不该慢太多（除了 Python 层的开销）。

1.2 llama-cpp-python 不是“另一个推理框架”

它的定位非常单纯：一层薄薄的绑定。它做的事情是把 C 接口用 ctypes 或者更底层的方式暴露成 Python 类，再加一些方便的参数封装，比如Llama(...)构造函数、create_completion、create_chat_completion、流式回调。它自己不做采样算法的创新，也不做张量调度优化，所有的计算都下沉到 llama.cpp。

所以有个判断标准：如果你的瓶颈在“每秒生成多少 token”，那问题在 llama.cpp 那一层，调 Python 代码是没用的；如果你的瓶颈在“请求排队”“上下文拼接”“多轮状态管理”，那才是上层该操心的事情。我在早期犯过一个错，把并发请求全部塞进同一个Llama实例，结果发现请求之间互相等待，还以为是绑定层不支持并发——实际上是 llama.cpp 的上下文对象本身就不是线程安全的，一个Llama实例对应一个llama_context，同一时刻只能服务一个序列。

真正要用多并发，正确做法是开多个进程，或者用它的 server 模式，而不是在 Python 里开线程池直接怼同一个对象。这一点在做小工具的时候不明显，一旦你要给局域网里的几个人同时用，立刻就会撞上。

1.3 LangChain 在这套组合里只做编排

LangChain 的价值在于把“一次推理调用”抽象成可组合的组件：Prompt 模板、输出解析器、检索器、记忆、工具调用。它本身不关心底层是 OpenAI 的接口还是你本地的 GGUF 文件，只要那个对象实现了它约定的接口（invoke、stream、batch），它就能把流程串起来。

这意味着两件事。第一，LangChain 永远不会让你的模型变快，它只会让你的代码变整齐，甚至在简单场景下还会多出一点封装开销。第二，LangChain 的模型封装层（比如LlamaCpp这个类）本质上是把 llama-cpp-python 的参数原样透传下去，你在 LangChain 里能调的n_ctx、n_gpu_layers，和直接实例化Llama时是一模一样的，没有魔法。

理解了这一层，你就能判断什么时候该用 LangChain，什么时候不该用。如果我只需要“输入一段文字，输出一段文字”，直接用 llama-cpp-python 就好了，多一层封装纯属给自己找麻烦。但如果我需要“先检索文档，再按模板拼接，再解析成结构化 JSON，失败还要重试”，那 LangChain 省下来的胶水代码非常可观。

2. GGUF 里到底装了什么：量化档位怎么选

模型文件的选择，是这套链路里唯一一个“选错了要全部重来”的决策。我见过不少人随手拉了一个 2bit 量化的文件，跑起来发现模型胡言乱语，然后开始怀疑是不是框架有问题、参数没调对，实际上问题在文件本身。这一章把我对 GGUF 和量化的理解摊开讲清楚。

2.1 从 float16 到 4bit：量化的物理含义

原始的模型权重是 float16 或者 bfloat16 存的，一个 7B 参数的模型大概要占 14GB 左右。量化的核心思路是：把每几十个或几百个权重分成一组，给这一组算一个缩放因子（scale）和一个最小值（zero point），组内的权重只存整数，读取的时候再乘回去。这样每个权重从 16 位压到 4 位甚至 2 位，体积直接砍到四分之一以下。

GGUF 这个格式本身只是一层容器，它把模型的结构信息（层数、隐藏维度、注意力头数、词表）和量化后的权重块打包在一起，还带了 tokenizer 的词表。所以你拿到一个 GGUF 文件，不需要额外的配置文件，也不需要原始权重，一个文件就是全部。这也是它比早期的 bin 格式好用的地方——早期格式经常出现“模型能加载但词表对不上”的诡异问题。

量化带来的损失并不是均匀分布的。经验上，注意力层的 QKV 投影和输出投影对精度更敏感，而 FFN 层相对宽容；越小的模型对量化越敏感，一个 7B 模型用 4bit 还能保持不错的对话质量，一个 1B 级别的模型用 4bit 就开始明显退化。这个规律我反复验证过，所以在小模型上我宁可多用一点内存上 6bit 或者 8bit，也不想为了省那几百兆把质量搞崩。

2.2 常用量化档位的实测取舍

GGUF 的量化命名有一套自己的规矩，Q4_K_M里的K表示用了 k-quants 那套分块量化方法，M表示 medium 档，介于S（small）和L（large）之间；Q4_0则是老式的均匀量化。名字看起来乱，但用起来就记住几条经验即可。

我自己的默认起点一直是Q4_K_M。原因不只是体积，还有计算效率：4bit 的 k-quants 在 llama.cpp 里有专门优化的矩阵乘内核，实际跑起来往往比Q3_K_M还快一点，因为 3bit 的分块处理在某些后端上反而没那么高效。这个细节在纯看理论体积的时候是想不到的，得实际跑过才知道。

提示：同一个模型的不同量化档位，文件名里通常带着明确的标识（比如-Q4_K_M.gguf），下载时务必确认分辨率和文件名一致。我吃过一次亏，下了一个名字写着 Q5 但实际是 Q4_0 重新打包的文件，速度和内存全对不上，排查了半天才发现是文件本身的问题。

2.3 内存预算怎么算

很多人是跑起来之后看内存监控才知道自己预算够不够，其实这件事在下载之前就能算。总占用可以拆成三块：权重、KV cache、运行时开销。

权重就是文件大小，Q4_K_M的 7B 模型约 4.1GB。KV cache 的公式是：

KV bytes = 2 × n_layer × n_ctx × n_kv_head × head_dim × bytes_per_element

拿一个典型的 7B 举例：32 层，32 个注意力头，但用了 GQA（分组查询注意力），KV 头只有 8 个，每个头的维度是 128，上下文开到 4096，元素用 fp16（2 字节）：

2 × 32 × 4096 × 8 × 128 × 2 = 536,870,912 B ≈ 0.5 GB

如果是老式的不带 GQA 的模型（32 个 KV 头），同样的上下文就是 2GB。这就解释了为什么同样开 4096 上下文，有的模型占用 5GB、有的要 7GB。运行时开销一般估 300MB 到 800MB，取决于编译时开了哪些后端。

所以一个 7B 的Q4_K_M加 4096 上下文，实际占用大概在 5GB 出头。如果你打算把n_ctx开到 16384，KV cache 直接翻四倍到 2GB，总占用逼近 6.5GB。这个数字决定了你是能在 8GB 显存的卡上全量卸载到 GPU，还是只能部分卸载。

3. 装环境这一步最容易翻车：编译开关与 Python 绑定

我装这套环境的次数大概有十几次，在三种操作系统、两种显卡后端上都试过，总结下来的规律是：装得快不代表装对了。默认pip install出来的东西能跑，但往往是纯 CPU 后端，你可能要等到跑长文本时发现速度不对，才意识到编译开关没开。这一章把安装环节的决策点拆开。

3.1 预编译 wheel 与源码编译的边界

pip install llama-cpp-python默认会优先拿预编译包。预编译包的好处是快，缺点是编译时的开关是固定的——通常只带基础的 CPU 指令集，不带 CUDA、不带 Metal、不带 BLAS 加速。

判断标准很简单：如果你的机器只有 CPU，预编译包完全够用，而且它一般会带上 AVX2 之类的指令集支持，性能损失不大。如果你有独立显卡并且想用上，或者你发现 CPU 推理速度远低于预期，那就必须走源码编译：

# 强制从源码编译，不带预编译缓存 CMAKE_ARGS="-DGGML_CUDA=on" \ pip install llama-cpp-python \ --no-binary :all: \ --force-reinstall \ --verbose

--verbose这个参数我强烈建议保留，因为编译过程会把实际启用的后端、找到的 CUDA 版本、编译的架构全部打出来。我第一次编译的时候就是靠这些输出发现系统里装了两套 CUDA 工具链，CMake 找错了那一套。

另外提醒一点：源码编译对环境的依赖比预编译包重得多。需要有 C++ 编译器、CMake、以及对应后端的开发库。缺任何一样都会在编译中途报错，而且报错信息通常不会直接告诉你缺什么，得往上翻几十行日志。

3.2 三个真正影响速度的编译开关

开关很多，但真正在速度上拉开差距的就那么几个，其余大多是边角优化。

最后那个GGML_NATIVE值得单独说说。它让编译器直接针对当前 CPU 的指令集做优化，AVX512 之类的能开就开，实测在纯 CPU 场景下能带来百分之十几的提升。代价是编出来的包换台机器就跑不了或者性能退化，所以只适合自己用的场景。

还有一个坑：不同版本的 llama-cpp-python 对应的 CMake 变量名不完全一样，老版本用LLAMA_CUDA这种前缀，新版本统一改成了GGML_前缀。如果你照着两年前的教程敲命令，很可能变量名根本没被识别，编译顺利完成，但后端根本没编进去，跑起来还是纯 CPU——而且不会有任何报错。这个静默失败是最恶心的。

3.3 怎么验证加速真的生效了

装完必须验证，别相信“编译成功”这四个字。最直接的办法是看后端支持情况：

from llama_cpp import llama_cpp print("GPU offload:", llama_cpp.llama_supports_gpu_offload()) print("mmap:", llama_cpp.llama_supports_mmap())

如果第一行打出来是False，那你的 CUDA 或者 Metal 后端就没编进去，后面设多少n_gpu_layers都是白设。这一步我建议写进自己的环境检查脚本里，每次换机器先跑一遍。

再进一步，可以用实际推理的耗时来验证。加载一个模型，固定max_tokens=128，跑一次看耗时。纯 CPU 的 7BQ4_K_M大概每秒 5 到 15 token（取决于核数和指令集），如果全量卸载到一块中端显卡上，通常能到 30 token 以上。差距非常明显，不需要精确基准测试就能判断。

注意：n_gpu_layers的值不是随便设的。设成 0 表示纯 CPU，设成一个小于总层数的值表示部分卸载，设成 999 或者总层数表示全部卸载。部分卸载时，输入层和输出层通常留在 CPU 上会更划算，因为这两层的数据搬运开销相对大。这个细节没有一个通用最优值，得自己试几档。

4. 第一次跑通推理：参数不是玄学

环境装对之后，第一次调通是最有成就感的环节，也是最容易“跑通了但不知道为什么”的环节。我在这一章里把每个参数的实际含义讲清楚，因为后面所有调优都建立在这些理解上。

4.1 最小可用调用

不追求功能，先追求能出字。这段代码是我每次换新环境时的第一段验证脚本：

from llama_cpp import Llama llm = Llama( model_path="./models/your-model-Q4_K_M.gguf", n_ctx=4096, # 上下文窗口 n_threads=8, # CPU 线程数 n_gpu_layers=0, # 不卸载到 GPU n_batch=512, # 批处理大小 verbose=False, # 关掉加载日志 ) output = llm( "用一句话解释什么是模型量化。", max_tokens=128, temperature=0.7, top_p=0.9, stop=["\n\n"], ) print(output["choices"][0]["text"])

这段跑通代表三件事：模型文件没损坏、tokenizer 能正常工作、后端计算链路是通的。如果这一步就失败，后面的所有东西都不用谈，先解决这里。常见失败原因是文件路径不对（相对路径和绝对路径混用）、文件下载不完整（大小和预期差一截）。

verbose=True的时候会打印一坨加载信息，包括模型参数数量、每层的量化类型、分配的内存大小。第一次加载某个模型时我建议打开看看，这些信息能帮你确认文件是不是你想要的档位——比如看到type = q4_K - medium就对了。

4.2 n_ctx、n_batch、n_threads 的真实含义

这三个参数是被问得最多的，也是误解最多的。

n_ctx是上下文窗口的 token 数上限，输入加输出的总长度不能超过它。它直接决定 KV cache 的内存占用，而且是在构造时就一次性按最大值分配好的。这意味着你把n_ctx设成 32768，哪怕实际只用 100 个 token，那部分内存也已经被占住了。我见过有人把它设成 128000 想支持超长文档，结果构造对象的时候就 OOM。做法是按实际需求设，需要长上下文的时候再单独构造一个实例，别用一个实例硬扛所有场景。

n_batch是单次前向计算处理的 token 数上限，主要影响 prompt 的预填充速度。它越大，长 prompt 的首次响应越快，但峰值内存也会上去。默认值通常是 512，一般够用。只有在处理特别长的输入（比如几千 token 的文档摘要）时，把它调到 1024 或者 2048 才有明显感知。

n_threads是 CPU 计算用的线程数，这里有个反直觉的点：设成逻辑核心数往往比设成物理核心数慢。因为超线程出来的两个逻辑核共享同一套执行单元，在密集的矩阵运算里抢资源反而拖后腿。我一般设成物理核数，8 核 16 线程的机器就设 8，实测比设 16 快一些。

4.3 流式输出与停止条件

真正的产品里几乎不会用一次性返回，用户等不了十几秒才看到第一个字。llama-cpp-python 支持流式，写法很简单：

for chunk in llm( "写一段关于本地推理的说明，200 字左右。", max_tokens=512, stream=True, ): piece = chunk["choices"][0]["text"] print(piece, end="", flush=True)

流式的原理是每生成一个 token 就回调一次，所以整体耗时不会缩短，但用户感知的延迟大幅下降。

stop参数值得单独说。它是一组字符串，一旦生成的文本里出现其中任何一个，就立即停止。这对结构化输出特别重要——比如你要模型输出 JSON，又不希望它在后面继续废话，就把"\n\n"或者特定的结束标记放进stop。有个细节：stop匹配的是生成出来的文本片段，判断发生在拼接之后，所以如果结束标记跨越了两个 token 的边界，也是能正确截断的。

还有max_tokens，它不是“希望输出多少”，而是硬性上限。设太小会出现句子说到一半被切断，设太大又浪费计算。我的习惯是按任务类型设：短问答 128，段落生成 512，长文档处理再单独放宽。

5. 接进 LangChain：把本地权重伪装成标准 LLM

前面四章解决的是“能跑”，这一章解决的是“能组成流程”。从直接调用到接进编排框架，中间有一层适配工作，做得好后面很顺，做得不好会碰到一堆格式问题。

5.1 LlamaCpp 封装的额外开销从哪来

LangChain 提供的LlamaCpp类，本质上是在内部持有一个Llama实例，然后把invoke映射到create_completion，把stream映射到流式回调。所以性能上不会有本质差别，多出来的开销主要是 Python 层的字符串处理和回调封装，量级很小。

真正的差别在参数管理。LlamaCpp把一部分生成参数（temperature、max_tokens、top_p）放在构造函数里，另一部分可以在调用时覆盖。这个设计一开始让我很困惑，因为我在构造函数里设了temperature=0.1，调用时又传了一次，结果发现后者生效了。理解之后觉得合理：构造参数是默认值，调用参数是一次性的覆盖。

有一个参数必须注意：model_kwargs。有些参数LlamaCpp没有直接暴露成构造参数，得通过这个字典传下去。比如你想设置use_mlock或者自定义chat_format，就得走这条路。

from langchain_community.llms import LlamaCpp llm = LlamaCpp( model_path="./models/your-model-Q4_K_M.gguf", n_ctx=4096, n_batch=512, n_gpu_layers=0, temperature=0.7, max_tokens=512, verbose=False, model_kwargs={"use_mlock": False}, )

5.2 Chat 模型与 Completion 模型的分叉

这是接进 LangChain 时最容易搞混的地方。llama-cpp-python 有两套接口：create_completion接收一段纯文本，create_chat_completion接收消息列表。LangChain 这边也对应两个类：LlamaCpp对应前者，ChatLlamaCpp对应后者。

区别不只是接口形式。Chat 接口会用模型自带的对话模板，把消息列表渲染成模型训练时见过的格式（比如带特殊的角色标记和结束符）。用错了会导致模型输出质量明显下降——表现是模型不知道自己在扮演什么角色，或者不停重复用户的话。

判断方法：如果你手上的模型是对话微调过的（名字里通常带chat、instruct这类标识），就用 Chat 接口；如果是基座模型，用 Completion 接口自己拼 prompt。我在早期把对话模型塞进LlamaCpp里跑，结果模型一直自问自答，换成ChatLlamaCpp之后立刻正常了。

chat_format这个参数也要留意。不指定的话，它依赖 GGUF 文件里内嵌的模板信息；有些模型文件里没带这个信息，就得手动指定。指定错了的表现是输出里出现奇怪的标记符号。

5.3 一条能复用的最小链

把模板、模型、解析器串起来，就得到一条完整的最小链：

from langchain_community.chat_models import ChatLlamaCpp from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser chat = ChatLlamaCpp( model_path="./models/your-model-Q4_K_M.gguf", n_ctx=4096, n_gpu_layers=0, temperature=0.3, max_tokens=512, verbose=False, ) prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个严谨的技术助手，回答控制在 200 字以内。"), ("human", "{question}"), ]) chain = prompt | chat | StrOutputParser() print(chain.invoke({"question": "GGUF 格式解决了什么问题？"}))

这条链的价值在于它可以继续往上叠。加一个检索器就是 RAG，加一个输出解析器就能出结构化 JSON，加一个失败重试就变成健壮的生产流程。而底层的推理部分完全不用动，换模型只需要换model_path。

StrOutputParser看着多余，实际很有用：它把消息对象里那一层结构剥掉，只留纯文本。不加的话你拿到的可能是一个消息对象，直接扔给下游会报类型错误。

6. 实测踩坑：报错信息背后的真实原因

这一章里的每一个问题我都真实遇到过，而且第一次遇到时都没能立刻定位。我把排查过程写下来，因为比“正确答案”更有用的是“怎么想到的”。

6.1 首 token 延迟高到离谱

现象：模型加载很快，但第一次调用卡了二三十秒才出第一个字，之后又恢复正常。换个小模型也一样。

我的第一反应是编译没开加速，检查后发现llama_supports_gpu_offload()返回 True，排除。第二反应是n_batch太小，调大之后有一点改善但不明显。

真正的原因是mmap 的惰性加载。llama.cpp 默认用 mmap 加载权重，构造对象时只是建立了地址映射，并没有真正读取文件内容。第一次前向计算要访问所有权重页，这时候才触发磁盘读取，如果模型放在机械盘或者网络挂载的目录上，这个代价极其可观。

验证方法很简单：连续调用两次，看第二次是否明显变快。如果第二次快得多，就是加载的问题。解决办法要么是把模型放到本地 SSD，要么在构造时预读一遍（用一个很短的 prompt 先跑一次），要么关掉 mmap 让它加载时就全读进内存——最后这个方案会牺牲构造速度换取首次调用的速度。

还有一种情况是首次调用时的图构建开销，在 GPU 后端上更明显，通常是几百毫秒级别，不会到几十秒。如果卡了几十秒，一定要先怀疑文件读取。

6.2 内存曲线突然飙升然后进程被杀

现象：跑短对话完全正常，输入一长就整个进程消失，日志里只有一个Killed。

排查链路我走的是这样：先看是不是n_ctx开太大导致构造时就分配了过多 KV cache——用ps或系统监控看构造完成后的常驻内存，如果构造完就已经接近上限，那就是这个原因。再看输入长度有没有超过n_ctx，超了的话有些版本会尝试扩展，直接导致内存暴涨。

还有一种很隐蔽的情况：同时存在多个实例。LangChain 的LlamaCpp在某些用法下会被重复实例化，比如在流式场景里，如果不小心在每次调用时都重新构造对象，模型会被反复加载，内存一路往上叠，最后被系统杀掉。这个问题的表现是“跑一会儿才崩”，而不是一上来就崩，很容易误判成内存泄漏。检查方法是在代码里打点，确认构造函数只被调用了一次。

第三类原因是n_batch开得过大配合长输入，峰值内存会瞬间冲到很高。这种情况下系统监控上能看到一个尖峰然后断崖式下跌，而不是缓慢上升。区分这两种曲线形态，基本就能定位原因。

6.3 输出重复、乱码、中途截断

这三种症状对应的原因完全不同，混在一起排查会疯掉。

重复：模型反复输出同一句话，通常是repeat_penalty太低或者采样参数太极端。temperature设得极低（比如 0.01）配合top_p也很低时，模型会一直选同一个 token，进入死循环。把repeat_penalty调到 1.1 到 1.2 之间，temperature回到 0.7 左右，基本能解决。

乱码：输出里出现一堆看不懂的符号或者基字符，八成是 chat 模板用错了，模型在按训练时的格式输出特殊标记，但因为外层没做对应处理，标记原样漏了出来。检查chat_format，或者换成 Completion 接口手动拼 prompt。

中途截断：句子说到一半停了，先看max_tokens是不是设太小；再看stop里是不是包含了会提前出现的字符串，比如把"\n"放进了stop，而模型恰好在段落中间换行；最后看n_ctx是否被撑满，输入加输出的总量碰到上限，生成会被强制停止。这三个原因按这个顺序查，命中率很高。

提示：日志不要只打最终输出。我在排查这类问题时养成了一个习惯，把每次调用的prompt_tokens、completion_tokens、finish_reason都打出来。finish_reason是length说明被长度限制截断，是stop说明命中了停止符，这一条信息就能省掉一半的排查时间。

7. 几个我反复用到的工程习惯

最后聊几个跟具体代码无关、但实打实省时间的做法。

第一个是模型文件统一命名和归档。我见过太多人（包括早期的我）把模型随便扔在一个目录里，文件名是下载时的乱码，过两个月完全不知道自己用的是哪个档位。我现在的习惯是目录名带模型标识，文件名固定格式模型名-量化档位.gguf，同时在目录里放一个短文本记录来源和下载日期。这件事花不了一分钟，但省下的排查时间是以小时计的。

第二个是把环境验证写成脚本。检查后端支持、检查模型能否加载、跑一次固定长度的推理并打印耗时，三件事做成一个脚本，换机器先跑一遍。很多“为什么这么慢”的问题，跑完这个脚本就有答案了。

第三个是参数先固定再调优。新手常犯的错是一次改好几个参数，然后发现效果变好了但不知道为什么，下次遇到问题还是不会调。我建议先固定一套保守参数（temperature=0.7、top_p=0.9、repeat_penalty=1.1、n_ctx按需），把这个基线记住，之后每次只改一个参数对比结果。慢一点，但积累下来的直觉是真正属于自己的。

第四点是不要迷信更大的上下文。我一度觉得上下文开得越大越好，直到发现一个开了 32768 上下文的实例在 8GB 内存的机器上根本跑不动，而实际业务里 90% 的对话根本用不到 4K。现在我的做法是按任务分实例：日常对话一个 4K 的实例，长文档处理单独构造一个 16K 的实例，用完就释放。资源利用率和稳定性都好得多。

这套组合最舒服的地方在于，它把“模型能力”和“工程编排”彻底解耦了。底下的推理内核可以在不改一行业务代码的情况下换成更快的后端或者更好的量化档位，上面的编排逻辑也可以在换模型时原样保留。把这个边界划清楚，后面无论往上叠检索、工具调用还是多轮记忆，路都会好走很多。这一篇记的是把地基打平的过程，往下就该处理更细的东西了——多轮对话里的上下文裁剪策略、模板里的占位符如何避免注入、以及怎么给一个本地模型套上能返回结构化数据的输出约束。