第21章：模型定制与私有化部署

很多团队在构建 Agent 的过程中，早晚会遇到一个诱惑：要不要自己训练或微调一个模型？有时候是因为调用云端 API 成本太高，有时候是数据不能出内网，有时候是通用模型在特定任务上表现不够稳定。

这一章讲的是模型层面的工程决策——什么时候该微调，怎么微调，微调完怎么高效部署，以及把这一切拼成一条完整链路需要面对的真实挑战。

本章是模型层与部署层主题，不是 Runtime 本身；Runtime 的可靠执行机制在第 16 章已经讲过，本章不重复。
注意时效：推理引擎生态变化较快。本章所有工具现状截至 2026.05，具体版本、性能数据请以官方文档为准。

21.1 何时需要微调 —— 大多数时候答案是"不需要"

核心直觉

微调是在预训练权重上打补丁。但大多数情况下，你遇到的问题根本不是"模型不够聪明"，而是"prompt 写得不够清楚"或"工具设计得不好"或"上下文管理有问题"。先把这些基础工作做扎实，比微调的性价比高得多。

先把这三件事做完再考虑微调

按照投入产出比排序：

1. 优化 System Prompt 和工具描述

大多数 Agent 表现不稳定，根因是指令不够清晰、工具命名模糊、参数描述不完整。改 prompt 是零成本、可以在几小时内验证的操作。

2. 结构化输出 + 约束解码

如果模型输出格式不稳定，先用 JSON Schema 约束格式，或者加外部 JSON 修复器（如 jsonrepair），而不是训练模型学会"稳定地输出 JSON"。

3. Few-shot 示例注入

在 prompt 里加 3-5 个高质量示例，常常能显著改善特定任务表现，而且比微调更快验证。具体提升幅度取决于任务、基础模型和示例质量，不能把某个百分比当成通用规律。

真正需要微调的几种情况

经过上面三步之后，如果还有问题，才考虑微调：

场景	为什么微调有效	典型例子
特定领域工具调用准确率低	通用模型没见过你的工具命名约定，微调后可以建立映射	内部 ERP 系统的 100 个 API
输出格式必须极度稳定	高吞吐场景下，模型级别的格式约束比推理层解析更快	实时 SQL 生成、结构化日志解析
数据不能出内网 + 本地资源充足	这是合规或安全驱动的需求，不是单纯性能驱动	医疗、金融、政府场景
需要固定行为风格或领域术语	模型反复处理同类任务，且 prompt 示例已经变得很长	内部客服口径、专业报告格式、行业术语规范

微调不能解决的问题

幻觉：微调通常无法根治幻觉，有时反而会让模型在训练域内更"自信地胡说"
上下文长度不足：微调不能扩展模型的物理上下文窗口，那需要架构改动
常识推理缺失：基础能力不足不是数据能补的，换更强的底座模型更有效

21.2 LoRA / QLoRA 微调实战

核心直觉

LoRA（Low-Rank Adaptation）的本质是：全量微调要改几十亿个参数，LoRA 只改一小个低秩矩阵来"逼近"你想要的参数变化。

为什么这样行得通？训练过程中的参数更新矩阵 $\Delta W$ 往往具有低秩结构——你的任务适应通常只需要改变模型的少数"方向"，不用动整个参数空间。

$$\Delta W = A \cdot B, \quad A \in \mathbb{R}^{d \times r}, B \in \mathbb{R}^{r \times k}, r \ll \min(d, k)$$

以 7B 参数模型为例：全量微调需要几十 GB 显存，LoRA（r=16）只需要几 GB 显存，可训练参数量降低约 100 倍。

QLoRA 是 LoRA 的量化版本——把基础模型用 4-bit NF4 量化加载进显存，再在此基础上训练 LoRA 适配器。单张 RTX 4090 就能微调一个 7B 模型，显存需求从 40GB 降到约 12GB。

训练数据构造：Agent 执行日志 → SFT 数据

微调 Agent 用的数据，最理想的来源不是手写，而是从生产日志中提炼。

Pipeline：

数据格式示例：

python

