LM Studio Linux 部署实战：虚拟模型参数隔离 + new-api 转发方案

本文最后更新于 2026年7月12日 晚上

作者: 小瑞
日期: 2026-05-03
环境: Ubuntu 24.04 / LM Studio (Linux) / new-api

目录

问题背景

在 Linux 服务器上通过 LM Studio 本地部署大语言模型（如 Qwen3.6-35B-A3B），为 Hermes、OpenClaw 等 AI Agent 提供本地推理服务。部署过程中遇到了两个棘手问题：

  • 参数隔离问题 — 不同模型需要不同的推理参数（temperature、topP 等），但 Linux 版缺少 Windows 版的图形化参数管理

  • 协议兼容问题 — 第三方客户端通过 Anthropic 格式连接 LM Studio 时频繁报错

这两个问题一度严重影响了工作效率，经过反复摸索，终于找到了可靠的解决方案。

问题一：Linux 版无法为每个模型设置独立参数

现象

LM Studio 的 Windows 版有直观的图形界面，可以方便地为每个模型设置独立的推理参数（温度、采样策略、上下文长度等）。

但 Linux 版主要面向无头服务器（headless server）运行，缺少等价的 GUI 参数管理。所有模型共享同一套全局设置，导致：

  • Qwen3.6 需要 temperature=0.7, topP=0.8（Instruct 模式）

  • 其他模型可能需要完全不同的参数

  • 切换模型后，必须手动修改全局配置再重启

这在多模型并存的场景下完全不可接受。

解决方案：虚拟模型参数隔离

什么是虚拟模型

LM Studio 支持通过 model.yaml 文件定义虚拟模型（Virtual Model）。虚拟模型本质上是同一个 GGUF 模型文件的不同”配置视图”，每个虚拟模型可以拥有独立的加载参数和推理参数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

1
2
3
4
5
6
7
8

~/.lmstudio/hub/models/custom/
├── qwen3.6-35b-a3b-256k/        # 虚拟模型 A（256K 上下文 + 特定采样参数）
│   ├── model.yaml
│   └── manifest.json
├── qwen3.6-35b-a3b-64k/         # 虚拟模型 B（64K 上下文 + 不同采样参数）
│   ├── model.yaml
│   └── manifest.json
└── ...

它们共享同一个底层 GGUF 文件，但拥有完全独立的参数配置。

model.yaml 配置示例

以下是一个完整的虚拟模型配置文件，每个字段都带有注释说明：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

model: custom/qwen3.6-35b-a3b-256k
base:
- key: lmstudio-community/Qwen3.6-35B-A3B-GGUF
  sources:
  - type: huggingface
    user: lmstudio-community
    repo: Qwen3.6-35B-A3B-GGUF
metadataOverrides:
  domain: llm
  architectures:
  - qwen35moe
  compatibilityTypes:
  - gguf
  contextLengths:
  - 262144
  vision: true
  reasoning: true
  trainedForToolUse: true
config:
  load:
    fields:
    - key: llm.load.contextLength
      value: 262144                    # 256K 上下文窗口
    - key: llm.load.numParallelSessions
      value: 2                         # 并发会话数
    - key: llm.load.llama.acceleration.offloadRatio
      value: 1.0                       # GPU 全量卸载
    - key: llm.load.numCpuExpertLayersRatio
      value: 0.3                       # 30% MoE 专家走 CPU
  operation:
    fields:
    - key: llm.prediction.llama.cpuThreads
      value: 8
    - key: llm.prediction.temperature
      value: 0.7                       # Instruct 模式推荐值
    - key: llm.prediction.topP
      value: 0.8
    - key: llm.prediction.topK
      value: 20
    - key: llm.prediction.minP
      value: 0.0
    - key: llm.prediction.presencePenalty
      value: 1.5                       # 防重复循环

关键设计

配置区
作用
独立性

base
指向底层 GGUF 模型文件
所有虚拟模型共享同一文件

load
模型加载参数（上下文长度、GPU 卸载比例等）
每个虚拟模型独立配置

operation
推理参数（temperature、topP、topK 等）
每个虚拟模型独立配置

metadataOverrides
模型元数据（上下文长度声明、能力标记等）
每个虚拟模型独立配置

效果

通过虚拟模型，我们在 Linux 上实现了和 Windows 版等价的参数管理体验：

1

一个 GGUF 文件 → 多个虚拟模型 → 各自独立的参数配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

切换模型时，LM Studio 自动加载对应的参数，无需手动修改全局配置。

---

## 问题二：Anthropic 协议连接报错

### 现象

在解决了参数隔离问题后，又遇到了第二个问题。部分 AI 客户端（如 Cherry Studio）在连接 LM Studio 时，偏好使用 **Anthropic 协议格式**。但 LM Studio 原生只提供 **OpenAI 兼容的 API 接口**（`/v1/chat/completions`），对 Anthropic 协议的支持不完善：

- 请求格式不兼容，频繁返回错误

- 消息格式转换丢失字段

- 流式输出中断

### 问题本质

这是一个**协议不匹配**问题：

1

客户端发出 Anthropic 格式请求 → LM Studio 期望 OpenAI 格式 → 格式冲突 → 报错

解决方案：new-api 协议转发

什么是 new-api

