kelu | 血衫非弧修改

2026-05-08 00:00:00

最近给 Mac Studio 配了一套监控方案，通过 macmon-prometheus-exporter 采集硬件指标，接入 Prometheus + Grafana。整个过程比想象中简单，记录一下细节。

安装 macmon

参考macmon - Apple Silicon Mac 的性能监控利器

安装 Exporter

macmon-exporter 通过 Homebrew 一键安装：

brew install macmon-prometheus-exporter

安装后会自动注册为 launchd 服务，监听 9101 端口。验证一下：

curl http://localhost:9101/metrics | head -20

关键指标一览

macmon-exporter 暴露的指标都在 mac_ 命名空间下，都是 Gauge 类型（瞬时值）：

注意：macmon-exporter 提供的是瞬时百分比值，不是累积计数器。这意味着在 Grafana 中不需要使用 irate() 或 rate()。

Prometheus 配置

prometheus.yml

- job_name: 'node-studio'
    static_configs:
      - targets: ['studio.local:9101']
        labels:
          exported_instance: "studio"
          node: "studio"

Grafana 面板配置

CPU / GPU 使用率

Linux 节点通常用 irate(node_cpu_seconds_total{mode="idle"}) 计算 CPU 使用率，但 Mac Studio 的 macmon-exporter 直接提供百分比值：

# CPU 使用率（除以100因为Grafana自带百分号）
avg(mac_cpu_usage_percent{node="studio"}) by (node) / 100

# GPU 使用率
avg(mac_gpu_usage_percent{node="studio"}) by (node) / 100

CPU 核心数对比

Linux 节点用 count(node_cpu_seconds_total{mode="system"}) 统计核心数，Mac Studio 需要分别查询 P-Core 和 E-Core：

# Mac Studio: 8P + 4E = 12 核心
sum(mac_pcpu_cores{node="studio"}) + sum(mac_ecpu_cores{node="studio"})

内存使用率

同样，macmon-exporter 直接提供百分比：

# 内存使用率（除以100）
avg(mac_memory_usage_percent{node="studio"}) by (node) / 100

# 内存总量（注意单位）
mac_memory_total_bytes{node="studio"} / 1024^3

踩坑：Grafana 默认使用十进制单位（1 GB = 10^9 bytes），所以 mac_memory_total_bytes 直接除以 1024^3 后显示为 96 GiB（二进制），而不是 103 GB（十进制）。在 Grafana 面板中将 Unit 设为 gibibytes (GiB) 即可正确显示。

CPU / GPU 温度

# CPU 温度
mac_cpu_temperature_celsius{node="studio"}

# GPU 温度
mac_gpu_temperature_celsius{node="studio"}

功耗监控

Apple Silicon 的功耗数据很有参考价值：

# CPU 功耗（瓦特）
mac_cpu_power_watts{node="studio"}

# GPU 功耗（瓦特）
mac_gpu_power_watts{node="studio"}

# 系统总功耗
mac_system_power_watts{node="studio"}

# 过去1小时的平均系统功耗
avg_over_time(mac_system_power_watts{node="studio"}[1h])

# 过去24小时的平均系统功耗
avg_over_time(mac_system_power_watts{node="studio"}[24h])

# 过去7天的平均系统功耗
avg_over_time(mac_system_power_watts{node="studio"}[7d])

注意事项

1. 瞬时值 vs 计数器：macmon-exporter 的百分比指标是 Gauge，不需要 irate()。只有累积计数器才需要 rate/irate。

2. 单位转换：Grafana 的 Unit 设置会影响显示值，注意区分 GB（十进制）和 GiB（二进制）。

3. 温度监控：macmon-exporter 只暴露 CPU/GPU 温度，没有硬盘 SMART 信息。如果需要磁盘温度，需要额外安装 smartmontools。

2026-05-08 00:00:00

最近给 QwenPaw 配置 LM Studio 时，发现一个现象：LLM 请求的 KV Cache 命中率始终为 0。

排查了一圈配置和代理链路，最终发现这不是 bug，而是 Apple Silicon (MLX) 与 NVIDIA CUDA 在 KV Cache 实现上的根本性差异。记录一下排查过程和实验数据。

架构与现象

我们的请求链路如下：