# 一个 Agent 工具调用的 SFT 样本
{
    "messages": [
        {
            "role": "system",
            "content": "你是一个内部 ERP 系统的 Agent，负责处理工单..."
        },
        {
            "role": "user",
            "content": "帮我查一下订单 ORD-2024-0312 的物流状态"
        },
        {
            "role": "assistant",
            "content": None,
            "tool_calls": [{
                "function": {
                    "name": "query_order_status",
                    "arguments": '{"order_id": "ORD-2024-0312", "include_logistics": true}'
                }
            }]
        },
        {
            "role": "tool",
            "content": '{"status": "shipped", "carrier": "顺丰", "tracking": "SF1234567890"}'
        },
        {
            "role": "assistant",
            "content": "订单 ORD-2024-0312 已发货，承运方为顺丰，运单号 SF1234567890。"
        }
    ]
}

关键点：SFT 主集只放高质量轨迹。失败轨迹不要直接混进 SFT，否则模型可能学到错误工具路径或坏格式；但失败轨迹非常适合做 DPO / preference 数据、red team regression eval 和 hard negative。生产日志转训练数据前，还必须做 PII 脱敏、secret 清理、租户隔离和授权确认。不要把用户私有对话、工具返回里的 access token、内部 URL、客户数据原样送进训练集。

实战配置参考

python

# 使用 Hugging Face TRL + unsloth 做 QLoRA 微调
# 注意：具体参数取决于模型架构和硬件，以下仅作参考

from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments

# 加载 4-bit 量化的基础模型
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="Qwen/Qwen2.5-7B-Instruct",
    max_seq_length=8192,
    load_in_4bit=True,  # QLoRA：4-bit NF4 量化
)

# 添加 LoRA 适配器
model = FastLanguageModel.get_peft_model(
    model,
    r=16,               # LoRA 秩，越大容量越强，但也更容易过拟合、显存更多
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],  # 常见做法：覆盖注意力层和 MLP 层，具体以模型结构为准
    lora_alpha=16,
    lora_dropout=0.05,
)

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        num_train_epochs=3,
        learning_rate=2e-4,
        fp16=True,
        output_dir="./lora-agent-finetuned",
    ),
)
trainer.train()

微调后评估

微调完不能只看 Loss 下降了多少。对 Agent 场景，需要专门评估：

工具调用准确率：在 hold-out 测试集上，工具名选择正确率、参数填充准确率
格式合规率：结构化输出是否稳定（针对无约束解码场景）
回归测试：检查微调有没有破坏通用能力（问答、推理）
安全回归：检查微调后是否更容易泄露系统提示、跳过审批或调用越权工具
分布外表现：检查没有出现在训练集里的工具、参数组合和异常输入

一个简单但有效的检验方法：拿 100 个生产真实 case 跑微调前后的对比，人工标注哪个输出更好。同时保留第 18 章的自动 eval 套件，用它检查工具调用、格式、权限和长任务是否回归。人工判断和自动 eval 是互补关系，不是谁替代谁。

21.3 模型蒸馏 —— 大模型 → 小模型

核心直觉

模型蒸馏的比喻：大模型是一位经验丰富的老师，小模型是学生。学生不只看课本答案（ground truth），还要学习老师在任务上的行为分布——哪些答案更可能、哪些工具路径更可靠、哪些中间检查点更关键。这比只让学生背标准答案要学得多。

两种蒸馏路线

知识蒸馏（Knowledge Distillation）：经典方式。大模型（Teacher）的输出概率分布作为软标签，小模型（Student）学习逼近这个分布。

$$\mathcal{L}_{KD} = \alpha \cdot \text{KL}(p_T / \tau | p_S / \tau) + (1 - \alpha) \cdot \text{CE}(y, p_S)$$

其中 $\tau$ 是温度，$p_T$ 是 Teacher 的 softmax 输出，$p_S$ 是 Student 的输出。

轨迹蒸馏（Trajectory Distillation）：对 Agent 场景更实用。直接用大模型生成高质量的工具调用轨迹，小模型在这些轨迹上做 SFT。本质是让大模型当"标注工"。

