翻译的health很慢




translator的设计 ： 

QueryParser 里面 并不是调用的6006，目前是把6006做了一个provider，然后translate的总体配置又有6006的baseurl，很混乱！！！

config.yaml 里面的 翻译的配置  不是“6006 专用配置”，而是搜索服务的
6006本来之前是做一个provider。
结果后面改造成了综合体，但是还没改完，改到一半发现之前的实现跟我的设计或者想法有偏差。


需要继续改完！！！！！！！！


-  `config.yaml` **不是“6006 专用配置”**，而是整个系统的 **统一 services 配置**，由 `config/services_config.py` 读取，**搜索 API 进程和翻译服务进程都会用到它**。
- 关键决定行为的是这一行：

```yaml
translation:
  provider: "llm"
```

在当前配置下：

- 搜索 API 进程里，`QueryParser` 初始化翻译器时走的是：

```python
create_translation_provider(...)  # provider == "llm"
```

进而返回的是 `LLMTranslatorProvider`（本进程内调用），**不会走 `base_url`，也不会走 6006 端口**。  
- `base_url: "http://127.0.0.1:6006"` 只在 `provider: "http"` / `"service"` 时被 `HttpTranslationProvider` 使用；在 `provider: "llm"` 时，这个字段对 `QueryParser` 是完全被忽略的。

所以现在的实际情况是：

- **QueryParser 中的翻译是“本进程直连 LLM API”**，所以日志在搜索后端自己的日志文件里。  
- 如果你希望「QueryParser 永远通过 6006 端口的翻译服务」，需要把 provider 改成 HTTP：

```yaml
translation:
  provider: "http"         # ← 改成 http 或 service
  cache: ...
  providers:
    http:
      base_url: "http://127.0.0.1:6006"
      model: "llm"         # 或 "qwen-mt-flush"，看你想用哪个
      timeout_sec: 10.0
    llm:
      model: "qwen-flash"  # 留给翻译服务自身内部使用
    qwen-mt: ...
    deepl: ...
```












查看翻译的缓存情况

向量的缓存








AI - 生产 - MySQL
HOST：10.200.16.14 / localhost
端口：3316
用户名：root
密码：qY8tgodLoA&KT#yQ

AI - 生产 - Redis
HOST：10.200.16.14 / localhost
端口：6479
密码：dxEkegEZ@C5SXWKv


远程登录方式：
# redis
redis-cli -h 43.166.252.75 -p 6479

# mysql 3个用户，都可以远程登录
mysql -uroot -p'qY8tgodLoA&KT#yQ'
CREATE USER 'saas'@'%' IDENTIFIED BY '6dlpco6dVGuqzt^l';
CREATE USER 'sa'@'%' IDENTIFIED BY 'C#HU!GPps7ck8tsM';



ES：
HOST：10.200.16.14 / localhost
端口：9200
访问示例：
用户名密码：saas:4hOaLaf41y2VuI8y


你安装过nvidia-container-toolkit吗
现在有一些开源的推理引擎对向量化模型和重排模型支持的比较好，我们这块也正好要单独拎出来，因此想改造下。
已决策：embedding 先统一为 Qwen3-Embedding-0.6B（Sentence Transformers，本地 6005），后续若要独立高并发服务优先评估 TEI。
最好以 docker 方式部署，让 gpu 对 docker 可见需要 nvidia-container-toolkit，
我试了多种方法安装 nvidia-container-toolkit 都失败了
https://mirrors.aliyun.com/github/releases/NVIDIA/nvidia-container-toolkit/
https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/index.html


qwen3-embedding
qwen3-reranker

选一个推理引擎，相比于我自己直接调 sentence-transformers，主要是多进程和负载均衡、连续批处理，比较有用
当前结论：embedding 场景优先 TEI；vLLM 更偏向生成式与 rerank 场景。






混用 大模型 使用：hunyuan-turbos-latest
混元 OpenAI 兼容接口相关调用示例：https://cloud.tencent.com/document/product/1729/111007


腾讯云 混元大模型 API_KEY：sk-mN2PiW2gp57B3ykxGs4QhvYxhPzXRZ2bcR5kPqadjboGYwiz

hunyuan翻译：使用模型  hunyuan-translation
https://cloud.tencent.com/document/product/1729/113395#4.-.E7.A4.BA.E4.BE.8B



谷歌翻译 基础版：https://docs.cloud.google.com/translate/docs/reference/rest/v2/translate



阿里云 百炼模型 现在使用的apikey是国内的。
各地域的 Base URL 和对应的 API Key 是绑定的。

现在使用了美国的服务器，使用了美国的地址，需要在 美国地域控制台页面（https://modelstudio.console.aliyun.com/us-east-1 ）中创建或获取API_KEY：

登录 百炼美国地域控制台:https://modelstudio.console.aliyun.com/us-east-1?spm=5176.2020520104.0.0.6b383a98WjpXff
在 API Key 管理 中创建或复制一个适用于美国地域的 Key