换行符引发的惨案

最近在读go源码。

本来环境都搭建好了,源码也上传git了。

但从另一台电脑下载源码后,报了一堆神奇的错误。

最后发现是go.env文件中,回车换行是按windows系统设定上传到git的,改为linux系统设定就好了。

想起入行以来,因为字符集、换行符、正斜杠反斜杠、tab还是空格,遇到的那堆坑,唏嘘不已。希望UTF-8早日一统天下。

qwen.cpp简明教程

1、下载并编译qwen.cpp

git clone --recursive https://github.com/QwenLM/qwen.cpp
cd qwen.cpp
cmake -B build
cmake -B build -DGGML_OPENBLAS=ON
cmake -B build -DGGML_CUBLAS=ON
cmake --build build -j --config Release

2、下载模型,转化为ggml格式

#从hf下载模型,下载完成后,本地地址为 ~/.cache/huggingface/hub/模型名称
#部分代码文件会有缺失,可以到hf上对比下载
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen-7B-Chat",trust_remote_code=True)
#模型转化为ggml格式
#同时进行量化,降低资源需求
python3 qwen_cpp/convert.py -i PATH_TO_MODEL -t q4_0 -o qwen7b-q40-ggml.bin

3、运行模型

./build/bin/main -m qwen7b-q40-ggml.bin --tiktoken PATH_TO_MODEL/qwen.tiktoken -i

chatglm.cpp简明教程

1、下载并编译chatglm.cpp

git clone --recursive https://github.com/li-plus/chatglm.cpp.git
cd chatglm.cpp
git submodule update --init --recursive
#cmake -B build
cmake -B build -DGGML_OPENBLAS=ON
#cmake -B build -DGGML_CUBLAS=ON
cmake --build build -j --config Release

2、下载模型,转化为ggml格式

#从hf下载模型,下载完成后,本地地址为 ~/.cache/huggingface/hub/模型名称
#部分代码文件会有缺失,可以到hf上对比下载
from transformers import AutoModel
model = AutoModel.from_pretrained("THUDM/chatglm-6b",trust_remote_code=True)
#模型转化为ggml格式
#同时进行量化,降低资源需求
pip install torch tabulate tqdm transformers accelerate sentencepiece
python3 chatglm_cpp/convert.py -i PATH_TO_MODEL -t q4_0 -o chatglm-6b-q40-ggml.bin

3、运行模型

./build/bin/main -m chatglm-6b-q40-ggml.bin -i

4、常见问题

#下面的错误,是transformers版本太高导致
AttributeError: 'ChatGLMTokenizer' object has no attribute 'sp_tokenizer'. Did you mean: '_tokenize'?
#需要降低transformers版本
pip uninstall transformers
pip install transformers==4.33.2

大语言模型资料汇总

一、之前整理了一些大模型的Demo,汇总如下
1、ChatGPT
https://github.com/neohope/NeoDemosChatGPT

2、Llama2
https://github.com/neohope/NeoDemosLlama2
可同步看一下中文版Llama2
https://github.com/ymcui/Chinese-LLaMA-Alpaca-2

3、阿里千问
https://github.com/neohope/NeoDemosQwen

4、清华ChatGLM
https://github.com/neohope/NeoDemosChatGLM

二、建议看一下llama.cpp
1、llama.cpp
https://github.com/ggerganov/llama.cpp

2、python的llama.cpp封装
https://github.com/abetlen/llama-cpp-python

3、千问的qwen.cpp实现
https://github.com/QwenLM/qwen.cpp

4、ChatGLM的chatglm.cpp实现
https://github.com/li-plus/chatglm.cpp

三、还有量化
https://github.com/AutoGPTQ/AutoGPTQ

四、当然还有langchain
https://github.com/langchain-ai/langchain

五、如果有余力,看一下Transformer实现
https://github.com/huggingface/transformers

llama.cpp简要教程

1、下载并编译llama.cpp

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make

