2026-07-29

MiniMax 添加的 128 token 隐藏 System Prompt

今天在调试沉浸式翻译的自定义翻译服务，想要调整一下请求的 system prompt 顺序来优化缓存命中率，以及尝试关闭思考模式，看看能不能提升响应速度。然后发现不管什么样的请求，它至少都会有 128 token 的缓存命中率

测试了使用 OpenAI SDK 直接调用 MiniMax 的接口

response = client.chat.completions.create(
    model="MiniMax-M3",
    messages=[
        {"role": "user", "content": ""},
    ],
    extra_body={
        "thinking": {"type": "disabled"},
    },
)

然后他思考了很多，提了一句自己是谁。

{
    "choices": [
        {
            "finish_reason": "stop",
            "index": 0,
            "logprobs": null,
            "message": {
                "content": "It looks like you've shared the system message for a model called \"MiniMax-M3,\" but you haven't asked a question or given a task yet.\n\nHow can I help you? Feel free to ask me anything—whether it's coding, writing, brainstorming, analysis, or just a conversation. I'm ready when you are.",
                "refusal": null,
                "role": "assistant",
                "annotations": null,
                "audio": null,
                "function_call": null,
                "tool_calls": null
            }
        }
    ],
    "created": 1785262168,
    "model": "MiniMax-M3",
    "object": "chat.completion",
    "moderation": null,
    "service_tier": "standard",
    "system_fingerprint": null,
    "usage": {
        "completion_tokens": 64,
        "prompt_tokens": 163,
        "total_tokens": 227,
        "completion_tokens_details": null,
        "prompt_tokens_details": {
            "audio_tokens": null,
            "cache_write_tokens": null,
            "cached_tokens": 128
        },
        "total_characters": 0
    },
    "input_sensitive": false,
    "output_sensitive": false,
    "input_sensitive_type": 0,
    "output_sensitive_type": 0,
    "output_sensitive_int": 0,
    "base_resp": {
        "status_code": 0,
        "status_msg": ""
    }
}

看上去是有一个隐藏的 system prompt，描述一下模型的输入信息。这样子如果未来有人用它来模拟另一个模型，估计检测掺水更容易了。
不过这也相当于每次调接口都至少会产生 128 token 的 cache read 的消耗，入场费属于是。

在沉浸式翻译中关闭 MiniMax 模型的 Reasoning

• 高级自定义选项 | 沉浸式翻译

在插件设置的 开发者设置 中有一个 Edit Full User Config，找到对应的服务，添加 "bodyConfigs": { "thinking": { "type": "disabled" } }

"translationServices": {
"custom-ai-HSJCPfql": {
  "assistantId": "common",
  "bodyConfigs": {
	"thinking": {
	  "type": "disabled"
	}
  },
  "customModels": [
	"MiniMax-M3"
  ],
  "extends": "custom-ai",
  "group": "custom",
  "maxTextGroupLengthPerRequest": "30",
  "maxTextGroupLengthPerRequestForSubtitle": "30",
  "maxTextLengthPerRequest": "10000",
  "model": "MiniMax-M3",
  "name": "MiniMax",
  "type": "custom-ai",
  "visible": true
},
},

实测基本不能提升响应速度，因为思考的 token 其实不多。主要还是排队，换成高速的模型应该能快点，或者提升 service_tier，提升大概 20% 吧

---

不过发现过程中遇到了一个小插曲，因为我自己使用 Bifrost 布了一个中转站 LLM Gateway 选型，实际上它目前 v1.6.6 版本会忽略所有不认识的参数

• [Bug]: Custom provider (openai-compatible) silently drops extra parameters · Issue #4272 · maximhq/bifrost

导致设置的一些参数传不过去，目前换成官方 API 都没有问题，也可以在沉浸式翻译 加上 Bifrost 要求的 x-bf-passthrough-extra-params Header

"custom-ai-HSJCPfql": {
  "bodyConfigs": {
	"service_tier": "priority",
	"thinking": {
	  "type": "disabled"
	}
  },
  "headerConfigs": {
	"x-bf-passthrough-extra-params": "true"
  },

Docker 镜像中的 symlink 无法被 bind mount 覆盖

今天按照 Docker 容器设置时区 方式给 Alloy 容器设置时区失败了

docker run --rm -it --entrypoint sh \
  -v /usr/share/zoneinfo:/usr/share/zoneinfo \
  -v /etc/localtime:/etc/localtime \
  -v /etc/localtime:/etc/localtime2 grafana/alloy
  
# date
Wed Jul 29 14:36:04 UTC 2026
 
# findmnt
TARGET              SOURCE                          FSTYPE  OPTIONS
|-/usr/share/zoneinfo/Etc/UTC
|                   /dev/sda3[/usr/share/zoneinfo/Asia/Shanghai]
|                                                   ext4    rw,relatime,discard,errors=remount-ro
|-/etc/localtime2   /dev/sda3[/usr/share/zoneinfo/Asia/Shanghai]
|                                                   ext4    rw,relatime,discard,errors=remount-ro
`-/usr/share/zoneinfo
                    /dev/sda3[/usr/share/zoneinfo]  ext4    rw,relatime,discard,errors=remount-ro
# cat /usr/share/zoneinfo/Etc/UTC
TZif2UTCTZif2UTC
UTC0
 
# ls -al /etc/local*
lrwxrwxrwx 1 root root  27 Jun 29 21:56 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC
-rw-r--r-- 1 root root 561 Apr 28 19:04 /etc/localtime2

当 Docker 挂载主机的 /etc/localtime 到容器时，如果主机上是 symlink，则会把目标文件挂上去。
巧就巧在，grafana/alloy 这个镜像在打包时就设置了 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC，所以 -v /etc/localtime:/etc/localtime 这行把 Host 上的 /usr/share/zoneinfo/Asia/Shanghai 绑定到容器的 /usr/share/zoneinfo/Etc/UTC 文件上去了。

• In container, “/etc/localtime” allways points to “/usr/share/zoneinfo/UTC” · 议题 #16481 · moby/moby 这是个十几年的 Issue 了
• bind-mounting to a symlink mount point in a container · Issue #17944 · moby/moby

解决方法是只挂载 /etc/localtime

services:
  app:
    volumes:
      - /etc/localtime:/etc/localtime:ro