ollama本地部署大语言模型记录

最近突然对大语言模型感兴趣

同时在平时的一些线下断网的CTF比赛中,大语言模型也可以作为一个能对话交互的高级知识检索库

本篇文章旨在记录我在本地部署大语言模型的过程

安装Ollama

Ollama是一个轻量级、可扩展的框架,旨在帮助用户在本地机器上构建、运行和分享大语言模型。

前往Ollama的官网Ollama下载最新版本的安装包

需要注意的是,该软件默认安装在C盘下,所以如果有精神洁癖的小伙伴也可以使用docker部署Ollama

在终端中输入ollama --version

请添加图片描述

返回版本信息,说明安装成功

更改模型存放位置

前往系统环境变量设置,添加如下系统变量

请添加图片描述

重启Ollama

拉取模型

Gemma

目前在Ollama上,Gemma模型已经拥有超过430K的拉取次数。基本上Gemma可以算是Ollama最热门的模型了

Gemma提供了不同参数规模的版本,2b(20亿参数)和7b(70亿参数)。参数的数量直接影响了模型对语言的理解能力,更多的参数通常意味着更好的理解、生成和预测能力,但同时也需要更强大的计算资源和更长的处理时间

每个参数版分为轻量版和全量版,2b模型即便是在没有独显的笔记本电脑上都能尝试运行,而规模更大的7b、7b全量版分别需要8GB和16GB显存。

因为本人的笔记本显卡是RTX 3070Laptop,为了防止显卡撑爆,选择部署2b全量版

首先确保Ollama框架有在运行,在终端中输入ollama pull gemma:2b-instruct-fp16拉取模型

gemma后跟的是参数版本

拉取模型的过程中尽量开代理,因为Ollama的数据库在海外

请添加图片描述

提示success说明拉取成功

Mistral

Mistral 7B 是一款拥有70亿参数的精心设计的语言模型,旨在实现卓越性能和高效运行。它在各类基准测试中表现出色,超越了当前最佳的开源13B模型——Llama 2,并在推理能力、数学计算精准度以及代码生成任务上均超越了已公开的34B模型——Llama 1

执行ollama pull qwen:7b拉取模型

Qwen1.5(通义千问)

考虑到本地部署时对硬件的要求,我们不得不选取参数量较小的模型

通常的游戏笔记本的显卡内存在4G到8G之间,对应的模型参数量范围在20亿到70亿间

而今年年初阿里巴巴开源的Qwen1.5恰好有一个70亿参数量的版本,显存占用在7G左右,非常适合在中高端游戏本上部署

执行ollama pull mistral:latest拉取模型

codellama

code llama在llama2模型的基础上,利用代码数据进行训练和微调,提高了llama2在代码生成上的能力

code llama提供了三种模型,每种模型包含7B,13B,34B三个尺寸,支持多种编程语言,如Python, C++, Java, PHP, Typescript (Javascript), C#, Bash等。

  • Code Llama,代码生成的基础模型;
  • Code Llama-Python,单独针对于python的模型;
  • Code Llama-Instruct,根据人工指令微调的模型。

这里我们选用基础模型,执行ollama pull codellama:7b拉取模型

部署Open webui

Open WebUI是目前GitHub上开源的类Chatgpt前端界面中,star数量最多的框架之一

而更重要的是Open WebUI的前身即Ollama WebUI,所以它对于Ollama的支持非常好

执行下面的指令来拉取并部署Open WebUI的docker容器

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

在浏览器上访问https://localhost:3000

请添加图片描述

点击加号添加刚刚拉取的所有模型,方便后续同时测试多个模型

请添加图片描述

测试性能

在本文章中,会对部署在本地的模型进行相同的提问测试,包括知识广度和代码能力

知识广度

首先是知识广度上的测试,我们询问2道安全岗的面试题

问题1

  1. 请向我介绍一下蜜罐技术</
