vLLM release notes, April 2026: which v0.19.0 changes survive the Anthropic-shape shim a Mac agent has to put in front

vLLM v0.19.0 landed on April 3, 2026 with 448 commits from 197 contributors. The headline items in the release notes: full Gemma 4 family support (MoE, multimodal, reasoning, tool-use, requires transformers>=5.5.0), Model Runner V2 maturation with piecewise CUDA graphs for pipeline parallelism, zero-bubble async scheduling now compatible with speculative decoding, CPU KV cache offloading with pluggable eviction policies, a new /v1/chat/completions/batch endpoint for offline batch processing, NVIDIA B300/GB300 (Blackwell Ultra) support with AllReduce fusion for SM 10.3, online MXFP8 quantization for both MoE and dense models, NVFP4 accuracy fixes, the new QeRL quantization method, vision encoder CUDA graphs, DBO microbatch generalization across model types, and new model architectures including Cohere ASR, ColQwen3.5, and Granite 4.0 Speech, with new tool parsers for GigaChat, Kimi-K2.5, and Gemma 4. The follow-up patch releases v0.19.1 and v0.19.2 landed mid-April with regression fixes around SM100 MLA prefill and DeepGEMM accuracy on Qwen3.5.

vLLM serves OpenAI-shape API on /v1/chat/completions by default. A consumer Mac agent like Fazm injects ANTHROPIC_BASE_URL into the bundled Claude Code/ACP subprocess (Desktop/Sources/Chat/ACPBridge.swift line 381) and expects the Anthropic POST /v1/messages contract with content_block_delta streaming. The two shapes do not line up. So the v0.19.0 release notes apply to a Mac agent only after an Anthropic-shape translator (claude-relay, LiteLLM's anthropic adapter, or a one-file FastAPI shim that maps /v1/messages onto vLLM's /v1/chat/completions) sits in front of vllm serve on a different port. Every release-notes line item then sorts into one of three buckets: reaches you through the shim, dies at the shim because the shim does not translate it, or is irrelevant for an interactive Mac agent loop.

Reaches you: Gemma 4 model support (the model itself is what runs, the shape in front of it is independent), Model Runner V2 throughput improvements, online MXFP8 quantization (lower latency per token), NVIDIA B300 / Blackwell Ultra support if you are on that hardware, CPU KV cache offloading (longer context stays usable), DBO microbatch generalization, vision encoder CUDA graphs (only matters if your shim translates Anthropic image content blocks into vLLM multimodal input). Dies at the shim unless the shim explicitly forwards them: the new /v1/chat/completions/batch endpoint (the shim listens on /v1/messages, not on /batch), the new tool parsers (GigaChat, Kimi-K2.5, Gemma 4 native parsing) only matter if the shim hands the model's raw text back through Anthropic's tool_use envelope rather than parsing it itself, structured-output JSON Schema enforcement (the shim has to forward Anthropic's tool input_schema as vLLM's response_format), guided decoding flags. Irrelevant for an interactive Mac agent: most server-side tuning knobs and operations metrics, since the agent loop is pure request/response from the agent's seat.

Three pieces in front of one open-source model. First, run vllm serve with v0.19.0 (vllm serve google/gemma-4-31b-it --port 8000 or whatever model you want). Second, run an Anthropic-shape translator on a different port: claude-relay --backend vllm --base-url http://127.0.0.1:8000 --port 8766 is the simplest one-liner, or use LiteLLM's anthropic adapter as a long-running proxy. Third, open Fazm Settings, find AI Chat > Custom API Endpoint, flip the toggle on, paste http://127.0.0.1:8766. The setting is backed by the AppStorage key customApiEndpoint (Desktop/Sources/MainWindow/Pages/SettingsPage.swift line 840) and the placeholder text in the field is exactly https://your-proxy:8766. When you save, ChatProvider.restartBridgeForEndpointChange runs and the next subprocess inherits ANTHROPIC_BASE_URL pointing at your shim. From that turn forward, every Ask Fazm query routes through your local vLLM v0.19.0.