2、下载llama-2-7b-chat
a、可以从fb或hf下载
b、可以使用脚本下载工具,比如llama-dl
c、可以使用Chinese-LLaMA-2-7B
d、可以使用其他三方源

3、模型转换为ggml格式

python3 convert.py ../llama/llama-2-7b-chat/ 
Loading model file ../llama/llama-2-7b-chat/consolidated.00.pth
params = Params(n_vocab=32000, n_embd=4096, n_layer=32, n_ctx=2048, n_ff=11008, n_head=32, n_head_kv=32, n_experts=None, n_experts_used=None, f_norm_eps=1e-06, rope_scaling_type=None, f_rope_freq_base=None, f_rope_scale=None, n_orig_ctx=None, rope_finetuned=None, ftype=None, path_model=PosixPath('../llama/llama-2-7b-chat'))
Found vocab files: {'tokenizer.model': PosixPath('../llama/tokenizer.model'), 'vocab.json': None, 'tokenizer.json': None}
Loading vocab file '../llama/tokenizer.model', type 'spm'
Vocab info: <SentencePieceVocab with 32000 base tokens and 0 added tokens>
Special vocab info: <SpecialVocab with 0 merges, special tokens unset, add special tokens unset>
tok_embeddings.weight                            -> token_embd.weight                        | BF16   | [32000, 4096]
norm.weight                                      -> output_norm.weight                       | BF16   | [4096]
output.weight                                    -> output.weight                            | BF16   | [32000, 4096]
layers.0.attention.wq.weight                     -> blk.0.attn_q.weight                      | BF16   | [4096, 4096]
...
layers.31.ffn_norm.weight                        -> blk.31.ffn_norm.weight                   | BF16   | [4096]
skipping tensor rope_freqs
Writing ../llama/llama-2-7b-chat/ggml-model-f16.gguf, format 1
Ignoring added_tokens.json since model matches vocab size without it.
gguf: This GGUF file is for Little Endian only
[  1/291] Writing tensor token_embd.weight                      | size  32000 x   4096  | type F16  | T+   3
...
[291/291] Writing tensor blk.31.ffn_norm.weight                 | size   4096           | type F32  | T+ 314
Wrote ../llama/llama-2-7b-chat/ggml-model-f16.gguf

4、模型量化,减少资源使用

