Hi there 👋

前言 最近一直在搞各种大模型 API 中转服务，为了能用上低价甚至免费的 API，我真是煞费苦心，尝试了各种方案： 自搭建 GLM-5.1-w8a8 模型，使用 vllm + litellm 提供 API 接入服务 购买便宜的 Deepseek v4 pro 的 API 在各种二道贩子、小众平台上购买 GPT 号、搭建 GPT 号池并最终反代出 Codex API 参与学校的 token plan，拿到免费的 Deepseek v4 pro 和 qwen3.6 的 API 接入 Nvidia 自部署并且可以免费使用的各种模型的 API 从熟悉的同学那里求来用不完或者免费的 API 额度 但是随着服务数量的增多和额外需求的增加，我同时也重构了我现在的在校服务器搭建和配置方案，因此在此分享一下我的方案，提供一种可行的思路。 背景 在正式讲述我的搭建方案前，我需要声明一下我所拥有的资源情况： 一台位于宿舍由主机改造而来的小型服务器 特点：4 核心、8g ddr4 内存、512g 固态硬盘、千兆网卡 限制：宿舍晚上 23:30 熄灯，直到早上 6:00 才上电自动开机，因此无法熬夜使用 一台校内 Vlab 平台提供的 kvm 虚拟机 特点：2 核心、6g 内存、16g 机械硬盘、千兆网卡 限制：性能一般，尤其是磁盘随机读写性能较差，只能跑一些简单的服务，而且伴有由于维护带来的强制重启和停机的风险 一台位于香港的轻量级 VPS ...

前言 通常，代理通常有两种方式，一种是开放端口，让需要代理的应用主动通过暴露的端口被代理访问远程服务；一种是使用 tun mode，即虚拟网卡模式，所有流量都会被虚拟网卡设备拦截从而被动代理访问远程服务。 对我来说，我并不希望在我的服务器上采取被动方式，因为它会对服务器上的所有应用产生影响，而且一旦代理软件崩溃退出，我将无法访问互联网，而且会影响比如 ping 等工具的执行（拦截 ICMP 数据包），这是极其不好的，因此平时在我的服务器上，我更倾向于使用主动方式，只有应用需要被代理才会主动去访问代理端口。 说是主动，也并不完全主动，无非就是设置环境变量： export http_proxy=http://127.0.0.1:7890 export https_proxy=http://127.0.0.1:7890 但是，对于 Docker 来说，通过设置环境变量的方式来配置代理会非常麻烦，如果不使用 docker compose，每次运行 docker run 的时候都需要输入长长的一串环境变量；如果使用 docker compose，要修改的部分也非常多，如下所示： services: app: image: my-app environment: - HTTP_PROXY=http://host.docker.internal:7890 - HTTPS_PROXY=http://host.docker.internal:7890 - NO_PROXY=localhost,127.0.0.1 extra_hosts: - "host.docker.internal:host-gateway" # only for linux 除此之外，使用主动代理还有其他弊端： 如果 docker compose 中有多个 service，你可能需要花费功夫判断哪些 service 需要代理，哪些不需要代理。 如果镜像中的应用不支持通过环境变量配置代理，那么以上配置就完全无效了。 最重要的，在 docker build 的过程中，Docker 会起一个临时容器来运行 dockerfile 中的命令，而在这个过程中，如果没有配置代理或镜像，那么一些基本的命令，比如 apt update、apt install 以及 pip install 等等，就会导致镜像构建缓慢，非常折磨人，而在 dockerfile 中配置代理也是一个非常麻烦的事情，很多时候都是发现 docker build 执行缓慢或者失败的时候才想到要配置代理，浪费大把时间。 ...

前言 不久之前，我接手了一套服务器集群，这个集群由一个登录节点和多个计算节点组成，其中登录节点可以通过外网访问，而计算节点只能通过登录节点跳板访问。 拿到手，我最先做的便是探查一下这个集群的网络架构，而在我排查过程中，我发现登录节点 80 端口上开了一个 HTTP 访问，是用于计算节点资源管理的后台管理平台，不足为奇。 但是我有点好奇，想看一下这个 80 端口运行的那个服务是哪个进程管理的，顺便也能看一下这个管理平台是如何搭建起来的。 然后，按照运维的惯例，执行以下几个命令来查找对应进程： lsof -i :80 netstat -tlnup | grep :80 ss -tlnup | grep :80 并不奇怪，输出结果显示： $ netstat -tlnup | grep :80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3202/nginx: master 即，80 端口是一个 nginx 进程在提供服务，但是我们知道，管理平台不是静态网页，nginx 大概率是一个反向代理的作用。 因此，我打开了 /etc/nginx/nginx.conf 查看一下 80 端口具体代理了哪里的网络服务（省略无关配置）： stream { server { listen 80; proxy_pass 172.20.2.31:80; } } 看样子代理了 172.20.2.31 这个计算节点上 80 端口的服务。 接着，我 ssh 连接上了这个节点，同样使用惯例的指令查询 80 端口上的服务，但是这一次，奇怪的事情出现了，终端里什么输出都没有，也就是说，“没有”任何进程在 80 端口上服务？ ...

前言 从大二上计算机组成原理的时候我就想写一篇这样的文章了，当时我调研了 x86 架构平台的计算机的启动过程，意识到很多人实际上并不是非常了解一台计算机从上电到进入桌面的全过程。 虽然网上有很多关于计算机启动过程的文章，结合了具体的系统，甚至制作了精美的动画，但是我觉得它们为了讲解的清晰，往往省略了实际执行的指令细节，导致理解启动原理和实际安装系统之间仍存在一定的距离。 因此，本文我将以 x86 架构为例，结合 Arch Linux 系统的安装过程来讲解计算机的启动过程。 背景 基本流程 虽然很多文章已经讲解过计算机的启动过程了，但是为了便于不了解计算机原理的读者理解，我还是想先介绍一些背景知识。 除了某些嵌入式（Embedded）系统以外，大多数计算机都采取类似的启动过程，如下图所示： 图 1 计算机启动过程 ...

前言 Typst 一直以来都是我非常喜欢的一个排版工具，相比于 LaTeX，Typst 的语法简单，编写体验好；相比于 Markdown，Typst 的功能强大，标准统一，符合我对排版工具的所有想象。 自从我接触到 Typst 之后，不仅我的日常的作业、报告、简历等文档都使用 Typst 写的，而且我也开发了一个 Typst Package 用于在 Typst 中绘制树状图，比如二叉树、红黑树、语法树等等 —— tdtr (i.e. tidy tree)，感兴趣的话可以看看。 因此，我一直想在我的 Blog 中使用 Typst 来编写文章，但是苦于 Typst 对 HTML 导出的支持仍然处于实验性阶段，因此搭建 Blog 的想法也一直一拖再拖。 但是，直到最近，我对于搭建 Blog 的需求越来越迫切了，所以我就决定不再等待 Typst 对 HTML 导出的支持了，而是自己动手来实现这个功能。这篇文章讲述的就是我如何实现在 Hugo 中使用 Typst 编写文章的。 Blog 的源代码位于 github.com/Vertsineu/blog，欢迎 star 和 fork。 使用 如果你也想像我的 Blog 一样使用 Typst 来编写基于 Hugo 的 Blog 的话，可以按照以下步骤来操作： 首先安装我修改过的 Hugo，目前还没有发布版本，因此需要手动编译安装： 首先，clone 下来我修改过的 Hugo 的代码，并切换到 support-typst 分支，即： ...