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

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

网络拓扑

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

架构核心思想

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

…

前言

随着大语言模型（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 的部署方案和一些实用的配置技巧。

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

最近 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.