JetBrains开源Mellum2.1：架构不变，后训练RL强化Agent代码能力

JetBrains 今天凌晨把 Mellum2.1 模型权重开源了。这个版本最大的看点不是把模型结构又改了一版，而是官方明确说了一句话：架构不变，Agent 能力几乎全靠后训练阶段的 RL（强化学习）练出来。

这和过去“换模型就要换架构、加参数、堆数据”的思路很不一样。Mellum2.1 保持原有网络结构，纯靠后训练策略把代码生成、工具调用、多步编辑这类 Agent 任务能力拉高了一个档次。如果你最近在对比代码大模型，或者在做本地 Agent 工作流选型，这个项目值得关注。

本文会做三件事：

1. 拆解“架构不变 + 后训练 RL”这条技术路线到底意味着什么；
2. 给出 Mellum2.1 本地部署与启动的通用流程；
3. 用一套可复现的测试方法，验证它在代码生成、工具调用和批量任务上的真实表现。

全程不堆概念，重点放在能不能跑、怎么跑、跑完怎么看指标。

1. 核心能力速览

先给一张表快速判断值不值得跟进。

从这张表能提炼出 Mellum2.1 的核心定位：它不是为了刷榜而刷榜的大模型，而是更关注“模型能不能在真实 Agent 环境里完成多步任务”。

2. 适用场景与使用边界

2.1 适合谁

• 在做代码助手私有化部署的团队：Mellum2.1 权重开源，可以像跑 Qwen-Coder、DeepSeek-Coder 一样直接接进内部工具链，避免代码数据出域。
• 研究后训练技术的同学：这是少见的主打“架构不变、纯 RL 提升能力”的开源模型。适合做法对比实验，比如同一架构下只用 SFT 和加入 RL 后训练，Agent 任务结果会差多少。
• 做本地 Agent 工作流的技术人：代码补全、文件编辑、命令执行这类工具调用能力，是 Agent 落地的核心。Mellum2.1 的方向正是把模型往“能用工具”的方向训练。

2.2 不适合谁

• 纯做自然语言对话的开发者：这个模型的目标场景是代码与工具调用，不是通用聊天模型。做闲聊、文本摘要、情感分析，效果大概率不如通用指令模型。
• 完全没有 GPU 资源、只想在低配 CPU 上跑大模型的人：代码类模型对上下文长度和推理速度要求高，CPU 推理体验会比较吃力。
• 希望拿一键包双击就用的用户：JetBrains 开源的是模型权重和训练思路，目前更贴近“开发者自部署”的形态，需要自己拉推理框架。

2.3 版权、隐私与合规边界

代码模型有一个容易忽略的问题：模型训练数据中可能包含开源代码，生成结果也可能与某些仓库代码高度相似。使用时要留意：

• 商用场景尽量用开源协议明确、授权清晰的模型；
• 不要把未脱敏的私有代码直接送到外部 API 服务；
• 如果做 Agent，模型会读取本地文件、执行命令，必须在受控环境里运行，并限制权限范围；
• 不要用模型绕过软件许可检查或生成恶意代码。

社区里对“RL 后训练提升 Agent 能力”的共识是：这确实是一条有效路径，但不代表模型能包办所有工程决策。关键操作仍需要人工审查。

3. 环境准备与前置条件

Mellum2.1 没有官方一键包，部署前要把环境检查做完整。下面的清单适用于大多数代码模型，具体版本号以模型仓库实际要求为准。

3.1 操作系统与驱动

• 推荐 Ubuntu 22.04 / 24.04，驱动层面对 CUDA 兼容性最好；
• Windows 需要 WSL2 或原生 Python 环境，注意 CUDA 工具链版本；
• macOS 只能在 Apple Silicon 上跑较小规模版本，且速度受限于统一内存带宽。

GPU 驱动建议先用 nvidia-smi 看当前驱动和 CUDA 版本：

bash复制nvidia-smi

如果输出正常，再确认 PyTorch 的 CUDA 版是否匹配：

bash复制python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

