本周精选 · 第4期 — 本地AI部署全链路：从推理引擎到交互界面的5个核心开源项目
又到周六。这周我连着写了几篇硬核教程——从 …
又到周六。这周我连着写了几篇硬核教程——从 Proxmox GPU 直通到 5G 模组备份链路，基本把 Homelab 跑 AI 的底层架子搭起来了。那架子搭好之后，上面该跑什么？这期精选就来捋一捋：从模型推理到前端交互，本地 AI 部署全链路上一共需要哪些开源项目，以及它们各自卡在哪个环节。
1. Ollama — 本地 LLM 推理的”一键安装”
如果你只想在本地跑个大模型聊聊天，Ollama 就是最省心的选择。一行 curl 命令装完，然后 ollama run qwen2.5:14b 直接开聊。它自带模型管理、量化支持、GPU 加速（自动检测 CUDA/ROCm），还暴露了兼容 OpenAI 格式的 REST API。
适合场景：个人使用、快速验证、小团队共享。不适合：高并发生产环境（这时候该上 vLLM 了，但那是另一个话题）。
# 安装（Linux）
curl -fsSL https://ollama.com/install.sh | sh
# 拉一个 14B 模型，大概占 9GB 显存
ollama pull qwen2.5:14b
# 启动 API 服务（默认 11434 端口）
ollama serve
# 另一个终端测试
curl http://localhost:11434/api/generate -d '{
"model": "qwen2.5:14b",
"prompt": "用一句话解释什么是 PCIe passthrough"
}'一个小坑：Ollama 默认只在 127.0.0.1 监听。如果要从内网其他机器调用，记得设环境变量 OLLAMA_HOST=0.0.0.0，或者前面套一层 Nginx 反代——安全第一，别直接把推理端口暴露到公网。
2. Open WebUI — 把本地模型包装成 ChatGPT 体验
Ollama 的命令行虽然能用，但让人正经聊天还是得有个界面。Open WebUI 是目前社区最活跃的 LLM 前端，界面长得跟 ChatGPT 几乎一模一样：多轮对话、Markdown 渲染、会话管理、RAG（文档问答），应有尽有。
它默认对接 Ollama 的 API，也支持 OpenAI 兼容接口。Docker 一条命令跑起来：
docker run -d -p 3000:8080 \
-v open-webui:/app/backend/data \
-e OLLAMA_BASE_URL=http://192.168.1.100:11434 \
--name open-webui \
ghcr.io/open-webui/open-webui:main如果你的 Ollama 和 Open WebUI 跑在同一台 Docker 主机上，OLLAMA_BASE_URL 可以直接用 http://host.docker.internal:11434，省得配 IP。
3. LiteLLM — 一个 API 入口，调度所有模型
当你手上有多个模型——一台机器跑 Ollama 的 Qwen、另一台跑 vLLM 的 DeepSeek、还有云端 OpenAI 的 API Key 备用——每个调用方都要记住不同地址和 Key，这体验很糟糕。
LiteLLM 就是来解决这个问题的：它充当一个统一代理层，把所有模型提供商的接口都转成 OpenAI 格式。你只需要记住 LiteLLM 的地址，客户端不用改一行代码。
# litellm_config.yaml
model_list:
- model_name: qwen-fast
litellm_params:
model: ollama/qwen2.5:14b
api_base: http://192.168.1.100:11434
- model_name: deepseek-pro
litellm_params:
model: openai/deepseek-chat
api_key: sk-xxxx
- model_name: gpt4-fallback
litellm_params:
model: openai/gpt-4o
api_key: sk-yyyy
# 启动
docker run -d -p 4000:4000 \
-v ./litellm_config.yaml:/app/config.yaml \
ghcr.io/berriai/litellm:main-latest \
--config /app/config.yaml然后所有客户端统一指向 http://litellm:4000，model 参数填 qwen-fast、deepseek-pro 之类的别名就行。内置了速率限制、负载均衡、成本追踪，Homelab 级够用了。
4. ComfyUI — 图像生成的”工作流引擎”
AI 不只是聊天。Stable Diffusion 系的图像生成在本地同样跑得飞起。ComfyUI 是目前最主流的节点式图像生成工具——把模型加载、提示词编码、采样器、VAE 解码等每一步都拆成可拖拽的节点，可视化编排。
和 Automatic1111 WebUI 比起来，ComfyUI 最大的优势是工作流可复用：别人调好的 workflow JSON 你导进来就能用，显存利用率也更高。对多 GPU 场景尤其友好——你可以把文本编码器放 GPU 0、UNet 放 GPU 1。
# 安装（建议用 venv 或 conda 隔离）
git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI
python -m venv venv && source venv/bin/activate
pip install -r requirements.txt
# 把模型放到 models/checkpoints/ 下
# 启动，默认 8188 端口
python main.py --listen 0.0.0.0 --port 8188注意：如果你是用 Proxmox GPU 直通跑 ComfyUI，显存分配要留余量。14B 的 LLM 和 SDXL 模型同时跑，16GB 显存就有点吃紧了——分两台机器各干各的，体验会好很多。
5. Langflow — 拖拽式 AI 应用编排
当你不只是想聊天或生成图片，而是想搭一条自动化流水线——比如”抓取 RSS 摘要 → 用 LLM 翻译 → 存入 Notion”——这时候就该 Langflow 出场了。
它本质是 LangChain 的可视化前端，把 Prompt 模板、LLM 调用、向量检索、API 请求等组件都抽象成可拖拽的节点。搭好流程后可以一键导出为 Python 代码或直接暴露成 API。比手写 LangChain 代码快 10 倍，调试也直观得多。
docker run -d -p 7860:7860 \
-v langflow-data:/app/data \
langflowai/langflow:latest启动后浏览器打开 7860 端口，拖几个节点、连上线，一个 RAG 问答机器人或者翻译流水线就搭好了。对于不想写胶水代码的场景，这玩意儿省下的时间非常可观。
全链路串联起来
如果把上面五个项目串在一起，你的本地 AI 工作站大概是这样的：
- 底层推理：Ollama 跑 LLM，ComfyUI 跑图像生成
- 统一网关：LiteLLM 把 Ollama + 云端 API 包成统一入口
- 交互层：Open WebUI 提供聊天界面，Langflow 搭建自动化流水线
- 基础设施：Proxmox 做虚拟化隔离，5G 模组做备份链路，Nginx 做反代
这一套全跑在 Homelab 里，数据不出门、延迟个位数、每月零 API 费用——这就是本地优先的价值。
下周我会开始拆解其中几个项目的进阶玩法，包括 Ollama 多机负载、LiteLLM 的 fallback 策略、以及 ComfyUI 的 LoRA 热加载。感兴趣的可以蹲一下。
以上就是本周精选第 4 期。老规矩，有问题评论区聊。
——IT大叔，2026.08.08
