Qwen 3.8 27B 本地跑通指南：从 Spring Boot 调用

昨天早上，我的信息流又被一个模型发布刷屏了。但这一次和平时那种前沿模型发布不同。Qwen 3.8 27B 登上了 Hacker News 榜首并稳居不下：我查看时，帖子在不到一天内获得了 1194 点积分和 713 条评论。这种热度通常只有那种每百万 token 收费 5 美元的 API 发布才能享受到。

特别之处在于：这是一个拥有 270 亿参数的开源密集模型，采用 Apache 2.0 许可证，人们正在笔记本上运行它。Simon Willison 在 M5 Max MacBook Pro 上通过 LM Studio 运行它，使用了 17GB 的 GGUF 文件，花了 21 分钟看它思考一张 SVG（这是他的评论）。我使用 Spring Boot 和 Spring AI 构建生产级 AI 系统，所以我的第一个问题不是"它有多聪明"，而是：我能否用我现有的代码调用它，不需要第二个 SDK 或云账户？

答案是可以，而且配置比模型的许可证文件还小。以下是发布的内容、社区实际运行后发现的情况，以及本地运行 Qwen 3.8 27B 的 Spring Boot 完整接线方式。

实际发布的内容

Qwen 3.8 是阿里巴巴开源模型家族的最新一代，27B 是其紧凑型密集成员。模型卡列出了主要细节：

• 一个 270 亿参数的密集视觉语言模型。一个基于 Qwen3.5 架构构建的因果语言模型，带有视觉编码器，可接收文本、图像和视频输入。
• 262,144 个 token 的原生上下文。卡片称可以通过 RoPE 缩放（YaRN）扩展到 100 万 token，不过卡片警告静态 YaRN 可能会损害较短输入的性能。
• 来自实验室的 FP8 量化。FP8 仓库使用细粒度 fp8，块大小为 128，声称"性能指标与原始模型几乎相同"。
• 默认开启思考。Qwen3.8 默认运行在思考模式下，有三个推理努力级别：xhigh、medium 和 low。它还保留早期消息的推理上下文（preserve_thinking），用于多步骤 agent 工作。
• 多 token 预测（MTP）。使用草稿模型训练，这也是下面几个社区基准测试运行所使用的方式。

模型一发布就势头强劲：在发布后约一天内，基础仓库获得了 91,917 次下载和 9,465 个 star，FP8 仓库获得了 123,157 次下载。Apache 2.0 意味着你可以使用、修改和发布它，而无需征求许可。

在基准测试方面，Qwen 自己的表格显示相比 Qwen3.6-27B 有大幅提升。这些是厂商数字，使用 Claude Code harness 在 temperature 1.0 和 256K 上下文窗口下评估的，所以把它们当作方向性参考：

• Terminal Bench 2.1：73.0，相比 Qwen3.6-27B 的 63.4
• SWE-bench Pro：61.7，相比 53.5。在同一表格中，Opus 4.6 Max 得分为 53.4
• DeepSWE 1.1：42.2，相比 13.3
• LiveCodeBench v6：90.3，相比 83.9
• OSWorld-Verified：84.3，相比 63.9。这已经进入了计算机使用领域，在同一表格中它超越了 Opus 4.6 Max 的 72.7

再次强调：这些是 Qwen 自己的数字。社区帖子才是真正考验模型的地方，那里的人不在乎厂商的表格，而有趣的东西也正是在那里出现。

开发者实际运行时发现了什么

HN 帖子异常密集地包含了实践经验报告，因为 27B 开源模型是大多数观众当天就能拉取和运行的。

Simon Willison 在笔记本上运行了它。M5 Max MacBook Pro、LM Studio、17GB GGUF。它生成了他所说的本地模型中见过的最好的 SVG 鹈鹕骑自行车图，但花了 21 分钟，使用了 22,276 个推理 token，产生了 3,223 个输出 token。他的原话是："这绝对是我在笔记本上运行的模型中见过的最好的鹈鹕"（评论）。

