这篇排障记录针对一个具体场景：将本地部署的 Qwen3.8 27B 接入 DSH 后，执行 compact 时偶发压缩失败。原作者最初怀疑是模型指令遵循问题，但观察到压缩失败后会话仍可继续，因此另开会话排查，最终把问题定位到压缩阶段的 token 上限与模型思考输出之间的冲突。

故障原因

原有压缩策略会把压缩上下文上限显式限制为 8192 token。直接使用 Qwen3.8 27B 作为压缩模型时，其思考过程可能使输出超过这一上限，内容被截断后导致 compact 失败。

作者的处理思路有两步：

  1. 为压缩任务单独配置一个本地 provider，并关闭思考。
  2. 复制现有模式，在 agent.cordis.yml 中指定压缩模型，同时把压缩上限扩大到 16384 token。

第一步：在 .dsh/settings.yaml 增加压缩专用 provider

llama-compact:
  displayName: llama.cpp (compaction) # 显示名称
  apiKeyEnv: LLAMA_API_KEY # 改成你设置的 key
  api: openai-completions # 类型
  baseURL: http://127.0.0.1:18080/ # 实际的本地 LLM URL
  reasoning: off # 该字段需要通过下面的 reasoningEfforts 字段生效
  compat:
    thinkingFormat: openai
    supportsReasoningEffort: true
  models:
    - id: qwen3.8-27b
      name: Qwen3.8-27b (compaction)
      contextWindow: 128000
      maxTokens: 64000
      input:
        - text
      reasoningEfforts:
        off: none # 必须为 none
        low: low
        medium: medium
        xhigh: xhigh

这里有三个需要对应本机环境核对的值：

  • apiKeyEnv 必须与实际设置的环境变量名一致。
  • baseURL 必须指向本地 LLM 的实际 OpenAI 兼容接口。
  • provider ID llama-compact 和模型 ID qwen3.8-27b 要与下一步配置保持一致。

关闭思考的关键不只是顶层 reasoning: off，还要让 reasoningEfforts.off 映射到 none。

第二步：修改模式中的 agent.cordis.yml

作者先复制了一份正在使用的标准模式，然后打开对应文件夹，在 agent.cordis.yml 中找到 id: compaction-basic，补充压缩模型并提高截断上限：

- id: compaction-basic
  name: '@deepseek-ai/dsh-compaction-basic'
  config:
    summarizationProvider: llama-compact # 与上一步的 provider ID 一致
    summarizationModel: qwen3.8-27b # 与上一步的模型 ID 一致
    maxTokens: 16384 # 扩大到 16K

验证结果

完成两处配置后，作者再次执行 compact，压缩可以正常完成。验证时应重点确认：

  • DSH 能连接 baseURL 指向的本地推理服务；
  • 压缩任务实际选择了 llama-compact 与 qwen3.8-27b；
  • 压缩阶段的思考强度确实为 off；
  • 长会话触发 compact 后不再出现原先的压缩失败。

适用边界

这是一份针对“本地 Qwen3.8 27B + DSH compact”组合的故障记录。原帖没有说明完整的 DSH 版本、推理后端版本、硬件配置，也没有给出其他模型或远程 API 的对照测试，因此不能据此推断所有 compact 失败都由 8192 token 截断引起。遇到相似问题时，应先根据实际日志确认是否确有输出截断，再调整压缩模型和 token 上限。

原作者：Ruby_axx（Ruby）
原帖：https://linux.do/t/topic/2800291