推理能力蒸馏

这是 2024-2025 年兴起的方向：把强推理模型解决任务的行为迁移到小模型里。这里要小心一个边界：很多商业模型不会暴露原始 Chain-of-Thought，而且直接训练模型复述长 CoT 也可能引入幻觉和安全问题。更稳妥的做法是蒸馏可验证的推理轨迹：任务分解、工具调用序列、检查点、最终答案和经过清洗的简短理由。

DeepSeek 发布 R1 时公布的一个关键信息：他们用 R1 生成的推理轨迹数据，成功训练出了 7B 和 14B 级别的小模型，这些小模型在数学和代码推理任务上的表现远超同参数量的普通指令微调模型。来源：DeepSeek-R1 技术报告。

对 Agent 开发者的含义：如果你需要一个能做复杂规划的轻量模型，蒸馏大模型的可验证轨迹通常比只蒸馏最终答案更有效。但训练前必须过滤失败轨迹、去掉不可公开的内部推理文本，并确保数据许可证允许用于训练。

端侧 Agent：蒸馏的终极目标

手机和边缘设备上能跑的模型通常在 1-7B 参数之间。通过蒸馏，可以把特定场景的 Agent 能力压缩到这个规模里。目前已经有一些团队在做"离线 Agent"：不依赖云端 API，完全在设备本地运行。

代价：通用性大幅下降。端侧模型通常只能做好 1-2 个特定任务，复杂规划能力很有限。

21.4 推理部署引擎

微调完的模型需要高效地对外提供服务。这里介绍几个主要工具，并说明它们各自的定位。

vLLM —— 生产首选

vLLM 由 UC Berkeley Sky Computing Lab 发起，是生产环境中最活跃的开源推理引擎之一。核心技术是 PagedAttention——借鉴操作系统虚拟内存的分页机制管理 KV Cache，让多个并发请求更高效地使用显存，显著提升吞吐量。

核心能力（截至 2026.05）：

Continuous batching：请求动态加入/离开 batch，无需等到一批全部完成
PagedAttention：大幅提升 KV Cache 利用率，支持高并发
多 LoRA 热加载：在不重启服务的情况下，同时服务多个 LoRA 适配器
OpenAI 风格 API：支持 Chat Completions 等常用接口，方便接入已有客户端
工具调用支持：需要按模型选择 --tool-call-parser 和 chat template，不能假设所有模型自动可用
量化支持：FP8、INT8、AWQ、GPTQ、GGUF 等多种格式（具体组合以版本文档为准）
支持大量模型架构：Llama、Qwen、Gemma、Mistral、DeepSeek 等

bash

# 安装并启动 vLLM 服务（需要 NVIDIA GPU）
pip install vllm

# 启动 OpenAI 兼容的推理服务
vllm serve Qwen/Qwen2.5-7B-Instruct \
    --port 8000 \
    --max-model-len 32768 \
    --gpu-memory-utilization 0.9

# 如需 OpenAI 风格 tool calling，需要按模型选择 parser / chat template
# 例如某些模型可使用 hermes、qwen3_xml、llama3_json 等 parser
vllm serve <model> \
    --enable-auto-tool-choice \
    --tool-call-parser <parser_name>

# 如果有微调的 LoRA 权重，可以热加载
vllm serve base-model \
    --enable-lora \
    --lora-modules "my-agent-lora=/path/to/lora/weights"

调用方式接近 OpenAI API，但工具调用质量取决于模型本身、chat template 和 tool parser：

python

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")

response = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "分析这份合同的风险条款..."}],
    tools=[...],  # API 形状接近 OpenAI；服务端仍需要匹配模型的 tool parser
)

vLLM 的典型部署形态：

什么时候选 vLLM： 生产环境、高并发、需要多 LoRA 服务、需要 OpenAI 风格 API、GPU 服务器部署。不要只看 QPS，也要看上下文长度、输出长度、并发数和 P95 延迟。

Ollama —— 本地开发首选

Ollama 的定位是"本地开发和测试"。一条命令把模型跑起来，适合快速验证想法。