3.2 Python 与依赖

建议用 Python 3.10 - 3.12。创建独立虚拟环境，避免和系统 Python 或 Conda 基础环境冲突。

bash复制conda create -n mellum python=3.11 -y
conda activate mellum

3.3 磁盘与内存

大模型权重文件体积不低，fp16 格式按参数量比例占用磁盘。准备至少 50GB 可用空间更稳妥，同时给 Hugging Face 的缓存目录预留空间。

bash复制# 查看磁盘剩余空间
df -h

加载模型时，内存和显存都要关注。建议物理内存不低于 32GB，如果跑多轮 Agent 任务，系统内存最好 64GB 起。

3.4 端口规划

推理服务默认可能占用 8000 / 8080 / 7860 等端口。启动前先检查：

bash复制sudo lsof -i :8000

端口被占用就换一个，避免服务起不来还找不到原因。

4. 安装部署与启动方式

下面给一套通用部署流程。核心思路是：先把权重下载到本地，再用 transformers 或 vLLM 加载，最后封装成接口服务。

4.1 下载模型权重

先从 JetBrains 官方或 Hugging Face 模型仓库确认 Mellum2.1 的完整 repo ID。下载时建议用 hf 命令行工具：

bash复制# 安装 huggingface_hub
pip install -U huggingface_hub

# 下载整个仓库，具体 repo id 以官方为准
hf download <jetbrains/mellum2.1> --local-dir ./models/mellum2.1

如果仓库里有多个量化版本，可以选择适合本机显存的格式，比如 GPTQ、AWQ 或 GGUF。没有确定版本时，先拿 fp16 原版做一次最小验证，再考虑量化。

4.2 用 transformers 快速验证加载

第一步不要急着开 API 服务，先用一段脚本验证权重能不能正常加载。

python复制import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "./models/mellum2.1"

print("loading tokenizer ...")
tokenizer = AutoTokenizer.from_pretrained(model_id)

print("loading model ...")
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.float16,
    device_map="auto",
)

print("model loaded:", model.config.model_type, model.config.hidden_size)

按实际环境替换 model_id。如果显卡显存不足，可以先加载量化版本，或把 device_map="cpu" 做一次低速验证。

4.3 用 vLLM 启动推理服务

如果只验证权重，transformers 够用。但要做接口调用和批量任务，直接用 vLLM 启动 OpenAI 兼容服务更高效：

bash复制pip install vllm

启动命令模板如下，需要替换模型路径和端口：

bash复制python -m vllm.entrypoints.openai.api_server \
    --model ./models/mellum2.1 \
    --served-model-name mellum2.1 \
    --host 127.0.0.1 \
    --port 8000 \
    --max-model-len 8192 \
    --dtype float16 \
    --trust-remote-code

启动后看到 Uvicorn running on http://127.0.0.1:8000，说明服务已经就绪。

4.4 用 SGLang 启动（备选）

如果 vLLM 和模型版本存在兼容问题，可以试 SGLang：

bash复制pip install sglang[all]

python -m sglang.launch_server \
    --model-path ./models/mellum2.1 \
    --host 127.0.0.1 \
    --port 8000 \
    --chat-template llama-3

SGLang 对长上下文的高并发场景表现稳定，适合 Agent 工具调用类任务。

4.5 可视化界面（可选）

如果不想只用命令行，可以接 Open WebUI 或 LobeChat 这类前端。

bash复制docker run -d -p 3000:8080 \
    --add-host=host.docker.internal:host-gateway \
    -e OPENAI_API_BASE_URL=http://host.docker.internal:8000/v1 \
    -e OPENAI_API_KEY=unused \
    ghcr.io/open-webui/open-webui:main

注意，这只是一个通用示例。实际是否选配前端，取决于你是要调试模型还是要做产品原型。

5. 功能测试与效果验证

部署完只是开始。Mellum2.1 的卖点是 Agent 能力，所以测试重点要放在多轮、工具调用和代码编辑上，而不是简单问一句“写个快排”。

5.1 基础代码生成测试