QwenPaw (Linux) → Docker(cli-proxyapi:8317) → LM Studio (Mac M2 Max, 100.100.100.11:1234)

在 LM Studio 的 Web UI 中，我已经开启了 KV缓存量化 (Experimental)，上下文长度设为 262144。但 QwenPaw 的 token 用量日志显示，每次请求都是全新的 prompt，缓存从未命中。

排查过程

Step 1: 排除代理层干扰

首先怀疑是 cli-proxyapi 在转发时注入了动态 header（如 X-Request-Id、时间戳等），导致每次请求的 HTTP 头不一致。

curl -sv ... http://cli-proxyapi.sh4.local:8317/v1/chat/completions 2>&1 | grep -E "^[<>]"

结果：两次请求的 header 完全一致，代理层干净。

Step 2: 排除多实例负载均衡

如果 LM Studio 背后有多台机器轮询，缓存自然无法复用。我是单实例运行，无负载均衡。

Step 3: KV Cache 压力测试

我构造了两组对比实验：

实验 A：完全相同的 prompt 重复发送

{"model":"qwen3.6-35b-a3b@8bit","messages":[{"role":"system","content":"You are a test bot."},{"role":"user","content":"What is 1+1?"},{"role":"assistant","content":"2"},{"role":"user","content":"And 2+2?"}],"max_tokens":5,"temperature":0}

• Req1: 1011ms
• Req2: 444ms (↓ 56% 加速)

实验 B：相同前缀(100K chars) + 不同后缀（模拟 Agent 多轮对话）

PREFIX=$(python3 -c "print('A'*100000)") # 约 25K tokens
# Req1: system="$PREFIX", user="Say ONE word: test"
# Req2: system="$PREFIX", user="Say ONE word: test" (完全相同)

• Req1: 632ms
• Req2: 753ms (反而更慢，缓存未生效)

核心结论：MLX vs CUDA 的 KV Cache 差异

实验数据说明了原因：

QwenPaw 的 Agent 场景每轮发送的 prompt 结构如下：

[固定 System Prompt (~15K tokens)] + [变化的对话历史] + [新的 User Message]
         ↑ 前缀固定                          ↑ 每轮变化

在 CUDA 推理框架中，vLLM/TGI 会自动提取相同的前缀进行 KV Cache 复用，Agent 场景的缓存命中率通常能达到 30%~50%。

但在 Apple Silicon 上，LM Studio 底层使用 MLX 框架。MLX 的 KV Cache 实现较为朴素，仅支持精确匹配（Exact Match），不支持前缀缓存 (Prefix Caching)。Apple Silicon 的 KV Cache 优化目前仍处于实验阶段，前缀复用功能尚未稳定。

踩坑记录

1. Apple Silicon 的 MLX 框架限制：MLX 在推理速度上已经非常优秀，但在企业级特性（如 Prefix Caching、Continuous Batching）上仍落后于 CUDA 生态。选型时需明确场景需求。
2. 实验设计：用 date +%s%N 记录毫秒级耗时，配合完全相同的 prompt vs 前缀相同后缀不同的对比，能最快定位缓存生效边界。

2026-05-03 00:00:00

最近在折腾本地 AI 代理服务，把 CLIProxyAPI 和 CPA Usage Keeper 部署到了 Docker 里，记录一下过程。

背景

CLIProxyAPI

CLIProxyAPI 是一个开源的 AI API 代理服务，主要用来：

• 转发 OpenAI/Gemini/Claude/Codex 等模型的 API 请求
• 支持 OAuth 登录，获取官方模型的配额
• 可以对接 OpenRouter 等第三方 API 聚合平台
• 提供 Web 管理界面和 API

对于我这种无法直接访问 OpenAI/Gemini 官方 API 的人来说，它是个不错的解决方案。可以把请求转发到 OpenRouter，由 OpenRouter 帮我调用意愿的模型。

CPA Usage Keeper

CPA Usage Keeper（简称 CPA）是 CLIProxyAPI 的配套管理工具，主要功能：

• 同步 CLIProxyAPI 的使用数据（请求数、Token 消耗等）
• 管理 API Keys 和凭证
• 提供使用量统计和可视化界面
• 支持多用户/多项目统计

简单说就是给 CLIProxyAPI 做一个”后台”，方便查看花了多少钱、用了多少 Token。

