由于我只有一台内存 2G 的云服务器，上面也部署了一些 Docker 服务，加上近期启用了 n8n 实例，导致内存频繁达到 90% 的告警线：
虽说我可以把告警上调至 95% 来避免这个问题，但是内存不足的问题并没有得到实际解决。于是稍微查了下服务器中哪些 Docker 服务比较占内存：
尽管 n8n 占用的内存是最多的，但是我在上面搭建了一些工作流和接口服务，所以是必要的，无法被替代。其它的服务要么也是不可替代，要么占用内存极低，所以最显眼的就是 uptime-kuma 了。尽管它占用的内存严格来说也不算特别多，但谁叫我服务器内存不够呢😂，而且 uptime-kuma 是一个网络服务健康检测的工具，功能不算很复杂，但内存也是轻松超过 100M（据说是 nodejs 的锅，因为我部署的一些其它自带前后端的 Docker 服务，采用 Go 写的，内存就只有不到 30M）。
虽然 Uptime Kuma 的界面简洁，用来检测服务和证书的状态也很方便，但是现在也只能说再见了
现在很多 OCR 模型实际上已经支持了一定程度内的旋转文本的识别，即图片中的非水平方向的文本可以正确识别其方向并按照正常的水平顺序返回该文本；但这仅限于每一个 Bounding Box 内的文本，因为 OCR 模型一般原始输出都是从图片中获取一个个单独的文本区域——即 Bounding Box，然后识别该区域的文本，并不会对这些 Bounding Box 进行拼接得到按正确顺序返回的完整文本，如：
从图中右侧不难发现哪怕图片中的文本有一些旋转，OCR 模型也可以识别出这些文本块的方向，并返回正确的文本顺序；但是如果要以正确的顺序（从左至右，从上至下）返回所有的文本行，就需要自己去处理了。
一般来说，我们可以假设图片中的文本旋转方向都是一样的（适用于常见的单页文本拍照或者扫描件），因此只需要得到一个整体的旋转方向，然后基于这个方向进行一个逆运算即可得到正常水平方向的 Bounding Box 位置，也就能拼接得到视觉层面上正常顺序的完整文本了。
bge-m3 是由 BAAI 在 2024 年推出的一个比较经典的 Embedding 模型，是一个支持多语言的 Embedding 模型，除此之外，它还支持输出稀疏向量和 ColBERT 向量，因此用途比较广泛。按照目前 AI 模型的发展速度（竞争很激烈），这个推出了一年多的模型理应算是个老古董了，实际上到目前为止（2025-9-20），该模型还能在 MTEB Leaderboard 榜单上保持在第 23 位的位置，且在 hugging face 上的月下载量保持在五六百万之多：
不过话又说回来，这大概率是因为 Embedding 模型还没有隔壁 LLM 那么卷，2025 截至目前也就阿里推出的 Qwen3-Embedding 模型很有竞争力；
其实本来只打算写一下我是如何通过自定义材质来实现特定场景下突破 UBO 数量限制的，但是写着写着发现很有必要捋清楚 Babylonjs 内部着色器预编译的机制，不然连我自己都不清楚我为啥要这么做🙈。
虽然我之前确实对 Babylonjs 的源码做过一些分析记录，但总体比较零散，完全无法在脑海中形成一个系统性的、清晰的流程。所以这次我就把 Babylonjs 的仓库 clone 到本地，使用 Cursor 将其作为本地知识库进行详细的源码分析，得到了多份分析报告文档，基于这些文档我才对 Babylonjs 内部一些机制有了更详细和全面的了解。
而这些报告文档我都放到了 Github 上，感兴趣的可以去看一看，我觉得从里面确实可以学到不少关于 Babylonjs 源码的思路。
我前不久独自开发了一个 在线3D展览 的项目，该项目的主要需求就是渲染展厅模型及展厅中的大量展品，也包含大量用来给展品打光的聚光灯。