一条命令在HF Jobs上启动vLLM服务器
Run a vLLM Server on HF Jobs in One Command
HuggingFace Jobs 支持一条命令启动 vLLM 服务器,用于测试、评估或批量生成。使用 `hf jobs run` 命令,指定官方 `vllm/vllm-openai` 镜像、GPU flavor(如 `a10g-large`)、暴露端口 8000 并设置超时。服务器启动后可通过 OpenAI 兼容 API 访问,每次请求需携带 HF token 作为 bearer token(仅限有读权限的用户)。示例部署了 Qwen/Qwen3-4B(多 GPU 需 `--tensor-parallel-size`)。`a10g-large` 价格为 $1.50/小时,按分钟计费,可通过 `hf jobs cancel` 停止。
这是一条命令在HF上启动vLLM的完整教程,适合快速测试模型的开发者,但方案完全绑定Hugging Face平台,通用性有限。
你只需一条命令,就能在 Hugging Face 基础设施上启动一个私有的、兼容 OpenAI 的 LLM 端点——无需配置服务器,无需 Kubernetes,按秒计费。一旦启动,你就可以从笔记本电脑、notebook 或任何其他地方向它发起查询。
这是为测试、评测或批量生成快速搭建模型的最快方式。(如果你想要的是托管式的、生产就绪的服务,那正是 Inference Endpoints 的用途——关于何时选择哪种方案,文末有更多说明。)
下面是完整的端到端流程。
前置条件
- 一种支付方式,或正数的预付费余额(Jobs 按硬件使用时长每分钟计费)。
huggingface_hub >= 1.20.0:pip install -U "huggingface_hub>=1.20.0"。- 已在本地登录:
hf auth login。
启动服务器
hf jobs run 是面向 HF 基础设施的 docker run。我们使用官方 vllm/vllm-openai 镜像,申请一块带 --flavor 的 GPU,并通过 --expose 暴露 vLLM 的端口:
hf jobs run --flavor a10g-large --expose 8000 --timeout 2h \
vllm/vllm-openai:latest \
vllm serve Qwen/Qwen3-4B --host 0.0.0.0 --port 8000
--expose 8000 通过 HF 的公共 jobs 代理转发容器的端口(完整参考见 Serve Models 指南)。该命令会打印出你的服务器可访问的 URL:
✓ Job started
id: 6a381ca1953ed90bfb947332
url: https://huggingface.co/jobs/qgallouedec/6a381ca1953ed90bfb947332
Hint: Exposed ports are reachable at (requires an HF token with read access to the job):
https://6a381ca1953ed90bfb947332--8000.hf.jobs
6a381ca1953ed90bfb947332 是你的任务 ID。请记好它,我们后面会用到。在本文剩余部分,我们将用 <job_id> 作为它的占位符。
给它几分钟时间下载权重并启动。当日志显示 Application startup complete 时,就说明已经上线了。
从任何地方查询它
vLLM 使用 OpenAI API 协议,每个请求只需将你的 HF token 作为 bearer token 传入即可。最快的方式是用 curl 发起请求:
curl https://<job_id>--8000.hf.jobs/v1/chat/completions \
-H "Authorization: Bearer $(hf auth token)" \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen3-4B",
"messages": [{"role": "user", "content": "Hello!"}],
"chat_template_kwargs": {"enable_thinking": false}
}'
它会返回常见的 OpenAI 风格 JSON,其中 choices[0].message.content 包含 "Hello! How can I assist you today? 😊"。
或者,在 Python 中,将 OpenAI 客户端指向暴露出来的 URL,并把 token 作为 API key 传入:
from huggingface_hub import get_token
from openai import OpenAI
client = OpenAI(
base_url="https://<job_id>--8000.hf.jobs/v1",
api_key=get_token(),
)
resp = client.chat.completions.create(
model="Qwen/Qwen3-4B",
messages=[{"role": "user", "content": "Hello!"}],
extra_body={"chat_template_kwargs": {"enable_thinking": False}},
)
print(resp.choices[0].message.content)
Hello! How can I assist you today? 😊
开始之前先做个快速健康检查:curl https://<job_id>--8000.hf.jobs/v1/models -H "Authorization: Bearer $(hf auth token)" 应当列出该模型。
🔐 该端点受访问控制保护,并非公开。 每个请求都必须携带一个对任务所在命名空间具有 读取权限 的 HF token。直接用浏览器访问会被拒绝。实际上,任务代理 就是 你的 API 网关:访问权限仅限于你(以及你的组织)。这对私人使用来说没问题,但要相应地对待这个 URL:不要分享它并指望它是公开的,也不要把你的 token 粘贴到不受信任的地方。如果你需要更细粒度或公开的访问权限,请在前面部署一个正规的网关。或者参见下方的 HF Jobs 还是 Inference Endpoints?。
清理
任务按秒计费,所以用完后请停止服务器:
hf jobs cancel <job_id>
你设置的 --timeout 是一道安全网(它会自动停止),但显式取消更省钱。一个 a10g-large 的运行价格为 $1.50/小时——查看 hf jobs hardware 了解完整价格列表,并挑选适合你模型的最小规格。
更进一步:更大的模型
同一条命令可以扩展到更大的模型——挑选一个更强的 --flavor,并通过 --tensor-parallel-size 让 vLLM 把模型分片到多个 GPU 上。例如,在 2× H200 上运行 122B 的 Qwen3.5 混合专家模型:
hf jobs run --flavor h200x2 --expose 8000 --timeout 2h \
vllm/vllm-openai:latest \
vllm serve Qwen/Qwen3.5-122B-A10B \
--host 0.0.0.0 --port 8000 --tensor-parallel-size 2 \
--max-model-len 32768 --max-num-seqs 256
--tensor-parallel-size 应与该规格中的 GPU 数量一致(h200x2 → 2,h200x8 → 8)。运行 hf jobs hardware 查看有哪些可用规格,并给更大的模型设置更长的 --timeout,因为它们下载和加载需要更长时间。对于大型模型,H200 规格通常性价比最高。
--max-model-len 32768 --max-num-seqs 256 这些标志是该模型特有的:Qwen3.5-122B 是一种混合 Mamba/注意力架构,默认上下文为 256K token,这没有为 vLLM 的默认批处理设置留下足够内存。限制上下文长度和并发序列数可以让它保持在 GPU 的内存范围内。如果某个模型因内存不足或缓存块错误而启动失败,首先应该尝试的就是把这两项调低。其他一切(暴露的 URL、OpenAI 客户端、token 认证)都完全保持不变。
更进一步:在 UI 中与它对话
更喜欢聊天窗口而不是 curl?只需几行Gradio指向同一个端点。把--reasoning-parser deepseek_r1加到vllm serve命令中,这样 Qwen3 的思考过程会作为单独的字段返回(不是必须的,但很有用),然后在本地运行这段代码(你只需要 job ID):
import gradio as gr
from gradio import ChatMessage
from huggingface_hub import get_token
from openai import OpenAI
client = OpenAI(base_url="https://<job_id>--8000.hf.jobs/v1", api_key=get_token())
def chat(message, history):
messages = [{"role": m["role"], "content": m["content"]} for m in history if not m.get("metadata")]
messages.append({"role": "user", "content": message})
stream = client.chat.completions.create(model="Qwen/Qwen3-4B", messages=messages, stream=True)
thinking, answer = "", ""
for chunk in stream:
delta = chunk.choices[0].delta
thinking += delta.model_extra.get("reasoning", "")
answer += delta.content or ""
out = []
if thinking.strip():
status = "done" if answer.strip() else "pending"
out.append(ChatMessage(role="assistant", content=thinking, metadata={"title": "💭 Thinking", "status": status}))
if answer.strip():
out.append(ChatMessage(role="assistant", content=answer))
yield out
gr.ChatInterface(chat).launch()
运行它,打开 http://127.0.0.1:7860,然后开始对话——推理过程会流式输出到可折叠面板中,答案显示在下方。
更进一步:通过 SSH 连接到正在运行的服务器
需要调试启动失败、查看 GPU 内存,或者交互式地跟踪日志?你可以直接打开一个 shell 进入正在运行的 job。用 --ssh 启动它,并确保你的公钥已在 huggingface.co/settings/keys 注册:
hf jobs run --flavor a10g-large --expose 8000 --timeout 2h --ssh \
vllm/vllm-openai:latest \
vllm serve Qwen/Qwen3-4B --host 0.0.0.0 --port 8000
然后用 job ID 连接:
hf jobs ssh <job_id>
现在你已经进入容器内部,可以运行 nvidia-smi、检查进程,或者直接探查模型——这让调试和监控比从外部读取日志要容易得多。SSH 支持需要 huggingface_hub >= 1.20.0。
更进一步:用 Pi 将其作为编码智能体后端
同一个端点还能支撑终端编码智能体。Pi 是一个与提供商无关的智能体框架。把它指向这个任务,你就能得到一个运行在你自己自托管模型上的 Read/Write/Edit/Bash 智能体。
首先需要设置一件事:智能体通过工具调用来驱动模型,而 vLLM 只有在服务器启动时启用了工具调用,才会接受这些调用。因此,请用 --enable-auto-tool-choice 以及一个与模型系列匹配的 --tool-call-parser(Qwen3 对应 hermes)重新启动。智能体也能从更强的模型中获益,所以这里是引入更大模型的好时机:
hf jobs run --flavor h200x2 --expose 8000 --timeout 2h \
vllm/vllm-openai:latest \
vllm serve Qwen/Qwen3.5-122B-A10B \
--host 0.0.0.0 --port 8000 --tensor-parallel-size 2 \
--max-model-len 32768 --max-num-seqs 256 \
--reasoning-parser deepseek_r1 \
--enable-auto-tool-choice --tool-call-parser hermes
然后在 ~/.pi/agent/models.json 中把这个任务添加为自定义提供商:
{
"providers": {
"hf-jobs": {
"baseUrl": "https://<job_id>--8000.hf.jobs/v1",
"api": "openai-completions",
"apiKey": "!hf auth token",
"models": [
{ "id": "Qwen/Qwen3.5-122B-A10B" }
]
}
}
}
然后针对它启动智能体:
pi
你几条命令之前启动的那个模型,现在正在你的终端里驱动一个交互式编码智能体。
HF Jobs 还是 Inference Endpoints?
HF Jobs 并不是在 Hugging Face 上服务模型的唯一方式。Inference Endpoints 是我们为同一任务提供的托管产品,哪一个更合适取决于你的需求。
当你想要最大的灵活性和控制力时,就选择 HF Jobs:它本质上就是在 HF 基础设施上运行 docker run,因此你可以自行选择镜像、确切的 vllm serve 参数以及硬件,并且只需按作业运行的秒数付费。这使它非常适合实验、一次性评测、批量生成,或者在正式投入之前先试跑一下某个模型。
当你想要更接近生产就绪的方案时,就选择 Inference Endpoints。它们补充了长期运行服务所需的运维便利性:更细粒度的访问控制(端点可以是公开、受保护或私有的),以及缩容到零,因此在不活跃期间不会计费。如果你要搭建的是一个持久化端点,而不是运行一个作业,那这就是该用的工具。
延伸阅读
本文只聚焦 vLLM,但同样的暴露端口模式适用于任何 OpenAI 兼容的服务器。如果想用 llama.cpp 来服务 GGUF,或者改用 SGLang,请参阅 Serve Models on Jobs 指南,其中详细介绍了这些后端。
来源:Hugging Face:Blog(RSS) · huggingface.co