./quantize ../llama/llama-2-7b-chat/ggml-model-f16.gguf  ../llama/llama-2-7b-chat/ggml-model-f16-q4_0.gguf q4_0 
main: build = 2060 (5ed26e1f)
main: built with cc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 for x86_64-linux-gnu
main: quantizing '../llama/llama-2-7b-chat/ggml-model-f16.gguf' to '../llama/llama-2-7b-chat/ggml-model-f16-q4_0.gguf' as Q4_0
llama_model_loader: loaded meta data with 15 key-value pairs and 291 tensors from ../llama/llama-2-7b-chat/ggml-model-f16.gguf (version GGUF V3 (latest))
llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output.
llama_model_loader: - kv   0:                       general.architecture str              = llama
llama_model_loader: - kv   1:                               general.name str              = llama
llama_model_loader: - kv   2:                       llama.context_length u32              = 2048
llama_model_loader: - kv   3:                     llama.embedding_length u32              = 4096
llama_model_loader: - kv   4:                          llama.block_count u32              = 32
llama_model_loader: - kv   5:                  llama.feed_forward_length u32              = 11008
llama_model_loader: - kv   6:                 llama.rope.dimension_count u32              = 128
llama_model_loader: - kv   7:                 llama.attention.head_count u32              = 32
llama_model_loader: - kv   8:              llama.attention.head_count_kv u32              = 32
llama_model_loader: - kv   9:     llama.attention.layer_norm_rms_epsilon f32              = 0.000001
llama_model_loader: - kv  10:                          general.file_type u32              = 1
llama_model_loader: - kv  11:                       tokenizer.ggml.model str              = llama
llama_model_loader: - kv  12:                      tokenizer.ggml.tokens arr[str,32000]   = ["<unk>", "<s>", "</s>", "<0x00>", "<...
llama_model_loader: - kv  13:                      tokenizer.ggml.scores arr[f32,32000]   = [0.000000, 0.000000, 0.000000, 0.0000...
llama_model_loader: - kv  14:                  tokenizer.ggml.token_type arr[i32,32000]   = [2, 3, 3, 6, 6, 6, 6, 6, 6, 6, 6, 6, ...
llama_model_loader: - type  f32:   65 tensors
llama_model_loader: - type  f16:  226 tensors
llama_model_quantize_internal: meta size = 740928 bytes
[   1/ 291]                    token_embd.weight - [ 4096, 32000,     1,     1], type =    f16, quantizing to q4_0 .. size =   250.00 MiB ->    70.31 MiB | hist: 0.037 0.016 0.025 0.039 0.057 0.077 0.096 0.111 0.116 0.111 0.096 0.077 0.057 0.039 0.025 0.021 
...   
[ 291/ 291]               blk.31.ffn_norm.weight - [ 4096,     1,     1,     1], type =    f32, size =    0.016 MB
llama_model_quantize_internal: model size  = 12853.02 MB
llama_model_quantize_internal: quant size  =  3647.87 MB
llama_model_quantize_internal: hist: 0.036 0.015 0.025 0.039 0.056 0.076 0.096 0.112 0.118 0.112 0.096 0.077 0.056 0.039 0.025 0.021 
main: quantize time = 323302.84 ms
main:    total time = 323302.84 ms

5、使用模型

./main -m ../llama/llama-2-7b-chat/ggml-model-f16-q4_0.gguf -n 256 --repeat_penalty 1.0 --color -ins

现阶段AI是否会替代人类

近期在读一个LangChain的系列文章,文章的最后,作者提出了一个问题:“AIGC来了,人类画师还有价值吗?”

这是一个好问题,在现阶段,我的理解是这样的:

AI绘画提供了一种通用能力,而且很多时候效果很不错,有商用价值,但并非无所不能。说白了就是一种新工具而已,我们该用积极心态看待问题。

就像本文指出的,对人来说效果并非一切。人是有情感的,不仅现在的AI生成物无法替代,很多客观指标更好的物品都无法替代。自己钓的鱼和市场买的是不一样的,自己阳台种的菜和农场种的是不一样的,父母做的菜和餐厅里的是不一样的,儿女给我们画的画和别人的画是不一样的,哪怕替代品指标更好,也无法完成情感需求的替代。

但更进一步,人从一开始不应该和AI比。人很早就学会了不要和机器去比,机器比人力气大,比人跑的快,比人跳得高,但人类为何还要不断挑战自我呢?一旦我们把人工智能,随便换个名字,类人脑型计算阵列设施,问题就简化了。影像医生为何要和AI去比谁能先找到微小肺结节?画师为何要和AI比谁画图更快?网球裁判为何要和AI比谁能更准确的判断球是否出界?用好这些工具就好了啊。

从人类历史的经验看,机器替代人工的过程,在近现代史上出现了太多次,但实质上都是,熟练用工具的人大幅提升效率,最终替代了无法熟练使用工具的非顶尖人才。互联网时代也是一样的,互联网媒体兴起时,对传统媒体产生了巨大压力,但现在自媒体市场兴起,又给多少非科班同学创造了机会。AI短期内一定会抢占一些人类的工作岗位,熟练使用AI辅助编程的人,会挤压掉很多重复编码的工作机会。

但同样的,非科班同学将会拥有编程能力,未来一定会创造更大的市场。未来我们每个人都能有足够好的编程,绘画,作曲,剪辑,写作能力,都有便捷高效的获取并使用近乎无限知识的能力。专业知识普及化,会缓解人类教育周期过长的问题,会带来生产力质的变化。希望这种生产力的飞跃,能带领我们进入一个新的时代。

碳基生物和硅基生物

在ChatGPT大力出奇迹之后,大模型已经从“萌宠时代”,正式迈入了蹒跚学步的“婴儿时代”。
这个婴儿虽然短期记性不算好,但学习能力和长期记忆能力却无与伦比,潜力无限。

现在大家又通过langchain、plugin等方式,帮助这个婴儿学习使用工具。
当大模型可以理解工具,使用工具,甚至制造工具、创造工具时,硅基生物时代也就开始降临了。

在这个过程中,可能会有以下几个阶段:
1、硅基生物智力和能力有限的阶段
碳基生物需要学会如何运用硅基生物,提升自己的生活水平

2、两种可能
2.1、硅基生物智力无限和能力有限的阶段
碳基生物变成了硅基生物的执行者,相互依赖,容易形成共同体,更容易走向共存的结局

2.2、硅基生物智力有限和能力无限的阶段
碳基生物需要学会如何控制硅基生物的能力,熊孩子教育不好,容易走向一起灭亡的结局

3、硅基生物智力和能力无限的阶段
硅基生物最好能学会如何和碳基生物共存,希望碳基生物不要仅仅是一段引导代码,善待引导代码

微服务性能调优03

近期遇到一些技术问题,记录如下:

1、NAS引起的惨案一
上次说到,大家都在降本,于是我们做了一系列调整工作。但降本总有一个永恒不变的主题:降配。
于是我们和集团的科技,同时开始了惨无人道的降配工作。
在一顿神奇操作后,系统终于区域稳定,好景不长,突然间又出问题了。

表现:
系统部分服务的部分节点,在服务高峰期之后,总是会出现时不时的系统卡顿。
关键这个卡顿很有规律,总是上午10点,下午4点出现,完美错过我们的上下午业务高峰。
原因:
经过技术委员会小伙伴通力排查,大家最终定位到是应用日志写入到归档NAS时,NAS性能十分不稳定,IO时间有时会高达几秒。
一旦遇到NAS卡顿,会阻塞日志,进而阻塞服务。
而且,当前NAS是和兄弟公司公用的,NAS卡顿时,正值他们的业务高峰期。
解决:
应用日志不再输出到NAS,而是输出到日志云。

2、NAS引起的惨案二
平稳度过了几天,周五,问题又来了。
表现:
系统时不时卡顿,没有任何规律,和业务高峰没有任何关系,一切监控都正常。
原因:
经过N个小时排查,我们的小伙伴,终于发现问题还是出现在日志上,只不过这一次,是GC日志。
GC日志同样是在归档NAS上,此时归档NAS更加不稳定,minor gc日志写入,偶尔会遇到NAS IO延时,引起系统卡顿。
解决:
应用日志不再输出到归档NAS,而是输出到中端闪存NAS,花钱买平安。
进一步:
针对当前遇到的情况,重新制定日志规范,尽快推广落地。

3、一次RefreshScope引发的惨案
表现:
使用nacos动态刷新了一个配置,但相关服务突然越来越慢,并有大量的锁等待:sun.misc.Unsafe.park

原因:
初步分析,nacos更新配置后,对应RefreshScope的类需要重新加载配置,从而调用了GenericScope类的destroy方法,在该方法中加了writelock
同时,业务代码在处理请求的时候,同样的用到了GenericScope::LockedScopedProxyFactoryBean的invoke方法,在该方法中加了readlock
先是读锁(多个),再写锁(一个),再读锁(多个),最后死锁了,都无法获取锁,服务就卡住了。问题是,一开始的锁为何不释放呢?

进一步分析,发现是在服务业务代码中,用到了HttpClient的org.apache.http.impl.io.SessionInputBufferImpl.streamRead方法
该方法调用了java.net.SocketInputStream.socketRead,该方法触发了jdk8的一个bug,该native方法无法返回

解决:
升级JDK版本,同时代码改造缩小RefreshScope的范围

4、一次redis引发的惨案
表现:
几分钟内redis内存飙高,直接爆掉。
查看了业务系统日志,没有出现业务激增的情况。
查看redis日志,发现AOF日志不断增大,重写的时候缓存爆掉,导致主备切换。
监控日志反馈存在大量setex操作。

原因:
reids集群出现大量setex操作,导致AOF日志激增,日志重写时落盘速度缓慢(出现了short write),结果AOF日志缓存爆掉,主从切换

解决:
临时升级了内存,后续将日志盘从NAS改为SSD,并好服务的redis主从切换配置
但setex激增的原因暂时还没有查到,补充了一些防御性代码

5、一次jdk引发的惨案
表现:
一个生成表单PDF的微服务会产生大量的临时文件,而且不会自行清理。

原因:
在用到的一个第三方Jar包中,用到了java.awt.Font类,该类用到了createFont方法

//不会产生大量临时文件
static Font createFont(int fontFormat, File fontFile)
//会产生大量临时文件,初步判断是JDK的问题
static Font createFont(int fontFormat, InputStream fontStream)

解决:
重写了改Jar包的类,从InputStream切换到了File

6、一次防火墙引发的惨案
表现:
部分用户反馈,无法正常加载微信小程序,需要点击右上角进行刷新才行

原因:
从腾讯后台可以看到,有大约18%的请求会超过60S,其余正常
然后到微服务层,发现有一些请求,在返回数据包的时候,会收到“连结已断开”的反馈,与腾讯后台表现较为一致
然后向前一点儿一点儿的捋,最后发现,需要访问的腾讯IP有5个,之前开墙只开了4个,第5个IP数据返回时就被防火墙直接拦截了。

解决:
提单,开墙,解决问题

使用ChatGPT翻译了几本书

在2014年左右,一直想翻译几本小册子(主要是介绍编的程经验教训,内容其实很老了,但当时有些内容确实触动了我),陆陆续续翻译了其中的一些文章,但各种原因还是没能翻译完毕,算是一个小遗憾。

最近用ChatGPT硬翻了一遍,感觉效果还可以,感兴趣的朋友可以随便翻翻。

架构师应该知道的97件事【ChatGPT翻译版本,52篇】
https://github.com/neohope/97-things-every-software-architect-should-know.git

敏捷程序员应该知道的97件事【ChatGPT翻译版本,26篇】
https://github.com/neohope/97-things-every-agile-developer-should-know.git

程序员应该知道的97件事【ChatGPT翻译版本,97篇】
https://github.com/neohope/97-things-every-programmer-should-know.git

对比了一下自己翻译的版本:
1、最大的感触之一是质量的提升,比Goolge、NewBing翻译的都要好很多,十年前的翻译效果更是没法比
2、最大的感触之二是效率,175篇文章,加上编程、翻译及校对的时间,花了不到10小时(很多是零散时间),平均一篇文章3分半不到,比之前人工+Google的速度快了不止10倍
3、有些文章质量仍有待提升

还有一些感触:
1、虽然有些文章质量有待提升,但非专业领域翻译相关工作被替代可能性十分高大概率会被迫转型,专业领域翻译相关工作效率也会大幅增加大概率不需要这么多人力了
2、后续互联网客服、视频脚本编写、字幕翻译、新闻稿编写、文章编纂、律师助理等文字相关工作人员,会逐步面临更大职业压力
3、建议早点学会用AI提升个人生产力,淘汰不会用AI的人

微服务性能调优02

在各项目组努力下,终于达成了几个目标:
1、springboot升级到2.x
2、干掉了老技术中台,全部系统对接到新技术中台,实现了技术中台统一
3、填了一波史前巨坑

今年希望达到几个目标
1、科技降本600万
2、升级k8s到1.20
3、如果时间来得及,实现动态扩缩容
4、日常,继续填历史的技术坑

1、redis调优
数据流:
数据库查询结果-》缓存到redis-》缓存使用者
表现:
bigkey一大堆,单个key存放数据3M多(你咋不把整个JVM塞到redis里去呢),redis服务器所需内存、带宽都特别高
原因:
分析后发现,之前架构确定的技术方案有问题
解决:
a、改变序列化方式,从jvm序列化,调整为protobuff,调整后,带宽瞬间大幅下降
b、减少序列化的数据内容,只保存真正需要的,调整后,redis内存大幅下架,带宽大幅下降
c、对redis进行拆分,将一个大redis,按领域拆分为多个小redis,性能提升明显
d、对于热数据不明显的低频访问场景,不缓存到redis,大家慢慢优化去吧

2、网关调优
数据流:
外网请求-》外网网关-》外网鉴权-》内网转发-》内网网关-》内网鉴权
表现:
外网网关和内网网关功能一样,而且逻辑超级复杂,性能垃圾的一塌糊涂
原因:
分析后发现,之前架构确定的技术方案有问题
解决:
a、干掉外网网关鉴权内容
b、增加外网网关黑名单过滤、访问频率限制等功能
c、外网网关性能大幅提升

3、数据流优化
数据流(大幅简化后):
C系统-》数据中台-》逻辑加工-》H系统
Y系统-》数据中台-》逻辑加工-》H系统
H系统-》数据中台-》逻辑加工-》C系统
C系统-》数据中台-》逻辑加工-》H系统
H系统-》F系统
表现:
业务逻辑分散到各业务系统,数据来回传递多次,多个系统加工同一批数据,一旦出问题,要多个系统联查,花费很长时间才能定位到问题
原因:
分析后发现,之前架构确定的技术方案有问题
解决:
C系统-》Y系统-》H系统-》逻辑加工-》F系统
C系统-》数据中台
Y系统-》数据中台
H系统-》数据中台
在哪个环节出了问题十分清晰,用户自己都能初步定位到问题

4、数据修改请求超级多
数据流:
问题1、问题2、、、问题X-》老子就要修改数据-》提工单
表现:
数据质量差,任务都给到了IT,管理方没有管理动力,数据质量持续差,修改量逐年上升
原因:
分析后发现,各业务条线管控要求很多,不放权,与各地执行机构有轻度脱节
数据生产者,不承担数据质量差的职责,没有提升数据质量动力
总部管理部门,不承担数据质量差的职责,不清楚数据质量哪里差,没有工作重点
解决:
a、分析数据修改工单,归纳前几类修改请求
b、与业务方沟通,对分支机构可以修改的数据,将功能开放给各分支结构,定期公示修改量、业务影响程度等数据,作为总部管理部门的管理抓手
c、对于分支结构不可以修改的,开放数据修改功能给总部管理部门,进行统一管控,定期公示修改量、业务影响程度等数据,作为总部管理部门的管理抓手
d、数据质量与考核挂钩
e、数据质量快速提升,工单量大幅下降

5、降本
数据流:
应集团要求,降本压力巨大,科技承接了600万降本指标
表现:
科技方压力山大
原因:
一开始几年,没有这么大的压力,大家手都比较松,各条线都存在较大浪费,科技也是如此
最近几年,都是在之前资源上,不断的挤压资源,来满足每年业务快速增长的需要
今年,一方面业务继续快速增加,另一方面要大幅降本,压力山大
解决:
a、第一轮,运维小伙伴拉流量,无流量服务应关尽关,应下尽下,应合尽合
b、第二轮,运维小伙伴拉各类峰值,先统一砍一刀(网络、数据库、主机)
c、第三轮,运维小伙伴看账单,按账单大头,如网络、数据库、主机等逐条应用降本方案
d、第四轮,运维小伙伴看账单,对于不合理的条目逐条检视,逐个逐个扣
e、第五轮,各项目组,结合业务实际情况,各自制定降本方案,限时落地
f、第六轮,技术委员会,对于20%的关键业务进行性能优化,逐步降本
g、第七轮,在运维小伙伴推动下,实现自动扩缩容,继续降本