部署步骤

1. 准备目录和配置文件

创建工作目录：

mkdir -p /root/docker/cliproxyapi
cd /root/docker/cliproxyapi

配置文件 config.yaml：

host: "0.0.0.0"
port: 8317

remote-management:
  allow-remote: true
  secret-key: "my-simple-key"

api-keys:
  - "cliproxy-default-key"

openai-compatibility:
  - name: "openrouter"
    prefix: "openrouter"
    base-url: "https://openrouter.ai/api/v1"
    headers:
      Content-Type: "application/json"
    api-key-entries:
      - api-key: "你的 OpenRouter API Key"
    models:
      - name: "minimax/minimax-m2.5:free"
        alias: "minimax-m2.5-free"

2. config.yaml 完整配置

记得开启 usage-statistics-enabled，否则不会记录使用量：

host: "0.0.0.0"
port: 8317

remote-management:
  allow-remote: true
  secret-key: "my-key"

api-keys:
  - "cliproxy-key"

openai-compatibility:
  - name: "openrouter"
    prefix: "openrouter"
    base-url: "https://openrouter.ai/api/v1"
    headers:
      Content-Type: "application/json"
    api-key-entries:
      - api-key: "你的 OpenRouter API Key"
    models:
      - name: "minimax/minimax-m2.5:free"
        alias: "minimax-m2.5-free"
  - name: DeepSeek
    base-url: https://api.deepseek.com
    models:
      - name: deepseek-v4-pro
      - name: deepseek-v4-flash
    headers:
      Authorization: Bearer 你的DeepSeek-API-Key
      Content-Type: application/json
    prefix: ds
  - name: lmstudio
    prefix: studio
    base-url: http://本地IP:1234/v1
    models:
      - name: qwen3.6-35b-a3b@8bit

usage-statistics-enabled: true

3. docker-compose.yml

version: '3'
services:
  cli-proxy-api:
    image: eceasy/cli-proxy-api:latest
    container_name: cli-proxyapi
    network_mode: bridge
    volumes:
      - ./config.yaml:/CLIProxyAPI/config.yaml
      - ./auths:/root/.cli-proxy-api
      - ./logs:/CLIProxyAPI/logs
    restart: unless-stopped

  cpa-usage-keeper:
    image: ghcr.io/willxup/cpa-usage-keeper:latest
    container_name: cli-cpa
    restart: unless-stopped
    network_mode: bridge
    environment:
      - TZ=Asia/Shanghai
      - CPA_BASE_URL=http://cliproxyapi.local:8317
      - REDIS_QUEUE_ADDR=cliproxyapi.local:8317
      - CPA_MANAGEMENT_KEY=my-key
      - AUTH_ENABLED=true
      - LOGIN_PASSWORD=password
    volumes:
      - ./keeper:/data

4. 启动服务

docker-compose up -d

5. 验证

检查容器状态：

docker ps | grep cli-

CLIProxyAPI 默认监听在 8317，CPA 默认监听在 8080。

调用示例

配置好模型后，就可以像调用普通 OpenAI API 一样调用 CLIProxyAPI：

curl http://cliproxyapi:8317/v1/chat/completions \
  -H "Authorization: Bearer cliproxy-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "minimax-m2.5-free",
    "messages": [
      {"role": "user", "content": "Hello!"}
    ]
  }'

参数说明：

如果需要添加更多模型，只需要在 config.yaml 的 openai-compatibility.models 中添加即可。

其他模型示例：

curl http://cliproxyapi:8317/v1/chat/completions \
  -H "Authorization: Bearer cliproxy-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.6-35b-a3b@8bit",
    "messages": [
      {"role": "user", "content": "你好"}
    ]
  }'

一些坑

1. 密钥配置

CLIProxyAPI 的 secret-key 支持明文配置，启动时会自动 bcrypt 哈希。所以直接写明文就行，别像我一开始那样直接贴个 bcrypt 哈希上去，结果两边密钥对不上。

2. 免密登录

试了下把 secret-key 设为空想免密，结果管理 API 直接返回 404 不可用了。CPA 还需要管理 API 来同步数据，所以没法完全免密。好在明文密钥两边会自动哈希匹配，保持一致很简单。

