← 返回
精选AI模型发布/更新#LM Studio#Qwen 3.8 27B#本地推理#视觉语言模型#阿里

Qwen 3.8 27B 评测:默认过度思考,但本地运行能力出色

Simon Willison 博客(Atom)T2
06:0008/17 06:00社区阅读原文 ↗导出 MD ↓

评分

79
信息增量9 ×0.3

提供大量一手测试细节和独特发现,信息增量高。

内容质量9 ×0.2

内容详实,包含具体示例、数据和对比,质量高。

实用价值8 ×0.2

给出明确的调优建议,对本地用户很有操作指导意义。

时效性9 ×0.15

针对刚刚发布的模型进行即时效评测,时效性强。

信源可信度9 ×0.15

Simon Willison 是业内知名技术博主,信源可信度高。

基础分 88 × T2 信源权重 ×0.9 = 79

精选线 70已入选精选

精选理由

该评测基于一手实测,包含具体数据与对比,对本地模型用户有直接参考价值。

AI 点评

「这可能是近期最实用的本地模型评测之一。对于想要在笔记本上跑模型的开发者,Qwen 3.8 27B 的默认配置是个坑,Simon 的调优建议能直接帮你省下几十分钟等待。此外,他能让模型自己生成工具的做法也很有启发性。」

速览

Simon Willison 评测阿里 Qwen 3.8 27B:Apache 2.0 许可、27B 参数视觉模型,本地运行表现出色,但默认 xhigh 推理强度导致严重过度思考,连画个圆的 SVG 都要长篇推理。调低思考强度后性能依旧优秀,边界框定位极其精准,还能离线开发定制工具。建议用户务必手动调整默认设置。

  • Qwen 3.8 27B 是阿里开源 Apache 2.0 许可的 27B 参数视觉语言模型。
  • 默认 xhigh 推理强度导致严重过度思考,生成一个 Pelican SVG 花 21 分钟。
  • 调低推理强度后速度大幅提升,且边界框(bounding box)检测非常精准。
  • 模型可在本地离线完成复杂工具开发,适合个人电脑。

正文

以下为原文,中文全文翻译生成中

Friday's big release was Qwen 3.8 27B, an Apache 2 licensed 27B parameter vision-capable LLM from Alibaba's Qwen research lab. I've been looking forward to this one: 27B is an excellent size for running a model on a reasonably specced laptop, and its predecessor Qwen 3.6 27B was impressive.

Qwen's self-reported benchmarks for this model are eye-opening. They show a boost from both Qwen 3.6 27B and the closed-weight Qwen 3.7-Plus, which was one of Qwen's strongest models of any size as recently as May this year. It will be interesting to hear what independent benchmarks have to say about the model.

I've been running the model on two different machines: my 128GB M5 Max MacBook Pro, and an NVIDIA DGX Spark. On both machines I'm running LM Studio and their 17GB Q4_K_M quantized build. I also tried using llama-server directly on the Spark.

The default of extra high results in spectacular over-thinking

Qwen's documentation describes the model as defaulting to xhigh for the reasoning effort, and the LM Studio GGUF I've been trying preserves that default:

Qwen3.8 comes with official support for reasoning_effort, which can be used to adjust reasoning depth and control cost:

  • xhigh (default): for complex tasks demanding thorough analysis
  • medium: balancing accuracy and speed
  • low: efficient reasoning optimizing for speed and cost

This is a hilarious default. It's absolutely not a good way to run the model, especially on consumer hardware. I've been finding the results extremely entertaining.

I quickly ran into problems with LM Studio's default context limit of 8,192 tokens - Qwen was using them all up thinking about even the most mundane of problems. I loaded the model with the full 262,144 maximum context length and that problem went away.

Here's the pelican riding a bicycle SVG I got from my first attempt with that increased context length. It took 21 minutes to generate, using 22,276 reasoning tokens to produce 3,223 tokens of output. You can read the reasoning trace here.

A very pleasing image of a pelican riding a bicycle. The bicycle is red and has the correct frame shape. The pelican looks like a pelican and has its wing extended to the handlebars.

This is by far the best pelican SVG I've been able to generate with a model that runs on a local machine - and this Qwen is pretty small, just a 17GB file on disk. There's a lot to like about this:

  1. The bicycle frame is the right shape
  2. It has legs on each side of the bike - that's very rare
  3. Good, clear pelican pouch
  4. The wings extend to touch the handlebars!
  5. The motion lines are behind, not in front
  6. It has a tasteful background - nice sun, clouds, hill, flowers and grass.

