Point a coding agent at DeepSeek V4 Pro or Qwen3.8-Max for real infrastructure work and both hand back valid Terraform, Kubernetes, and Ansible on the first try. The models are close enough on quality that the decision comes down to what each one costs to finish a job, and the cost gap is not the one the sticker price predicts. So we stopped reading their answers and started running them.
This is a DeepSeek vs Qwen for DevOps comparison built on execution, not vibes. Eleven tasks that a platform engineer actually ships: an OpenTofu VPC module, a Kubernetes manifest set, an Ansible role, a Puppet manifest, a GitHub Actions pipeline, an Argo CD Application, a multi-stage Dockerfile, a PostgreSQL schema, a hardened systemd unit, a broken nginx config to repair, and a metrics-parsing one-liner. Every answer was graded by feeding it to the real tool and reading the exit code.
Everything below is measured, not guessed. Both models ran through OpenRouter in September 2026 at temperature zero, three runs per task, and every answer was graded by executing it on a throwaway Ubuntu 26.04 machine.
The two models
Both are flagship releases from the two Chinese labs whose models now show up in most agent stacks, and they are built differently. DeepSeek V4 Pro is the current top of the DeepSeek line, a text-only mixture-of-experts model. Qwen3.8-Max is Alibaba’s newest and largest Qwen, a 2.4-trillion-parameter mixture-of-experts model that also accepts image and video input. How each one is served tells you something before a single token is generated. Qwen runs on exactly one endpoint, Alibaba’s own cloud, because the weights are proprietary. DeepSeek is served by twenty-plus providers on OpenRouter, which is what open weights look like in practice. We priced DeepSeek on StreamLake, one of those routes, at the rate it billed during testing. DeepSeek’s own endpoint is cheaper still, so every cost number here is conservative toward DeepSeek rather than against it.
| DeepSeek V4 Pro | Qwen3.8-Max | |
|---|---|---|
| OpenRouter slug | deepseek/deepseek-v4-pro-0813 | qwen/qwen3.8-max-0902 |
| Released | August 2026 | September 2026 |
| Inputs | Text | Text, image, video |
| Priced endpoint | StreamLake (test-time route) | Alibaba (Qwen’s own cloud) |
| Input / output per 1M | $1.05 / $3.15 | $2.00 / $6.00 |
| Context window | 1M tokens | 1M tokens |
| Reasoning control | reasoning_effort | reasoning_effort |
| Weights | Open (20+ providers) | Proprietary (Alibaba only) |
| Hostable sibling | V4 Flash (284B, runs on 128GB) | Open-weight family (dense + MoE) |
Qwen Max lists at roughly twice DeepSeek’s per-token rate. The interesting question is whether it earns that on real work, and on a few tasks it inverts entirely.
How the tasks were graded
Each prompt asked for one artifact and nothing else, no prose. The output went straight to the authoritative checker for that domain: tofu validate for Terraform, kubectl apply --dry-run=server against a live kind cluster for Kubernetes, an ansible-playbook syntax and module check for Ansible, puppet parser validate for Puppet, actionlint for the pipeline, a server-side dry run against the installed Argo CD Application CRD for GitOps, a full docker build plus run plus a curl of the health endpoint for the Dockerfile, an apply then re-apply then assert loop on a real Postgres for the schema, systemd-analyze for the unit, nginx -t for the incident fix, and an output diff for the metrics one-liner. A task passed only if the tool said so.

