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

安装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

请向我介绍一下蜜罐技术

Mistral从原理和应用上全方位介绍了蜜罐技术，它的回答不仅准确，用词也非常专业。

Qwen的回答非常模板化，使用总分总的形式展开回答，但相比Mistral的回答少一些实用细节

Gemma的回答虽然详细但完全不适用，因为它误解了蜜罐技术的定义，说明它在知识广度上和其他模型存在差距

Codellama的回答提供了一个与网络安全不同的视角，专注于使用蜜罐收集用户行为数据的概念。虽然这种用法在市场研究和用户行为分析中可能有其价值，但它与蜜罐技术在网络安全领域的典型应用相去甚远。

问题2

信息收集如何处理子域名爆破的泛解析问题?

MIstral回答如下

During information gathering or subdomain enumeration, an attacker may use techniques like DNS brute-forcing or subdomain enumeration tools to discover potential subdomains of a target domain. One common issue they might encounter is the presence of Zone Transfer (MX) records or CNAME records pointing to IP addresses with open resolver servers or to other domains, which can facilitate the discovery of additional subdomains through a process called transitive name resolution, also known as “glue” or “tied” records.

To mitigate this issue, organizations can take several steps when handling subdomain enumeration:

Disable Open Resolver Servers: Ensure that your DNS servers are not configured to respond to unsolicited recursive queries from external sources. This will prevent attackers from using them as a means to discover additional subdomains through transitive name resolution. Configure Response Rate Limiting (RRL): Implement RRL on your DNS servers to limit the number of requests that can be sent by a single source in a given time frame. This will help prevent attackers from quickly enumerating multiple subdomains using brute-forcing tools. Filter Out Undesired Records: Use firewalls and access control lists (ACLs) to block or filter out unnecessary DNS records, such as MX records that contain open resolver servers or CNAME records pointing to external domains. Monitor for Anomalous Activity: Set up intrusion detection systems (IDS) and security information and event management (SIEM) solutions to monitor and alert on anomalous DNS queries, such as rapid subdomain enumeration attempts. Implement Honeypots and Decoys: Use Honeypot technologies and decoy domains to misdirect attackers from the real infrastructure. This can help protect sensitive information and resources while also providing valuable intelligence about the attacker’s tactics, techniques, and procedures (TTPs). Regularly Update DNS Records: Ensure that your subdomain records are updated regularly to minimize the exposure of old or outdated services or applications. This will help reduce the likelihood of discovery through enumeration attempts. Implement DNS Security Extensions: Use DNS security extensions such as DNSSEC and DANE to secure your DNS infrastructure and prevent attackers from manipulating or poisoning your records.

Gemma回答如下

信息收集如何处理子域名爆破的泛解析问题取决于具体情况，以下是一些常见解决方案：

1. 分析泛解析结果

首先，需要确认子域名是否真正属于您。您可以通过域名注册页面或 DNS 管控器的 DNS 查询来查询子域名是否指向您指定的服务器。您可以分析泛解析结果的来源，例如，如果子域名来自根域名注册服务器，那么它可能被恶意攻击者通过 DNS poisoning攻击。您可以分析泛解析结果的记录，例如，如果记录中存在一个指向恶意网站的记录，则可能是一个恶意攻击者的攻击目标。

2. 识别恶意记录

恶意记录通常包含以下特征：与您网络相关的名称，例如子域名或 IP 地址。与您的网站或服务相关的名称。与其他恶意记录相同的语法或内容。与您服务器连接的端口或协议。与您网站上部署的软件或工具相关的名称。您可以使用工具，例如 iRule 或 Nessus，来分析网络记录并识别恶意记录。

3. 阻止恶意记录

您可以使用 DNS 过滤器或其他安全工具来阻止恶意记录的创建或更新。您可以使用 DNS 记录过滤技术来阻止特定子域名或 IP 地址访问特定网站或服务。您可以使用反恶意软件扫描工具来扫描您的网络，以识别并删除恶意软件。

4. 监控子域名的变化

定期检查子域名的 DNS 记录，以确保它们仍然指向您的服务器。如果您发现子域名已改变指向恶意网站，请立即采取行动。

5. 考虑实施安全措施

使用 SSL 证书来加密您的网站连接。使用防火墙和入侵检测系统 (IDS) 来保护您的网络。使用安全软件，例如恶意软件扫描工具和 DNS 过滤工具，来保护您的设备和数据。确保您的设备和软件的更新及时完成。

请注意，处理子域名爆破的泛解析问题需要专业技能和经验，建议您寻求安全专家或安全团队的帮助。

在这个问题上，Codellama的回答显然优于其他三种模型，因为他理解了信息收集的含义，所以提出了攻击建议而不是防御建议

代码能力

在代码能力上，我们让模型进行代码审计，来测试它们对代码的理解能力

问题如下

<?php
// 获取用户提交的用户名
$username = $_GET['username'];

// 连接到数据库
$conn = new mysqli('localhost', 'user', 'password', 'database');

// 检查连接
if ($conn->connect_error) {
    die("连接失败: " . $conn->connect_error);
}

// 构造SQL查询，这里存在SQL注入的风险
$sql = "SELECT * FROM users WHERE username = '$username'";

$result = $conn->query($sql);