bash

# 拉取并运行模型
ollama run qwen2.5:7b

# 启动 API 服务（默认端口 11434）
ollama serve

# 用 Python 调用（OpenAI 兼容接口）
import openai
client = openai.OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

截至 2026.03，Ollama 在 Apple Silicon 上的新特性： 开始使用 MLX（Apple 的机器学习框架）驱动推理，在 M 系列芯片上的速度相比之前的 Metal 方案有提升。来源：Ollama MLX 预览博客

Ollama 还支持： 结构化输出（JSON Schema 约束）、工具调用、流式工具调用、云端模型和多种开发工具集成。具体模型是否能稳定 tool call，仍要看模型模板和运行时支持。

什么时候选 Ollama： 开发机本地验证、Mac 本地原型、小团队内网低并发工具。不适合生产高并发或强 SLA 场景。

TGI（Text Generation Inference）—— 已进入维护模式

需要特别说明一个重要变化：HuggingFace 官方文档已经将 TGI 标注为维护模式（maintenance mode）。

官方文档原文：

"TGI has initiated the movement for optimized inference engines to rely on a transformers model architectures. This approach is now adopted by downstream inference engines, which we contribute to and recommend using going forward: vllm, SGLang..."

来源：TGI 官方文档首页

这意味着新项目不宜默认选择 TGI。如果你的团队还在用 TGI，不一定要立刻迁移，但应该评估 vLLM、SGLang 或 llama.cpp / MLX 等替代方案的长期维护和性能收益。

TGI 的历史贡献是推动了生产级推理引擎的标准化。它在已有系统中仍可能稳定工作，但作为新项目选型，持续演进速度已经不是优势。

SGLang —— 新兴竞争者

SGLang 是 2024-2026 年快速崛起的推理引擎，强调高性能 serving、结构化生成和复杂推理工作负载。它也是 HuggingFace 文档中推荐关注的 TGI 替代方向之一。如果你的场景对长上下文、批量吞吐、结构化生成或推理模型延迟有极致要求，值得和 vLLM 做实测对比。

对比总结

维度	vLLM	Ollama	SGLang
主要定位	生产部署	本地开发	高性能推理
高并发支持	强	弱	强
多 LoRA 支持	支持热加载	有限	支持
硬件要求	NVIDIA GPU 最佳	CPU/Apple Silicon	NVIDIA GPU 最佳
OpenAI 风格 API	是	是	是
社区活跃度	非常活跃	活跃	快速增长
使用门槛	中	低	中

21.5 开源模型做 Agent 的工程现实

用开放权重模型（Llama、Qwen、Mistral、DeepSeek 等）做 Agent，和调用闭源 API 有本质区别。这一节讲真实踩坑和工程应对，不是参数对比。

工具调用能力差异

不同开放权重模型的工具调用实现不统一。有的支持原生 function calling 格式，有的需要把工具描述塞进 system prompt 再手动解析输出。

常见现实：

Qwen2.5 / Qwen3 系列有自己的工具调用模板；Qwen3 官方更推荐 Hermes-style tool use，推理模式和工具调用模板要谨慎组合
Llama 3.1/3.2/4 系列支持工具调用，但模板和解析器仍要按具体模型确认
Mistral 系列有自己的 function calling 格式
小模型的工具调用稳定性通常低于大模型，尤其在工具数量多、参数 schema 复杂、上下文很长时

处理方式：用推理框架的工具解析器（vLLM 内置多种 tool_parser，也支持自定义 parser），或者在外部加 JSON 修复层和 schema 校验。不要指望直接用 OpenAI SDK 连本地模型就能完美工作。

提示格式绑定

每个模型有自己的 chat template，对话格式、系统提示的位置、特殊 token 都不一样。用错格式会导致模型"失忆"——它看到的不是正确的对话结构，所以输出质量下降。

python

# 正确做法：用 tokenizer 内置的 chat template
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct")

messages = [
    {"role": "system", "content": "你是一个 Agent..."},
    {"role": "user", "content": "帮我查订单状态"},
]

