原文链接:概率论-参数检验
git github仓库管理
原文链接:git github仓库管理
拉取镜像
github的仓库有两种下载方式,http和ssh,http是对外公开的,可以直接clone,ssh的一般是自己的或内部的仓库,仓库需要配置ssh-key才能使用git@ clone.
或者直接网页下载
linux配置远程ssh服务
原文链接:linux配置远程ssh服务
ssh服务器配置
安装
安装ssh服务
1 | sudo apt-get install openssl-server |
启动
启动并检查状态
1 | service sshd start |
sshd_config
ssh配置文件在/etc/ssh/sshd_config
Port ID 设置开放指定端口,如Port 22(默认)
AuthorizedKeys配置
sudo vim /etc/ssh/sshd_config在末尾添加
1 | RSAAuthentication yes |
然后重启sudo service sshd restart
ssh密钥管理
服务器生成密钥,直接回车3次
1 | ssh-keygen -t rsa |
在~/.ssh目录下有id_rsa.pub为公钥
创建一个authorized_keys,如果需要配置免密连接
可以把远程连接的电脑的公钥放在这个文件
修改权限
1 | sudo chmod 700 .ssh/ |
ssh连接
vscode 连接
下载remote ssh扩展
使用ssh命令即可连接
命令行连接
1 | ssh <username>@<ip> -p port |
远程启动管理
sudo poweroff reboot 远程关机 重启
两行代码永久关闭windows 更新
ubuntu掉驱动 NVIDIA-SMI has failed because
原文链接:ubuntu掉驱动 NVIDIA-SMI has failed because
导言
打开电脑查看nvidia-smi,结果报错:
NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
dockerfile规则和一个指定硬件资源的SSH连接系统镜像示例
glm3源码学习
原文链接:chatglm源码学习
GLM3源码:https://github.com/THUDM/ChatGLM3
我们直接从openai_api_demo入手,因为api_demo一般是nlp模型后端核心功能实现的部分
openai_api_demo源码
api_server.py
api_server.py是提供web api接口的入口文件,是使用flask框架提供的一个异步接口支持
1 | app = FastAPI(lifespan=lifespan) |
1 | class ModelCard(BaseModel): |
上面这一堆class是实现chat这个api功能的主要对象,如模型卡、请求体和响应体
1 | @app.get("/health") |
这个是测试api状态函数,可以看到这个测试功能还是很直接的,没有考虑部署应用下的问题,如负载情况和安全状况,这个demo也就是一个学习的小demo项目。
1 | @app.post("/v1/embeddings", response_model=EmbeddingResponse) |
这个函数是获取文本向量编码的,sentences_to_embeddings功能。
这里面有个函数num_tokens_from_string是统计文本的tokens数量,使用的tiktoken模块是openai开源的一个快速分词统计库,cl100k_base是和gpt4同款编码器,也就是说glm3的tokenizer实际上是使用的gpt4的tokenizer,在论文里面glm的baseline是最开始的gpt-1模型,那从理论上,glm3的性能提升肯定会受到分词的影响的(清华博士教大家的水论文小技巧hhh)。
1 | class ModelCard(BaseModel): |
这个list_models直接限定了就是chatglm3-6b模型了,里面没有包括实际的模型
1 | @app.post("/v1/chat/completions", response_model=ChatCompletionResponse) |
chat最核心的响应函数了,由于函数较长就不全截了。
首先我们看到的是一个消息验证不允许assistant多次生成,原因主要是这个功能本身对助手是没有什么意义的,而且多次生成的训练效果比较差,之前我测试过gpt api的多次生成。因为他们用的训练数据基本上都是一个消息内全部回复了,上下文数据本身不存在多次生成的场景,因此这些模型多次生成并不是把问题分多次回复(和人类不同,一句话可以多方面讲,分段讲),只是把答案回答多次。
如果要实现更真实的问答AI,拥有更真实的对话体验,那对数据的要求是很高的,最好的数据集应该是QQ微信这种聊天软件的数据,但是企业是不可能拿这些隐私数据训练的。不过也有平替,如贴吧微博这些开放平台的数据也是很好的,但是这些数据看过后,上下文的逻辑性还是有问题的,并且多轮对话的人物被屏蔽了,也就是说明明是多个人的对话被训练成了二人的对话,这些模型后面肯定被高质量多轮对话微调过,不然单纯这些语料不会达到gpt的这种效果。
响应类型分为直接响应和SSE响应,其中直接响应简单,就是拿model直接推理得到message。
这里有个问题是这个chat函数是asyn异步的,但是model资源是global的单个模型,如果同时多个请求可能会报错。可以对模型封装个请求拥塞队列,比如大于3个请求就返回繁忙。
SSE响应部分和直接响应不同,SSE没有提供使用量这些信息,仅返回了响应文本,SSE还对前端的响应方法有要求,因此如果是仅学习开发和小规模应用没有必要追求SSE
1 | predict_stream_generator = predict_stream(request.model, gen_params) |
通过predict_stream创建一个生成器,next生成下一个字符然后返回。
utils.py
utils.py提供了响应的实现函数generate_stream_chatglm3和generate_chatglm3
1 | def generate_chatglm3(model: PreTrainedModel, tokenizer: PreTrainedTokenizer, params: dict): |
循环调用generate_stream_chatglm3后返回响应
generate_stream_chatglm3函数
1 | def generate_stream_chatglm3(model: PreTrainedModel, tokenizer: PreTrainedTokenizer, params: dict): |
其中里面有个函数很关键process_chatglm_messages:消息处理函数
1 | def process_chatglm_messages(messages, tools=None): |
这个函数就是把message对象转化为dict对象,我们可以看到这里面有system、observation、assistant、user。
在generate_stream_chatglm3:inputs = tokenizer.build_chat_input(query, history=messages[:-1], role=role)
这个函数中把dict对象对应的history转换成了文本格式,例如:
1 | <|system|> |
也就是说我们以为的多轮对话实际上就是把历史记录拼起来的。
这部分想到了个idea,这种拼起来的实际上有历史限制,如果让模型生成每个对话的重要性,然后按照重要性+时间权重排序选择性记忆能不能增强长期记忆能力?感觉这部分应该有人在做或者做出来了。
main
最后回来看下api_server.py的main函数
1 | if __name__ == "__main__": |
main函数从transformers加载模型然后作为global对象推理。
transformers模型就和传统的bert、t5类似了
chatglm的改进主要包括:
- 二维位置编码+GELU+残差、层归一化重排序
- 文档级+句子 NLG预训练
- NLG+NLU两种任务都进行训练,同时微调的时候还使用了slot填空的NLU方法
总结
之前没怎么看过这种有上下文模型响应的完整流程,这趟下来解决了我之前好几个疑惑:
- transformer的重复问题我遇到了好几次,可以通过惩罚参数控制
- 上下文实现方法-实际上还是把历史对话融在一起
- 模型推理资源占用问题,请求队列感觉是一定要有的,web框架本身是异步请求响应的,不对临界资源管理感觉没啥可靠性
加上这个,目前已经把带上下文的文本生成+知识库扩展永久记忆解决了,后面再对模型结构魔改下,然后集成一些动作指令,就可以实现本地部署家用AI女仆了hhh。
操作系统引导全过程
关于将linux作为主系统近一个月的感想
原文链接:关于将linux作为主系统近一个月的感想
导言
在一个月前我从win10转到了ubuntu系统,主要目的是能觉得linux更加契合开发环境,并且也有很多人一直使用linux作为办公娱乐系统。
但是实际体验过之后只有一个感想,linux只能作为专用开发的系统,或者说第二系统,除非你没有任何的工作、娱乐需求。
要点
缺点
软件生态问题
很多的工具都没有linux版本,如各类游戏,大部分装机的测试工具,还有很多办公软件,除了大厂软件和国外的开源软件,大部分软件都没有Linux版本。虽然说有wine可以执行win程序,但是也仅止步于执行了,一些软件执行中的很多莫名的bug你甚至都搜不到有其他人问。游戏就更算了,linux用户基本不要考虑用linux游戏,很多问题都来源于没有需求的需求服务兼容和稳定性问题
虽然linux上开发很高效,但是实际部署的时候会出现其他系统中不会遇到的许多问题,如之前给本地的一个局域网主机设置共享网络时,在linux系统下一直无法成功,
在windows下很简单就完成了.办公问题
同样的问题再说一遍,基本上office waps是办公必备的软件了,但是linux虽然提供了libreoffice能编写文档,但是这些文档存在格式不兼容的问题,word编写在其他系统上的和在
linux上的格式不一样,可能同样的格式显示不一样,或者显示一样格式却不一样.