Was that worth waiting 21 minutes for? Absolutely not.

Here's that same prompt run with reasoning turned off - transcript here. This one produced 3,715 tokens and took 137s - just over two minutes.

The bicycle frame is a bad shape now. The pelican remains recognizable but has a less obvious pouch. The feet miss the pedal, there is no attempt to hold the handlebars. And just for completeness, I used OpenRouter to run the same prompt through the much larger Qwen 3.8 2.4T-A95B (released last week) and got this snazzy animated SVG:

Your browser does not support HTML5 video.

I said Qwen at xhigh has a tendency to over-think things, but how bad really is it?

I tried a much simpler prompt, again with that default extra high setting:

draw an svg of a circle

Qwen's reasoning trace started like this:

The user is asking for an SVG drawing of a circle. Simple request — but I want it to be a carefully crafted piece. Let me make something that goes beyond just <circle>: a single self-contained SVG file with character — maybe a geometric "circle study," with subtle animation, layered rings, and a distinctive palette.

Keep the scope right: they asked for an SVG of a circle. So the core is a circle. But I can add craft: concentric guide circles (like a compass/geometry drawing), tick marks, a soft gradient fill on the main circle, restrained ambient motion (a slowly rotating dashed ring, pulsing glow). Respect prefers-reduced-motion? That's more for CSS; SVG SMIL or CSS inside SVG will do.

Palette options: deep teal ink on warm paper? Or bold vermilion circle on off-white with navy construction lines — Bauhaus/compass-drawing vibe. Let me go with a "geometric study" look: cool slate background, or bright paper white? Paper white is fine if it's not the cream-and-terracotta combo. [...]

Several minutes later it produced this absolutely beautiful animated circle, which was entirely not what I had asked for!

Your browser does not support HTML5 video.

My strong recommendation: ignore that default. Run Qwen 3.8 27B on low or even no reasoning levels at first. It's a great model, but wow that default setting is a bad place to start.

It's very good at bounding boxes

A fun way to test a vision model is to see how well it can return bounding boxes around items in a photograph. I've seen previous Qwen models deal well with this, so I decided to put it to the test drawing bounding boxes around some pelicans.

I've seen asking for 0-1000 scale produce good results in the past. I tried this:

llm -a https://static.inaturalist.org/photos/714731804/large.jpg \
  -m lmstudio/qwen/qwen3.8-27b \
  'Return JSON bounding boxes for the pelicans in this photo, 0-1000 scale for each dimension'

Here's the reasoning trace, which produced this:

