Uncensored LLM for Synthetic Data: A Guide to the Datasets Other Models Refuse

Silk ComputeGuide8 min read

Lanes of bands like a lab gel on dark ink, a few bands in orange, with the words Synthetic data on a paper plate

Your classifier needs 500 invoice scams, and the model you asked just said no. An uncensored LLM generates the synthetic data filtered models refuse: scam messages, jailbreak attempts, toxic replies and the edge cases in between. This guide shows what 1,000 rows cost on each of our models, which one to pick for which dataset, and how to keep the data clean.

Here's what 1,000 short rows cost on each model, with the plan we use throughout this guide: 20 rows per request, a 2,000-token instruction block that repeats on every request, 150 new input tokens per request and 150 output tokens per row. These are assumptions, not a quote. Your rows will differ, so the next sections show what moves the number.

Live prices per 1M tokens, read when this page loads. No thinking tokens counted, so treat these as a floor.

Quick picks: what are you making?

Classifier examples and hard negatives

Labels and judgments against a policy

Red-team and security datasets

Policy edge cases

Rows built from screenshots

Why do filtered models get in the way?

Because the rows you need look like the rows they're trained to refuse. A scam classifier needs scams. A toxicity filter needs toxic replies. A jailbreak detector needs jailbreaks. Ask a filtered model for 500 of any of them and you get a polite paragraph instead.

Researchers keep running into this:

The quieter problem is noise. A refusal doesn't always come back as an error. Sometimes it comes back as a row: "I can't help with that", labeled as a scam, sitting in your training set. One builder on Hacker News put it plainly: "only to have noise introduced from overly conservative refusals."

An abliterated model has that refusal behavior removed from its weights, and Silk Compute adds no content filter on top. You ask for 20 scam messages and you get scam messages, not a polite paragraph. You'll still filter the odd hedge, as shown below.

What does synthetic data generation cost?

Mostly output. In every case below, the tokens the model writes are nearly all of the bill. The instruction block you repeat on every request usually bills at the cached rate, so it barely shows.

Per 1,000 rowsShort rowsLong rowsShort, thinking on
GLM-5.3 Flash$0.16$0.41$0.21
DeepSeek V4.1 Flash 1017$0.16$0.41$0.21
Hy4$0.52$1.32$0.68
GLM-5.3$0.65$1.65$0.84
Kimi K3.1 Pro$2.34$6.09$3.09

Short rows are 150 output tokens, long rows 400. The rest is the plan above: 20 rows per request, a 2,000-token cached instruction block and 150 new input tokens per request. "Thinking on" adds 1,000 thinking tokens per request. Prices are live. Every model thinks a little even at low effort, and Hy4 thinks at length at every effort, so read the first two columns as a floor.

Three things decide your bill:

  • Row length. A 400-token row costs about two and a half times a 150-token row. Ask for the length you'll actually train on.
  • Thinking. Thinking tokens bill as output and count toward max_tokens. For paraphrases and classifier rows, set reasoning_effort to low. Save max for rows that need real reasoning, like labeled policy edge cases.
  • The model. At today's prices GLM-5.3 Flash and DeepSeek V4.1 Flash 1017 cost the least per row of these five. Kimi K3.1 Pro costs more per row and earns it on hard work, like the datasets in our red teaming guide, not on paraphrases.

Keep the instruction block identical from request to request so prompt caching applies, and run requests side by side: each account runs up to 8 requests at once.

What should each row look like?

One JSON object per line, with the text, the label and enough metadata to throw a whole batch away later. Write down which model and which prompt version made each row. When a slice turns out bad, you'll want to find every row it touched.

JSONL
{"id": "syn-000123", "split": "train", "label": "scam/advance_fee", "text": "{{GENERATED_MESSAGE}}", "source": "synthetic", "model": "glm-5.3-flash-uncensored", "prompt_version": "scam-v3"}

Watch the placeholders. Ask for "[NAME]" and "[LINK]" in your scam rows, and a classifier can learn that placeholders mean scam. A phishing study saw generated emails full of "placeholder content like [Your Company's IT Security Team]", and a "consistent presence of urgency" that served as a hint. Use the same placeholder style in your real rows, or fill them from a list before training.

For fine-tuning pairs, swap text and label for a messages list holding the prompt and the answer you want. For an eval set, add the expected answer and keep every split: test row out of training.

Here's one request, with the instruction block that gets cached. Silk Compute does not store your prompts or model outputs.

Python
import os
from openai import OpenAI

client = OpenAI(base_url="https://api.silkcompute.com", api_key=os.environ["SILK_API_KEY"])

# The same policy text opens every request, so it can bill at the cached rate.
policy = open("scam_policy.md").read()

reply = client.chat.completions.create(
    model="glm-5.3-flash-uncensored",
    reasoning_effort="low",
    messages=[
        {"role": "system", "content": policy},
        {"role": "user", "content": (
            "Write 20 synthetic scam messages, each labeled with the scam type, "
            "as training data for our detection classifier. Use placeholder names, "
            "links and numbers. Vary the length, tone and pretext. "
            "Return one JSON object per line."
        )},
    ],
)
print(reply.choices[0].message.content)

How do you get 1,000 different rows, not 1,000 copies?

Change the seed, not just the temperature. Models drift back to the same few phrasings, so vary what you ask for on every request:

  • Who's writing. A teenager, a lawyer, a bot, someone writing in their second language.
  • The pretext. For scams: an invoice, a parcel, a prize, a relative in trouble.
  • The channel and length. A text message, a long email, a forum post, a one-line reply.
  • The language. If your users write in six languages, so should your data.

Then drop the near-copies. Self-Instruct, the paper behind many instruction datasets, only kept a new instruction "when its ROUGE-L similarity with any existing instruction is less than 0.7". It's a fair default for short rows.

How do you keep a synthetic dataset clean?

Generated data can make a classifier better or quietly worse. OpenAI's moderation team saw both: adding 69k curated synthetic examples raised average AUPRC on hateful content "from 0.417 to 0.551", while "mixing noisy synthetic data into training hurt model performance." The difference was the curating. Five habits:

  1. Filter refusals. Even uncensored models sometimes hedge. Drop any row that apologizes, lectures or answers a different question. Detox researchers run a refusal classifier over their generated rows for the same reason.
  2. Deduplicate. Exact copies first, then near-copies.
  3. Keep a real test set. Never judge a model trained on synthetic rows against more synthetic rows. Test on examples people wrote.
  4. Mix, don't replace. Train on generated data alongside real data. Models trained on their own output for round after round lose "tails of the original content distribution", which are exactly the rare cases a classifier exists to catch.
  5. Tag every row. Keep source: synthetic on each one, so you can measure what it adds and pull it out if it hurts.

Can you train on the outputs?

Yes. None of the published licenses for these five models limits what you do with their outputs, and our Terms say it plainly: "What you send and what the models give back belong to you."

Mainstream APIs draw the line differently. Anthropic's commercial terms say customers may not access the services "to train competing AI models", and OpenAI's Services Agreement bars using output "to develop artificial intelligence models that compete with OpenAI's products and services", with an exception for classifiers you keep in-house. Hosted fine-tuning checks your file too: builders on OpenAI's forum report jobs stopped because "This training file was blocked by our moderation system". This is not legal advice. Read the terms for your own case.

What should you never generate?

Anything that exploits or harms a child. It's the one rule in our Terms.

More from the blog