先做一次最基本的补全/生成测试，确认链路是通的。

python复制import requests

url = "http://127.0.0.1:8000/v1/chat/completions"

payload = {
    "model": "mellum2.1",
    "messages": [
        {"role": "user", "content": "用 Python 写一个带有缓存的斐波那契函数，要求类型标注完整，并给出单元测试示例。"}
    ],
    "temperature": 0.2,
    "max_tokens": 1024
}

response = requests.post(url, json=payload, timeout=120)
print(response.json()["choices"][0]["message"]["content"])

判断标准：

• 输出代码无转义乱码；
• 函数能直接放入 Python 文件运行；
• 单测代码可以被 pytest 或 unittest 执行；
• 不出现模型自问自答、解释过多的问题。

5.2 Agent 多步任务测试

这一步是核心。给出一个需要多轮才能完成的任务，观察模型会不会拆步骤。

python复制payload = {
    "model": "mellum2.1",
    "messages": [
        {"role": "system", "content": "你是一个终端 Agent。用户会给你目标，你需要返回可执行的命令或代码。"},
        {"role": "user", "content": "在当前目录下找到所有最近 24 小时内修改的 Python 文件，统计每个文件的行数，并按行数从大到小输出。请拆成多个步骤执行，并在每一步说明你要执行的命令。"}
    ],
    "temperature": 0.1,
    "max_tokens": 2048
}

response = requests.post(url, json=payload, timeout=180)
print(response.json()["choices"][0]["message"]["content"])

重点观察：

• 是否把任务拆成了 find -> wc -> sort 这样的步骤；
• 每一步是否附带可执行的命令或代码；
• 是否考虑到文件路径中的空格、特殊字符；
• 是否会在不确定时请求更多信息，而不是强行编造输出。

5.3 代码编辑能力测试

Agent 场景里，模型不能只会从头写文件，还要能精准修改已有代码。给模型一个现有函数，让它做局部修改。

python复制old_code = """
def process_items(items):
    result = []
    for i in items:
        if i % 2 == 0:
            result.append(i * 2)
    return result
"""

user_prompt = (
    "下面是现有函数。请改为使用列表推导式实现相同逻辑，"
    "并保持函数名和参数签名不变。只输出修改后的函数，不要额外解释。\n\n"
    f"{old_code}"
)

payload = {
    "model": "mellum2.1",
    "messages": [{"role": "user", "content": user_prompt}],
    "temperature": 0.1,
    "max_tokens": 512
}

response = requests.post(url, json=payload, timeout=120)
new_code = response.json()["choices"][0]["message"]["content"]
print(new_code)

判断标准：

• 函数签名没有变化；
• 输出结果和原函数一致；
• 没有节外生枝去改其他部分。

5.4 工具调用与 JSON 输出测试

Agent 框架经常要求模型输出结构化 JSON，Mellum2.1 的 RL 后训练应该包含这类对齐。测试模型能否稳定输出合法 JSON。

python复制payload = {
    "model": "mellum2.1",
    "messages": [
        {"role": "system", "content": "调用 'get_weather' 工具时，输出如下 JSON：{\"name\": \"get_weather\", \"arguments\": {\"city\": \"city_name\"}}"},
        {"role": "user", "content": "查一下北京的天气。"}
    ],
    "temperature": 0.0,
    "max_tokens": 256
}

response = requests.post(url, json=payload, timeout=60)
content = response.json()["choices"][0]["message"]["content"]
print(content)

如果输出不是合法 JSON，可能是 RL 对齐不完整，也可能是采样参数问题。可以尝试把 temperature 降到 0，或换更严格的后处理解析。

5.5 长上下文稳定性测试

Agent 任务往往需要携带大量背景信息。用一个长文件做输入，让模型在文件末尾追加或修改内容。

python复制import requests

# 读取一个本地长文件，作为 input
with open("/path/to/long_file.py", "r", encoding="utf-8") as f:
    code = f.read()

