qysh123的专栏

但是GitHub这里说得比较简略了，具体怎么解决呢，在yaml文件的method那一部分加入：deepspeed: examples/deepspeed/ds_z3_config.json。如果需要微调比较大的模型，例如Qwen2.5-32B，那么在两个3090上可能不够用，这里我用A6000×4的服务器。呵呵呵，这个bug还不知道有什么办法能解决，现在对32B的模型可以这样，72B的就无能为力了。哪怕不加上微调模块，模型输出也是胡说八道（输出乱码）。ps：从loss看似乎没训练好，但是总是可以跑了。

其实到最后也没搞清楚，是其中一步起了作用，还是很多步综合起来起了作用。不过相信遇到类似问题的朋友按照我这种操作，应该还是可以解决这个问题的。这两天试了一下在Ubuntu上安装docker版本的Dify，说来惭愧，之前一直没怎么用过docker。碰到了一些问题，这里记录一下。这两篇博客都已经讲的比较详细了，我就不再重复了。首先我不知道为什么要加这么多源，难道大家就不能选几个有用的源？其次，发现加了之后依然没用。结果发现没有任何区别。

这个嘛，能通过这种方式装pytorch？由于PyTorch版本是1.13.0，那么CUDA还是先装11.7吧（参考我之前的博客。也就是说环境的问题基本上解决了。感觉发论文的这些学生脑子都是浆糊，就这还发表在顶刊上，只能说学术界太辣鸡了。就把下面几个装完了。然后试着运行一下pip install -r requirements.txt。类似，不得不说这些发论文的人都太不细心了，让人怎么相信你们的研究结论呢？我就想问候一下作者的家人，这是个什么鬼？不应该是下面这个吗？还是没有说python的版本。

仔细看一下作者的文件夹，有torch_persistent_homology和repo/torch_persistent_homology两个文件夹，但是这两个文件夹作者完全没有解释啊。关于第一个问题，虽然上面这个repo没有setup.py，但是TopoGDN的作者实际上是加上了setup.py的（虽然自己一句也没提起什么作用）。就简单记录这么多，想着有朋友可能会遇到类似的问题（不一定是一样的过程，但是解决思路是相似的），就简单记录一下。不得不说，这个repo的质量也太差了，呵呵呵。

这也是个很简单的问题，我简单总结一下，目前在家里有一台双3090涡轮版的PC，声音真的很大，可是很多时候我们其实并不需要其功率很好，只要显存够用就可以。看有些人说Ubuntu上现在不能设置，可是我在24.04上测试是可以设置的。另外，上面的文章往往只提到用一个GPU时的情况，我总忘记怎么指定两个卡。重启后需要重新运行。

然后再运行pip就可以正常安装了。感觉在国内装环境，百分之50的时间都是在处理和网络相关的问题，呵呵呵。

这样就指定了上下文长度为8192。

其实User，Group之类的都不需要修改，主要是要加上端口号才能正常运行。原本42GB的qwen2:72b变成49GB了，interesting，虽然大小只变化了一点，但在CPU上之后速度慢了很多。可以看到服务是active的。说起来这个问题真实让人无语。

在一个新的Ubuntu 24.04上安装Ollama，结果报类似于：curl: (28) Failed to connect to github.com port 443 after 136027 ms: Couldn't connect to server的错，想想可能还是网络的问题。则不能解决问题（和上面这些稍有不同，我这里查到的github.com的网址是：140.82.112.3）。发现这样确实可以解决问题。如果socks5代理应该这样写（我之前参考的这篇博客。发现这种方法依然不能解决问题。

例如我们在windows环境变量中可以把OLLAMA_KEEP_ALIVE改成1h，OLLAMA_NUM_PARALLEL改成2，就可以同时有两个并发访问，并且驻留时间为1h了（如果用ollama ps则会显示59 minutes）。如果要改驻留时间，就修改OLLAMA_KEEP_ALIVE，那这个环境变量是什么单位呢？

中间这句我注释掉了，可以用来设置http代理。运行以后出现图形界面——选择Models，然后就可以看到punkt，然后通过键盘上下键选择到punkt这一行，再点Download即可下载。这个问题本来不想记录，但是在好几个机子上都碰到了（用到了LangChain读Word文档）。

其中有两个是Deprecated的，而我们平时用到的HuggingFace的embedding model都基本以SentenceTransformer形式提供，我测试了一下，embeddings.huggingface.HuggingFaceBgeEmbeddings这个类是可以使用的，embeddings.huggingface.HuggingFaceInstructEmbeddings这个会报错，也没有仔细检查原因。经过测试，发现比Ollama自己的embedding模型的中文效果好多了。