一位评论者作为软件工程师测试了它。他们让它用 JS 构建了一个功能完整的待办事项 Web 应用，然后用 Rust 和 Tauri 重写。"模型就其大小来说很强。它一次就搞定了 Web 应用，没有 bug。" Rust 重写有一个 bug，在一次后续 prompt 中修复了（评论）。

另一位做了一个私有基准测试。Qwen 3.8 27B 是在 Gemma 4 之后，第二个能正确推理通过他们私有基准测试的本地模型。需要注意的是：启用 MTP 后，它消耗了 5 倍的 token 和 12 分 30 秒。他们还标记了 VRAM 效率：仅 32K 上下文就占用了 2.5GB VRAM，他们甚至无法在将 V 量化为 Q4_0 的情况下装下 128K（评论）。

过度思考问题是真实存在的。一位测试 WordPress 插件的评论者发现，在 xhigh 推理模式下，模型"过度思考严重到写出糟糕的灌木丛式代码"，并看到它在"最终最终方案"和"好的真的是最终方案"之间循环后才完成。在 low 模式下表现更好（评论）。

聊天模板开箱即用有问题。一个常见抱怨：Jinja 模板需要修复才能可靠地进行工具调用和思考控制。社区构建了 Qwen-Fixed-Chat-Templates 来减少或关闭思考、修复工具调用，并保持 100% 的 KV 缓存命中率（评论）。

速度很大程度上取决于引擎。一位 RTX 5090 所有者报告使用 ninfer 推理引擎大约 138 tokens/秒，大约是其 naive llama.cpp 设置的两倍（评论）。一位 20GB VRAM 显卡用户报告在 30K 上下文下大约 30 tokens/秒，并指出 Muse Glimmer 在同一张卡上 128K 上下文能提供 65-80 tokens/秒（评论）。

热情是关于这个类别的。一位评论者总结道："开源权重/源码的小型密集模型对公众最有好处，因为它们能让更多人用上"（评论）。另一位则直白地描述了这个里程碑：如果基准测试站得住脚，这就"非常接近 Opus 4.6 的能力"，而这正是他们个人衡量 AI 是否好到不用它的转折点（评论）。

所有这些报告的模式：模型就其大小来说确实有能力，而摩擦是操作层面的。思考 token、上下文预算和 VRAM 计算。这些正是 Spring Boot 集成应该为你解决的问题，而事实证明这个集成很简单。

构建：从 Spring Boot 本地运行 Qwen 3.8 27B

先完整披露：我是在模型发布当天写完这篇文章的。我对照 Spring AI 参考文档和 Ollama 库页面验证了下面的每个 API 调用，并对照社区运行报告交叉检查了数字，但我还没有用生产工作负载指向这个特定模型。接线模式和我日常通过 Ollama 使用其他本地模型的模式相同，而且确实很简单。

步骤 1：本地运行模型

最简单的方式是 Ollama。库中已经列出了 qwen3.8，带有 27b、27b-q4_K_M、27b-q8_0、27b-bf16、27b-mxfp8、27b-nvfp4 和 MTP 变体的标签（库页面）。拉取适合你硬件的量化版本：

ollama pull qwen3.8:27b-q4_K_M

来自帖子的硬件现实检查：4 位量化版本大约 17GB，可以在有 32GB+ 统一内存的 Mac 或 24GB 显卡上运行。在 20GB 显卡上你需要权衡上下文长度和速度，而 5090 级别的显卡在正确引擎下能超过 100 tokens/秒。如果你更喜欢 LM Studio，它的 Qwen3.8 页面托管了相同量化选项的 GGUF。

步骤 2：添加 Spring AI Ollama starter

这是你唯一需要的依赖。Spring AI 的 Ollama starter 使用 OpenAI 兼容的聊天格式，所以任何在 Ollama 后面运行的东西都是直接替换：

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-ollama</artifactId>
</dependency>

步骤 3：在 application.properties 中配置模型

两个属性。base URL 是 Ollama 的默认本地端口，模型名称匹配你拉取的标签：