# apply_chat_template 会自动处理模型特定的格式
prompt = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True  # 加上模型回复的开头 token
)

长任务可靠性

开放权重模型的长任务稳定性不只取决于参数量，也取决于训练数据、chat template、推理引擎和上下文管理。常见问题包括：

到上下文后半段时"忘记"前面设定的任务目标
工具调用轨迹过长后开始产生格式错误
自我修正能力弱——出错后无法有效回溯

应对策略：

上下文压缩：每隔 N 步做一次摘要，清理冗余的工具返回
外置检查点：在 Runtime 层保存每一步的状态，出错时从检查点恢复而不是从头重来（第 16 章）
Sub-agent 隔离：把长任务拆成短子任务，每个子任务用独立的上下文窗口

评估重点：不是聊天能力

选开源模型做 Agent，不能只看通用排行榜（MMLU 之类）。Agent 场景的核心指标是：

工具调用准确率（Tool Calling Accuracy）：给定任务，模型选对工具 + 填对参数的概率
结构化输出稳定性：连续生成 100 次，JSON 格式合规率
长轨迹跟随能力：20 步以上的任务，最终成功率和路径偏差率

可参考的基准包括 BFCL（Berkeley Function-Calling Leaderboard）、τ-bench、ToolBench、MCPToolBench++ 等。不要只看通用聊天榜单；真正上线前，仍然要用自己的工具 schema 和真实任务做第 18 章那类回归 eval。

一个稳定的工程规律

社区经验反复指向同一个规律：工具数量、工具描述长度和 schema 复杂度一上来，小模型最先失稳。解决方案不是盲目换最大模型，而是在运行时动态加载工具子集：按任务类型、用户权限和当前状态只暴露最相关的 5-15 个工具。

这也印证了第 7 章讲的工具管理原则：工具数量本身不是问题，但一次性暴露给模型的工具数量需要控制。对开放权重模型尤其如此。

21.6 私有化部署的完整链路

把上面所有内容串起来，是一条从"选模型"到"上线运行"的工程链路。

模型选择

选开放权重模型时，几个优先考虑的维度：

许可证与使用限制：是否允许商用、再分发、微调、蒸馏、托管服务；是否有用户规模、地域、行业限制
工具调用原生支持：模型是否内置了 function calling 格式，还是需要 prompt 工程绕过
上下文窗口：Agent 任务通常需要 32K+，短上下文模型不适合长任务
量化友好：模型是否有官方量化版本（减少你自己量化的工作）
社区活跃度：是否有持续的微调数据集、benchmark 结果和工程踩坑分享
供应链可信度：权重来源、checksum、模型卡、训练数据声明、安全扫描记录是否完整

截至 2026.05，工具调用能力综合表现较好的开放权重模型系列包括 Qwen2.5 / Qwen3、Llama 3.x / 4、Mistral、DeepSeek 等，具体版本和能力边界以当时的官方模型卡、推理框架文档和自己的 eval 为准。

量化

量化能显著降低模型显存占用，代价是精度和稳定性可能下降。对大多数 Agent 任务，INT8 或 FP8 量化的精度损失通常较小；INT4 量化收益更大，但在工具调用、代码生成、长上下文和数字密集任务上更容易出错，需要单独评估。

常用量化方案：

AWQ（Activation-aware Weight Quantization）：精度损失较小，社区预量化模型多
GPTQ：更早期的方案，兼容性好
FP8：vLLM 原生支持，精度损失很小，推荐在支持 FP8 的 GPU 上优先使用
GGUF：适合 llama.cpp / Ollama 生态和 CPU / Mac 本地推理，不一定是 GPU 高并发生产 serving 的最佳格式

部署

生产环境的最小可用部署配置：

yaml

# docker-compose.yml 示例（仅供参考，生产配置需根据实际情况调整）
version: '3'
services:
  vllm:
    image: vllm/vllm-openai:v0.x.y  # 生产环境固定具体版本
    command: >
      --model /models/Qwen2.5-7B-Instruct
      --port 8000
      --gpu-memory-utilization 0.85
      --max-model-len 32768
      --enable-lora
    volumes:
      - /data/models:/models
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    ports:
      - "8000:8000"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

