环境

• hermes-router / hermes-router-tokenizer 26.6.0-rc.3,KServe LLMInferenceService + Envoy Gateway,GIE InferencePool v1(extensionRef.failureMode: FailOpen)
• EPP 配置含 tokenizer data-producer(hf backend,tokenizerSource 指向模型 tokenizer 目录)
• 模型:DeepSeek-V4-Flash W8A8 量化 artifact —— tokenizer_config.json 无 chat_template(量化发布件常见;该模型引擎侧靠 --tokenizer-mode deepseek_v4 内置渲染,不依赖 HF 模板)

现象

1. tokenizer sidecar warmup 调 apply_chat_template 失败:

   initialize warmup failed: Cannot use chat template functions because tokenizer.chat_template is not set and no template argument was passed!
   

   EPP 侧 Plugin.Init 进入无限重试:

   Tokenizer initialization failed; retrying ... retryDelay:1
   

2. 该状态下,经该 InferencePool 的所有请求不可用:直连 KServe gateway 的请求挂死到客户端超时(curl 000,60-90s);上游 Envoy AI Gateway 侧表现为 503 no healthy upstream(envoy access log:response_flags: UH, response_code_details: no_healthy_upstream,upstream_cluster 为该 HTTPRoute rule 对应的 InferencePool cluster);
3. EPP 容器期间还会被 liveness 反复重启(init 循环影响健康探针);
4. 给 tokenizer 目录补上 chat_template 后 init 完成,同链路恢复 200 —— 因果可复验。

期望行为

tokenizer 插件在运行期对单请求失败已是明确 fail-open(日志 continuing without tokenized prompt,请求继续走负载信号调度)。但初始化阶段失败却导致整条路由 fail-closed,两者不一致:

• 期望:init 失败时 EPP 照常调度(跳过 tokenize,等价于运行期 fail-open),后台继续重试 init;
• 或至少:EPP readiness 如实反映不可用,让网关不把流量导入一个只会挂死请求的 ext_proc;
• 结构性说明:InferencePool 路由用 ORIGINAL_DST + EPP 注入目标端点,EPP 不给答案时 envoy 没有兜底端点,failureMode: FailOpen 在这个拓扑下无法自然兜底 —— 这可能需要在 EPP 侧保证"永远给出一个端点"来兑现 FailOpen 语义。

复现步骤(标准配置)

1. 任取一个 tokenizer_config.json 无 chat_template 的模型目录(或删掉该字段),作为 EPP tokenizer 插件的 tokenizerSource 部署;
2. 观察 sidecar / EPP 日志出现上述 init 重试循环;
3. 经网关(InferencePool 路径)发任意 chat 请求 → 挂死或 503;
4. 给该目录的 tokenizer_config.json 加任意有效 chat_template 后 EPP init 完成,同请求恢复正常。

相关(供参考,非本 issue 诉求)

• init 成功后仍有第二个限制:上游 GIE v1.5.0 将 data-producer 每请求预算硬编码为 400ms(prepareDataTimeout,kubernetes-sigs/gateway-api-inference-extension#2081)。长 prompt(实测 ~3.7ms/1k token,≥50k token 且与引擎争 CPU 时)tokenize 必超时,逐请求静默 fail-open → kvcache-aware 在长上下文场景实际不生效。hermes 作为集成方或需 vendor 调整/推动上游可配置化。
• 我们环境的绕过(标注:自行推断,非官方配方):为 DSV4 构造了与引擎 deepseek_v4 渲染逐 token 对齐的等价 jinja chat_template(经引擎 /tokenize 多组探针比对一致)后注入 tokenizer 目录。仅为解除 init 阻塞;不改变本 issue 描述的 fail-closed 行为本身。