No, not directly. The new batch endpoint is async by design: you submit a batch of prompts and poll for results, similar to OpenAI's batch API. A Mac agent like Fazm runs a tight interactive loop where each turn needs a streaming response within a couple of seconds because the user is watching. The shim that sits in front of vLLM listens on /v1/messages with streaming SSE; the batch endpoint is a separate path that the shim has no reason to forward. So the headline release-notes item that closes a real gap with SGLang for offline workloads is one of the v0.19.0 features that does not change how a Mac agent feels at all. Where it does help indirectly: if you run agent traces overnight to evaluate a new model, you can hit /v1/chat/completions/batch directly without going through the shim, then read the results in the morning.

Gemma 4 native tool-parser support, paired with online MXFP8 quantization. The Mac agent loop fires tool_use JSON content blocks every turn against a five-MCP server surface (fazm_tools, playwright, macos-use, whatsapp, google-workspace). When the model's tool-use JSON is malformed, the Claude Code runtime rejects the turn and the session stalls. v0.19.0's new Gemma 4 tool parser means vLLM itself parses the structured-output blocks, so the shim does not have to invent a brittle text-to-tool-use translation. Combined with MXFP8 dropping per-token latency on the same B-series hardware, the practical effect is that a 31B Gemma 4 dense behind a self-hosted vLLM v0.19.0 plus a thin Anthropic-shape shim feels closer to a hosted API than v0.18.x ever did.

Three to know. v0.19.0 requires transformers>=5.5.0 for Gemma 4, so any environment that pinned an older transformers will fail model loading on first launch (the v0.19.0 release notes call this out under breaking changes). The DBO microbatch optimization generalization changed behavior for some custom model architectures that relied on the older single-architecture path. The v0.18.1 patch from March 31 fixed SM100 MLA prefill issues and DeepGEMM accuracy problems for Qwen3.5, and those fixes are bundled into v0.19.0, so if you skipped 0.18.1 and went straight to 0.19.0 you also picked up that fix silently. The v0.19.1 hotfix on April 8 then patched a regression in zero-bubble async scheduling when speculative decoding was enabled simultaneously, which is one of the headline new combinations. v0.19.2 on April 14 cleaned up an MXFP8 numerical edge case for Llama-shape models.

The Fazm desktop app captures the macOS accessibility tree of the foreground window through AXUIElementCreateApplication (Desktop/Sources/AppState.swift line 439) and feeds the structured tree to the model as text on every turn. While you are upgrading, you can have the GitHub release-notes page open in a browser and Terminal.app showing your vllm serve logs side by side, then ask Fazm to compare them. Because Fazm reads each app through accessibility APIs and Playwright (not by sending screenshots), it gets verbatim text from the release page and exact text of the log output, which means the model can pick out which release-notes items are relevant to the actual flags your vLLM is launched with.

Two reasons. First, the SERP for vllm release notes april 2026 is dominated by transcribed changelogs aimed at vLLM operators serving production traffic to OpenAI-shape clients, which is most of vLLM's userbase. Second, the small overlap of people who both run vLLM and want to drive a desktop Mac AI agent through it has, until recently, mostly been DIYing through OpenAI-shape clients (which means a different agent than Fazm) or through the hosted Anthropic API directly (which means no vLLM at all). Fazm's Custom API Endpoint setting plus the maturation of Anthropic-shape translators in early 2026 is what makes this seat a real one. None of the existing v0.19.0 roundups cover it.

It depends on the model behind vLLM, not on vLLM itself. For interactive Ask Fazm latency (the agent feels live below about 2 seconds per turn), Gemma 4 9B or Qwen 3 7B on a single H100 with MXFP8 quantization is comfortable for a small group of users. Gemma 4 31B dense fits on one H100 80 GB and gives stronger tool-use JSON stability, at the cost of per-turn latency. The 754B-class GLM-5.1 is not a self-host story for a Mac agent operator, period. The v0.19.0 release notes also add Blackwell Ultra B300/GB300 support which matters if you are on that hardware tier, otherwise the SM 10.3 paths do not affect you. CPU KV cache offloading (also new in v0.19.0) is useful when you push past the per-GPU VRAM budget on long multi-turn agent sessions.