在 2.2.2 节完成本地部署后，若仍感觉补全延迟高或显存吃紧，可通过以下手段进一步压榨硬件性能。以下参数大多只需修改一次，即可在全项目周期内受益。
1. 量化策略：用精度换速度
模型文件体积直接决定加载速度和推理延迟。
- 日常补全：优先使用 Q4_K_M 量化版本。它在 7B 模型上通常只损失约 2–4% 的代码准确率，但推理速度比 Q8_0 快 30–50%，显存占用减少近半。
- 复杂重构：若临时需要更高精度，再切换至 Q8_0 或原始精度模型；不建议常驻 F16/FP32，除非显存 ≥ 48 GB。
- 避免 Q2 和旧版 Q4_0：它们对代码类模型的权重压缩过于激进，容易出现括号不匹配、变量名乱码等低级错误。
2. 动态收紧上下文窗口
本地显存是硬瓶颈，上下文长度每翻一倍，KV Cache 显存占用几乎线性增长。
- 补全场景：将
context length限制在 2048–4096。单函数补全极少需要更长上下文，且短上下文能显著降低首个 Token 延迟（Time To First Token）。 - 对话/解释场景：可临时调高至 8192，完成后立即切回，防止多人共用时显存溢出。
- vLLM 用户：显式设置
--max-model-len 4096和--max-num-batched-tokens 4096，防止框架按模型配置文件默认加载过长上下文。
3. GPU 层卸载（GPU Layers）
llama.cpp / Ollama 系列允许指定加载到显存的模型层数。
- 原则：尽可能让
n_gpu_layers接近模型总层数，实现“全 GPU 推理”。 - 显存不够时：宁可加载 一半层数到 GPU，也不要全部放 CPU。混合卸载的延迟通常远好于纯 CPU。
- Apple Silicon：Metal 后端会自动管理，但可通过
num_gpu参数限制不超出统一内存的 70%，避免系统杀进程。
4. 批处理与并发控制
多人或高频调用时，合理设置批处理能减少排队。
- vLLM：启用 Continuous Batching，保持
--max-num-seqs 4–8。若仅个人使用，设为 1 可降低显存碎片。 - Ollama：修改
OLLAMA_NUM_PARALLEL环境变量（默认 1）。单机共享给 2–3 人时设为 2 即可，过高会导致显存撑爆。 - llama.cpp：启动时加入
-np 2允许两个并行槽位，配合-cb开启连续批处理。
5. 系统级加速
- 锁定内存（mlock）：Linux 下启动 llama.cpp 或 Ollama 时开启
mlock，防止模型权重被换入 Swap，避免突发性卡顿。 - 关闭 Swap 或限 Swap：纯 GPU 推理时，Swap 基本用不上；若系统内存紧张，建议
sudo swapoff -a（临时测试），观察是否还出现硬盘狂转。 - CPU 亲和性（NUMA）：双路服务器或 Threadripper 平台运行纯 CPU 推理时，在 llama.cpp 中开启
--numa distribute，可减少跨节点内存访问延迟。
6. 采样参数微调
性能不仅看硬件，生成策略也影响实际体感。
- Temperature：设为 0.1–0.2。低温不仅提升准确性，还能减少解码步骤中的随机分支计算，轻微加速输出。
- Repeat Penalty：建议 1.0–1.05。过高的重复惩罚会引入额外计算，且对代码补全帮助有限。
- 限制 Max Tokens：补全单行至多 100–150 tokens，函数体生成至多 512 tokens。不要默认让模型生成到上下文上限。
7. 一键速查表
| 场景 | 推荐配置 |
|---|---|
| 个人笔记本 4060/8G，7B 补全 | Q4_K_M + ctx 2048 + 全 GPU 卸载 |
| 工作站 3090/24G，14B 共享 | Q4_K_M + ctx 4096 + batch=2 + mlock |
| 服务器 A10/24G，32B 服务多人 | vLLM + Q4 + max-model-len 4096 + max-num-seqs 4 |
| 旧机纯 CPU，7B 应急 | Q4_K_M + ctx 1024 + 4 线程 + NUMA distribute |
调优后，建议用同一段代码反复测试 3–5 次补全延迟，取平均值对比。若首个 Token 延迟仍超过 2 秒，说明硬件已触及瓶颈，应降级模型尺寸而非继续调参。