[All In One] HomeLab 虚拟化 iKuai + Mihomo

本文思路基本遵循 iKuai与Openwrt的有机结合:传统旁路由方案的完美替代,主要差异点如下:

  • 虚拟化平台: unRaid 替换为 Proxmox VE (PVE)
  • 透明网关: OpenWRT 替换为 Debian + Mihomo
  • DNS 服务: paopaodns 替换为 SmartDNS + AdGuard Home 组合

网络拓扑

为方便描述,下文统一将处理出站流量的虚拟机称为透明网关 (gateway)

架构核心思想

本方案采用“主路由 + 透明网关”的模式。iKuai 作为主路由,以其出色的稳定性、多线负载和流控能力负责整体网络的 DHCP、NAT 和流量调度。透明网关则是一个专职处理特定流量(如国际流量)的“处理器”。iKuai 通过策略路由(PBR)将特定流量“扔”给透明网关处理,处理完毕后再由透明网关“扔”回给 iKuai,由 iKuai 统一出口。这种架构实现了功能解耦,稳定性和灵活性兼得。

LiteLLM 多模型 API 中转

前言

随着大语言模型(LLM)应用场景的不断扩展,管理和统一调用多个 AI 模型接口的需求日益突出。目前市面上有多种解决方案,每个都有其独特的优势和适用场景:

  • one-api/new-api: 这类项目提供完整的 Web UI 界面,支持多用户管理、使用量统计等功能,适合团队或小型组织使用。
  • uni-api: 采用 Provider-First 的配置思路,通过简单的配置文件启动,特别适合个人用户快速配置多个模型服务。
  • openrouter: 作为一个集中式的 AI 模型网关,支持多个主流服务商,但对某些区域性服务(如国内的 siliconflow)支持有限,且无法配置同一服务商的多个账号。
  • LiteLLM: 既可作为 SDK 使用,也可作为独立的 LLM Gateway 部署。采用 Model-First 的配置方式,虽然在多模型配置上略显繁琐,但提供了更细粒度的模型控制能力,而且代码质量也比 uni-api 更好。

所以我使用了一段时间的 new-api 和 uni-api 之后,现在切换到 LiteLLM。本文将介绍 LiteLLM 的部署方案和一些实用的配置技巧。

MacOS Bootstrp with Nix

最近更换了 M4 Pro 的 MacBook Pro,面临着重新配置开发环境的挑战。虽然我之前已经在 dotfiles 项目中维护了 tmux、alacritty 和 neovim 等工具的配置,但实际上还有许多其他组件需要重新设置。起初我考虑编写一个 setup 脚本来自动化这个过程,但在研究过程中接触到了 Nix 这个声明式的包管理器,它的设计理念让我眼前一亮。

Fluency Support Full Rss

最近 Follow 这个内容浏览器十分热门, 我把自己博客添加进去后发现 Hugo 的 RSS 默认并没有全文输出.

所以给当前在用的 Fluency 主题增加了一个可选配置,可以开启全文 RSS 输出.

又水一篇.

This message is used to verify that this feed (feedId:55671961817022580) belongs to me (userId:67409085208279040). Join me in enjoying the next generation information browser https://follow.is.

[All In One] PVE 中 OpenWrt LXC 重启问题

从去年开始,我的 OpenWrt 是安装在 PVE 中的 LXC 容器中,但一直以来都有一个问题,OpenWrt 关机后就无法再次启动了。

我是将 enp6s0(有线网卡)、wlp2s0(无线网卡)硬件直通给 LXC 容器:

lxc.net.0.type: phys
lxc.net.0.link: enp6s0
lxc.net.0.flags: up
lxc.net.1.type: phys
lxc.net.1.link: wlp2s0
lxc.net.1.flags: up

查看 LXC 的启动日志发现网卡重命名失败: