1. 为什么要在本地搭一套 Ollama DeepSeek-R1 AnythingLLM如果你正在做安全实训、漏洞分析或者企业内部文档问答把敏感数据丢到公有云大模型上基本等于把底牌摊开。我这次实训的核心目标很明确让模型跑在自己的机器上断网也能用数据不出域同时还能通过 Python 脚本和 BurpSuite 把整条请求链路看清楚。这套组合里Ollama 负责把 DeepSeek-R1 拉起来并提供本地 APIAnythingLLM 负责把文档变成可检索的知识库Python 脚本用来验证 API 调用BurpSuite 用来抓包核对请求到底发到了哪里、返回了什么。适合谁适合手里有一台 8GB 显存以上显卡的笔记本、想入门本地大模型部署、又需要做安全验证的同学。我用的模型是deepseek-r1:8b8b 指 80 亿参数在 8GB 显存上跑推理基本够用响应速度也能接受。下面按实训节奏把每一步拆开命令和配置都可以直接复制。2. 前置准备Ollama 安装与 DeepSeek-R1 拉起2.1 安装 Ollama 并确认服务端口Ollama 安装完成后默认监听11434端口。先确认服务是否正常ollama --version ss -tlnp | grep 11434如果11434没有被监听手动启动ollama serve看到类似Listening on 127.0.0.1:11434就说明服务起来了。这里有个坑如果你后面要改端口不能只改客户端配置服务端启动参数也要同步改否则就是连接拒绝。2.2 拉取 DeepSeek-R1 并验证ollama pull deepseek-r1:8b ollama listollama list里能看到deepseek-r1:8b就说明模型已就位。直接命令行提问验证ollama run deepseek-r1:8b 用一句话解释什么是 SQL 注入能正常输出就说明模型推理链路通了。这一步别跳过后面 AnythingLLM 和 Python 调用都依赖这个本地模型。3. AnythingLLM 工作区配置与知识库导入3.1 接入本地 Ollama打开 AnythingLLM进入设置里的模型提供方选择 Ollama地址填http://127.0.0.1:11434模型选deepseek-r1:8b。保存后点测试连接能返回模型列表就说明对接成功。3.2 创建工作区并导入文档新建一个工作区命名比如sec-knowledge。把实训用的漏洞报告、靶场说明、客户代码片段拖进工作区文档区点击 Move to Workspace 完成向量化。导入完成后在工作区对话框里问一个只有文档里才有的问题比如某个靶场的数据库账号如果模型能根据文档回答说明知识库检索生效了。注意AnythingLLM 的向量化依赖嵌入模型如果嵌入模型没配好文档会导入失败但界面不一定报错建议导入后立刻做一次问答验证。4. Python 调用本地 API 与 BurpSuite 抓包验证4.1 Python 调用 Ollama APIOllama 提供的是兼容 OpenAI 风格的接口基础调用如下import requests url http://127.0.0.1:11434/api/generate payload { model: deepseek-r1:8b, prompt: 分析这段登录请求是否存在 SQL 注入风险, stream: False } resp requests.post(url, jsonpayload, timeout120) print(resp.status_code) print(resp.json()[response])脚本正常运行并输出分析结果说明 Python 到 Ollama 的链路是通的。4.2 BurpSuite 抓包核对请求链路BurpSuite 安装完成后在浏览器扩展里新建代理地址127.0.0.1:8080。然后安装 CA 证书Linux 下可以用sudo trust anchor --store bp.der证书装好后把 Python 脚本的请求代理指向 Burpproxies { http: http://127.0.0.1:8080, https: http://127.0.0.1:8080 } resp requests.post(url, jsonpayload, proxiesproxies, verifyFalse, timeout120)在 Burp 的 HTTP history 里就能看到发往11434的请求核对请求体里的 model、prompt 和返回内容确认数据没有流向外部地址。这一步是安全实训里最关键的验证动作。5. 本篇常见报错排查5.1 端口改为 11435 后连接拒绝报错长这样ConnectionRefusedError: [Errno 111] Connection refused原因很简单Ollama 服务端还在11434监听客户端却去连11435。要么把服务端启动参数改成OLLAMA_HOST0.0.0.0:11435 ollama serve要么客户端地址改回11434。两边必须一致。5.2 模型名写成 deepseek-r2 报 not found{error:model deepseek-r2:8b not found}Ollama 的模型名是精确匹配的deepseek-r2不存在。用ollama list看实际名称改成deepseek-r1:8b即可。5.3 开启 stream 后 JSON 解析失败json.decoder.JSONDecodeError: Extra data: line 2 column 1 (char 147)流式输出返回的是多行 JSON不是单个 JSON 对象直接resp.json()必然报错。两种处理方式要么把stream设为False要么逐行解析for line in resp.iter_lines(): if line: print(line.decode(utf-8))5.4 Kali 虚拟机连不上主机 11434 端口Kali 里访问主机 Ollama 时连接失败通常是主机防火墙没放行或者 Ollama 只监听了127.0.0.1。让 Ollama 监听所有网卡OLLAMA_HOST0.0.0.0:11434 ollama serve然后在主机防火墙放行11434Kali 里用主机 IP 访问即可。6. 需要云端模型兜底时怎么接本地 Ollama 适合数据不出域的场景但遇到需要更大参数模型、或者本地显卡跑不动的时候可以保留一套云端 API 作为补充。TaoToken 提供统一的模型接入入口Python 里换 base_url 和 key 就能切换不用改业务代码。获取 API Key 后把上面的脚本改成url https://taotoken.net/api/v1/chat/completions headers { Authorization: Bearer 你的API_KEY, Content-Type: application/json } payload { model: deepseek-r1, messages: [{role: user, content: 分析这段登录请求}], stream: False } resp requests.post(url, jsonpayload, headersheaders, timeout120) print(resp.json())本地和云端两套链路可以并存敏感数据走本地11434通用问答走云端接口。需要长期做编码或 Agent 任务的话可以看下 Coding Plan只想先验证模型效果直接进模型对话页面试接入细节和参数说明在接入文档里都有。本地部署这条链路踩坑最多的地方就是端口和模型名不一致把这两处对齐剩下的抓包验证基本一次过。