vLLM 生态里，“Transformers modeling backend”这个方向值得关注：它瞄准的是一个很实际的痛点，开发者希望复用 Hugging Face Transformers 里的模型定义和生态接口，同时又想拿到 vLLM 在推理吞吐、调度和显存利用上的性能优势。标题里的 native-speed 说明重点不只是“能跑”，而是尽量接近 vLLM 原生模型后端的执行速度。
由于来源摘要没有提供更多实现细节，下面会把确定信息限定在标题表达的范围内；涉及落地命令和代码的部分，会以“可以这样实践”的方式给出，方便你在自己的模型服务里验证兼容性、吞吐和延迟。
为什么这个后端有价值
过去在 LLM 推理链路里，模型实现通常有两类选择。
一类是直接用 Transformers。好处是模型覆盖广、接口熟、社区更新快；代价是高并发推理时，你需要自己处理 batching、KV cache、请求调度、显存碎片和服务化细节。
另一类是使用 vLLM 原生支持的模型后端。好处是吞吐和服务能力强，尤其适合在线推理；代价是模型结构需要被 vLLM 后端支持，遇到新架构、改造模型或研究代码时，接入成本可能更高。
Transformers modeling backend 的目标，就是把这两边的距离拉近：让开发者保留 Transformers 模型代码路径，同时把执行放进 vLLM 的高性能推理框架里。对团队来说，这通常意味着更短的模型接入周期、更少的自定义后端代码，以及更容易从实验模型走到在线服务。
“接近原生速度”真正要看什么
标题强调 native-speed，但上线前不能只看宣传词。推理后端的性能通常由几个具体指标决定：
- prefill 延迟：长 prompt 首次处理的速度，影响首 token 时间。
- decode 吞吐：连续生成 token 时的稳定速度，影响并发容量。
- 显存占用：相同模型、相同上下文长度下，能否承载更多请求。
- 调度效率：多请求混跑时，是否能稳定合批，而不是吞吐忽高忽低。
- 模型兼容性：Transformers 侧的自定义 forward、attention mask、position encoding、量化方式是否能被正确处理。
所以，native-speed 更适合作为验证目标，而不是直接作为上线结论。你应该用自己的模型、上下文长度、并发模式跑一轮基准测试。
可以这样实践：用 vLLM 启动一个 OpenAI 兼容服务
下面示例展示一个最小服务化验证流程。请把 MODEL_ID 改成你要测试的 Hugging Face 模型，例如本地路径或模型仓库名。不同 vLLM 版本对后端选择参数可能变化，运行前建议用 vllm serve --help 查看当前安装版本支持的选项。
python -m venv .venv
source .venv/bin/activate
pip install -U vllm openai
export MODEL_ID="Qwen/Qwen2.5-0.5B-Instruct"
vllm serve "$MODEL_ID" \
--host 0.0.0.0 \
--port 8000 \
--dtype auto \
--max-model-len 4096
服务启动后，可以用 OpenAI 兼容接口做一次最小调用：
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen2.5-0.5B-Instruct",
"messages": [
{"role": "system", "content": "You are a concise assistant."},
{"role": "user", "content": "用三句话解释 vLLM 适合什么场景。"}
],
"temperature": 0.2,
"max_tokens": 128
}'
如果你需要在应用里调用，可以这样写一个可复制的 Python 客户端：
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="local-dev-key",
)
resp = client.chat.completions.create(
model="Qwen/Qwen2.5-0.5B-Instruct",
messages=[
{"role": "system", "content": "You answer in practical engineering terms."},
{"role": "user", "content": "What should I benchmark before moving a model to vLLM?"},
],
temperature=0.2,
max_tokens=160,
)
print(resp.choices[0].message.content)
运行前需要修改两处：模型名要和服务端一致；如果服务部署在远端，把 base_url 改成你的服务地址。
可以这样验证：比较 Transformers 与 vLLM 的端到端表现
如果你关心“Transformers 建模后端是否真的接近原生速度”，不要只测单条请求。下面是一个简单的压测脚本，可以作为起点。它通过 OpenAI 兼容接口并发请求 vLLM 服务，统计总耗时和粗略 token 输出量。
import concurrent.futures
import time
from openai import OpenAI
MODEL = "Qwen/Qwen2.5-0.5B-Instruct"
N_REQUESTS = 32
WORKERS = 8
client = OpenAI(base_url="http://localhost:8000/v1", api_key="local-dev-key")
prompt = "Write a short checklist for safely deploying an LLM inference service."
def call_once(i: int) -> int:
resp = client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content": f"{prompt}\nRequest id: {i}"}],
temperature=0.2,
max_tokens=128,
)
text = resp.choices[0].message.content or ""
return len(text.split())
start = time.perf_counter()
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as pool:
word_counts = list(pool.map(call_once, range(N_REQUESTS)))
elapsed = time.perf_counter() - start
print(f"requests: {N_REQUESTS}")
print(f"workers: {WORKERS}")
print(f"elapsed_seconds: {elapsed:.2f}")
print(f"approx_output_words: {sum(word_counts)}")
print(f"requests_per_second: {N_REQUESTS / elapsed:.2f}")
这个脚本不是严肃 benchmark，但能快速暴露几个问题：服务是否稳定、并发下是否报错、首轮加载是否太慢、输出延迟是否符合预期。正式评估时，应补充 token 级统计、P50/P95/P99 延迟、显存曲线和不同上下文长度的数据。
采用建议：从兼容性矩阵开始，而不是从性能数字开始
这个后端最适合两类团队：一类是模型迭代快，经常从 Transformers 拉新模型或改模型结构；另一类是已经用 vLLM 做服务，希望减少新模型接入成本。
落地时可以按这个清单推进：
- 先确认模型能加载、能生成、输出质量与 Transformers 路径一致。
- 再测短 prompt、长 prompt、低并发、高并发四组场景。
- 检查量化、LoRA、工具调用、结构化输出等业务能力是否受影响。
- 对比 vLLM 原生后端和 Transformers 路径的吞吐差距，而不是只看单点延迟。
- 在灰度环境观察显存峰值、请求失败率和重启恢复时间。
边界也要讲清楚：Transformers 模型代码越自定义，越可能遇到兼容性或性能折损；模型越接近主流架构，越容易拿到稳定收益。把它当成“降低模型接入摩擦的高性能路径”更合理，而不是默认替代所有手写后端。