deepseek-flash 每百萬 token 價格較低，但程式碼任務單次成本高於 glm-5.3

I measured nine model-task combinations on the same endpoint. Per-million pricing predicted almost none of it.

Every "which model is cheapest" post compares price per million tokens. That number is easy to find and almost useless for deciding what to run.

So I measured the thing that actually shows up on a bill: what one request costs, on three task shapes, across three model families. Everything below comes from the usage fields the API returned, not from a price list.

Method

Same endpoint, same key, same three prompts, three runs each, reporting the median.

• short — "In one sentence, what is a prompt cache?" (a chat reply you'd get from any assistant)
• code — "Write a Python function that validates an email with a regex. Only code." (a small, well-scoped generation)
• long — a ~400-token input asking for a three-sentence summary (input-heavy, output-light)

Cost per request = input tokens × input rate + output tokens × output rate.

The numbers

Finding 1: the "cheap" model cost 70% more

On paper deepseek-flash is $0.68 in / $2.75 out per million. glm-5.3 is $3.50 / $11.00 — roughly five times more expensive on every line of the price table.

On the code task, the expensive model was half the price per request.

The reason is in the output column: 509 tokens versus 68 for the same prompt, producing a function of similar length. The cheap-per-token model simply wrote more — explanation, alternatives, a docstring you didn't ask for. You pay for all of it at the output rate, which is 4× the input rate.

Per-million pricing assumes every model emits the same number of tokens for the same request. They don't.

Finding 2: output is the bill, not input

Take the two extremes:

• deepseek-flash, code task: 45 input tokens, 509 output. 97% of the cost was output.
• glm-5.3, long task: 378 input tokens, 70 output. 37% of the cost was output.

So "input is cheap, right?" depends entirely on what the model does after reading it. A 400-token input is almost free; a model that answers it in 700 tokens is not.

This is also why "summarise this document" and "write me a function" have completely different economics even though both are one API call.

Finding 3: latency follows output too

Median wall time on the short task: 1.0s (deepseek-flash), 2.2s (glm-5.3), 1.3s (kimi-k2.6). On the code task, 1.5–2.9s.

The slow requests were always the ones emitting a lot of tokens, never the ones with a long input. If a call feels like it's hanging, look at the output length before you blame the network.

What I'd actually do with this

1. Measure your own three shapes. Take three prompts that represent the bulk of your traffic — a short one, a generation one, an input-heavy one — and log usage for each. Ten minutes of work, and it replaces every "cheapest model" list you've read.
2. Route by task, not by model ranking. A short classification call and a 2,000-token refactor are different purchases. One model winning the first says nothing about the second.
3. Watch output length, not just rate. If a prompt starts producing noticeably longer answers after a model update, your bill moves even though the price per million didn't.
4. Check variance before you trust a number. On one model, the code task varied 2.5× across consecutive runs of the identical prompt. A single measurement is an anecdote, which is why the table above is medians of three.

Reproduce it

Any OpenAI-compatible endpoint returns the fields you need:

curl https://api.switchllm.net/v1/chat/completions \
  -H "Authorization: Bearer $SWITCHLLM_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-flash",
    "messages": [{"role": "user", "content": "In one sentence, what is a prompt cache?"}]
  }'

The usage object in the response has prompt_tokens and completion_tokens. Multiply by your provider's rates and you have the real cost of that request. Log those two numbers for a day and you'll know more about your bill than any comparison table can tell you.

Caveats

• One run per cell, three repetitions, medians. Variance is real — see point 4 above.
• Rates are the ones on the endpoint I used, at the time of writing. Your provider's rates will differ; the shape of the finding is what generalises.
• The prompts are synthetic and small. Real application prompts are longer and messier, and a single number per task hides a wide distribution.
• Provider-side caching, if enabled, changes input costs substantially and is not reflected here.

Disclosure

I run SwitchLLM — the OpenAI-compatible endpoint these measurements were taken on. One key for DeepSeek, GLM and Kimi, prepaid from $9.9, sign-up with an email address.

Everything above is the advice I'd give you on someone else's platform: the point is that per-million pricing doesn't tell you what a request costs, and the only way to know is to measure yours.