I Connected Qwen3.8-27B to DeepSeek Harness

After Qwen3.8-27B was open-sourced, my first reaction wasn't to check the benchmarks.

It was: can I plug it into DSH?

Running a model on its own makes it, at best, a talking API.

Connecting it to Harness, where it can read files, run commands, invoke tools, and continue working based on the results, is what gives it real hands and feet.

The answer is: yes.

And the whole process was simpler than I imagined.

The core is just two steps:

First, get Qwen3.8-27B running with vLLM, then plug its OpenAI-compatible API endpoint into DSH.

First, Get Qwen3.8-27B Running

This deployment uses Qwen3.8-27B-FP8.

Qwen3.8-27B is a 27B dense model natively supporting a 262,144 token context, commonly referred to as 256K. The official vLLM Recipe also specifically provides reasoning parsing and tool-call parsing configurations, both of which are key for integrating with DSH. ([vLLM Recipes][1])

Image: Qwen3.8-27B deployment page in vLLM Recipes

I started it directly using Docker:

docker run -itd \
  --restart always \
  --name llm_server \
  --gpus '"device=2"' \
  -e CUDA_VISIBLE_DEVICES=0 \
  -v /data/pretrained_models/Qwen3.8-27B-FP8/:/models/Qwen3.8-27B-FP8 \
  -p 8004:8000 \
  vllm/vllm-openai:v0.21.0 \
  --model /models/Qwen3.8-27B-FP8 \
  --served-model-name Qwen3.8-27B-FP8 \
  --gpu-memory-utilization=0.95 \
  --dtype auto \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len=262144 \
  --tensor-parallel-size=1 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --max-num-seqs 512 \
  --mm-encoder-tp-mode data

This command looks long, but only a few parameters really matter.

--max-model-len=262144 sets the maximum context length to 256K.

However, this is just the upper limit; it doesn't mean every request must fill it. The longer the context, the larger the KV Cache footprint. If you run out of VRAM at startup, you can first lower it to 65536 or 131072, get it running, and then gradually increase it.

--served-model-name Qwen3.8-27B-FP8 is also very important.

The model ID you fill in DSH later must match this exactly. If the names don't match, DSH will tell you it can't find the model even though it's already running.

Then there are these three parameters:

--reasoning-parser qwen3
--enable-auto-tool-choice
--tool-call-parser qwen3_coder

The first one parses the model's reasoning content, and the latter two are responsible for recognizing and parsing tool calls.

After all, connecting to DSH isn't about giving the model a new interface to chat with you.

The real test is whether it can correctly invoke Bash, read files, modify code, and then continue working based on the results returned by the tools.

There's also something that looks a bit odd:

--gpus '"device=2"'
-e CUDA_VISIBLE_DEVICES=0

This isn't a mistake.

The first device=2 means using GPU number 2 on the host machine. Once this card enters the container, it gets remapped to GPU number 0 inside the container, hence the subsequent CUDA_VISIBLE_DEVICES=0.

It's a layer of nesting, but the logic is sound.

If you are not using a pre-configured Docker image but installing vLLM directly in a local Python environment and encounter model configuration or Processor loading errors, first check the transformers version. The official Recipe requires transformers >= 5.8.0. ([vLLM Recipes][1])

Don't Rush to Open DSH

After the model starts, first check the endpoint.

curl http://127.0.0.1:8004/v1/models

If the returned result shows:

Qwen3.8-27B-FP8

It means the vLLM service is up and running normally.

It's best not to skip this step.

Otherwise, when DSH fails to connect later, you'll easily suspect the model isn't supported or the tool calls are broken, and after a lot of tinkering, you'll finally realize the port just wasn't reachable.

Then Plug the Model into DSH

Next, start DeepSeek Harness:

npx @deepseek-ai/dsh web

After opening the DSH workspace, go to:

Settings → Models → Add Custom Provider

DSH natively supports connecting to self-hosted OpenAI-compatible services. You need to fill in the Provider ID, API address, interface protocol, and model information. After saving, new requests will use the new configuration immediately without restarting DSH. ([GitHub][2])

My configuration here is roughly:

Provider ID: qwen-local
Display Name: Qwen Local
API Address: http://<Model Server IP>:8004/v1
API Protocol: openai-completions
Model ID: Qwen3.8-27B-FP8
Model Name: Qwen3.8-27B-FP8

If DSH and vLLM are on the same machine, the API address can be filled in directly as:

http://127.0.0.1:8004/v1

If they are on different machines, use the actual IP of the model server.

If the local vLLM has no API authentication configured, the API Key can be left blank; if a Key was set when starting the service, fill it in according to the actual value.

I'll emphasize this once more:

The model ID in DSH must be completely identical to vLLM's --served-model-name.

Not a single character should differ.

After saving, go back to the chat page and find the newly added Qwen3.8-27B-FP8 in the model selector.

At this point, the model is officially installed in DSH.

After Connecting, the Point Isn't Just Saying "Hello"

A normal conversation returning successfully only proves the interface is working.

For Harness, that's far from enough.

So this time, I didn't fob it off with a question like "Introduce yourself," but directly threw a real task I was working on at it: WorldQuant BRAIN Alpha Research and Batch Simulation.

This task is not simple.

It requires first reading the project's scripts, skills, and reference materials, checking if existing tools are usable; then logging into the API, probing data fields, designing candidate Alphas, launching multiple parallel simulation groups, checking correlations, Margin, Turnover, and error messages, and finally proceeding to the next round of optimization.

In other words, it's not just about writing a piece of code.

It's about continuously completing the entire workflow of "read files — write code — execute commands — wait for results — analyze logs — find problems — continue fixing" around a single goal.

In testing, Qwen3.8-27B's performance in DSH was more stable than I expected.

It would read project files on its own, invoke PowerShell to execute Python scripts, generate candidate configurations, launch background tasks, and simultaneously maintain a task list recording which steps were completed, which were executing, and what needed to be done next.

It wasn't entirely error-free.

For example, a race condition occurred when writing batch simulation results, leaving only one record in the final results file. After discovering the incorrect number of results, the model didn't just freeze; it continued checking logs, determined the problem was due to concurrent writes, and then switched to reading the complete results from the JSONL log.

This point is actually quite important.

Real development tasks can't possibly be smooth sailing. The key isn't whether the model encounters errors, but whether it can continue investigating along the goal after an error occurs.

The image above shows DSH's conversation view.

You can see the model reporting current progress while executing tasks: which tools were checked earlier, which batch of simulations is running, and what correlation and result file issues were found.

At the bottom of the page, there's also a continuously updated task list.

The entire task ran continuously for over thirty minutes, executing nearly forty steps. It involved multiple file reads and writes, code generation, background processes, log analysis, and result judgment. The model didn't noticeably forget the original goal, nor did it suddenly start doing something else midway.

The speed wasn't particularly fast, and the Time to First Token wait in long tasks was quite noticeable.

But at least from this test, writing code, executing goals, and continuously running long tasks showed no obvious problems.

What I liked even more was DSH's trace view.

After switching to the trace page, the entire task is broken down into a complete execution chain.

Which step was model output, which step invoked a tool, when new context was injected, when background tasks completed — all arranged in chronological order.

Clicking on one item allows you to further view what specific tool was called, what parameters were passed, what content the command returned, and what judgment the model made after receiving the results.

At the top of the page, the time spent on Input, Model, and Tools is also drawn as a timeline.

At which step the model thought for a long time, which command executed slowly, at which stage the task started going in circles — you can basically locate it at a glance.

Previously, running such long Agent tasks usually meant staring at lines of logs in the terminal and guessing.

Now, it's like having the model's entire "think — act — feedback — correct" process laid out directly in front of you.

So after this round of testing, my judgment of this combination shifted from "it can be connected" to "it can actually get work done."

Qwen3.8-27B is responsible for understanding goals, writing code, and making judgments.

DeepSeek Harness is responsible for files, commands, tool orchestration, and process recording.

Put together, they are no longer just a local chat model with a different interface, but an Agent capable of working continuously for dozens of minutes around a real goal.

At least this time, it wasn't simply "able to run."

It genuinely got the work done.