生产部署还要补几件 docker-compose 示例里没有体现的事：

镜像和模型权重要固定版本，不要长期使用 latest
对模型文件做 checksum 校验，防止权重被替换
API 前面加认证、限流和租户隔离，不要把 vLLM 端口直接暴露到公网
配置 GPU 监控、节点亲和性、PodDisruptionBudget 和滚动升级策略
对不同租户或业务线设置独立 quota，防止一个 Agent 抢光显存和队列

监控

私有化部署不代表可以不做监控。vLLM 内置了 Prometheus 指标，暴露到 /metrics 端点。关键指标：

vllm:e2e_request_latency_seconds：端到端延迟
vllm:gpu_cache_usage_perc：KV Cache 使用率（高于 90% 时需要注意）
vllm:num_requests_running / waiting：队列深度，反映负载情况
vllm:prompt_tokens_total / generation_tokens_total：Token 用量，用于成本核算

具体指标名会随 vLLM 版本变化，生产接入时以实际 /metrics 输出为准。除了系统指标，还要监控 Agent 质量指标：

工具调用成功率、格式合规率、schema 修复率
超时率、重试率、熔断次数
每任务 token 数和 cost per successful task
LoRA 版本、量化版本、chat template 版本与失败率的关联
安全指标：越权工具调用拦截数、外传尝试、审批触发率

更新策略

私有化部署的模型版本管理是个容易被忽视的工程问题：

微调好的新版本模型如何灰度切流
LoRA 适配器的版本管理（不用重新部署基础模型，只更换适配器）
量化版本与新训练数据的兼容性
chat template、tool parser、tokenizer 和模型权重必须作为一个版本包管理
新模型上线前必须跑第 18 章的 regression eval，不能只看离线 loss 或通用 benchmark

实践上，把模型路径、LoRA 配置、chat template 和 tool parser 做成版本化配置，配合第 19 章讲的 Feature Flag 机制，可以做灰度切流和快速回滚。需要注意：LoRA 适配器热加载不等于基础模型热更新；基础模型、量化格式、tokenizer 变化通常需要滚动重启推理实例。

私有化部署的隐藏成本

很多团队只比较"API 单价 vs GPU 成本"，低估了自托管的总成本。私有化部署还包括：

GPU 采购或租赁、利用率管理、空闲成本
推理引擎升级、CUDA / driver / kernel 兼容性
模型许可证审查和安全扫描
数据脱敏、审计、访问控制
线上故障值班、容量规划、备份和灾备
自建 eval、监控、灰度和回滚平台

一个务实判断：如果你的主要需求是合规或数据驻留，私有化部署可能是必须选项；如果只是想省钱，先算清 GPU 利用率、运维人力和质量回归成本，再决定是否值得。

面试高频题

如何判断你的 Agent 是否需要微调？

参考答案框架：

先排除其他原因：表现不好的根因是什么？工具设计、prompt 质量、上下文管理，这三个问题比微调更容易且有效地修复
量化差距：建立评估集，测量当前基础模型的表现。如果准确率已经很高，微调可能收益有限；如果远低于产品要求，先判断是领域差距、工具设计问题还是基础模型能力不足
数据可行性：是否有足够的高质量轨迹数据？几百个高质量样本可以验证方向，稳定上线通常需要更多覆盖长尾和失败模式的数据
合规驱动：如果是数据不能出内网，那是合规需求，不是性能需求，判断逻辑不同

加分点： 讲清楚微调能解决什么（领域工具调用适配）和不能解决什么（幻觉、长任务可靠性），说明自己了解评估体系而不是把微调当万能药。

微调后如何评估效果？

参考答案框架：

任务相关指标优先：工具调用准确率、格式合规率，而不是通用 benchmark
回归测试：确保微调没有破坏通用能力、安全边界、工具审批和长任务恢复能力
实际 case 对比：用真实生产 case 对比，人工判断哪个更好
在线 A/B 测试：如果有生产流量，在真实环境中对比微调前后的成功率