. 使用量统计默认关闭

一开始 CPA 怎么都拉不到数据，后来发现 CLIProxyAPI 默认关闭了使用量统计。需要在 config.yaml 里加上：

usage-statistics-enabled: true

4. CPA 登录保护

CPA 默认不带密码，如果暴露在公网很危险。启用登录保护：

environment:
  - AUTH_ENABLED=true
  - LOGIN_PASSWORD=password

访问

• CLIProxyAPI API: http://CLIProxyAPI:8317

• CLIProxyAPI Dashboard: http://CLIProxyAPI:8317/v0/management

  

• CPA 管理界面: http://CPA:8080

  

小结

这两个工具配合起来挺香的，CLIProxyAPI 做代理转发，CPA 做使用量统计和密钥管理。内部网络环境下，通过 OpenRouter 访问各种模型还是很方便的。

2026-04-30 00:00:00

跑本地 LLM 模型的时候，一直想看 GPU 和 ANE 的实时功耗和温度。macOS 自带的 Activity Monitor 只有 CPU 使用率，看不到功耗数据。之前有 powermetrics 可以看，但要 sudo 权限，输出也是纯文本。后来发现了 macmon，Rust 写的 TUI 工具，不需要 sudo 就能看到芯片级的实时数据，果断装上。

安装

通过 Homebrew 安装：

/opt/homebrew/bin/brew install macmon

⚠️ 仅支持 Apple Silicon（M1-M5），x86 的 Homebrew 会报架构不兼容。

功能

macmon 通过 macOS 私有 API 采集数据，和 powermetrics 用同一个底层接口，但不需要 root 权限。主要功能包括：

• ⚡ 实时功耗：CPU / GPU / ANE 的实时功耗（瓦特）
• 📊 CPU 集群利用率：E-Core 和 P-Core 分开显示
• 💾 内存 / Swap 使用量
• 🌡️ CPU / GPU 温度
• 📈 历史曲线：带平均值和最大值
• 🎨 6 种配色主题，按 c 切换
• 🪟 紧凑模式可以塞进小窗口

使用

基本 TUI

macmon

运行后界面分几个区域：

• 顶部：芯片型号、E/P 核心数、GPU 核心数、内存大小
• CPU 使用率曲线：E-Core 和 P-Core 分开显示，macOS 日常用 E-Core，重负载才切 P-Core
• GPU 使用率：图形处理负载
• 功耗和温度：系统总功耗、CPU/GPU/ANE 分项功耗，以及 CPU/GPU 平均温度

键盘操作：

控制采样间隔

macmon -i 500

默认 1000ms 刷新，可以改成 500ms 更频繁。

输出 JSON 给其他工具

macmon pipe -s 10

会输出 10 条 JSON 格式的指标数据，适合管道到 jq 或者其他脚本处理。

macmon -i 500 pipe -s 10 | jq

HTTP Server 模式

macmon 还支持把指标暴露为 HTTP 服务，方便接入 Prometheus / Grafana：

macmon serve          # 默认 9090 端口
macmon serve -p 8080  # 自定义端口
macmon serve -i 500   # 采样间隔 500ms

两个端点：

接入 Prometheus 的配置示例：

scrape_configs:
  - job_name: macmon
    static_configs:
      - targets: ["localhost:9090"]

小结

macmon 是目前 Apple Silicon Mac 上最方便的终端监控工具，Rust 实现，单二进制文件，无需 sudo 就能看到芯片级功耗和温度。对于跑本地模型、监控系统负载来说非常实用。

参考

• macmon GitHub：https://github.com/vladkens/macmon

2026-04-27 00:00:00

最近在使用 opencode 时遇到了一个奇怪的报错：

$ opencode
TypeError: fn3 is not a function. (In 'fn3(input)', 'fn3' is an instance of Object) at <anonymous> (src/plugin/index.ts:87:28)

但 opencode --help 和 opencode debug 却能正常运行。排查下来发现是版本过旧 + Homebrew upgrade 失效导致的问题，后续又牵连出一系列插件配置问题。记录一下完整的排查过程。

问题排查

确认环境

$ node --version
v18.20.8

$ npm --version
10.8.2

$ which opencode
/opt/homebrew/bin/opencode

$ opencode --version
1.1.50

发现版本不匹配

