Schematron V2 Small Guide: HTML to JSON With a Specialist

Extraction usually fails quietly. A model returns valid JSON for a product page, the parser is happy, and the variant table with six sizes and three prices has collapsed into a single price field. Nobody notices until a customer does. The more nested the schema, the more often it happens.

Schematron V2 Small is Inference.net's model for the hard end of that range. It takes HTML and a JSON schema and returns JSON that fits the schema, and of the two V2 models it is the one tuned for extraction quality rather than throughput.

This is not a chat model

The most important thing to know before calling it: the schema is the instruction. Provider documentation for V2 Small says extraction instructions must be supplied through a JSON schema in response_format, not through system or user prompts. The HTML goes in the message; what you want out of it goes in the schema.

That inverts the usual habit. With a general model you describe the task in prose and hope the output parses. Here, field names, types, descriptions and required lists carry all the intent. A field called price with no description and no type is an underspecified request, and the model cannot ask what you meant.

{
  "type": "json_schema",
  "json_schema": {
    "name": "product",
    "strict": true,
    "schema": {
      "type": "object",
      "properties": {
        "name": { "type": "string" },
        "price": { "type": "number", "description": "Current sale price, no currency symbol" },
        "currency": { "type": "string", "description": "ISO 4217 code" },
        "in_stock": { "type": "boolean" }
      },
      "required": ["name", "price", "currency", "in_stock"]
    }
  }
}

OpenRouter lists no tool calling for it, and an output cap of 4,096 tokens. Both are consistent with the job: one page in, one object out.

Small, Turbo and the original 8B

Inference.net announced the V2 generation on 16 April 2026 with two models, and OpenRouter lists V2 Small from 12 September 2026. Provider listings describe it as a 3B-parameter model, and the pricing table in Inference.net's launch post calls the pair V2 3B and V2 3B Turbo, though the post gives no further detail on size. Its numbers, all from Inference.net's own evaluation:

• Extraction quality, graded 1 to 5 by GPT-5.4: V2 Small 4.060, V2 Turbo 4.039, original Schematron 8B 4.070, original 3B 3.909.
• Throughput on one H100 with 10K input and 500 output tokens: V2 Small 2.47 requests per second, V2 Turbo 4.14, original 8B 1.63.
• SimpleQA as a search pipeline, with GPT-5 Nano answering from Exa results: 83.10 with V2 Small doing extraction, 79.42 with Turbo, 85.58 with the original 8B, against 8.54 for GPT-5 Nano with no search at all.

Read together: V2 Small gives nearly the old 8B's quality at the old 3B's speed. Turbo trades a little quality for about two-thirds more throughput. The grading is LLM-as-judge on Inference.net's own data, so treat the small gaps as noise and the large ones as signal. The jump from the original 3B to V2 Small is the meaningful one.

If you are deciding between the two V2 models, the Schematron V2 Turbo guide covers the throughput side. The short rule: Small for complex schemas and long, messy pages; Turbo when volume is high and the schema is simple.

Closed weights this time

The first Schematron models, at 8B and 3B, were published on Hugging Face in 2025. V2 is different: Inference.net says the V2 weights remain closed and are available only as a hosted API, which is also how OpenRouter serves them.

That changes the calculation for anyone who was planning to self-host. If you scrape at a scale where a dedicated GPU is cheaper than per-token billing, or you cannot send page content to a third party, the open V1 models are still the option you control. V2 Small is a managed service.

What it costs at scale

Inference.net's launch post priced V2 Small at $0.10 per million input tokens and $0.25 per million output, while the OpenRouter listing showed $0.05 and $0.23 at the time of writing, so check before budgeting. Extraction is input-heavy, so the input price dominates. A million pages a month at 10,000 input tokens each is ten billion input tokens: about $1,000 at the launch price or $500 at the OpenRouter listing, before output.

That is the number to compare against a general model doing the same work. The saving comes from the input side, and it is only real if quality holds on your pages. Stripping scripts and styles before sending is still the single largest cost lever. Inference.net's documentation recommends it, while advising you to err on the side of removing too little rather than too much.

When a general model is the better choice

• When the input is not HTML: PDFs, emails, free text. Schematron is built and evaluated for web markup.
• When the extraction needs judgement beyond the page, such as normalising a vague category against your own taxonomy.
• When volume is low. At a few hundred pages a day the saving does not pay for a second provider in your stack.

For everything else, run a fair test: take fifty pages from your real crawl, hand-label the expected JSON, and compare field-level accuracy against the general model you use now. LLM data extraction covers designing the schema first, and structured outputs and JSON mode explains why schema-valid JSON can still be wrong, which is what your labels are there to catch.