加分点： 提到"微调前先建立基准（baseline），再微调，再对比"——没有基准就没有改进。提到 pass@k 和 pass^k 两种指标的区别（参见第 18 章）。

参考资料

[1] DeepSeek-AI - DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning - (https://arxiv.org/abs/2501.12948)

[2] Hu et al. - LoRA: Low-Rank Adaptation of Large Language Models - ICLR 2022 (https://arxiv.org/abs/2106.09685)

[3] Dettmers et al. - QLoRA: Efficient Finetuning of Quantized LLMs - NeurIPS 2023 (https://arxiv.org/abs/2305.14314)

[4] vLLM 官方文档 - Easy, fast, and cheap LLM serving for everyone (https://docs.vllm.ai/en/latest/)

[5] Ollama 官方博客 - Ollama is now powered by MLX on Apple Silicon in preview, March 2026 (https://ollama.com/blog/mlx)

[6] HuggingFace TGI 官方文档 - Text Generation Inference（维护模式声明）(https://huggingface.co/docs/text-generation-inference/index)

[7] Lin et al. - AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration (https://arxiv.org/abs/2306.00978)

[8] vLLM 官方文档 - Tool Calling (https://docs.vllm.ai/en/latest/features/tool_calling.html)

[9] Berkeley Function-Calling Leaderboard (BFCL) (https://gorilla.cs.berkeley.edu/leaderboard.html)

[10] SGLang 官方文档 (https://docs.sglang.ai/)

第21章：模型定制与私有化部署 ​

21.1 何时需要微调 —— 大多数时候答案是"不需要" ​

核心直觉 ​

先把这三件事做完再考虑微调 ​

真正需要微调的几种情况 ​

微调不能解决的问题 ​

21.2 LoRA / QLoRA 微调实战 ​

核心直觉 ​

训练数据构造：Agent 执行日志 → SFT 数据 ​

实战配置参考 ​

微调后评估 ​

21.3 模型蒸馏 —— 大模型 → 小模型 ​

核心直觉 ​

两种蒸馏路线 ​

推理能力蒸馏 ​

端侧 Agent：蒸馏的终极目标 ​

21.4 推理部署引擎 ​

vLLM —— 生产首选 ​

Ollama —— 本地开发首选 ​

TGI（Text Generation Inference）—— 已进入维护模式 ​

SGLang —— 新兴竞争者 ​

对比总结 ​

21.5 开源模型做 Agent 的工程现实 ​

工具调用能力差异 ​

提示格式绑定 ​

长任务可靠性 ​

评估重点：不是聊天能力 ​

一个稳定的工程规律 ​

21.6 私有化部署的完整链路 ​

模型选择 ​

量化 ​

部署 ​

监控 ​

更新策略 ​

私有化部署的隐藏成本 ​

面试高频题 ​

如何判断你的 Agent 是否需要微调？ ​

微调后如何评估效果？ ​

参考资料 ​

第21章：模型定制与私有化部署

21.1 何时需要微调 —— 大多数时候答案是"不需要"

核心直觉

先把这三件事做完再考虑微调

真正需要微调的几种情况

微调不能解决的问题

21.2 LoRA / QLoRA 微调实战

核心直觉

训练数据构造：Agent 执行日志 → SFT 数据

实战配置参考

微调后评估

21.3 模型蒸馏 —— 大模型 → 小模型

核心直觉

两种蒸馏路线

推理能力蒸馏

端侧 Agent：蒸馏的终极目标

21.4 推理部署引擎

vLLM —— 生产首选

Ollama —— 本地开发首选

TGI（Text Generation Inference）—— 已进入维护模式

SGLang —— 新兴竞争者

对比总结

21.5 开源模型做 Agent 的工程现实

工具调用能力差异

提示格式绑定

长任务可靠性

评估重点：不是聊天能力

一个稳定的工程规律

21.6 私有化部署的完整链路

模型选择

量化

部署

监控

更新策略

私有化部署的隐藏成本

面试高频题

如何判断你的 Agent 是否需要微调？

微调后如何评估效果？

参考资料