<think>好的,我现在需要帮助用户解决在本地部署Dify和Ollama时,添加模型供应商没有响应的问题。首先,我应该回忆一下用户提到的这两个项目的基本情况。Dify是一个AI应用开发平台,而Ollama是用于本地运行大型语言模型的工具。用户的问题是在部署这两个工具时,添加模型供应商时没有反应,可能需要逐步排查可能的原因。 首先,用户可能遇到网络连接问题。因为Ollama需要在本地运行模型,所以需要确认Ollama服务是否已经正确启动,并且Dify能够访问到该服务。检查Ollama的默认端口11434是否开放,是否有防火墙或安全软件阻止了连接。用户可以通过curl命令测试接口是否可用,例如curl http://localhost:11434/api/tags,看看是否能获取模型列表。 接下来,考虑配置问题。Dify中添加模型供应商时,需要正确填写Ollama的API地址,通常是http://localhost:11434。如果Dify和Ollama不在同一台机器上,可能需要使用宿主机的IP地址,而不是localhost,同时确保端口映射正确。比如在Docker环境中,可能需要配置正确的网络模式或端口转发。 模型加载也是一个可能的问题。用户需要确认在Ollama中已经成功下载并加载了所需的模型。使用ollama list命令可以查看已安装的模型。如果没有安装模型,需要先执行ollama pull <模型名>来下载。例如,ollama pull llama2。 版本兼容性方面,Diy和Ollama的版本是否匹配?可能需要检查两者的文档,确认是否有版本要求。更新到最新版本可能解决一些已知的问题。 日志信息是排查问题的关键。查看Diy和Ollama的日志,看看是否有错误信息。启动Ollama时添加--verbose参数可以获取详细日志,帮助定位问题。同样,Dify的日志也可能提示连接失败的原因。 权限问题也不能忽视,特别是在Linux系统中,确保运行Ollama和Dify的用户有足够的权限访问相关端口和文件。SELinux或AppArmor有时会限制应用程序的网络访问,需要适当配置。 如果以上步骤都没问题,可能需要查阅社区或GitHub上的Issue,看看是否有其他用户遇到类似问题,并找到解决方案。此外,确保系统资源足够,比如内存和CPU,大型模型需要较多的资源才能正常运行。 总结下来,可能的解决步骤包括检查服务状态、验证网络连接、确认模型加载、检查配置是否正确、查看日志、处理权限问题,以及更新软件版本。逐步排查这些方面应该能帮助用户解决问题。</think>### 分步解决方案:Dify + Ollama 本地部署添加模型供应商无响应的排查与修复 #### 1. 验证 Ollama 服务状态 - **检查服务运行** 确认 Ollama 服务已启动并监听端口: ```bash # Linux/Mac 查看进程 ps aux | grep ollama # 检查端口占用 lsof -i :11434 # Windows 检查服务状态 Get-Process -Name ollama ``` - **测试 API 连通性** 使用 `curl` 验证接口是否返回模型列表(需先安装至少一个模型): ```bash curl http://localhost:11434/api/tags # 正常响应示例: # {"models":[{"name":"llama2","modified_at":"2024-05-01T00:00:00Z"}]} ``` #### 2. 检查 Dify 配置细节 - **模型供应商配置截图示例** - **供应商类型**:选择 `Ollama` - **API 端点**:填写 `http://localhost:11434`(若跨机器部署则替换为宿主机IP,如 `http://192.168.1.100:11434`) - **模型名称**:必须与 Ollama 已加载模型名称完全一致(区分大小写) - **Docker 网络配置(若适用)** 当 Dify 与 Ollama 均运行在 Docker 中时: ```yaml # docker-compose.yml 关键配置 services: dify: networks: - ollama_network ollama: networks: - ollama_network ports: - "11434:11434" networks: ollama_network: driver: bridge ``` 此时 Dify 中填写的 API 地址应为 `http://ollama:11434`(使用 Docker 服务名) #### 3. 模型加载验证 - **安装与验证模型** ```bash # 查看已安装模型 ollama list # 安装新模型(以 llama2 为例) ollama pull llama2 # 启动模型交互测试 ollama run llama2 > Hello # 测试是否能生成响应 ``` - **常见模型名称对照表** | Ollama 模型名 | 对应模型标识 | |---------------|------------------| | llama2 | llama2:latest | | mistral | mistral:7b | #### 4. 日志深度分析 - **Ollama 详细日志** 启动时附加调试参数: ```bash ollama serve --verbose # 观察日志中是否有 "API request received" 记录 ``` - **Dify 连接日志定位** 在 Dify 日志中搜索 `Ollama API Error` 关键词,常见错误类型: ```log # 连接拒绝 ConnectionRefusedError: [Errno 111] Connection refused # 模型未找到 {"error":"model 'llama' not found"} ``` #### 5. 高级网络调试技巧 - **跨主机访问测试** 使用 telnet/nc 验证端口可达性: ```bash telnet 192.168.1.100 11434 # 替换为实际IP # 成功会显示 Connected ``` - **防火墙规则检查** ```bash # Linux ufw sudo ufw status # CentOS firewalld firewall-cmd --list-ports ``` #### 6. 版本兼容性处理 - **推荐版本组合** | 组件 | 稳定版本 | 关键特性 | |--------|-----------------|-------------------------| | Ollama | ≥ 0.1.25 | 支持 GPU 加速 | | Dify | ≥ 0.6.8 | 增强 Ollama 集成 | #### 7. 系统资源监控 - **内存占用检查** 运行模型时监控资源使用: ```bash # Linux htop # Windows Task Manager → 性能标签 ``` - 7B 模型通常需要 ≥8GB 内存 - 13B 模型需要 ≥16GB 内存 ### 典型问题案例 **案例 1**:Docker 网络隔离导致连接失败 **现象**:Dify 日志显示 `Connection refused` **解决**:确认 Docker 网络配置为同一自定义网络,或使用 `host` 网络模式 **案例 2**:模型名称大小写不匹配 **现象**:API 返回 `404 Model not found` **验证**:`curl http://localhost:11434/api/tags` 检查实际模型名称 **案例 3**:AVX 指令集缺失 **现象**:Ollama 日志出现 `illegal instruction` 错误 **解决**:更换不需要 AVX 的模型版本或升级 CPU --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

handsomelky

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值