new-api 是一个开源的 AI API 网关，支持多种大模型 API 格式的互相转换。它的核心能力是：

  • 协议转换：自动将 Anthropic 格式请求转为 OpenAI 格式

  • 认证管理：为裸 API 添加 API Key 认证

  • 用量统计：记录每个密钥的调用次数和 Token 消耗

部署架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

    ┌──────────────┐
    │   Cherry     │
    │   Studio /   │
    │   Hermes /   │
    │   OpenClaw   │
    └──────┬───────┘
           │
Anthropic 或 OpenAI 格式
           │
    ┌──────▼───────┐
    │   new-api    │  ← 协议转换 + 认证 + 统计
    │  (:3000)     │
    └──────┬───────┘
           │
  OpenAI 格式（统一）
           │
    ┌──────▼───────┐
    │  LM Studio   │  ← 本地推理
    │  (:1234)     │
    └──────┬───────┘
           │
    ┌──────▼───────┐
    │  Qwen3.6-35B │
    │  (GGUF)      │
    └──────────────┘

配置步骤

第一步：部署 new-api

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

1
2
3
4
5
6
7

# Docker 部署（推荐）
docker run -d \
  --name new-api \
  --restart always \
  -p 3000:3000 \
  -v /path/to/new-api-data:/data \
  calciumion/new-api:latest

第二步：添加 LM Studio 渠道

在 new-api 管理后台（http://your-server:3000）中：

  • 进入「渠道管理」→「添加渠道」

  • 类型选择「自定义渠道」或「OpenAI」

  • 填写 LM Studio 的地址：

1
2
3
4
5

1

Base URL: http://10.28.9.6:1234/v1

  • 填写模型列表（与 LM Studio 中加载的模型对应）

第三步：创建令牌

在「令牌管理」中创建 API Key，用于客户端认证。

第四步：客户端连接

客户端连接配置：

参数
值

API Base URL
http://your-server:3000/v1

API Key
new-api 生成的令牌

协议格式
Anthropic 或 OpenAI 均可

new-api 的额外收益

引入 new-api 不仅解决了协议兼容问题，还带来了三个额外好处：

1. 认证保护

LM Studio 本身不提供认证机制，任何能访问端口的人都可以调用模型。new-api 在前面加了一层 API Key 认证：

1
2
3
4
5
6
7

1
2

无认证 → LM Studio (:1234)   ← 内网裸奔，有安全风险
有认证 → new-api (:3000)     ← API Key 保护，安全可控

2. 用量统计

new-api 自动记录每次调用的 Token 用量，可以按令牌、按渠道查看统计，方便监控模型使用情况。

3. 多客户端统一入口

不管是 Hermes（OpenAI 格式）、Cherry Studio（Anthropic 格式）还是其他客户端，都连接同一个 new-api 地址，由 new-api 统一转发到 LM Studio。配置管理大大简化。

最终架构

经过虚拟模型 + new-api 两层优化，最终的部署架构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│   Hermes    │  │ Cherry      │  │  OpenClaw   │
│  (OpenAI)   │  │ Studio      │  │ (OpenAI)    │
│             │  │(Anthropic)  │  │             │
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       │                │                │
       └────────────────┼────────────────┘
                        │
                 ┌──────▼──────┐
                 │   new-api   │  ← 认证 / 统计 / 协议转换
                 │  (:3000)    │
                 └──────┬──────┘
                        │
                 ┌──────▼──────┐
                 │  LM Studio  │  ← 本地推理引擎
                 │  (:1234)    │
                 └──────┬──────┘
                        │
            ┌───────────┼───────────┐
            │           │           │
     ┌──────▼────┐ ┌───▼────┐ ┌───▼────┐
     │ Qwen3.6   │ │ Model  │ │ Model  │
     │ 256K      │ │ B      │ │ C      │
     │ (虚拟模型) │ │(虚拟)  │ │(虚拟)  │
     └───────────┘ └────────┘ └────────┘
      temp=0.7     独立参数   独立参数
      topP=0.8

架构分层

层级
组件
职责

客户端层
Hermes / Cherry Studio / OpenClaw
不同协议格式的 AI 应用

网关层
new-api
协议转换、认证、统计

推理层
LM Studio
模型加载与推理

模型层
虚拟模型 × N
参数隔离、独立配置

总结

在 Linux 服务器上部署 LM Studio 时，两个核心问题的解决思路：

参数隔离 → 虚拟模型

  • LM Studio Linux 版缺少图形化参数管理

  • 通过 model.yaml 定义虚拟模型，实现同一 GGUF 文件的多配置视图

  • 每个虚拟模型拥有独立的加载参数和推理参数

  • 效果等同于 Windows 版的独立参数管理

协议兼容 → new-api 转发

  • LM Studio 原生只支持 OpenAI 格式，Anthropic 协议连接容易报错

  • new-api 作为中间网关，自动转换协议格式

  • 额外获得认证保护、用量统计、统一入口三大好处

这套方案已经在我们的服务器上稳定运行，希望对同样在 Linux 上部署 LM Studio 的朋友有所帮助。

技术笔记
LM Studio Linux 部署实战：虚拟模型参数隔离 + new-api 转发方案
https://www.normdist.com/2026/05/03/ND-20260503-003-lmstudio-linux-deployment-guide/
作者
小瑞
发布于
2026年5月3日
许可协议