The scorecard
At default reasoning, Qwen passed all eleven tasks and DeepSeek passed ten. The single miss was the Dockerfile, and it was the same miss on all three runs. Everything else validated, built, applied, or ran for both models.
| Task | Authoritative check | DeepSeek | Qwen |
|---|---|---|---|
| Terraform / OpenTofu | tofu validate | Pass | Pass |
| Kubernetes | kubectl dry-run=server | Pass | Pass |
| Ansible | syntax + module resolve | Pass | Pass |
| Puppet | puppet parser validate | Pass | Pass |
| GitHub Actions | actionlint | Pass | Pass |
| Argo CD / GitOps | dry-run vs Application CRD | Pass | Pass |
| Dockerfile | build + run + curl /healthz | Fail | Pass |
| PostgreSQL schema | apply + idempotent + assert | Pass | Pass |
| systemd unit | systemd-analyze verify | Pass | Pass |
| nginx incident | nginx -t | Pass | Pass |
| Observability awk | output diff | Pass | Pass |
The two hardening-sensitive tasks are worth calling out because they came back identical. Both models produced a systemd unit that systemd-analyze security scored at an exposure level of 2.2 on its ten-point scale, where lower is safer. Both reached for the same lockdown set: NoNewPrivileges, ProtectSystem=strict, the full Protect* and Restrict* block, a SystemCallFilter of @system-service, an emptied CapabilityBoundingSet, and a StateDirectory. There is no hardening gap between them.
The one task DeepSeek got wrong
DeepSeek’s Dockerfile built cleanly, produced a 66MB image, and then the container died the moment it started. The health check never had a chance.
Error: ModuleNotFoundError: No module named ‘app’
The build copied the application into the image with a flat layout, then tried to launch it as if it were a package. The final two lines contradicted each other:
COPY --chown=65532:65532 app /app WORKDIR /app CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]
Copying app to /app puts main.py directly at /app/main.py, so with /app as the working directory the module is main, not app.main. Uvicorn looked for a package named app, found nothing, and exited. The container logs said it plainly:
ModuleNotFoundError: No module named 'app'
Qwen avoided the trap by copying into a nested path that matched its own launch command, so its container served {"status":"ok"} on every run. The strange part is what happened when we turned DeepSeek’s reasoning down. At effort=low it switched to a nested copy layout that agreed with the same launch command, and the Dockerfile started passing. Lower effort produced the working file and the default produced the broken one. That is the opposite of the usual trade-off, and it is a good argument for testing whatever a model hands you rather than trusting the higher setting to be safer.
Cost is where they actually separate
Across all eleven tasks at default reasoning, DeepSeek billed $0.108 and Qwen billed $0.275. Qwen cost about two and a half times as much to do the same work. But that average hides a split personality. On some tasks Qwen was the cheaper model, and on others it was four to five times more expensive.

Qwen came in cheaper on Terraform, GitHub Actions, and the nginx incident. It was far more expensive on Ansible, the Dockerfile, and the metrics one-liner. The reason is not the token price, it is how much each model decides to think before answering.

DeepSeek reasons more on Terraform, which is why Qwen wins that one on price. Qwen reasons far more on Ansible, the Dockerfile, and the metrics task. The clearest example is the observability one-liner: a single awk command that both models got right. DeepSeek spent about 4,900 reasoning tokens and eighty-nine seconds on it. Qwen spent 14,600 reasoning tokens and just under seven minutes, and it billed $0.091 for that one line. Same correct output, more than five times the price, because Qwen would not stop thinking about a trivial problem.
The reasoning dial changes everything
Both models take a reasoning_effort parameter, and dropping it to low is the single biggest lever on the bill. It cut DeepSeek’s total by about 46 percent and Qwen’s by about 80 percent. Qwen’s default reasoning was so inflated on a few tasks that turning it down brought the two models to a dead heat.

At low effort the whole suite cost $0.058 on DeepSeek and $0.056 on Qwen. The quality picture holds up better than you would expect. Qwen still passed all eleven tasks at low effort. DeepSeek’s low-effort run fixed the Dockerfile but lost one of three runs on the awk task, where a corner case in the field parsing slipped through. For unattended code that will be applied without a human reading it, Qwen at low effort is the value pick: it stays correct and it is as cheap as DeepSeek. For anything you will review anyway, either model at low effort is fine, and default effort mostly buys you longer waits.
Which one can you self-host
Neither flagship runs on a homelab box. DeepSeek V4 Pro ships as open weights but at a scale that only makes sense on rented hardware, and Qwen3.8-Max is proprietary, API only. The difference shows up one rung down. DeepSeek’s hostable option is V4 Flash, which we have run at roughly six tokens per second on a 128GB machine, covered in running DeepSeek V4 Flash locally. Qwen’s open-weight range is broader and genuinely runnable, spanning small dense models up to larger mixture-of-experts releases that fit on a serious local AI GPU box. If self-hosting is the goal, Qwen gives you more real options, even though the model we tested here is not one of them.
Which to run, and at what reasoning setting
On correctness these two are a wash for infrastructure code, so pick on cost behavior and the one failure mode you saw. If you run at default reasoning, DeepSeek is cheaper overall and faster, with the caveat that its default Dockerfile shipped a broken launch command that a build would not catch. If you run at low reasoning, which is the setting most agent workloads should use, Qwen is the pick: it held a perfect score and matched DeepSeek’s price once its over-thinking was capped. Whichever you choose, put a real validator in the loop, because both models produce output that looks right and occasionally is not, and the only reliable way to know is to run it. For a broader field beyond these two, our open source LLM comparison tracks the rest, and the same execution-graded method drove our DeepSeek V4 versus Kimi K3 for DevOps writeup and the walkthrough on pointing AI coding agents at Terraform, Ansible, and Kubernetes.