spring.ai.ollama.base-url=http://localhost:11434
spring.ai.ollama.chat.options.model=qwen3.8:27b-q4_K_M
spring.ai.ollama.chat.options.temperature=0.7

步骤 4：通过 ChatClient 调用

Spring AI 给你相同的 ChatClient 构建器，你已经用它来调用任何其他模型。一个最小的服务：

@Service
public class QwenLocalService {

    private final ChatClient chatClient;

    public QwenLocalService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String ask(String question) {
        return chatClient.prompt()
            .system("You are a senior software engineer. Think briefly, then answer.")
            .user(question)
            .call()
            .content();
    }
}

这里的 system prompt 很重要。因为 Qwen3.8 默认会思考，会乐意在一个两句话的答案上烧掉 20,000 个推理 token，所以设置预期深度的 prompt 是对抗帖子中持续报告的过度思考的第一道防线。

步骤 5：多模态输入（图像和视频）

Qwen3.8 是一个视觉语言模型，Spring AI 的多模态支持覆盖了它。文档化的模式是附加了 Media 对象的 UserMessage。根据 Spring AI 多模态参考：

UserMessage message = UserMessage.builder()
    .text("Describe this diagram and explain what the arrows mean.")
    .media(new Media(MimeTypeUtils.IMAGE_PNG, new ClassPathResource("architecture.png")))
    .build();

ChatResponse response = chatClient.prompt()
    .messages(message)
    .call()
    .chatResponse();

这是让本地 Qwen 对 Java 团队有趣的部分：文档解析、截图分析和 UI 重建，而这些图像永远不会离开你的机器。

步骤 6：每个请求控制思考

Qwen3.8 暴露了 reasoning_effort（xhigh、medium、low）和完全禁用思考的能力。在 Ollama 上你可以通过 options map 传递这些，所以低延迟路径可以跳过长推理过程：

chatClient.prompt()
    .system("Answer directly, no reasoning.")
    .user(question)
    .options(OllamaOptions.builder()
        .model("qwen3.8:27b-q4_K_M")
        .temperature(0.7)
        .build())
    .call()
    .content();

模型卡自己对非思考模式的建议是 temperature=0.7、top_p=0.80、presence_penalty=1.5，这是直接回答工作负载的良好起点。

我会做得不同的地方，以及一个检查清单

帖子中的操作经验教训，变成了一个为任何将本地模型接入真实服务的人的检查清单：

永远不要默认运行 xhigh。模型卡把它设为默认；社区报告说它会过度思考、写出灌木丛式代码，并在"最终方案"消息之间循环。从 medium 开始，根据任务需要升级。

像花钱一样预算推理 token。一张 SVG 用 22,276 个推理 token 对一次 hobby 运行来说还可以，但对延迟敏感的端点来说是不行的。如果一个请求需要快速答案，禁用那个路径的思考。

拉取前先做 VRAM 数学题。27B 密集模型很耗上下文。仅 32K 上下文在一次报告中就占用了 2.5GB VRAM，而像 Muse Glimmer 这样的竞争对手在同一张卡上能容纳更多上下文。如果你在 modest 硬件上需要长上下文，这可能不是你的模型。

使用固定聊天模板进行工具调用。stock 模板有已知问题；社区修复（Qwen-Fixed-Chat-Templates）值得在使用此模型构建 agent 时采用。

根据你自己的工作负载验证基准声明。Qwen 的数字是真实的但是厂商运行的。帖子显示一个在表格上名列前茅的模型在生产中仍然需要仔细的 prompt 工作。

诚实的结论：Qwen 3.8 27B 是很长时间以来第一个让我重新检查云 API 账单的开源密集模型。对于 Spring Boot 团队来说，集成成本是一个依赖和两个属性，模型是 Apache 2.0，数据永远不会离开你的网络，而主要的工程工作是驯服它的思考。这是一个值得这个周末测试的权衡。

我每周写关于 Java、Spring Boot 和 AI 的文章。订阅，免费。

你在真实服务中运行过 Qwen 3.8 27B（或其他本地模型）吗？你首先需要驯服的是什么，速度还是思考？在评论中告诉我。