FDE W1D6 学习手册 · 本地模型体验 [B]

W1 Day6 · B 级（动手体验，面试加分）· 4h · 学完能讲清"量化本质 / 本地模型 vs API 的成本效果权衡"

一、为什么要亲手体验本地模型

做 FDE（前端/全栈开发工程师方向的 AI 能力岗），理解"模型怎么被部署、跑在自己机器上是什么体验"比只会调 API 更有竞争力。本地模型体验的核心价值有三层：

• 建立成本直觉：API 按 token 计费是"看不见的成本"，本地模型是"看得见的显存/电费/延迟"，亲手跑过才知道 7B 模型 fp16 要多少显存。
• 理解量化：量化是本地部署绕不开的概念，只有亲眼看到 int4 比 fp16 省多少显存、效果掉多少，才真正懂选型。
• 对比基线：面试常问"为什么这场景用本地而不是 API"，答好它需要先有第一手对比数据，而不是背结论。

二、Ollama 安装与启动

2.1 是什么

Ollama 是本地运行开源大模型的最简工具：一行命令装好，一行命令拉模型、起服务，自动处理权重下载、量化加载、本地 HTTP 接口（/api/generate）。它是 FDE 体验本地模型的首选，不用自己配 CUDA 环境。

2.2 安装与基本命令

# macOS / Linux 一键安装（详见官网 ollama.com）
# 启动后台服务
ollama serve

# 拉取并运行（首次会自动下载）
ollama run qwen3:8b
ollama run deepseek-r1:8b

# 列出本地已有模型
ollama list

# 查看模型信息（包含量化级别、参数规模、上下文长度）
ollama show qwen3:8b

2.3 资源

• 官网与下载：ollama.com（含各平台安装包）。
• Qwen3 模型页：ollama.com/library/qwen3（含 0.6B~235B 各尺寸与量化选项）。
• DeepSeek-R1 蒸馏版：ollama.com/library/deepseek-r1（含 1.5B~70B 蒸馏版）。

三、拉取并运行 Qwen3 / DeepSeek-R1 蒸馏模型

3.1 选哪个尺寸的蒸馏版

3.2 指定量化级别拉取

# 拉 int4 量化版（最省显存，速度最快）
ollama run qwen3:8b-q4_K_M

# 拉 fp16（全精度，最占显存，效果基准）
ollama run qwen3:8b-fp16

# 通过 Modelfile 自定义（改上下文、改系统提示）
ollama create my-qwen -f Modelfile

3.3 用代码调用本地接口

import requests, json

resp = requests.post("http://localhost:11434/api/generate", json={
    "model": "qwen3:8b-q4_K_M",
    "prompt": "判断以下特药理赔是否符合条款：患者患肺癌，申请奥希替尼，已购特效药险。请给结论和理由。",
    "stream": False,
    "options": {"temperature": 0.1, "num_ctx": 4096}
})
data = resp.json()
print(data["response"])

四、量化的本质：int4 / int8 / fp16

4.1 原理

大模型权重默认是 fp16（半精度浮点），每个参数占 16 bit。量化（Quantization）是用更少的比特表示权重，从而缩小体积、降低显存、加快推理：

• fp16：16 bit，基准精度，最占显存，效果最好（同尺寸下）。
• int8：8 bit，体积减半，精度损失通常很小（1~2% 以内）。
• int4：4 bit，体积降到 1/4，显存大幅下降，部分任务有可感知损失。
• int2/int3：更激进，损失明显，极少用于生产。

4.2 显存粗算

注意：实际启动还要加上 KV Cache、框架开销，所以 8B int4 常说"6GB 显存能跑"，而非理论 4GB。

4.3 为什么量化会掉效果

量化本质是有损压缩：低位宽装不下原始浮点精度，权重被"近似"。激活值偏大/偏小的层受影响更大；对数值敏感的任务是（如精确计算、长链推理）损失更明显。

五、量化选型：显存 / 效果权衡决策

5.1 决策表

5.2 选型经验

• 先 int8 起步：几乎不掉点，显存省一半，性价比最高。
• 再试 int4：在同任务评测集上对比 int8，若掉点在可接受范围（如准确率降 <2%）就留 int4。
• fp16 仅作基线：用来确认"量化到底掉了没、掉多少"。
• 用评测说话：不要拍脑袋，拉同一组题（如 50 条特药理赔判定）跑 int4/int8/fp16，记准确率。

