ML Env

Use casesCatalogue content

Rewrite one master listing for Amazon, bol.com and eBay

Reshapes one master product record per marketplace — Amazon bullets, Dutch bol.com titles, eBay item specifics — following rule sheets you maintain.

How it works
You keep one master product record; the model reshapes it per channel — Amazon's title conventions and five bullet points, bol.com's Dutch-language titles without prices, promotions or special characters, eBay's item specifics — following a written rule sheet you maintain for each marketplace. It only rewrites and reformats facts you supply; it is not asked to know anything about your products or the marketplaces on its own.
Data you need
Your master product content, plus a current, written style and rules document per marketplace and category: character limits, forbidden content, required attributes. Most shops do not have such a rule sheet written down yet — expect a one-off effort to distil it from each marketplace's seller documentation before this works. The model's built-in knowledge of marketplace rules is stale by definition; the rule sheets must come from you and be kept current.
What to expect
Removes the grind of maintaining three or four versions of every listing by hand, and applies your rules consistently once they are written down. Compliance rests on your rule sheets, not on the model — marketplace category requirements change often and no offline model tracks them. Even with good rules the model can occasionally drop a required attribute, run over a character limit, or slip in promotional wording a marketplace forbids, so listing rejection remains possible. Treat first batches per category as tests. If you have no written rule sheets, building them is the real first step of this project.
Where people stay involved
Someone who runs the marketplace account reviews output per category before upload and owns keeping the rule sheets up to date when marketplaces change policy. For bol.com, have a Dutch speaker spot-check the first batches — the model writes competent Dutch, but nuance and category jargon deserve a native eye.

Which model, and what it costs to run

Qwen3-32B

This job runs in bulk rather than to a waiting person, so size is not the constraint — we take the strongest independent score on structured output and tool calls that we may serve freely and that fits on a single card.

Licence
Apache-2.0
Weights at 4-bit
18 GB
Context
32K tokens
Publisher
Alibaba (Qwen Team)

What the hardware costs

One 48 GB card holds it

Rent in the EU
$1.60/hrScaleway, Paris (PAR2)
Buy the card
$7,569new, one-off
Or rent it by the token
$0.12 / $0.12per M in / out · Nebius AI Studio · EU

Hardware only, third-party prices from 2026-07. The figure excludes the KV cache, which grows with context length and how many people use it at once — sized properly in a conversation, not guessed here. Renting by the token is cheaper up front; why our customers still self-host is below.

Structured output and tool calls

Berkeley Function Calling Leaderboard · v4 · 13 of 18 models measured

Measured in a sandbox, on somebody else's functions. It tells you which models are capable of the shape of the job, not which one will survive contact with your API.

GLM-4.672.38%Kimi K259.06%DeepSeek-V3.254.12%Qwen3-32B48.71%Qwen3-235B-A22B47.99%Qwen3-8B42.57%Qwen3-30B-A3B41.39%Qwen3-14B41.03%
Longer is betterFree to serveConditions apply⚠ answered under 95%

Independent measurement · UC Berkeley (Gorilla project) · board updated 2026-04-12

Writing in your voice

No benchmark measures this

There is no benchmark for this and there is unlikely ever to be one. Anyone who shows you a chart ranking models on marketing copy has drawn it from a model's opinion of another model.

So we do not show a chart here. We measure it on your own content, in the first week, and you see the result before anything ships.

The API is cheaper per token. Here is why our customers don't use it.

We will not pretend otherwise: renting a model by the token from a serverless API costs less per million tokens than a card we run for you. We show that price on every use-case page. What it does not include is the part a shop with a customer database actually pays for.

  1. 01

    Your data never leaves hardware you can point at

    A serverless "we don't retain your data" is a clause in a contract. Running the model on a card in Amsterdam is a fact of architecture: your catalogue, tickets and customer records are never sent to a third party at all. For a GDPR audit, that is the difference between a promise and a floor plan.

  2. 02

    The price cannot move without your say-so

    A serverless rate card is somebody else's lever. The provider can raise the price, retire the model, or change the terms, and your cost moves with it. The same model on the same card costs the same next year — you own the number.

  3. 03

    The model cannot be taken away

    Hosted APIs deprecate models on their own schedule; the one you built on can be gone in a quarter. An open-weight model on your own hardware runs for as long as you keep the lights on. No vendor can end-of-life it out from under you.

And the price gap closes with volume: past a card you keep busy — very roughly four billion tokens a month — owning is cheaper outright, even before the three reasons above.

Getting a case like this one from a conversation to production takes about two months, and you can stop at the end of any phase.

Next

Tell us what your team does by hand

Describe the process that takes the most time. We will say plainly whether a model is the right tool for it.