本地多模型切换利器——Llama-Swap全攻略

本地多模型切换利器——Llama-Swap全攻略

运行多个大语言模型(LLM)非常有用:
无论是用于比较模型输出、设置备用方案(当一个模型失败时自动切换)、还是实现行为定制(例如一个模型专注写代码,另一个模型专注技术写作),实践中我们经常以这种方式使用 LLM。

一些应用(如 poe.com)已经提供了多模型运行的平台。但如果你希望完全在本地运行、多省 API 成本,并保证数据隐私,情况就会复杂许多。

问题在于:本地设置通常意味着要处理多个端口、运行不同进程,并且手动切换,不够理想。

这正是 Llama-Swap 要解决的痛点。它是一个超轻量的开源代理服务(仅需一个二进制文件),能够让你轻松在多个本地 LLM 之间切换。简单来说,它会在本地监听 OpenAI 风格的 API 请求,并根据请求的模型名称,自动启动或停止对应的模型服务。客户端无需感知底层切换,使用体验完全透明。


📌 Llama-Swap 工作原理

概念上,Llama-Swap 就像一个智能路由器,位于多个 LLM 服务进程之前。
当 API 请求到达(如 POST /v1/chat/completions),它会检查 JSON 里的 "model" 字段,加载对应的服务进程,如果需要,还会停止其他已经运行的模型。

例如:

  • 先请求模型 A,再请求模型 B
    → 代理会自动关掉 A 的进程,再启动 B,让每次请求都由正确的模型响应。

默认情况下,Llama-Swap 每次只允许运行一个模型。但它的 Groups 功能 可以调整:

  • swap: false → 组内的多个小模型可以同时运行,不会互相卸载
  • 大模型组 → 每次只启动一个,节省资源
    这样你可以灵活掌控系统资源与并发能力。

📌 环境准备

确保系统具备以下条件:

  • Python 3 (>=3.8):用于脚本和工具。
  • llama.cpp (llama-server):兼容 OpenAI API 的服务程序。
  • 硬件:现代 CPU 足够;GPU 可加速。
  • Docker(可选):运行预构建镜像,x86 更佳,Apple M1/M2 建议裸机安装。

Hugging Face CLI:便捷下载模型文件:

pip install -U "huggingface_hub[cli]" 

Homebrew(macOS):快速安装运行环境,例如:

brew install llama.cpp 

提供 llama-server 二进制文件来运行本地模型。


📌 分步操作

1. 安装 Llama-Swap
curl -L -o llama-swap.tar.gz \ https://github.com/mostlygeek/llama-swap/releases/download/v126/llama-swap_126_darwin_arm64.tar.gz tar -xzf llama-swap.tar.gz chmod +x llama-swap ./llama-swap --version 
2. 下载示例模型

SmolLM2-135MQwen2.5-0.5B 为例:

mkdir -p ~/llm-models huggingface-cli download bartowski/SmolLM2-135M-Instruct-GGUF \ --include "SmolLM2-135M-Instruct-Q4_K_M.gguf" --local-dir ~/llm-models huggingface-cli download bartowski/Qwen2.5-0.5B-Instruct-GGUF \ --include "Qwen2.5-0.5B-Instruct-Q4_K_M.gguf" --local-dir ~/llm-models 
3. 配置文件(config.yaml)
models: "smollm2": cmd: | llama-server --model /path/to/models/llm-models/SmolLM2-135M-Instruct-Q4_K_M.gguf --port ${PORT} "qwen2.5": cmd: | llama-server --model /path/to/models/llm-models/Qwen2.5-0.5B-Instruct-Q4_K_M.gguf --port ${PORT} 
4. 启动 Llama-Swap
./llama-swap --config config.yaml --listen 127.0.0.1:8080 
5. 调用 API 测试

👉 使用 Qwen2.5

curl -s http://localhost:8080/v1/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer no-key" \ -d '{ "model": "qwen2.5", "prompt": "User: What is Python?\nAssistant:", "max_tokens": 100 }' | jq '.choices[0].text' 

👉 使用 SmolLM2

curl -s http://localhost:8080/v1/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer no-key" \ -d '{ "model": "smollm2", "prompt": "User: What is Python?\nAssistant:", "max_tokens": 100 }' | jq '.choices[0].text' 

不同模型输出风格不同:

  • Qwen2.5 → 更技术性、更详细
  • SmolLM2 → 更简洁直观