六、上下文长度（Context Window）测试

6.1 概念

上下文长度 = 模型单次能"看见"的 token 总数（输入 + 输出）。本地模型默认上下文（如 2048/4096）往往比 API 模型（32K~128K）短得多，长文档会截断。

6.2 测试方法

# 用 Ollama 调大上下文
ollama run qwen3:8b --num_ctx 16384
# 或请求时指定
requests.post(..., json={"options": {"num_ctx": 16384}})

• 超长截断观察：给一份 30 页的特药条款 PDF 摘要，看模型在第几个 token 开始"忘事"（中间遗忘 / lost in the middle）。
• 延迟随上下文增长：注意本地模型上下文越长，首 token 延迟和显存占用都上升（KV Cache 随上下文线性增长）。
• 效果随位置衰减：把关键事实放在文档开头 vs 中间 vs 结尾，测模型是否还能正确引用。

七、本地模型 vs API 模型：延迟 / 成本 / 效果

7.1 三维度对比

7.2 怎么选——场景化

• 选本地：数据敏感必须不出域（医保理赔原始材料）、调用量巨大且预算敏感、要离线/内网运行、对延迟不敏感。
• 选 API：要最强效果与长上下文、偶发调用量小、团队无 GPU 运维能力、需要最新大模型能力。
• 混合（最务实）：敏感数据/高频简单任务走本地，复杂推理/长文档走 API；用 W1D4 的 Adapter 做模型路由。

八、测试环境搭建与结果记录（可复现）

8.1 必须记录的字段

8.2 实验结果记录模板

# 实验：Qwen3 8B 不同量化下特药理赔判定
| 版本        | 显存峰值 | 平均延迟 | 准确率 |
| qwen3 8b fp16 | 15.2GB  | 2.1s    | 86%   |
| qwen3 8b int8 | 8.1GB   | 1.4s    | 85%   |
| qwen3 8b q4   | 4.6GB   | 0.9s    | 81%   |
结论：int8 显存省一半、准确率仅降 1pt，性价比最优；
      q4 再省但掉 5pt，仅在显存受限时用。

九、vLLM 概念了解（推理加速引擎）

9.1 它解决什么问题

Ollama 适合单机体验，但高并发、低延迟、高吞吐的生产场景需要推理引擎。vLLM 是其中代表，核心是让 GPU 利用率和吞吐大幅提升。

9.2 关键概念

• PagedAttention：像操作系统"分页内存"一样管理 KV Cache，把显存碎片降到最低，显著提高并发吞吐、降低显存浪费。
• Continuous Batching（连续批处理）：不同请求在 token 级别动态拼批，不用等长凑批，大幅提升 GPU 利用率。
• 量化支持：vLLM 同样支持 AWQ/GPTQ 等量化，可在服务端进一步省显存。
• OpenAI 兼容接口：/v1/chat/completions，方便把本地部署伪装成 API 用。

9.3 资源

• 官方文档：docs.vllm.ai（概念与部署，FDE 了解层次即可）。

十、本地模型在医疗/保险场景的适用边界

10.1 什么适合本地

• 保险知识库问答（内网 RAG），数据不出域是硬合规。
• 高频简单任务：保单要素抽取、理赔单结构化、条款关键词匹配。
• 离线/边缘：医院内网、无外网环境的辅助录入。

10.2 什么不适合本地小模型

• 复杂特药适应症推理（需最新临床证据、长上下文）。
• 需要联网获取最新医保目录的动态判断。
• 对准确率零容忍且风险高的拒付决策——建议人审 + API 大模型兜底。

十一、面试达标线①：量化的本质与选型

十二、面试达标线②：一个场景说清"为什么本地 vs API"

示例（特药理赔初审）：

• 约束分析：理赔材料含患者隐私 + 医保数据 → 数据合规要求不出域；每天数万单 → 量大、成本敏感；但初审是结构化抽取，不需复杂推理。
• 选型：用本地 8B 模型（int8）做材料结构化抽取 + 简单条款匹配，数据不出内网、边际成本≈0。
• 兜底：抽取结果置信度低 / 复杂适应症判断，路由到 API 大模型 + 人工复核。
• 结论：不是"本地替代 API"，而是"本地做高频敏感预处理 + API 做复杂精算"，用 W1D4 Adapter 做路由。

十三、Day 6 自测清单

十四、高频面试题速记卡