大模型格式转换

lilac

2025-06-25 2025-04-25 约 1624 字预计阅读 8 分钟

通常部署本地大模型时，用户会在 Huggingface 网站上进行下载，然而部分作者上传的模型格式并非为 GGUF 格式，如：safetensors、bin 格式等。

当使用 Ollama 进行本地部署时，则需要将这些格式转换为 Ollama 工具可用的模型格式，下面举例将 safetensors 格式转换为 gguf 格式。

1 安装 llama.cpp

工具 llama.cpp 能够实现对模型的转换、量化操作，支持的转换格式有 PyTorch 的 .pth，huggingface 的 .safetensors，以及 llama.cpp 采用的 ggmlv3。

首先下载其工具仓库：

git clone --depth=1 https://github.com/ggerganov/llama.cpp
# --depth=1：该选项指定只获取最新的提交记录，而不是整个历史提交记录。这样可以有效减少下载的大小

安装工具所需依赖：

# 依赖配置文件可以在 llama 工程目录下找到
pip install -r requirements.txt

执行编译与安装：

cmake -Bbuild
# -Bbuild：该选项指定生成构建文件的目录名为 build

cmake --build build -D...
# --build：该选项指定执行构建过程
# build：构建文件的目录名
# -D...：该选项指定构建过程的参数（具体参数未指定）。

2 模型转换

通过项目中的 convert_hf_to_gguf.py 脚本进行转换，

python convert_hf_to_gguf.py /data/model/starcoder --outtype f16

3 模型部署

# 创建 Modelfile
touch Modelfile && echo "FROM /path/to/DeepSeek-R1-1.5B.gguf" > Modelfile
# 利用 ollama 工具的命令
ollama create <name> --file ./Modelfile
# 启动模型
ollama run <name>

3.1 模型访问记录

在访问 X 项目组模型时，出现连接创建错误 Failed to establish a new connection: [Errno 111] Connection refused')。运作之后，获得服务器账号密码，登录到目标服务器上。观察模型运行正常，于是查看对应端口的监听状态：

(base) root@ubuntu:/# sudo lsof -i :11434
COMMAND    PID      USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
ollama  529956    ollama    3u  IPv4 15772337      0t0  TCP localhost:11434 (LISTEN)

项目组 X 将访问监听设置在本地，防止服务器资源滥用。在目标机器上，使用 nginx 反向代理即可。

安装 nginx

配置代理文件

针对配置文件 /etc/nginx/sites-available/default 做出修改如下

server {
    listen 8080;    # 监听端口
    server_name _;

    access_log /var/log/nginx/access.log;      # 访问日志路径
    error_log /var/log/nginx/error.log debug;  # 错误日志路径和级别

    location / {
        proxy_pass http://127.0.0.1:11434;     # 代理到本地ip:port服务
        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;
    }
}

随后使用 nginx -s reload 来平滑重载，能不中断现有连接的方式进行配置替换。

测试模型

此时访问服务器 ip:8080 就可以将请求转发到本地，规避了 localhost:11434 监听导致的问题

4 模型散记

在实现业务过程中，X 部门希望成立 XX 项目对标 Cursor 来实现代码自动编程工作。

其中有几个诉求自己理解不深刻，记录一下：

知识底座

希望基于全量代码建库、基于表项设计、业务流设计灵活建库

不太理解这个建库对于大模型分析来说如何理解？
效果评估

精确衡量模型准确度，可以通过用户反馈增强学习

未了解如何进行增强学习的原理

效果评估

主要是通过用户的反馈来进行评估，通过不同的任务，评估的方式也不同，如：
- 有明确答案或预期结果的任务（信息检索类），能直接与标准答案对比
- 开放性与主观问题场景下（文本生成任务），标注标准可以是“完全契合、大部分契合、部分契合、不契合等”
- 还能通过进行用户行为进行监测，如聊天机器人以某种方式回复经常得到用户好评，那么可以增加该回复方式的概率；而用户多次重复提问或明确指出错误，则将其作为惩罚信号。
增强学习

能够分为在线和离线增强学习两种方式，如企业可能会在每周特定某个时间节点，将收集到的反馈信息进行汇总，并利用这些数据对模型进行重新训练。

在线增强学习中，这种模型权重的更新通常是实时的，以快速的适应用户的新需求和偏好。

而这种直接的反馈，会在一定程度上导致模型劣化的风险增高，相应的有一些措施预防，如：

① 使用较低的学习率使模型对新反馈的反应迟钝，这样权重变化小，有助于防止模型因为个别异常反馈产生剧烈波动

② 数据验证筛选工作，将异常值、噪声数据剔除

③ 定期模型评估与回滚机制，定期检测模型指标，如：准确率、召回率、F1值等是否存在下降，若有劣化则将模型回滚到一个较好的版本

在线的增强可以是整个模型级别，也能针对某个session或用户
用户干预

针对AI的分析结果和任务，用户能进行微调，及时纠错

如何让用户进行及时纠错？

这种诉求通常需要构建在线学习系统，让用户提供纠错的反馈，随后系统会利用这种反馈来更新模型，对模型权重进行微调。

这里需要一些策略，如：用户的反馈立刻更新，还是收集一定数量的反馈后进行批量更新；同时如何平衡不同用户反馈的权重，避免少数用户的错误反馈对模型产生过大的影响。