下载ai到本地
‘为什么要下载ai到本地’
- 本地运行ai可以更快的响应用户的请求，减少响应延迟。
- 本地运行ai可以更方便的调试和修改。
- 本地运行ai的请求内容和训练数据都是保存在本地的。
通过ollama下载
ollama是旨在简化大型语言模型本地部署和运行过程的工具。
下载安装ollama
我在写这篇blog的时候，ollama已经发布了llama3.3的下载链接
打开终端，执行
ollama run llama3.3 # 举例，也许你想run别的
ollama就会自动下载了
插一嘴，我因为不想自己微调，下载了3.2-chinese，结果效果并不好，不是说中文回答不好，也许是因为微调过拟合而不能很好地根据模型文件生成自定义模型了
又注，微调很容易过拟合而失去通用能力
到huggingface上下载guff格式的模型
ollama可以接受此类模型生成自己的模型文件，但同时，通过ollama下载的模型可能无法直接使用，所以ollama虽然方便，但如果之后有微调需要，还是从huggingface上下载好。
本地AI的配置
GUI配置
命令行和gui各有优劣吧。
命令行很带感有木有。
但是图形化界面很方便添加后续功能。
gui没有附带在ollama中，需要单独搜索下载安装
ollama-gui画面简洁，且脚本开源，非常推荐。不过也许你懒得自己写功能，那么还有其他功能已经完备的适用于ollama的软件。
或者你可以试试我的网页版，传送门
前提是你有一个本地ai，并了解过了有关端口服务
modelfile文件配置
详细内容直接移步：https://blog.csdn.net/Chaos_Happy/article/details/138276172
ollama create <新模型名> -f <modelfile文件路径>
modelfile文件格式：
FROM (必需的) 定义使用的基模型
PARAMETER(参数) 设置Ollama运行模型的参数
TEMPLATE(提示词模板) 于发送给模型的完整提示模板
//不是放提示词的意思，使用go语言编写，是正经模板
SYSTEM 指定将在模板中设置的系统消息
ADAPTER 定义适用于模型的（Q）LoRA适配器
LICENSE Specifies the legal license.
MESSAGE 指定消息历史
//消息历史能潜移默化地改变模型的行为，如果因为ai始终不做出满意的回答而气急败坏，不妨从这里入手，给它做个示范，也许效果不错
ai服务开放
ollama开放端口
ollama默认自启动，如果没有可以手动在终端输入命令
ollama serve
成功了它会告诉你开放了你的哪个端口，点击链接或者直接在互联网访问http://localhost:
在终端可以看到ollama的日志，访客信息，请求信息，请求状态等。
但到这一步，ai服务仅仅只能被局域网内的主机访问，因为你的ip被限制在了内网。
互联网访问
想要让ai服务在互联网上被访问，途径之一是将此端口投射到公网。
这一过程被称为内网穿透，你需要通过Ngix或者Cpolar等服务申请隧道，然后拥有一个暂时的域名，将你开放的端口投射到此域名上，然而我尝试的效果并不好，成功连接很不容易。
如果你资金充足，可以购买一个公网ip，甚至将ai上传到云服务器上，这样就可以让所有人24小时在公网上访问了。
所以你明白了什么叫梦想版。
抛开资金细节，我们已经拥有了一个域名，这个域名不是用来打开的，我们上传端口后，就获得了一个可以访问的api
api格式：
廉政版：http://127.0.0.1:端口号/api/chat
小康版：http://你的域名/api/chat
127.0.0.1就是你自己，仅供自己访问的意思，可以换成内网ip，就能让局域网内访问
如果你是小康版，且没有做任何限制，那么这个api是可以被任意访问的，访问的这个过程就是对api做出请求。
访问请求
我们假设我们奔小康了。
给出访问请求的格式方便理解请求这一过程（只拿js举例）：
const response = await fetch(`${API_URL}/api/chat`, {//替换为你自己的api地址
method: 'POST',//请求类型一般为post
headers: {//请求头
'Content-Type': 'application/json',//请求体格式为json
},
body: JSON.stringify({//请求体
model: 'cgl', // 替换为你所选择的模型名称
messages: [message],//用户输入的消息
stream: true,//是否持续返回结果
}),
});
这个请求会返回包含ai回复的json数据，其中就包括回复内容
stream为true，表示请求响应将持续不断，直到ai结束对话。如果请求需要token，那么每个token相当于将近一个汉字或一个词，所以如果请求过长，可能会导致响应延迟。
很多ai模型厂商如openAi对token做限制，现在注册成为普通用户，只能使用gpt-4o-mini，每分钟只能做3次对话，超过请求就会被拒绝，非常不舒服。
那，关于ai的流式返回和结果处理，我新开一篇写。
如果是非流式的api返回，那应当简单的多，正如同我当下利用的fittenCode的api，只需要等到接收到结果并呈现给用户，不过是如果返回的内容多的话，返回的时间会长一些。
我们继续往下说，此时梦想版的我们已经完成了api的访问和获得回复，我们还需要把请求这一过程图形化，即创建一个合适的前端页面，让用户可以输入消息，选择模型，点击发送，然后获取ai的回复。
这里没有什么可说的，重点是保存对话的历史记录，在请求时一并发送，这样ai就好像理解了上下文。
不得不称赞fittenCode的api，反应速度很快，每次返回都没什么延迟，就算对话历史内容越堆越多，几乎看不出差别，反观我本地的模型，如果提示词长了些，每次开始对话都需要很长一段时间加载，如果隔一段时间没对话，同样也要加载。
我想这跟ai模型的大小和服务器性能都有关系。
Ai模型的微调
到这里并不是终点，ai还仅仅只是原有的模型，我们需要根据自己的需求调整它。
训练与推理
lora模型混合
没有尝试的东西是没有办法继续往下写的，我目前还没有尝试的条件。
所以——
未完待续……
此方悬停