我们构造数据集的时候，最简单的方法就是只构造instruction和output。当然，如果训练数据集比较小的话，测试的效果也不会太好。如果大家只是想对微调效果和特定问题进行展示，可以训练模型到过拟合，呵呵呵。训练完成后切换到Export，然后在上面的“微调方法”——“检查点路径”中选择刚才存储的目录Train_2024_xxxx之类，然后指定导出文件的目录，然后就可以导出了。不过这时候还没有模型参数文件，对于国内用户而言，可以在这里。选择自己的私有数据集，可以预览一下，然后就可以开始训练了。

现在只要有额度，大家都可以调用OpenAI的多模态大模型了，例如GPT-4o和GPT-4 Turbo，我一年多前总结过一些OpenAI API的用法，发现现在稍微更新了一下。其实也是比较简单的，就是本地图片需要用base 64先编码，然后再上传。当然，大家用的时候还是要注意花费，现在感觉还是有点贵的。

可以看到/usr/share/fonts/MyFonts（这个文件夹也是新增的）下有很多字体。很多朋友说把字体拷贝到matplotlib目录下，例如我这里：/home/quyu/anaconda3/envs/TranAD/lib/python3.8/site-packages/matplotlib/mpl-data/fonts，但是个人感觉应该放到上面这个fonts文件夹的ttf目录下。这看起来就很清楚了，另外，从这个json看，是不是不拷贝到ttf目录下也能找到？这个我没测试，感兴趣的朋友可以试试！

在MathType里输入，首先输入一个正常字母，选中——样式——其他——对话框里选择“Euclid Math One”即可。这篇博客只是简单记录一下。

pygraphviz/graphviz_wrap.c:3020:10: fatal error: graphviz/cgraph.h: 没有那个文件或目录。结果报错：requires pygraphviz http://pygraphviz.github.io/

不知道细节的朋友可以看看我之前的几篇博客。

因为GPT-4并不是人人可用的，所以目前gpt-3.5-turbo是最应该尝试使用的。

其实已经说得很清楚了，在生产环境中，务必通过环境变量加载API key。这样做也能使自己的代码更安全，更方便地和别人共享。即可以设置API key了，而且也不怕key通过代码泄密，只有能访问你操作系统的人（也就是你自己）才能看到。就可以看到你的API key了。

其次，如果在刚才第一个页面中点Sign up，然后登录，在右上角自己用户名的图标点一下，可以看到有“View API keys”，然后就可以创建或者使用自己已有的API key了。有趣的是，生成了的API key，第二次在网站上也看不到字符串了。可以在嵌入之前先计算一下序列的长度，但文档里并没有说超长了怎么处理，是截断还是直接不处理了呢。这样就会列出所有的model名字，不过大家应该注意，每一次API调用都是要收钱的，我也不知道打印个list需要收钱不，保险起见，不运行也可以。

然后按序号选择一个老的版本，再看version，果然已经变成低版本了。再重新安装torch-scatter，果然就好了。今天尝试使用别人一个项目（

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver的一种简单解决方法

【代码】使用Python Seaborn绘制热力图（heatmap）的时候怎么改变配色。

经过网友的提醒，我发现现在的Joern确实可以处理Java源码了，这里简单介绍一下，在一台新的Ubuntu 22.04系统中怎么使用Joern。

定义好writer之后写每一行就可以了：writer.writerow(row)可以看到这个参数默认使用。

来看，目前（2022年11月），PyTorch稳定版本是1.13.0，而从第二个网页来看，PyG最多支持的PyTorch版本是1.12.*，所以应该安装更老一点的PyTorch。另外，从上面两个网页来看，最好是全都使用conda安装。也会报“段错误 (核心已转储)”。捜了一下，发现主要是因为PyTorch和PyG的版本不对应所致。大家都提到要注意PyTorch和PyG的版本的对应。发现都通过Conda安装后，是可以解决上面的“段错误 (核心已转储)”的报错的。怎么感觉PyG的开发有点滞后了呢？

会直接提示：Failed to verify gcc version. 安装gcc后，不用做降级，就可以直接运行了。安装方式也变多了很多。我之前的博客也已经写得很清楚了。

目前发现下面这个方法是最简单的，所以简单记录一下：其实删掉.pyc文件即可，但有时候由于anaconda之类的存在，我们都不太好定位到底是哪里的.pyc文件出了错，解决方法也很简单，在一个大的目录下，终端打开，运行：