怀疑是版本问题，尝试 brew upgrade opencode，但升级后版本仍然是 1.1.50。进一步查看：

$ brew info opencode
==> opencode: stable 1.4.10 (bottled)
AI coding agent, built for the terminal
https://opencode.ai

Installed:
/opt/homebrew/Cellar/opencode/1.1.50 (4 files, 101.5MB)

Tap 源已经有 1.4.10，但本地还停留在 1.1.50——brew upgrade 没有生效。

原因分析

我最初安装 opencode 时，它还未被收录进 Homebrew 官方核心库（homebrew-core），而是通过第三方 tap anomalyco/tap 安装的。后来 opencode 被官方收录，但本地环境依然优先读取旧的第三方 tap，导致版本停滞在旧版本。

可以通过 brew info 的 “From” 行来确认来源：

# 旧的第三方 tap 来源
From: https://github.com/anomalyco/homebrew-tap/blob/HEAD/opencode.rb

# 新的官方来源
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/o/opencode.rb

解决方案

1. 卸载旧版本

brew uninstall opencode

2. 移除旧的 Tap 源

这一步是关键，将 anomalyco/tap 从本地库中移除：

brew untap anomalyco/tap

3. 更新并重新安装

brew update
brew install opencode

这一次系统会从 homebrew-core 拉取最新版本：

🍺  /opt/homebrew/Cellar/opencode/1.4.10: 12 files, 101.3MB

4. 验证修复

$ opencode --version
1.4.10

$ opencode --help
# 正常显示所有命令

$ brew postinstall opencode
# 确保 post-install 步骤执行完成

重新安装后，CLI 模式正常工作，TypeError 报错消失。

后续：插件配置问题

升级版本后，CLI 模式已经正常，但使用 Web 界面时又遇到新错误：

unknown certificate verification error

实际排查后发现，真正的原因是 API 验证错误：

{
  "error": {
    "code": 34,
    "message": "request validation errors",
    "errors": [{
      "type": "Extra inputs are not permitted",
      "loc": ["body", "tools[0]", "eager_input_streaming"],
      "msg": "Extra inputs are not permitted",
      "input": true
    }]
  }
}

定位配置

opencode 的配置文件不在 ~/.opencode/，而是在：

$ ls ~/.config/opencode/
opencode.json  oh-my-opencode.json.bak

发现问题插件

查看 opencode.json 后发现：

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["oh-my-openagent@latest"]
}

这里配置的 oh-my-openagent 插件向 Minimax API 发送了不支持的 eager_input_streaming 参数，导致验证失败。

临时解决

将插件列表清空：

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": []
}

禁用插件后，opencode run "你好" 可以正常收到 AI 回复。

关于 oh-my-opencode 插件

opencode 本身只是一个框架，真正的能力来自插件。oh-my-opencode（后改名为 oh-my-openagent）是 opencode 的插件集合，提供多种专业 agent。

安装

bunx oh-my-opencode install --no-tui --skip-auth

--no-tui 参数可以跳过图形界面交互，适合非交互式环境。

模型配置

安装后可能会遇到模型验证问题：

Agent atlas's configured model opencode/glm-4.7-free is not valid

解决方法是更换为有效的模型，例如 opencode/big-pickle 或 opencode/gpt-5-nano。

包名变更

2026 年 3 月发生了一个重要变化：

配置文件名称有意保留旧名以保持向后兼容：

# 两种配置名都能工作
~/.config/opencode/oh-my-opencode.json    # 传统（推荐）
~/.config/opencode/oh-my-openagent.json    # 新式

Agent 体系

oh-my-opencode 中包含一套完整的 agent 协作体系：

opencode vs openclaw

之前也有人问 opencode 和 openclaw 的区别：

两者定位不同，没有必要互相替换。

总结

几点经验教训：

1. 遇到奇怪错误，先检查版本：很多问题就是版本太旧导致的
2. brew upgrade 不一定可靠：如果升级后版本没变，可能需要先 untap 再重装
3. 第三方 tap 要注意迁移：当项目被 Homebrew 官方收录后，旧的第三方 tap 可能不会自动更新
4. 错误信息要看完整：unknown certificate verification error 是误报，真正的错误在 API 响应体里
5. 插件配置要核对：确保插件名称与实际安装的包一致

