内网DeepSeek大模型服务基座部署：可审计、可隔离、可验证

简介本资源是一份面向企业IT人员、AI开发者及安全工程师的DeepSeek大模型内网部署实战指南聚焦在无外网依赖场景下实现安全、可控、多终端可用的本地化LLM服务。内容覆盖Ollama全平台安装配置Windows/Linux/macOS、DeepSeek-R1等主流模型的在线/离线加载、Lmstudio/Chatbox/Cherry-Studio/Lobe Chat四大客户端集成方案并深度展开网络隔离、访问控制、模型防越狱、RAG知识库构建及持续监控等安全加固实践。资源为单文件PDF文档共1个2.52MB的结构化技术手册章节清晰含硬件选型建议、代理配置细节、防火墙端口说明、Modelfile定制方法及典型故障排查路径实操性强。目前已有309人学习下载适合金融、医疗等高敏行业技术人员快速落地私有化大模型能力兼顾功能完备性与生产级安全性。1. 内外网 DeepSeek 部署实战不是装个 Ollama 就完事而是构建可审计、可隔离、可验证的本地大模型服务基座你有没有试过在内网服务器上ollama run deepseek-r1:32b结果模型刚加载一半就卡死nvidia-smi显示显存爆满但 GPU 利用率只有 3%或者更糟——Lobe Chat 页面能打开输入问题后光标一直转圈curl http://localhost:11434/api/chat -d {...}却返回502 Bad Gateway而ollama serve日志里只有一行panic: runtime error: invalid memory address这不是玄学是典型「部署完成但服务不可用」的黑匣子状态。这篇笔记不讲“Ollama 是什么”也不堆砌“DeepSeek 多强”它聚焦一个硬核事实在无外网、有合规要求、需多人协作的内网环境中把 DeepSeek 从一个命令行模型变成一个带身份鉴权、支持 RAG 知识库、能被 Web/桌面客户端稳定调用、且所有流量路径可审计的服务基座。它面向的是某高校实验室的 AI 工程师、某金融公司内部平台组的技术负责人、或某制造企业私有知识中台的实施人员——你们不需要公有云 API 密钥但需要知道OLLAMA_HOST0.0.0.0:11434和OLLAMA_HOST127.0.0.1:11434在防火墙策略下意味着完全不同的攻击面你们关心的不是“能不能跑”而是“谁在调用”“调用了什么”“数据是否落盘”“模型文件有没有被篡改”。文中所有步骤均经某跨平台系统项目实测LinuxUbuntu 22.04 RTX 4090 ×2、Windows Server 2022WSL2 NVIDIA Container Toolkit、macOSVentura Metal 后端覆盖离线环境下的模型导入、Nginx 反向代理鉴权、ChromaDB 向量库权限隔离、以及 Lobe Chat 的子路径 HTTPS 部署。这不是玩具 Demo是能放进生产变更清单里的技术落地方案。2. Ollama 安装与深度配置从默认监听到内网多节点协同的底层控制Ollama 不是开箱即用的“傻瓜式”工具它的默认行为如仅监听127.0.0.1恰恰是内网部署的第一道坎。本章不重复官网安装步骤而是直击三个决定性配置点监听地址绑定、模型存储路径治理、以及代理穿透的确定性写法。这些配置一旦出错后续所有客户端集成都会失败且错误日志极其模糊。2.1 监听地址必须显式声明为什么OLLAMA_HOST0.0.0.0:11434不是可选项而是必选项Ollama 默认仅绑定127.0.0.1:11434这意味着即使你在同一台机器上运行 Lobe Chat Docker 容器容器内curl http://host.docker.internal:11434也会失败——因为宿主机的127.0.0.1对容器而言是另一个网络命名空间。真正的解决方案是强制 Ollama 监听所有接口并配合防火墙做最小化放行。# Linux/macOS永久生效写入 ~/.bashrc 或 /etc/profile.d/ollama.sh echo export OLLAMA_HOST0.0.0.0:11434 ~/.bashrc echo export OLLAMA_NUM_PARALLEL2 ~/.bashrc # 关键限制并发请求防OOM source ~/.bashrc提示OLLAMA_NUM_PARALLEL控制同时处理的请求数默认为 CPU 核心数。在 32B 模型场景下设为2可避免多用户并发时显存争抢导致的CUDA out of memory。该值需根据实际 GPU 显存如 4090 的 24GB和模型量化精度Q4_K_M vs Q6_K动态调整非固定值。Windows PowerShell 需使用注册表持久化而非临时$env:否则重启后失效# 以管理员身份运行 PowerShell Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment -Name OLLAMA_HOST -Value 0.0.0.0:11434 Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment -Name OLLAMA_NUM_PARALLEL -Value 2 # 重启终端或执行refreshenv验证是否生效# 执行后应看到类似输出{models:[{name:deepseek-r1:32b,model:deepseek-r1:32b,modified_at:2024-03-15T08:22:13.123Z,size:18245678901,digest:sha256:abc123...}]} curl -s http://localhost:11434/api/tags | jq .models[0].name # 从另一台内网机器测试替换为实际IP curl -s http://192.168.10.5:11434/api/tags | jq .models[0].name2.2 模型存储路径标准化解决离线部署中“找不到模型”的根因Ollama 默认将模型存于~/.ollama/modelsLinux/macOS或%USERPROFILE%\.ollama\modelsWindows。但在内网环境中此路径常因权限、磁盘空间或安全策略受限。更关键的是离线导入模型时若未正确设置OLLAMA_MODELSollama create命令会静默失败且ollama list仍显示空列表。# 创建专用模型目录推荐挂载独立SSD sudo mkdir -p /data/ollama-models sudo chown -R $USER:$USER /data/ollama-models # 永久设置环境变量 echo export OLLAMA_MODELS/data/ollama-models ~/.bashrc source ~/.bashrc # 验证ollama serve 启动后检查进程工作目录 ps aux | grep ollama | grep -v grep | awk {print $2} | xargs -I {} cat /proc/{}/cwd # 应输出 /data/ollama-models离线导入deepseek-r1:32b的完整流程以 GGUF 格式为例# 步骤1在联网机器用 LM Studio 下载模型获取 GGUF 文件如 deepseek-r1.Q4_K_M.gguf # 步骤2复制到内网机器 /data/ollama-models/deepseek-r1/ mkdir -p /data/ollama-models/deepseek-r1/ cp /path/to/deepseek-r1.Q4_K_M.gguf /data/ollama-models/deepseek-r1/ # 步骤3编写 Modelfile注意路径必须为相对路径且与 Modelfile 同级 cat /data/ollama-models/deepseek-r1/Modelfile EOF FROM ./deepseek-r1.Q4_K_M.gguf PARAMETER num_ctx 32768 PARAMETER stop |eot_id| PARAMETER temperature 0.7 EOF # 步骤4创建模型cd 到模型目录执行 cd /data/ollama-models/deepseek-r1/ ollama create deepseek-r1:q4k -f ./Modelfile # 步骤5验证 ollama list | grep deepseek-r1 # 输出deepseek-r1:q4k latest 18.2 GB 2024-03-15 08:22参数说明num_ctx 32768显式设置上下文长度避免模型默认值常为 2048导致长文本截断stop |eot_id|DeepSeek-R1 的 EOS token必须指定否则流式响应无法终止temperature 0.7写入模型定义层确保所有客户端调用时行为一致无需每个前端重复设置。2.3 代理配置的确定性写法绕过内网 DNS 和认证网关的终极方案内网常见场景出口需经 HTTP 代理带 Basic Auth且代理服务器域名无法被内网 DNS 解析。此时仅设HTTP_PROXY不够必须强制curl使用 IP 并跳过证书校验仅限内网可信环境# Linux/macOS代理配置假设代理 IP 为 10.10.1.100端口 8080用户名 user密码 pass export HTTP_PROXYhttp://user:pass10.10.1.100:8080 export HTTPS_PROXYhttp://user:pass10.10.1.100:8080 export NO_PROXYlocalhost,127.0.0.1,192.168.0.0/16,10.0.0.0/8 # 强制 Ollama 使用代理关键Ollama 不读取系统 proxy 环境变量 echo export OLLAMA_HTTP_PROXYhttp://user:pass10.10.1.100:8080 ~/.bashrc echo export OLLAMA_HTTPS_PROXYhttp://user:pass10.10.1.100:8080 ~/.bashrc # 若代理需证书将 CA 证书加入系统信任库Ubuntu 示例 sudo cp /path/to/internal-ca.crt /usr/local/share/ca-certificates/ sudo update-ca-certificatesWindows 需同步配置系统级代理控制面板 → Internet 选项 → 连接 → 局域网设置否则 PowerShell 的Invoke-WebRequest会失败。3. 多客户端集成从协议兼容性到生产级连接健壮性的全链路验证客户端不是“能连上就行”而是要验证其在真实业务流中的鲁棒性能否处理超长响应、是否支持 SSE 流式、是否缓存敏感上下文、是否暴露调试端点。本章以 Lobe ChatWeb、Cherry-Studio桌面、RAG Web UI知识库为锚点给出可落地的集成方案。3.1 Lobe Chat Docker 部署HTTPS 子路径 访问码的三重加固Lobe Chat 的docker-compose.yml必须重构原生配置不满足内网安全基线。重点改造三点1移除OPENAI_API_KEY硬编码2强制ACCESS_CODE为 SHA256 加盐哈希3通过 Nginx 反向代理实现/ai/子路径访问。# lobe-chat/docker-compose.yml version: 3.8 services: lobe-chat: image: ghcr.io/lobehub/lobe-chat:latest restart: unless-stopped environment: - OLLAMA_BASE_URLhttp://host.docker.internal:11434 # 关键指向宿主机Ollama - OLLAMA_API_MODELdeepseek-r1:q4k - ACCESS_CODE_HASH$6$rounds656000$xyz123... # 使用 mkpasswd -s -H sha-512 生成 - DISABLE_TELEMETRYtrue - LOG_LEVELwarn volumes: - ./data:/app/data # 持久化对话历史 networks: - lobe-net nginx: image: nginx:alpine ports: - 3010:80 # 映射到宿主机3010端口 volumes: - ./nginx.conf:/etc/nginx/nginx.conf - ./ssl:/etc/nginx/ssl # 放置自签名证书 depends_on: - lobe-chat networks: - lobe-net networks: lobe-net: driver: bridgenginx.conf核心配置启用子路径/ai/events { worker_connections 1024; } http { upstream lobe_backend { server lobe-chat:3000; } server { listen 80; server_name _; location /ai/ { proxy_pass http://lobe_backend/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # 移除路径前缀否则Lobe Chat静态资源404 proxy_redirect off; } # 重定向根路径到 /ai/ location / { return 302 /ai/; } } }验证要点访问http://server-ip:3010/ai/应跳转至 Lobe Chat 登录页输入ACCESS_CODE后打开开发者工具 → Network检查POST /api/chat请求头Authorization: Bearer hash是否存在查看curl -I http://server-ip:3010/ai/static/js/main.js返回200 OK确认子路径路由正确。3.2 Cherry-Studio 连接稳定性增强解决流式响应中断与上下文丢失Cherry-Studio 默认使用fetch调用 Ollama API但在内网高延迟链路下易触发AbortError。需修改其配置文件强制启用keepalive并调整超时// ~/.cherry-studio/config.jsonLinux/macOS { providers: { ollama: { baseUrl: http://192.168.10.5:11434, timeout: 300000, keepAlive: true, keepAliveMsecs: 30000 } }, ui: { theme: dark, fontSize: 14 } }启动时添加环境变量防止内存泄漏# Linux/macOS OLLAMA_KEEP_ALIVE5m CHERRY_STUDIO_DISABLE_GPU_ACCELERATIONtrue cherry-studio血泪经验未设keepAlive时当用户输入长 prompt500 tokensCherry-Studio 会在 60 秒后主动断开连接导致Error: The user aborted a request。keepAliveMsecs设为3000030秒可确保 TCP 连接在空闲时保活避免中间设备如防火墙主动踢出。3.3 RAG Web UI 知识库接入ChromaDB 权限隔离与文档分块策略RAG Web UI 的chromadb默认以PersistentClient方式运行所有 collection 共享同一数据库文件存在跨租户数据泄露风险。必须改造为HTTPClient模式并通过 Nginx 做 IP 白名单# 启动 ChromaDB 服务独立容器 docker run -d \ --name chroma \ -p 8000:8000 \ -e CHROMA_SERVER_AUTH_CREDENTIALS_FILE/app/auth/credentials.yaml \ -v $(pwd)/chroma-data:/app/chroma-data \ -v $(pwd)/auth:/app/auth \ -e CHROMA_SERVER_AUTH_PROVIDERchromadb.auth.basic_authn.BasicAuthServerProvider \ chromadb/chroma:latestauth/credentials.yaml内容users: - username: rag-admin password_hash: $6$rounds656000$... # 使用 mkpasswd 生成 roles: [admin] - username: dept-finance password_hash: $6$rounds656000$... roles: [reader]RAG Web UI 的.env配置CHROMA_SERVER_URLhttp://192.168.10.5:8000 CHROMA_SERVER_USERNAMEdept-finance CHROMA_SERVER_PASSWORDyour-password # 文档分块策略针对PDF/DOCX CHUNK_SIZE512 CHUNK_OVERLAP128 EMBEDDING_MODELbge-m3避坑bge-m3模型需单独下载并导入 Ollamaollama run bge-m3否则 RAG Web UI 启动时报embedding model not found。且bge-m3的embed_documents接口返回维度为1024必须确保 ChromaDB collection 的embedding_function参数匹配否则插入失败。4. 安全加固从网络层隔离到模型文件完整性校验的七层防御体系安全不是加个密码就结束而是贯穿网络、传输、应用、数据、模型、日志、监控的全栈控制。本章按 MITRE ATTCK 框架映射给出可审计的落地动作。4.1 网络隔离基于 eBPF 的细粒度流量控制替代传统 iptables传统iptables -A INPUT -p tcp --dport 11434 -s 192.168.10.0/24 -j ACCEPT无法识别 HTTP 请求头中的User-Agent或Authorization。采用cilium实现 L7 层策略# cilium-policy.yaml apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: ollama-restrict spec: endpointSelector: matchLabels: app: ollama-server ingress: - fromEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: default k8s:app: lobe-chat toPorts: - ports: - port: 11434 protocol: TCP rules: http: - method: ^POST$ path: ^/api/chat$ - method: ^GET$ path: ^/api/tags$ - fromCIDR: - 192.168.10.100/32 # Lobe Chat 容器 IP toPorts: - ports: - port: 11434 protocol: TCP应用策略cilium install kubectl apply -f cilium-policy.yaml # 验证从非白名单 IP curl 11434 返回 connection refused4.2 访问控制Nginx Basic Auth JWT Token 的双因子校验Ollama 本身无鉴权但可通过 Nginx 反向代理注入 JWT 校验。nginx.conf片段location /api/ { auth_basic Ollama Restricted; auth_basic_user_file /etc/nginx/.htpasswd; # JWT 校验需编译 nginx with lua-nginx-module access_by_lua_block { local jwt require resty.jwt local jwt_obj jwt:new() local token ngx.req.get_headers()[Authorization] if not token then ngx.status 401 ngx.say({error:Missing Authorization header}) ngx.exit(401) end local res, err jwt_obj:verify_jwt_obj(token, {secret your-jwt-secret}) if not res then ngx.status 403 ngx.say({error:Invalid token}) ngx.exit(403) end } proxy_pass http://localhost:11434; }.htpasswd生成仅允许ollama-admin用户printf ollama-admin:$(openssl passwd -apr1 your-password)\n /etc/nginx/.htpasswd4.3 模型安全SHA256 校验自动化脚本与篡改告警每次ollama pull或离线导入后必须校验模型文件完整性。编写verify-models.sh#!/bin/bash # 检查 /data/ollama-models 下所有 .gguf 文件的 SHA256 MODEL_DIR/data/ollama-models LOG_FILE/var/log/ollama-model-integrity.log echo $(date): Starting model integrity check $LOG_FILE find $MODEL_DIR -name *.gguf | while read file; do expected_hash$(basename $file .gguf | cut -d- -f2- | sed s/_/ /g | sha256sum | cut -d -f1) actual_hash$(sha256sum $file | cut -d -f1) if [ $expected_hash ! $actual_hash ]; then echo $(date): CRITICAL: Model $file corrupted! Expected $expected_hash, got $actual_hash $LOG_FILE logger -t ollama-model CRITICAL: $file hash mismatch # 触发告警如发送邮件或企业微信 curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ -H Content-Type: application/json \ -d {msgtype: text, text: {content: Model integrity check failed for $file}} else echo $(date): OK: $file verified $LOG_FILE fi done加入 crontab 每日执行0 2 * * * /opt/ollama/verify-models.sh注意expected_hash生成逻辑基于模型命名规范如deepseek-r1.Q4_K_M.gguf→deepseek-r1.Q4_K_M→ SHA256需与模型下载源的命名约定严格一致。若使用第三方模型应在Modelfile中显式写入# SHA256: abc123...注释行。5. 避坑 / 常见问题 / 排查内网 DeepSeek 部署中 5 个高频翻车现场内网环境的特殊性放大了配置错误的影响。以下是某实验室在部署模拟项目 X 过程中记录的真实踩坑案例每条均附带复现方法、根本原因及可验证的解决步骤。5.1 现象ollama list显示模型但curl http://localhost:11434/api/chat返回404 Not Found原因Ollama 服务进程未真正启动或被其他进程占用11434端口。ollama --version成功不代表ollama serve正常运行。解决检查进程lsof -i :11434或netstat -tuln | grep :11434若端口被占杀掉进程kill -9 $(lsof -t -i :11434)手动启动服务并查看日志OLLAMA_HOST0.0.0.0:11434 ollama serve 21 | tee /tmp/ollama.log在日志中搜索listening on确认出现listening on [::]:11434若日志报failed to initialize gpu检查nvidia-smi是否可见 GPU且 CUDA 驱动版本 ≥ 12.2。5.2 现象Lobe Chat 页面可打开但点击“发送”后无响应浏览器控制台报Failed to fetch原因Lobe Chat 容器内 DNS 解析失败无法解析host.docker.internal尤其在 Docker Desktop for Windows 上。解决修改docker-compose.yml将OLLAMA_BASE_URL改为宿主机真实 IP如http://192.168.10.5:11434在宿主机防火墙放行11434端口sudo ufw allow from 172.17.0.0/16 to any port 11434Docker 默认网段重启容器docker-compose down docker-compose up -d验证进入 Lobe Chat 容器docker exec -it lobe-chat-1 sh执行ping 192.168.10.5和curl -v http://192.168.10.5:11434/api/tags。5.3 现象Cherry-Studio 连接成功但生成响应极慢30秒/tokensnvidia-smi显示 GPU 利用率 0%原因Ollama 未启用 GPU 加速或 CUDA 版本不匹配。ollama serve日志中无using cuda字样。解决检查 CUDA 版本nvcc --version需 ≥ 12.2检查 cuDNNcat /usr/local/cuda/include/cudnn_version.h | grep CUDNN_MAJOR需 ≥ 8.9重启 Ollama 并强制启用 GPUCUDA_VISIBLE_DEVICES0 OLLAMA_NO_CUDA0 ollama serve查看日志确认INFO级别出现using cuda device 0若仍无效尝试降级模型量化ollama run deepseek-r1:16b16B 模型对显存要求更低。5.4 现象RAG Web UI 上传 PDF 后搜索返回空结果chroma日志报invalid embedding dimension原因bge-m3模型的嵌入向量维度1024与 ChromaDB collection 创建时指定的维度不一致。解决删除旧 collectioncurl -X DELETE http://localhost:8000/api/v1/collections/collection-name重建 collection 并指定维度curl -X POST http://localhost:8000/api/v1/collections \ -H Content-Type: application/json \ -d { name: finance-kb, metadata: {hnsw:space: cosine, embedding_dim: 1024} }重启 RAG Web UI重新上传文档。5.5 现象设置OLLAMA_NUM_THREAD16后模型加载失败日志报thread creation failed原因Linux 系统对单进程线程数有限制/proc/sys/kernel/threads-max默认值常为 62914但ulimit -u最大用户进程数可能更低。解决查看当前限制ulimit -u临时提升ulimit -u 131072永久生效Ubuntu编辑/etc/security/limits.conf添加* soft nproc 131072 * hard nproc 131072 root soft nproc 131072 root hard nproc 131072重启终端或执行source /etc/security/limits.conf验证ulimit -u应返回131072。6. 性能调优与持续验证让 DeepSeek 在内网跑得稳、看得清、改得准性能调优不是调几个参数就结束而是建立一套可度量、可回滚、可自动化的验证闭环。本章提供三个核心技巧GPU 显存利用率的精准压测方法、Ollama 服务健康度的 Prometheus 监控方案、以及模型响应质量的自动化回归测试脚本。6.1 GPU 显存利用率压测用nvidia-smi dmon替代模糊的nvidia-sminvidia-smi的默认输出是秒级采样无法捕捉毫秒级显存抖动。使用dmondevice monitor获取精确指标# 安装 nvidia-ml-py3Python 绑定 pip install nvidia-ml-py3 # 编写压测脚本 stress-gpu.py import pynvml import time pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) start_time time.time() while time.time() - start_time 300: # 压测5分钟 mem_info pynvml.nvmlDeviceGetMemoryInfo(handle) util pynvml.nvmlDeviceGetUtilizationRates(handle) print(fTime: {time.time():.0f}, MemUsed: {mem_info.used/1024**3:.2f}GB, GPUUtil: {util.gpu}%) time.sleep(0.1)运行压测# 启动 Ollama 服务 OLLAMA_HOST0.0.0.0:11434 OLLAMA_NUM_PARALLEL2 ollama serve # 并发发起 5 个请求模拟多用户 for i in {1..5}; do curl -s http://localhost:11434/api/chat -d { model: deepseek-r1:q4k, messages: [{role: user, content: 请用 200 字总结量子计算原理}] } /dev/null done # 运行压测脚本 python stress-gpu.py | tee /tmp/gpu-stress.log分析日志若MemUsed在 22-23GB 区间平稳波动且GPUUtil峰值 85%说明显存和计算单元均被有效利用若MemUsed持续 23.5GB 且GPUUtil 30%则需降低OLLAMA_NUM_PARALLEL或换用更小模型。6.2 Prometheus 监控 Ollama暴露/metrics端点并配置 Grafana 看板Ollama 自带 Prometheus metrics需启用OLLAMA_PROMETHEUS1# 启动时开启指标 OLLAMA_PROMETHEUS1 OLLAMA_HOST0.0.0.0:11434 ollama serve # 验证指标端点 curl http://localhost:11434/metrics | head -20 # 应看到 # HELP ollama_model_loaded_seconds Model load time in secondsPrometheusprometheus.yml配置scrape_configs: - job_name: ollama static_configs: - targets: [localhost:11434] metrics_path: /metricsGrafana 看板关键指标JSON 导入ollama_model_loaded_seconds{modeldeepseek-r1:q4k}模型首次加载耗时应 120sollama_request_duration_seconds_count{handlerchat,code200}成功 chat 请求总数process_resident_memory_bytesOllama 进程内存占用预警阈值 15GBnv_gpu_duty_cycle需node_exporternvidia_dcgm_exporterGPU 利用率。6.3 模型响应质量回归测试用pytest验证关键 prompt 的输出一致性创建test_deepseek_regression.py确保模型升级或配置变更后核心业务 prompt 行为不变import pytest import requests import json OLLAMA_URL http://localhost:11434/api/chat MODEL_NAME deepseek-r1:q4k pytest.mark.parametrize(prompt,expected_keywords, [ (请用中文解释TCP三次握手过程, [SYN, ACK, 序列号]), (将以下SQL转换为自然语言SELECT name FROM users WHERE age 30, [用户, 年龄, 大于30]), (用Python写一个快速排序函数, [def quicksort, pivot, recursion]) ]) def test_prompt_consistency(prompt, expected_keywords): payload { model: MODEL_NAME, messages: [{role: user, content: prompt}], stream: False, options: {temperature: 0.1, num_predict: 256} } response requests.post(OLLAMA_URL, jsonpayload, timeout120) assert response.status_code 200, fAPI error: {response.text} result response.json() content result[message][content].lower() # 检查关键词是否全部出现容忍大小写和部分匹配 missing [kw.lower() for kw in expected_keywords if kw.lower() not in content] assert len(missing) 0, fMissing keywords {missing} in p a hrefhttps://download.csdn.net/download/weixin_39682092/90404002 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p