[
  {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
  {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

This is such a good match. Here are those boxes rendered on top of the photo:

A photograph of two pelicans on a rocky outcrop, with three other smaller birds. The pelicans both have bounding boxes exactly surrounding them, each with a label that says pelican.

Building a tool to label bounding boxes

That visualization of the bounding boxes was taken using a new custom tool that I had Qwen 3.8 27B build for me, running offline on my laptop.

I forgot to dial down the thinking effort so it was massively over-engineered, but it did manage to produce this full interface from this single prompt:

[
   {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
   {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

Build an HTML page which has an input box for accepting the URL to an image and a textarea for accepting the above style of JSON.

It appends the image to the page, measures its width and height, then treats the coords in the bbox_2d as scaled from 0-1000 and scales them against the actual width and height, then it renders labelled boxes over the image.

This screenshot shows one of the features I did not ask for - a demo scene, for if you don't have a photograph to test the tool with:

Screenshot of bbox·lab, a dark-themed web tool that overlays object-detection bounding boxes on an image, with an input panel on the left and a stage on the right showing two labeled boxes around stylized pelicans in a sunset illustration. Header: bbox·lab — normalized 0–1000 coords → pixel overlay; status indicator: RENDERED · 2 BOXES. Panel 01 INPUT (URL + detections) contains an IMAGE URL field reading data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA+, a DETECTIONS — JSON textarea reading  {"bbox_2d": 195, 290, 370, 780, "label": "pelicans"}, {"bbox_2d": 445, 320, 675, 850, "label": "pelicans"} , an orange RENDER BOXES button, and dashed boxes labeled DEMO SCENE and CLEAR. Panel 03 STAGE header: display 661 × 661 px · 1 unit = 0.661px x 0.661px · nat 1000×1000. The stage shows a flat-style illustration of two dark pelican silhouettes with orange beaks standing in calm water against an orange-to-purple sunset sky with a pale yellow sun and distant birds; an orange bounding box labeled 1 · pelicans surrounds the left pelican and a cyan bounding box labeled 2 · pelicans surrounds the right pelican. Footer: move the cursor over the image to read grid coords; boxes map 0–1000 → displayed px.

Here's the relevant segment of the thinking trace, where it decided to draw its own pelicans purely because I had used the label "pelicans" in the example JSON I gave it in the prompt:

Also a "load sample" that uses a known image? Can't depend on external images, but… the image URL input is user-provided; I could add a "try with sample" button [...] Hmm, I can draw a simple scene on canvas, export it as a data URL, and load it into the image — that's self-contained and demo-able! [...] But the user's coords are for an actual pelican image; a generated placeholder can still demo the scaling. Generate a 1000x1000 placeholder: gradient water + two blob-like "pelican" silhouettes placed at the given bboxes (using the same scale — cute: silhouettes at the exact 0-1000 positions, showing the boxes align). This makes for a fun, self-contained demo. Keep it simple: sky gradient, sun, water, two pelican-ish shapes (ellipse body, circle head, beak). Place at bbox centers.

(I'm slightly nervous that models around the world might have a bias towards drawing pelicans at any chance they can get, brought on by nearly two years of exposure to my own stupid benchmark.)

Is all that over-thinking necessary? Maybe it is, at least a bit. I tried with reasoning turned off and got this version, (transcript here), which nearly works but shows the boxes in the wrong place:

BBox Studio screenshot - a solid UI but the yellow and green boxes do not cover the pelicans.

So without reasoning it didn't quite one-shot a working tool. I'm sure it could get there with some follow-up prompts, but this is a good example of how reasoning can make a difference.

Yes, it can drive coding agents

One of the biggest questions around local models is whether or not they have enough horsepower to successfully run a coding agent loop. Coding agents require long context, strong code generation support and reliable tool-calling. On paper Qwen 3.8 27B has all three of these, so is it up to the task?

My initial experiments with Pi have been very promising. I chose Pi because it has a shorter system prompt than most other options, making it a better fit for trying out smaller models.

I configured Pi to use Qwen 3.8 27B running in LM Studio on the Spark (shared via tailscale serve) by adding this to ~/.pi/agent/models.json:

{
  "providers": {
    "spark": {
      "baseUrl": "https://spark-18b3.tail68a31.ts.net/v1",
      "api": "openai-responses",
      "apiKey": "dummy",
      "models": [
        {
          "id": "qwen3.8-27b",
          "reasoning": true
        }
      ]
    }
  }
}

Then ran pi --provider spark --model qwen3.8-27b in my ~/dev/datasette folder and prompted:

how does auth work?

After a sequence of reasoning and tool calls that accessed a bunch of different files it produced this reply, which is very solid.

Just one problem: I wanted to share that transcript. So I pointed Pi and Qwen 3.8 27B at the JSONL transcript file in ~/.pi/agent/sessions/--Users-simon-Dropbox-dev-datasette-- and prompted:

Write Python code to convert this jsonl to markdown

And it built and tested this pi_jsonl_to_md.py, which did exactly what I needed. Here's that session transcript, published using the tool that it created.

The quest for speed

So far this is all looking very promising. We have a 17GB model that runs on high-end consumer hardware and can write code, drive tools, annotate images and generally do everything that I need from an LLM for getting real work done.

There's one very significant catch: it feels slow - especially when it starts over-thinking, but even without that it's not particularly sprightly.

I've been getting around 15-30 tokens a second from LM Studio. That's not terrible, but it's slow enough that it's going to be hard to win me away from hosted API models, which can return results a whole lot faster. Artificial Analysis track token speed and show OpenAI 5.6 Sol at 74 tokens/second and 5.6 Luna at an impressive 184/second.

The good news is that the community have been exploring ways to speed things up since the model was first released two days ago.

One of the most promising optimizations is baked into the model itself. Qwen supports Multi-Token Prediction, an architecture trick where a cheaper mechanism guesses several tokens ahead and the main model can then quickly verify if the guesses were correct. This can have quite a dramatic effect on inference performance.

Based on this tweet from llama.cpp creator Georgi Gerganov I tried running the model with MTP like this on the Spark:

llama serve \
 -hf  ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
 -hfd ggml-org/Qwen3.8-27B-GGUF:Q4_0 \
 --spec-default \
 --spec-type draft-mtp \
 --reasoning-preserve

And sure enough, this gave me a significant boost. I had GPT-5.6 in Codex run a comparative benchmark on the Spark and the --spec-type draft-mtp server outperformed the LM Studio default GGUF by around 72%.

I expect we'll see a whole lot more innovation around serving this model faster over the next few weeks. The MLX community likely have some tricks brewing as well.

Some observations

The fact that a 17GB file can do all of this stuff on my home machines is a miracle. Once again, I'm delighted and amazed at how much progress local models have made this year. A year ago this would have been competitive with the best and most expensive of the proprietary models - today it can run on a capable laptop.

The only thing holding this back from being a daily driver is performance. It feels pretty slow on both the M5 Mac and the DGX Spark. That's the catch with these dense (non-Mixture-of-Experts) models - they require a whole lot of memory bandwidth to perform well, and neither of the machines I have access to are top performers in that regard.

The most important thing about Qwen 3.8 27B is what it demonstrates. We can have an open weights general purpose model with a long context, effective tool calling, strong vision ability, and competent code generation, and we can fit the whole thing in just a 17GB file.

The models at this size continue to get better at an impressive rate. We don't need to spend half a million dollars on datacenter-class hardware just to run a competent model.

Tags: ai, generative-ai, local-llms, llms, qwen, pelican-riding-a-bicycle, llm-reasoning, llama-cpp, llm-release, coding-agents, lm-studio, ai-in-china, nvidia-spark, pi

相关条目

91

五维评分

信息增量9 ×0.3

详细揭示了两个具体设置如何协同作用实现三倍性能提升,信息增量高。

内容质量8 ×0.2

来自OpenAI官方,数据明确,结构清晰,但缺少对比实验细节。

实用价值9 ×0.2

为AI工程师提供了可直接操作的性能调优方案,实用性强。

时效性10 ×0.15

消息刚发布,具有高度时效性。

信源可信度10 ×0.15

信源为OpenAI官方新闻,权威可靠。

基础分 91 × T1 信源权重 ×1 = 91

精选线 60已入选精选

23:00OpenAI:News(RSS)T1RSS

精选启用两项设置使ARC-AGI-3基准测试分数提升三倍

这项发现太关键了!它表明模型的性能不仅取决于训练,还取决于推理时的配置。对于AI工程师和研究者来说,这是一个必须注意的优化方向。特别是那些在资源受限设备上部署模型的团队,可能会因此找到低成本提升能力的方法。

科技模型#ARC-AGI-3#GPT-5.6#OpenAI
91

五维评分

信息增量9 ×0.3

首次公开GPT-5.6具体效率优化细节,此前仅有传闻。

内容质量8 ×0.2

内容简洁,关键指标明确,但缺乏详细技术文档支撑。

实用价值9 ×0.2

直接指导企业如何降低AI部署成本,具有商业参考价值。

时效性10 ×0.15

刚发布的官方新闻,时效性极强。

信源可信度10 ×0.15

来源为OpenAI官方博客,信源权威。

基础分 91 × T1 信源权重 ×1 = 91

精选线 60已入选精选

08:00OpenAI:News(RSS)T1RSS

精选GPT-5.6:前沿智能与前沿效率的融合

这条消息值得关注,因为它标志着大模型竞争从单纯拼参数转向拼效率。对于AI开发者和企业决策者来说,GPT-5.6意味着可以用更少预算获得更高性能,尤其适合那些被推理成本挡在门外的长上下文或Agent场景。OpenAI这一步,可能重新定义‘前沿’的标准。

AI模型#Agent工作流#GPT-5.6#OpenAI
91

五维评分

信息增量8 ×0.3

首次提出针对CPU优化的1M上下文模型,填补了边缘设备长文本推理的空白,信息增量显著。

内容质量9 ×0.2

技术细节清晰,提供了基准测试对比和架构解释,图文并茂,质量上乘。

实用价值10 ×0.2

直接降低长上下文应用的硬件成本,开源权重可立即部署,实用价值极高。

时效性10 ×0.15

当日发布的博客,且长上下文推理是当前AI热点,时效性满分。

信源可信度9 ×0.15

Hugging Face官方博客,作者为Liquid AI,属于第一方技术发布,可信度高。

基础分 90.5 × T1 信源权重 ×1 = 91

精选线 60已入选精选

23:01Hugging Face:Blog(RSS)T1RSS

精选LFM2.5-Encoder:面向CPU快速长上下文推理的新模型

这篇博文让我眼前一亮,因为它直接解决了大模型在CPU上跑长上下文的痛点。对于没有高端GPU的团队或个人开发者,LFM2.5-Encoder系列提供了可立即使用的开源方案。尤其推荐给做RAG、文档搜索或代码分析的朋友——现在用普通服务器就能处理百万级token的文档了。

AI模型#CPU推理优化#LFM2.5-Encoder#Liquid AI
91

五维评分

信息增量9 ×0.3

首次公开自动化红队系统的具体机制与实验发现,信息增量高。

内容质量8 ×0.2

来自官方,结构清晰,但未提供完整技术细节(如具体模型版本),扣1分。

实用价值9 ×0.2

对AI安全工程师、模型开发者和企业部署者直接指导作用,实用性极强。

时效性10 ×0.15

刚刚发布,是当前AI安全领域最前沿进展之一。

信源可信度10 ×0.15

信源为OpenAI官方新闻,权威且一手。

基础分 91 × T1 信源权重 ×1 = 91

精选线 60已入选精选

18:00OpenAI:News(RSS)T1RSS

精选GPT-Red:OpenAI通过自我对弈实现AI红队自动化,提升模型鲁棒性

GPT-Red 是红队测试从人工到自动化的里程碑,特别适合安全工程师和对齐研究者关注。它直接降低了测试成本,但也引发了对“自动攻击”本身的伦理讨论——值得所有关注AI治理的人深入思考。

AI模型#AI安全对齐#GPT-Red#OpenAI
91

五维评分

信息增量9 ×0.3

这是首个针对AI模型生物安全的漏洞赏金计划,为行业提供了全新的安全评估视角。

内容质量9 ×0.2

官方来源,内容清晰,涵盖范围、奖励、准则等关键细节。

实用价值8 ×0.2

对AI安全研究员和生物安全专家有直接参与价值,但普通用户关联度较低。

时效性10 ×0.15

刚刚发布,完全符合新闻时效要求。

信源可信度10 ×0.15

OpenAI官方RSS和博客,信源权威可靠。

基础分 91 × T1 信源权重 ×1 = 91

精选线 60已入选精选

18:00OpenAI:News(RSS)T1RSS

精选OpenAI推出GPT-5.5生物漏洞赏金计划

这个计划值得关注,因为它首次将AI漏洞赏金制度拓展到生物安全领域,不仅为安全社区提供了新的研究方向,也为AI风险治理提供了实际演练场。对模型安全研究者、生物安全专家以及关心AI双重用途的从业者尤其重要。

AI模型#Bio Bug Bounty#GPT-5.5#OpenAI
91

五维评分

信息增量8 ×0.3

公布了vLLM新后端的具体架构设计与实测数据,对了解推理优化前沿有较高信息增量。

内容质量9 ×0.2

技术细节清晰,有定量性能对比,来源为官方博客,内容质量高。

实用价值10 ×0.2

直接降低LLM部署门槛与成本,对AI工程化落地具有极高实用价值。

时效性10 ×0.15

发布即时,属于最新技术动态,时效性满分。

信源可信度9 ×0.15

来源为Hugging Face官方博客,vLLM为开源权威项目,可信度高。

基础分 90.5 × T1 信源权重 ×1 = 91

精选线 60已入选精选

08:00Hugging Face:Blog(RSS)T1RSS

精选vLLM推出原生速度Transformers建模后端,大幅提升推理性能

这项更新对于AI工程团队非常关键:无需格式转换意味着能更快地迭代模型,而2-5倍的速度提升直接降低GPU成本。如果你正在做LLM在线服务或者批量推理,这几乎是必读的技术更新。

AI模型#Hugging Face#PagedAttention#Transformers
90

五维评分

信息增量9 ×0.3

手语转文本是AI无障碍领域的新突破,提供了此前罕见的具体模型信息。

内容质量8 ×0.2

来源权威,内容清晰描述了模型功能、应用场景和开发理念。

实用价值9 ×0.2

对聋人群体、开发者和无障碍研究者具有直接参考与应用价值。

时效性9 ×0.15

刚刚发布的官方公告,时效性非常高。

信源可信度10 ×0.15

Google DeepMind官方博客,信源可信度极高。

基础分 89.5 × T1 信源权重 ×1 = 90

精选线 60已入选精选

22:01Google DeepMind:Blog(RSS)T1RSS

精选Google DeepMind 发布手语转文本模型 SL2T,助力聋人用户

这则消息的意义不仅在于技术突破,更在于AI开始真正关注边缘群体的需求。对开发者而言,SL2T的架构思路和技术路径值得深入研究;对无障碍倡导者来说,这是推动行业标准的重要案例。

AI模型#Google DeepMind#SL2T#手语识别

引用前请核对原文