2026-04-22 00:00:00

把 QwenPaw（原 CoPaw）装好了，记录一下安装和配置过程。

背景

QwenPaw 是 AgentScope 团队开源的个人 AI 助手，支持钉钉、飞书、微信、Discord 等多渠道，还能本地运行、扩展 Skills。GitHub 星标 15K+。

问题卡点

官方推荐三种安装方式：

1. pip install qwenpaw — 需要 Python 3.10+
2. 安装脚本 curl -fsSL https://qwenpaw.agentscope.io/install.sh | bash — 自动下载 uv
3. Docker

我的系统自带 Python 是 3.9.6，pip 版本也老（21.2.4），而 qwenpaw 要求 Python 3.10-3.14。我平时用 conda 管理 Python 环境，所以直接走 conda 路线。

用 conda 创建环境

# 1. 创建 Python 3.11 虚拟环境
conda create -n qwenpaw python=3.11 -y

# 2. 激活环境
conda activate qwenpaw

# 3. 安装 qwenpaw
pip install qwenpaw

这样就搞定了，不需要额外引入 uv。环境激活后 python 和 pip 都指向 conda 环境内的版本，不会产生污染。

配置 OpenRouter MiniMax 模型

qwenpaw 内置支持 OpenRouter provider，配置很简单。编辑 ~/.copaw/config.json：

{
  "$schema": "https://qwenpaw.agentscope.io/schema.json",
  "model": {
    "models": {
      "minimax-free": {
        "provider": "openrouter",
        "model": "minimax/minimax-m2.5:free",
        "base_url": "https://openrouter.ai/api/v1",
        "api_key": "你的OPENROUTER_KEY",
        "enabled": true
      }
    },
    "default_model": "minimax-free"
  }
}

注意：OpenRouter 的 MiniMax 模型 ID 格式是 minimax/minimax-m2.5:free，用冒号而不是连字符。

启动与验证

# 激活 conda 环境后，qwenpaw 命令可直接使用
conda activate qwenpaw

# 初始化（需要交互式终端）
qwenpaw init

# 或者启动 Web UI
qwenpaw app

启动后打开浏览器访问 http://127.0.0.1:8088/ 进行配置和聊天。

验证安装：

qwenpaw --version
# QwenPaw, version 1.1.3

Agent 配置：让 Agent 理解你是谁

安装完成只是第一步，真正的关键在于记忆文件配置。

核心记忆文件

QwenPaw 的工作区位于 ~/.copaw/workspaces/default/，包含以下文件：

配置流程

1. 首次启动 — Agent 自动读取所有记忆文件，为空则使用默认模板。
2. 手动配置 — 编辑 PROFILE.md 定义身份和偏好，编辑 SOUL.md 定义行为边界。
3. 持续迭代 — Agent 会在每次会话中主动记录重要信息到 memory/YYYY-MM-DD.md，定期提炼到 MEMORY.md。

关键：QwenPaw 不会每次重启都重新初始化。记忆通过文件持久化，会话中断后自动恢复上下文。

依赖规模

qwenpaw 的依赖比较多（约 244 个包），包括：

• agentscope 1.0.19
• playwright 1.58.0（39MB）
• transformers 5.5.4（9.8MB）
• onnxruntime 1.23.2（16MB）
• chromadb 1.5.8（20MB）
• grpcio 1.80.0（11MB）
• pandas 3.0.2（9.5MB）
• 阿里系 SDK（alibabacloud-dingtalk 等）
• 消息渠道 SDK（discord-py、twilio 等）

首次安装需要下载不少内容，耐心等待即可。conda 环境下这些依赖会被隔离在环境目录中，不会影响系统。

相关工具对比

QwenPaw 和 OpenCode 可以通过 ACP（Agent Communication Protocol）互联，默认配置中已开启：

"acp": {
  "agents": {
    "opencode": { "enabled": true },
    "qwen_code": { "enabled": true },
    "claude_code": { "enabled": true }
  }
}

参考资料

• QwenPaw 官网：https://qwenpaw.agentscope.io/
• GitHub：https://github.com/agentscope-ai/QwenPaw
• OpenRouter MiniMax M2.5 Free：https://openrouter.ai/minimax/minimax-m2.5:free