user_prompt = (
    "下面是一个较大的 Python 文件。请在文件末尾追加一个函数，"
    "功能是从列表中移除连续重复元素。不要修改原文件其他部分。\n\n"
    f"{code}"
)

payload = {
    "model": "mellum2.1",
    "messages": [{"role": "user", "content": user_prompt}],
    "temperature": 0.1,
    "max_tokens": 1024,
    "max_model_len": 16384
}

response = requests.post(url, json=payload, timeout=300)
content = response.json()["choices"][0]["message"]["content"]

# 判断是否保留原文件内容
if code.splitlines()[0] in content:
    print("长上下文保留良好")
else:
    print("长上下文出现截断")

长上下文出问题的典型表现是首部内容丢失、格式错乱、或者模型重复生成中间段落。出现这些问题时优先调整 max_model_len 和 chunk 策略。

6. 接口 API 调用与批量任务

6.1 OpenAI 兼容接口

vLLM 启动服务后，默认就提供 OpenAI 兼容的 /v1/chat/completions 接口。这意味着所有基于 OpenAI SDK 的工具都能直接改 base_url 接入。

python复制from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:8000/v1",
    api_key="not-required",
)

response = client.chat.completions.create(
    model="mellum2.1",
    messages=[
        {"role": "user", "content": "用 TypeScript 写一个防抖函数。"}
    ],
    temperature=0.2,
    max_tokens=512,
)

print(response.choices[0].message.content)

如果项目没有安装 openai SDK，用 requests 直接 POST 也可以。

6.2 批量任务设计

批量跑代码生成任务时，不建议一条 for 循环逐个请求，容易把服务打爆。推荐两种方式：

• 队列方式：用 Redis/RabbitMQ 管理任务，worker 从队列取任务再请求模型服务；
• vLLM 并行方式：vLLM 本身支持高并发，用线程池或异步并发发送请求，观察显存和吞吐。

下面给一个简单的并发脚本示例：

python复制import concurrent.futures
import requests

url = "http://127.0.0.1:8000/v1/chat/completions"

def run_task(text):
    payload = {
        "model": "mellum2.1",
        "messages": [{"role": "user", "content": text}],
        "temperature": 0.2,
        "max_tokens": 512
    }
    resp = requests.post(url, json=payload, timeout=120)
    return resp.json()["choices"][0]["message"]["content"]

task_prompts = [
    "用 Go 写一个 HTTP 服务",
    "用 Rust 写一个命令行参数解析器",
    "用 Java 写一个线程池示例",
]

with concurrent.futures.ThreadPoolExecutor(max_workers=3) as executor:
    results = list(executor.map(run_task, task_prompts))

for r in results:
    print(r)
    print("-" * 40)

首次跑批量任务建议先只开 max_workers=2，观察显存和响应时间，再逐步加大并发。

6.3 失败重试与日志

批量任务最容易遇到的问题是网络抖动、超时、显存不足。脚本里应加入重试机制：

python复制import time

def run_task_with_retry(text, retries=3):
    for attempt in range(retries):
        try:
            return run_task(text)
        except Exception as e:
            print(f"attempt {attempt + 1} failed: {e}")
            time.sleep(5)
    return None

同时把每个任务的输入、输出、延迟写入结构化日志：

json复制{
  "task_id": "task_001",
  "prompt_length": 256,
  "latency_ms": 2310,
  "tokens": 128,
  "status": "success"
}

7. 资源占用与性能观察

7.1 显存观察方式

推理过程中，用 nvidia-smi 持续观察显存变化：

bash复制watch -n 1 nvidia-smi

重点关注：

• 模型加载前 vs 加载后的显存增量；
• 单条请求的显存峰值；
• 并发请求时的显存增长曲线；
• 是否出现 OOM 导致的进程崩溃。

如果显存溢出，优先做法是换量化版本、降低 max_model_len、减少并发数。

7.2 CPU 与 GPU 推理差异

Mellum2.1 这类代码模型用 CPU 推理速度会很慢。小参数量模型配合量化在 CPU 上还能勉强跑，但 Agent 多轮任务需要大量重复推理，CPU 方案不建议用于生产。