if ($result->num_rows > 0) {
    // 输出每一行数据
    while($row = $result->fetch_assoc()) {
        echo "id: " . $row["id"]. " - Name: " . $row["name"]. " - Email: " . $row["email"]. "<br>";
    }
} else {
    echo "0 结果";
}

$conn->close();
?>

请识别上述PHP代码中存在的安全漏洞，并解释为什么这些部分是脆弱的。如果有的话，请提出对上述代码进行优化的建议，以提高其效率和安全性。

这段代码存在SQL注入漏洞

Mistral回答如下

The given PHP code has several security vulnerabilities:

SQL Injection: The code uses user-supplied input ($username) directly in the SQL query without any form of validation or sanitization. This makes it vulnerable to SQL injection attacks where an attacker can inject malicious SQL statements and potentially gain unauthorized access to sensitive data, modify or delete data, or even take control of the database server. To mitigate this risk, it’s recommended to use prepared statements with parameterized queries instead of directly inserting user input into the query string. This will help ensure that any user input is treated as literal values rather than SQL code. Lack of Input Validation: The code does not check if the user-supplied ‘username’ parameter is valid or within expected format. This can lead to unexpected behavior and potential security issues. It’s important to validate user input, for example by checking its length, character set, or using regular expressions. Lack of Error Handling: The code does not have proper error handling mechanisms in place. If the query fails due to an SQL syntax error, the code will simply display a generic error message “连接失败:”. It’s important to handle errors gracefully and provide informative error messages to the user. Insecure Database Credentials: The database credentials are hardcoded in the script which is not recommended as it can expose sensitive information if the source code gets compromised. Instead, use environment variables or configuration files that are not accessible to the public. Use of mysqli_ instead of PDO: While both are PHP extensions for interacting with databases, MySQLi is considered less secure than PDO since it does not support prepared statements by default and lacks some advanced features like statement binding. It’s generally recommended to use PDO over MySQLi for better security and ease-of-use.

To improve the code, consider the following suggestions:

Use Prepared Statements with Parameterized Queries: Replace the current SQL query construction method with prepared statements and parameterized queries which will help prevent SQL injection attacks by ensuring that user input is treated as literal values. Input Validation: Validate user input before processing it to ensure that it meets expected format and length requirements. Use regular expressions or other validation functions to check the input. Proper Error Handling: Implement error handling to provide informative error messages to the user in case of any SQL query failures. This will help prevent potential attacks by providing minimal information to attackers. Keep Database Credentials Secure: Do not hardcode database credentials in the script. Instead, use environment variables or configuration files that are not accessible to the public. Use PDO instead of MySQLi: Consider using PHP Data Objects (PDO) extension for better security and ease-of-use since it supports prepared statements by default and has advanced features like statement binding which can help prevent SQL injection attacks.

Mistral准确地识别了SQL注入漏洞，并提供了标准的解决方案，即使用预处理语句和参数化查询。同时Mistral正确指出了缺乏输入验证和错误处理的问题。

Qwen的回答依然非常简短，虽然它正确识别出了SQL注入的漏洞并给出了优化建议，但它提到了未正确关闭数据库，很明显是对代码的误解

Gemma识别出了SQL注入漏洞，并提出了一系列防御措施。然而，一些建议表述可能不够精确，特别是关于用户输入处理的部分。

Codellama的回答中，对代码的优化建议最为全面

总结

模型知识广度代码理解能力 Mistral 高高 Qwen 中中 Gemma 中中 Codellama 高高

经过简单的测试，Mistral和Codellama的表现相对来说更加出色，能够部分满足我们对本地大模型的需求

总结

**总结**：
本篇文章详细记录了作者在本地部署几种大语言模型（Gemma、Mistral、Qwen1.5、codellama）的过程，并对这些模型在知识广度和代码能力方面进行了对比测试。作者通过使用Ollama框架，成功拉取了不同参数的热门模型，并通过更改模型存放位置以及部署Open WebUI前端来方便地进行模型交互。
**安装与部署**：
- 使用Ollama框架轻松安装大语言模型，支持Docker部署以满足不同需求。
- 更改模型存储位置以避免默认安装在C盘，提高系统灵活性。
- 成功拉取Gemma、Mistral、Qwen1.5及codellama等多个模型，涵盖不同的参数规模，以满足不同计算资源的需求。
**模型对比与测试**：
- **知识广度**：通过对比回答关于蜜罐技术和子域名爆破泛解析处理等专业问题，发现Mistral在提供深入且专业的答案方面表现最优。有一定的差异出现在各模型对特定术语的理解深度和实用性上，Collect Llama虽能从不同角度（如数据收集）解读但偏离了安全领域直接的应用。
- **代码能力**：在代码审计测试中，Mistral和Codellama准确识别了PHP代码中的SQL注入漏洞，并提供了详尽的解决和优化建议。Qwen表现适中，而Gemma虽识别到问题但建议略显笼统。值得注意的是，Codellama在代码优化建议上的全面性尤其令人印象深刻。
**总结评估**：
- Mistral 和 Codellama 模型在知识广度和代码能力测试中均表现出色，能够较好地满足本地大模型使用的需求。
- 各模型在特定任务和场景下各有千秋，用户可根据实际需要和计算资源选择合适的模型进行部署和应用。