我也是同感，不教会别人怎么用，说那么多有什么意义？第一个\normalsize指定了圆圈的大小，后面一个\normalsize是为了使正文中的其他字体恢复正常。如果使用\textcircled，数字编号大的时候，数字会跑到圆圈外面。最后给出一个具体示例，大家看看便知，再吐槽一下，写博客是为了帮助大家解决问题，不是炫自己的知识，第一篇博客我看了好久，还是不会用。小四号 　12pt 　　　　4.2175mm　　　 \normalsize。四号 　　13.75pt 　　 4.83mm　　　　 \large。

这个问题我已经碰到过很多次了。先说一下原因：我们提交会议论文的时候，如果不设置，一般是没有页码的。但是从审稿人和控制页数的角度，都是加上页码以后方便（例如Reviewer直接说Page X有YYY问题）。这样第一页是没有页码的，但是并不妨碍Reviewer的工作。

不过遇到新的需求的时候，还是想记录一下。不过因为只是简单记录，所以这篇博客很水。就简单总结这么多，应该说我对Scrapy这个爬虫的使用算是相当了解了。

不得不说，和上面相比，差别有点大啊（例如：tokenizer = Tokenizer(WordLevel())，以及必需要加tokenizer.pre_tokenizer = Whitespace()这一行）。其实这个问题应该是很好解决的，想不到竟然花了3个多小时。我去，这个原因我也是醉了，所以最后手动建立一个空白的merges.txt文件，然后就可以正常保存和使用这个tokenizer了。从之前说的RoBERTa的示例代码可以知道， 需要再重新加载的tokenizer需要在一个文件夹下，所以这个也不行。

从上面的输出中可以看到，encoded['input_ids']对应的就是输入到transformer encoder的tensor输入，.tokens()返回的是tokenize以后的token，.word_ids()返回的是tokenize以后的token的编码（而并不是输入sequence的）。为了展示方便，省略了之前很长的那些print，可以看到，最后生成的这个word_2_token_mapping是完全正确的。，这个和API文档里说的完全不一样啊。，这个表明的是在原输入序列中的位置。

​这篇博客很简单，接上一篇：在Ubuntu上安装并运行DeepProbLog的简单过程_蛐蛐蛐的博客-CSDN博客。其实要运行ProbLog代码是相当简单的，如上一篇博客中所说的，首先安装engine：​

可以通过binary形式安装，照着输入命令就可以了，然后再运行pythonaddition.py，发现就可以正常开始训练了。，原来是个Prolog的engine，想不通，我只想运行一下这个model，为啥还要装Prolog呢，这个model不是基于Problog的吗？就是论文里说的图像数字相加的例子。这篇博客只是简单记录一下，没什么技术含量。...

这篇博客只是简单记录和吐槽一下。Datalog Disassembly发表于USENIX Security 2020。GitHub repo是：GitHub - GrammaTech/ddisasm: A fast and accurate disassembler看到其repo上说所以试一下怎么通过安装这个GTIRB来安装Datalog Disassembly：GitHub - GrammaTech/gtirb: Intermediate Representation for Binary analysi

这个问题说来比较绕，主要是因为我系统上的node.js版本太低了，想安装新的版本，参考这里的说明：https://github.com/nodesource/distributions/blob/master/README.md首先输入：结果就报了下面的错：我这里特别想吐槽一下：这个源不能用就不用了呗，为啥就exit了，这是什么傻叉逻辑？？？于是得想办法解决这个报错。看到一些朋友说是加入签名，更新/etc/apt/sources.list文件，删除软件源等等（例如：sudo apt-get updat

这已经是这个系列的第四篇博客了（上一篇是怎样用O0来（尽可能地）编译Linux Kernel_蛐蛐蛐的博客-CSDN博客），但是还是很多问题没有解决。上一篇博客中说了用O0编译的方法，但是O0编译的很不全，还是有报错，我也没有精力挨个去解决error，想着O1似乎也可以用，就想试试，找了找，可以参考这篇博客里的方法：如何在编译linux内核时不优化内核以便于调试内核?_weixin_30662109的博客-CSDN博客具体而言，还是先将Makefile中的O2，O3，Os等等都改成O1，其次，按照上面

这篇博客接前面两篇：在Ubuntu上编译特定版本的Linux Kernel_蛐蛐蛐的博客-CSDN博客和怎样编译Linux Kernel中的尽可能多的源码_蛐蛐蛐的博客-CSDN博客。有时候我们想尽量用O0来编译Kernel，以进行一些后续分析，但是就像上面第二个链接中说的，基本上用O0编译是很难的。我主要参考了一下这篇博客：使用-O0编译Linux内核_玉双龙的博客-CSDN博客首先，将makefile中的O2，O3，Os都改成O0。（我这里依然以v5.12-rc2为例）其次然后这时候就会有下