[feature request]希望llamacpp后端也能使用约束解码与束搜索

[KagaJiankui]

研究llama-cpp文档和当前仓库利用hf/transformer后端的拼音约束解码实现后，发现llama-cpp同样支持自定义采样器、实现自定义约束解码的难度较低，同时也有较高可能性实现自定义束搜索。

llamacpp相比hf/transformer后端更轻量、更“本地化”且不依赖外部python环境，因此实现llamacpp后端的拼音约束解码更有助于“开箱即用”的使用体验。

[scukeqi]

我也认为全部集成在一起会更好。

关于约束解码，目前还是实验性质。我正在评估从 Rime 获取合法候选词，再用 LLM 进行重排序，是否比生成后再进行约束效果更好。

接下来一两个月我会比较忙于毕业设计，只能利用空闲时间推进相关工作。后续有进展会在这个 issue 里同步。

[KagaJiankui]

如果采用LLM重排合法候选词组的方式，模型选择上需要较大转向，从当前预训练、未微调的LLM基模转向嵌入与重排模型；而且相较于对输入法生成的候选词组进行重排，我认为当前用LLM基模直接端到端生成next token的方式更加高效/更符合第一性原理。

时间比较紧的情况下，可以先用空闲时间弄一点理论方面的估算和规划。

[scukeqi]

感谢您的建议，分析得很有道理。约束解码这条路径也确实更加干净清晰。我这边也需要梳理一个整体的开发路线规划。

[KagaJiankui]

另外我认为目前的当务之急之一是给OpenAI兼容后端增加额外请求参数控制，便于根据不同厂商API细节传入关闭thinking、限制CoT预算的参数

[Felix3322]

已先落地这个 issue 最新讨论里提到的 OpenAI 兼容后端额外请求参数控制，方便不同厂商 API 透传关闭 thinking、限制 CoT / 推理预算等专有字段。

这次改动主要包括：

• 新增 llm/openai/extra_body：支持从 YAML 的 map / list / 标量递归序列化后，合并进最终 chat completions 请求体
• 新增 llm/openai/extra_headers：支持补充自定义 HTTP headers；若已显式提供 Authorization / Content-Type，则不会重复附加默认头
• 同样能力补到了记忆压缩通道：llm/memory/extra_body 和 llm/memory/extra_headers
• README 增加了配置示例，便于直接给不同兼容厂商传特有参数

一个典型例子：

llm:
  openai:
    api_url: "https://your-provider.example/v1/chat/completions"
    api_key: "your-api-key"
    model: "your-model"
    max_tokens: 20
    temperature: "0.6"
    extra_body:
      reasoning_effort: "low"
      thinking:
        type: "disabled"
      chat_template_kwargs:
        enable_thinking: false
        thinking_budget: 0

本地已对相关文件做过构建检查（WeaselServer/LLMProvider.cpp、WeaselServer/MemoryCompressor.cpp），当前没有报错。

如果后续继续推进标题里的 llama.cpp 约束解码 / 束搜索，这部分兼容参数能力也可以先把云端与 OpenAI 兼容后端的可配置性补齐。

详见#7

[Felix3322]

你可以先看看#7，目前在做测试，测试完成后会修改为正式PR