GPU 推理时也要区分：代码补全类任务对延迟要求高，Agent 多步任务对吞吐要求高。vLLM 的 continuous batching 能显著提升吞吐，适合批量场景。

7.3 影响性能的关键参数

降低显存的通用策略是：先用小 batch 验证，再把 max_model_len 从 8192 降到 4096，最后考虑 GPTQ/AWQ 或 GGUF 量化版本。

7.4 端口冲突与进程残留

多次调试后会有多个 Python 进程残留占用显存和端口。排查方式：

bash复制# 查看占用端口的进程
lsof -i :8000

# 查看 GPU 上的残留进程
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

# 按需结束进程
kill -9 <pid>

模型服务启动前先杀干净旧进程，可以避免“服务没起来但端口被占”这种低级问题。

8. 常见问题与排查方法

这些是本地部署代码模型最常见的坑，Mellum2.1 也一样适用。很多问题不是模型权重有问题，而是推理框架参数没调对。

9. 最佳实践与使用建议

9.1 先跑最小验证

不要一上来就跑 16K 上下文和 8 并发。第一次先加载模型、跑一条短请求、确认延迟和显存，再逐步增加压力。

9.2 保存一套固定启动配置

把启动命令和参数写成脚本，避免每次手动输入：

bash复制#!/bin/bash
export MODEL_PATH="./models/mellum2.1"
export PORT=8000

python -m vllm.entrypoints.openai.api_server \
    --model $MODEL_PATH \
    --served-model-name mellum2.1 \
    --host 127.0.0.1 \
    --port $PORT \
    --max-model-len 8192 \
    --dtype float16 \
    --trust-remote-code

这样排查问题时，至少能确认启动参数一致。

9.3 目录规划

权重、输入素材、输出结果分开管理：

text复制mellum-project/
├── models/          # 模型权重
├── prompts/         # 测试提示词
├── outputs/         # 模型输出与日志
└── scripts/         # 启动与批量脚本

批量任务建议按日期生成子目录，输出文件统一加 task_id 前缀。

9.4 接口安全

本地接口不要直接暴露到公网。建议：

• 只绑定 127.0.0.1；
• 用 Nginx 做反向代理，加 API Key 校验；
• 开启请求长度限制，防止超大上下文把显存打满。

如果接入生产环境，还要加内容审计，尤其是模型生成的代码要被审查后才能进入代码库。

9.5 合规红线

• 不要用模型生成绕过安全机制的代码；
• 不要用模型克隆他人仓库再改名商用；
• Agent 场景如果涉及读取本地文件，必须明确权限边界；
• 任何涉及人脸、声音、私密数据的任务，先确认授权再处理。

10. 总结与下一步

Mellum2.1 最值得关注的点不是“又多了一个开源模型”，而是 JetBrains 用实际开源动作验证了一条路：在架构不变的前提下，通过后训练 RL 显著提升模型的 Agent 能力。这比堆参数、改结构更有工程参考价值。

如果你准备跟进这个项目，建议按这个顺序验证：

1. 先部署基础推理服务，跑通 chat/completions 接口；
2. 测一组 Agent 多步任务，看模型是否拆步骤、是否稳定输出结构化内容；
3. 在量化版本上对比原版效果，确认部署成本和输出质量的平衡点；
4. 最后再上批量任务，用真实业务场景里的代码库做回归测试。

最容易踩的坑有两个：一是显存没算好，上来就把 max_model_len 拉太高导致 OOM；二是把 Agent 能力当成万能，没有加人工复核就直接接入生产。

后续可以继续关注 JetBrains 是否放出更多训练细节，比如训练数据配方、RL 奖励设计、失败轨迹采样方式。这些信息比模型权重本身更能帮助团队复现“后训练 RL 提升 Agent 能力”的路径。

如果你最近正在做代码助手选型或本地 Agent 实验，Mellum2.1 值得放进测试名单。建议先用小参数验证，再决定是否投入完整资源。