📌 结论

恭喜!你已在本地成功配置 Llama-Swap,实现双模型动态切换。
你可以扩展更多模型(如 TinyLlama、Phi-2、Mistral),并结合 LangChain、FastAPI 等框架,打造强大的个性化应用环境。

Read more

前端趋势:别被时代抛弃

前端趋势:别被时代抛弃 毒舌时刻 这代码写得跟博物馆似的,都是过时的技术。 各位前端同行,咱们今天聊聊前端趋势。别告诉我你还在使用过时的技术,那感觉就像在 5G 时代还在用 2G 网络——能用,但慢得要命。 为什么你需要关注前端趋势 最近看到一个项目,还在使用 React 16,不知道 React 18 的并发模式。我就想问:你是在做开发还是在做考古? 反面教材 // 反面教材:使用过时技术 // App.jsx import React, { useState, useEffect } from 'react'; function App() { const [data, setData] = useState([]); const [loading, setLoading] = useState(true)

前端也需 OOP 思维!面向过程 vs 面向对象开发,90% 的人没搞懂

前端也需 OOP 思维!面向过程 vs 面向对象开发,90% 的人没搞懂

前端也需 OOP 思维!面向过程 vs 面向对象开发,90% 的人没搞懂 今天遇到个挺有代表性的事:我吭哧吭哧写完一个需求,领导 review 代码时说:“你这是面向过程开发的,得用面向对象的思维来写。” 我当时就懵了——前端 JS/TS 里,面向过程和面向对象到底有啥区别?不都是写函数、调 API 吗? 直到我把两段代码摆在一起对比,才恍然大悟。 一个真实场景:用户订单处理 假设我们要处理用户订单,计算价格、验证库存、生成记录。 ❌ 面向过程写法(我最初写的) // 一堆函数,数据到处传递functioncalculateTotal(price:number, quantity:number, discount:number):number{return price * quantity *(1- discount);}functioncheckStock(

Token分析平台系统架构设计:从前端到核心逻辑的全景解析

导读:在上一篇文章中,我们提出了构建Token分析与成本优化平台的愿景——让企业每一分AI成本都清晰可见。但一个好的系统离不开扎实的架构设计。本文将深入剖析该平台的系统架构,从前端交互界面到后端核心逻辑,带你了解如何用FastAPI、Tiktoken、Plotly等工具搭建一个可扩展、高性能的成本监控系统。无论你是架构师还是开发者,都能从中获得可落地的设计思路。 一、引言:为什么需要清晰的架构? 在开发Token分析平台时,我们面临的挑战包括: * 如何高效处理大量日志写入? * 如何快速查询和聚合数据? * 如何让前端图表响应流畅? * 如何保证系统的可扩展性? 回答这些问题,需要一个清晰的、分层的系统架构。本文将基于三层架构模型——前端/客户端层、应用层、核心逻辑与处理层,详细拆解每一层的职责、技术选型和交互方式。 二、整体架构概览 下图展示了平台的系统架构: ┌─────────────────────────────────────┐ │ FRONTEND / CLIENT LAYER │ │ ┌────────────────────────────

Flutter 三方库 arcade 的鸿蒙化适配指南 - 实现高性能的端侧 Web 框架、支持轻量级 HTTP 路由分发与服务端逻辑集成

Flutter 三方库 arcade 的鸿蒙化适配指南 - 实现高性能的端侧 Web 框架、支持轻量级 HTTP 路由分发与服务端逻辑集成

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 arcade 的鸿蒙化适配指南 - 实现高性能的端侧 Web 框架、支持轻量级 HTTP 路由分发与服务端逻辑集成 前言 在进行 Flutter for OpenHarmony 的全栈式开发或特定的边缘计算场景,我们有时需要在鸿蒙应用内部直接启动一个功能完备但又极其轻量的单文件 Web 服务器。arcade 是一个主打微核心设计的 Dart 服务端框架。它能让你在鸿蒙真机上以最少的内存占用,快速运行起一套处理 REST 请求的逻辑中心。本文将指导大家如何在鸿蒙端利用该框架构建微服务。 一、原理解析 / 概念介绍 1.1 基础原理 arcade 采用了非阻塞式的 IO 事件循环架构。它通过直接包装 dart:io 的 HttpServer,提供了一套高度流式(