@reranker/backends/qwen3_vllm.py 单次 generate 前有进程内锁，同一进程里不会并行多路 vLLM 推理，这个锁有必要吗？是否会影响性能？是否能够打开，使得性能更好？比如这个场景，我一次请求 400 条，分成每64个一个batch，基于我现在的gpu配置，可以再提高并发度吗？
测试了，让每个批次都并发地进行，耗时没有变化

增加款式意图识别模块

意图类型： 颜色，尺寸（目前只需要支持这两种）

意图召回层：
每种意图，有一个召回词集合
对query（包括原始query、各种翻译query 都做匹配）

意图识别层：
如果召回 判断有款式需求，


是否有：
颜色需求
尺码需求
如果有： 先做sku筛选，然后把最优的拼接到名称中，参与reranker。


现在在reranker、分页之后、做填充的时候，已经有做sku的筛选。
需要优化：
现在是，先做包含的判断，找到第一个 option_value被query包含的，则直接认为匹配。改为
1. 第一轮：遍历完，如果有且仅有一个才这样。
2. 第二轮：如果有多个，跳到3。如果没有，对每个词都走泛化词表进行匹配。
3. 第三轮：如果有多个，那么对这多个，走embedding相关性取最高的。如果一个也没有，则对所有的走embedding相关性取最高的
这个sku筛选也需要提取为一个独立的模块



2026-03-21 10:29:23,698 - elastic_transport.transport - INFO - POST http://localhost:9200/search_products_tenant_163/_search?include_named_queries_score=false [status:200 duration:0.009s]
2026-03-21 10:29:23,700 - request_context - INFO - 分页详情回填 | ids=20 | filled=20 | took=7ms
2026-03-21 10:29:23,700 - request_context - INFO - 重排分页切片 | from=20, size=20, 返回=20条
2026-03-21 10:29:23,720 - embeddings.text_encoder - ERROR - TextEmbeddingEncoder service request failed: 502 Server Error: Bad Gateway for url: http://127.0.0.1:6005/embed/text?normalize=true&priority=1
Traceback (most recent call last):
  File "/data/saas-search/embeddings/text_encoder.py", line 63, in _call_service
    response.raise_for_status()
  File "/data/saas-search/.venv/lib/python3.12/site-packages/requests/models.py", line 1026, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 502 Server Error: Bad Gateway for url: http://127.0.0.1:6005/embed/text?normalize=true&priority=1
2026-03-21 10:29:23,720 - search.searcher - WARNING - Failed to encode SKU option1 values for final-page sorting: 502 Server Error: Bad Gateway for url: http://127.0.0.1:6005/embed/text?normalize=true&priority=1
Traceback (most recent call last):
  File "/data/saas-search/search/searcher.py", line 448, in _apply_sku_sorting_for_page_hits
    encoded_option_vectors = text_encoder.encode(option1_values_to_encode, priority=1)
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/saas-search/embeddings/text_encoder.py", line 112, in encode
    response_data = self._call_service(
                    ^^^^^^^^^^^^^^^^^^^
  File "/data/saas-search/embeddings/text_encoder.py", line 63, in _call_service
    response.raise_for_status()
  File "/data/saas-search/.venv/lib/python3.12/site-packages/requests/models.py", line 1026, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 502 Server Error: Bad Gateway for url: http://127.0.0.1:6005/embed/text?normalize=true&priority=1
2026-03-21 10:29:23,721 - request_context - WARNING - SKU option embedding failed: 502 Server Error: Bad Gateway for url: http://127.0.0.1:6005/embed/text?normalize=true&priority=1




先阅读文本embedding相关的代码：
@embeddings/README.md @embeddings/server.py  @docs/搜索API对接指南-07-微服务接口（Embedding-Reranker-Translation）.md  @embeddings/text_encoder.py 
目前有TEXT_MAX_INFLIGHT / IMAGE_MAX_INFLIGHT 准入限制，超限返回过载状态码。

文本embedding服务，要支持 priority 查询参数，priority > 0：不计入上述 inflight、不会因准入被拒绝（图片embedding不需要支持，因为只有离线需要用到图片embedding）
priority == 0（默认，适合做索引之类的离线任务）：仍走原有 TEXT_MAX_INFLIGHT / IMAGE_MAX_INFLIGHT 准入；超限返回过载状态码。
priority > 0（或者==1）（适合在线请求）：不会因准入被拒绝，但是仍然需要占用inflight，这样保证在线请求不被限制，并且在线请求很多的时候可以拒绝掉离线的请求。

除了限制规则的修改，更进一步的，也需要保证这种请求是优先处理的（priority=1的相比=0的更优先被处理）。
关于技术方案，有Worker + 双队列、PriorityMutex等等，除此之外，也请你思考合适的方案。
成熟稳定、不带来复杂度、性能、稳定性方面的副作用，是最重要的。请先了解代码、需求，深度思考解决方案



配置体系的重构。

Referring to @docs/config-system-review-and-redesign.md , most of the modifications have been completed. Could you conduct a review to check what else needs improvement in the configuration documentation system? Are there any outstanding issues?

一、仍然存在大量通过环境变量获取配置的地方
_SERVICE_KIND = (os.getenv("EMBEDDING_SERVICE_KIND", "all") or "all").strip().lower()
if _SERVICE_KIND not in {"all", "text", "image"}:
    raise RuntimeError(
        f"Invalid EMBEDDING_SERVICE_KIND={_SERVICE_KIND!r}; expected all, text, or image"
    )
_TEXT_ENABLED_BY_ENV = os.getenv("EMBEDDING_ENABLE_TEXT_MODEL", "true").lower() in ("1", "true", "yes")
_IMAGE_ENABLED_BY_ENV = os.getenv("EMBEDDING_ENABLE_IMAGE_MODEL", "true").lower() in ("1", "true", "yes")
open_text_model = _TEXT_ENABLED_BY_ENV and _SERVICE_KIND in {"all", "text"}
open_image_model = _IMAGE_ENABLED_BY_ENV and _SERVICE_KIND in {"all", "image"}

_text_encode_lock = threading.Lock()
_image_encode_lock = threading.Lock()

_TEXT_MICROBATCH_WINDOW_SEC = max(
    0.0, float(os.getenv("TEXT_MICROBATCH_WINDOW_MS", "4")) / 1000.0
)
_TEXT_REQUEST_TIMEOUT_SEC = max(
    1.0, float(os.getenv("TEXT_REQUEST_TIMEOUT_SEC", "30"))
)
_TEXT_MAX_INFLIGHT = max(1, int(os.getenv("TEXT_MAX_INFLIGHT", "32")))
_IMAGE_MAX_INFLIGHT = max(1, int(os.getenv("IMAGE_MAX_INFLIGHT", "1")))
_OVERLOAD_STATUS_CODE = int(os.getenv("EMBEDDING_OVERLOAD_STATUS_CODE", "503"))
_LOG_PREVIEW_COUNT = max(1, int(os.getenv("EMBEDDING_LOG_PREVIEW_COUNT", "3")))
_LOG_TEXT_PREVIEW_CHARS = max(32, int(os.getenv("EMBEDDING_LOG_TEXT_PREVIEW_CHARS", "120")))
_LOG_IMAGE_PREVIEW_CHARS = max(32, int(os.getenv("EMBEDDING_LOG_IMAGE_PREVIEW_CHARS", "180")))
_VECTOR_PREVIEW_DIMS = max(1, int(os.getenv("EMBEDDING_VECTOR_PREVIEW_DIMS", "6")))
_CACHE_PREFIX = str(REDIS_CONFIG.get("embedding_cache_prefix", "embedding")).strip() or "embedding"





还有这些写死的地址 @embedding/config.py 

self.TEI_BASE_URL = str(text_backend.get("base_url") or "http://127.0.0.1:8080")
self.TEI_TIMEOUT_SEC = int(text_backend.get("timeout_sec", 60))

self.USE_CLIP_AS_SERVICE = services.image_backend == "clip_as_service"
self.CLIP_AS_SERVICE_SERVER = str(image_backend.get("server") or "grpc://127.0.0.1:51000")




看起来似乎并没有完全遵循这些原则？
4. 重新设计的设计原则
重新设计应遵循以下规则。

4.1 单一逻辑配置系统
可以有多个文件，但不能有多个职责重叠的加载器。
必须有一个加载器管道，能够生成一个类型化的 AppConfig 对象。

4.2 配置文件负责声明，解析代码负责解释，环境变量负责运行时注入
职责应明确如下：
配置文件
声明非敏感的目标行为和可部署的非敏感设置
解析逻辑
加载、合并、验证、规范化并暴露类型化的配置
绝不发明隐藏的业务行为
环境变量
承载密钥和少量运行时/进程相关的值
不随意地重新定义业务行为

4.3 整个系统采用单一的优先级规则
除非明确豁免，否则每个配置类别都应遵循相同的合并模型。

4.4 业务行为不得有静默的隐式后备
在启动时，如果必需的配置缺失或无效，应快速失败。
不要静默地回退到诸如硬编码语言列表之类的遗留行为。

4.5 有效配置必须可观测
每个服务都应能够展示：
配置版本或哈希值
加载的源文件
环境名称
经过清理的有效配置

5. 推荐的目标设计

5.1 边界模型
使用三个清晰的层级。
层级 1：代码仓库管理的静态配置
目的：
搜索行为
租户行为
提供商/后端注册表
非敏感的服务拓扑默认值
功能开关
示例：
字段权重
查询策略
重排序融合参数
租户语言方案
翻译能力注册表
嵌入后端选择默认值

层级 2：特定环境的层叠配置
目的：
按环境区分的非敏感差异
按环境区分的服务端点
按环境区分的资源大小默认值
开发/测试/生产环境的运维差异
示例：
本地嵌入 URL 与生产环境嵌入 URL
开发环境重排序后端与生产环境重排序后端
本地开发环境中较低的并发度

层级 3：环境变量
目的：
密钥
绑定主机/端口
外部基础设施凭证
容器编排器的最后一步注入
示例：
ES_HOST, ES_USERNAME, ES_PASSWORD
DB_HOST, DB_USERNAME, DB_PASSWORD
REDIS_HOST, REDIS_PASSWORD
DASHSCOPE_API_KEY, DEEPL_AUTH_KEY
API_HOST, API_PORT, INDEXER_PORT, TRANSLATION_PORT
规则：
环境变量不应成为选择业务行为（如翻译模型、嵌入后端或租户语言策略）的常规途径
如果允许对非敏感字段进行环境变量覆盖，则必须将其明确列出并记录为运维覆盖手段，而非隐藏的约定

5.2 统一的优先级
推荐的优先级顺序：
代码中的模式（schema）默认值
config/base.yaml
config/environments/<env>.yaml
来自 config/tenants/ 的租户层叠配置
针对明确允许的运行时键的环境变量
仅适用于当前进程的命令行标志
重要规则：
只能有一个模块实现此合并逻辑
任何业务模块不得直接调用 os.getenv() 来获取配置



二、cursor（composer2）帮我审查的

## 配置文档系统审查

这是对**配置文档系统**的简要审查，对照 [`docs/config-system-review-and-redesign.md`](docs/config-system-review-and-redesign.md) 和当前代码库进行。

### 实现已匹配的部分

代码库已朝着重新设计的目标迈进了很大一步：

- **单一类型化根节点**：`AppConfig` 位于 [`config/schema.py`](config/schema.py)，通过 [`config/loader.py`](config/loader.py) 和 [`get_app_config()`](config/loader.py) 加载。
- **精简的 `services_config`**：[`config/services_config.py`](config/services_config.py) 委托给 `get_app_config()`（解决了服务层的发现 A）。
- **租户目录**：[`config/tenant_config_loader.py`](config/tenant_config_loader.py) 使用 `get_app_config().tenants`。
- **重写资产路径**：`config/dictionaries/query_rewrite.dict` 已存在（解决了发现 E 中的文件名不匹配问题）。
- **可观测性**：[`GET /admin/config`](api/routes/admin.py) 返回**经过脱敏处理的有效配置树**；[`GET /admin/config/meta`](api/routes/admin.py) 暴露环境信息、`config_hash`、`loaded_files`、`deprecated_keys`（涵盖了 §5.10 的意图；文档中提议的是 `/admin/config/effective`，但实际实现位于 `/admin/config`）。

因此，**"单一加载器 + 有效配置可见性"** 的故事在代码中已基本实现；文档尚未完全跟上。

---

## 文档问题（影响最大）

### 1. 管理 API 文档中关于 `/admin/config` 的描述错误

[`docs/搜索API对接指南.md`](docs/搜索API对接指南.md)（管理部分附近）和 [`docs/搜索API对接指南-06-管理接口（Admin）.md`](docs/搜索API对接指南-06-管理接口（Admin）.md) 仍将 `/admin/config` 描述为**按租户**的 JSON（包含 `tenant_id`、`es_index_name`、`supported_languages` 等字段）。实际实现返回的是 **`AppConfig.sanitized_dict()`**（完整的应用配置，敏感信息已脱敏），而不是租户摘要字段。

**这些指南中还缺少：** `GET /admin/config/meta`。

**健康检查：** 拆分指南中的示例包含了 [`HealthResponse`](api/models.py) 中不存在的字段（只有 `status` 和 `elasticsearch`）。

对于任何仅根据文档进行 API 集成的人来说，这是最明显的"未解决问题"。

### 2. 面向开发者的指南仍将 `services_config` 作为"配置解析器"的核心

[`docs/DEVELOPER_GUIDE.md`](docs/DEVELOPER_GUIDE.md) §5.2 仍说搜索配置由 **`ConfigLoader`** 加载，服务由 **`config/services_config`** "解析"。§6.2 仍将 **`config/services_config.py`** 列为主要的"解析入口"。[`docs/QUICKSTART.md`](docs/QUICKSTART.md) §3.1 仍说"配置解析：`config/services_config.py`"。

文档中准确的说法应该是：**规范入口是 `config/loader.py` + `get_app_config()`**；[`config/config_loader.py`](config/config_loader.py) 中的 `ConfigLoader` 包装了统一加载器；`services_config` 是现有调用点的**兼容性外观**。

### 3. 重新设计文档本身不是"活的"状态文档

[`docs/config-system-review-and-redesign.md`](docs/config-system-review-and-redesign.md) 读起来仍是**纯粹的问题陈述 + 目标**，没有简短的**"已实现 vs 剩余"**部分。这很容易让人假设什么都没做，或者重复工作。添加一个小附录（或一页 `config/README.md` —— 见下文）可以解决这个问题。

### 4. 缺少 `config/README.md`（§5.3 中推荐）

仍然没有专门的 **`config/README.md`** 来描述：加载器入口点、高级优先级、字典存放位置、指向 `/admin/config` + `/admin/config/meta` 的链接，以及重新设计文档的链接。这是重新设计中明确的交付物，可以锚定"文档系统"。

### 5. 轻微的文档整洁问题

- [`docs/QUICKSTART.md`](docs/QUICKSTART.md) §1.9 环境变量项目后的行有一个多余字符：`---·`（可能是打字错误）。
- [`docs/DEVELOPER_GUIDE.md`](docs/DEVELOPER_GUIDE.md) §10 **文档索引**没有列出 `config-system-review-and-redesign.md` 或未来的 `config/README.md`。

---

## 重新设计目标与当前代码之间的差距（文档不应声称"已完成"）

这些影响文档的诚实度：

| 主题 | 状态 |
|--------|--------|
| **`config dump` CLI**（§5.10） | `main.py` 中不存在；运维人员依赖 HTTP 或临时脚本。 |
| **隐藏的 `["en", "zh"]` 回退**（阶段 3 / 发现 D） | 仍在 [`indexer/document_transformer.py`](indexer/document_transformer.py)、[`suggestion/builder.py`](suggestion/builder.py) 等中使用。 |
| **加载器外的 `os.getenv`**（规则 1–2） | 仍在例如 [`embeddings/server.py`](embeddings/server.py)、[`reranker/server.py`](reranker/server.py)、[`api/app.py`](api/app.py) 中使用 —— 文档声称"仅加载器"将是夸大其词。 |
| **拆分 `base.yaml` / `environments/` / `tenants/*.yaml`**（阶段 5） | 未采用；仍是单一的 [`config/config.yaml`](config/config.yaml)。 |
| **遗留租户标志**（阶段 6 / 发现 H） | [`indexer/README.md`](indexer/README.md) 仍描述上游 MySQL 的 `translate_to_en` / `translate_to_zh`（这可能作为**上游模式**文档保留；需与 Python `tenant_config` 模型区分开来）。 |

---

## 推荐的后续步骤（仅文档，按优先级排序）

1. **修复管理 API 文档**（合并指南 + `-06-` 拆分）：`/admin/config` 的响应格式，添加 `/admin/config/meta`，使健康检查示例与 [`HealthResponse`](api/models.py) 一致。
2. **更新 DEVELOPER_GUIDE §5–§6 和 QUICKSTART §1.9 / §3.1**，将 **`get_app_config()` / `loader.py`** 描述为主要入口，将 **`services_config`** 描述为适配器。
3. **添加 `config/README.md`**（简短的操作 + 开发者入口）。
4. **在 `config-system-review-and-redesign.md` 中添加**带日期的**实现状态表**（已交付 vs 推迟的内容），使审查文档不与现实矛盾。
5. **DEVELOPER_GUIDE §9 检查清单**：将"配置来自 `services_config`"替换为允许 `get_app_config()` 或精简适配器的语言，与 §6 保持一致。

如果需要，我可以在后续处理中为项目 1–3 和重新设计文档中的简短状态块应用补丁。




筛选SKU： 先只筛选第一个维度，但考虑到用户搜索词可能带了尺码，所以第二、三个维度也要考虑


引入图片的相关性：
图片的向量最好做SKU维度，用 SPU 维度还是 SKU 维度？
1. SKU维度（主款式，option1维度），如果用户搜索“蓝色 T恤”，这种图片相关性会比较有价值。
2. 我不考虑颜色的差异，其余的款式一般是大小之类的。这些图片，项链细粉到 SKU 维度，可能价值不大，性价比偏低



属性的筛选：
训练一个bert/transformer多分类模型，分类： 颜色、尺寸、材质 等等。但是要注意一些属性的值不规范、非常多，要考虑 是不是做规范化，如何规范化。




无结果重查
稀有语言，翻译可能超时（因为zh-en互译之外的翻译耗时更长）






检索相关性优化：
原始搜索词和翻译的词，都需要有对应的主干分析
这个主干可以根据词性简单提取名词即可
在搜索时，原始词和主干都成对地出现，原始词和trunk_keywords一起组成一个或查询。
有一种方案是把原始词和主干词拼接起来。但是bm25要调tf系数。




nllb-200-distilled-600M性能优化
已完成（2026-03）
- CTranslate2 迁移 + float16 转换
- 扩展压测报告：`perf_reports/20260318/translation_local_models_ct2/README.md`
- T4 聚焦调优报告：`perf_reports/20260318/translation_local_models_ct2_focus/README.md`
- NLLB T4 商品标题专项报告：`perf_reports/20260318/nllb_t4_product_names_ct2/README.md`
- 当前结论：
  - NLLB 在线默认推荐：`ct2_inter_threads=4 + ct2_max_queued_batches=32 + ct2_batch_type=examples + ct2_decoding_length_mode=source(+8,min=32)`
  - `opus-mt-zh-en` 维持保守默认更稳
  - `opus-mt-en-zh` 如追求离线吞吐可继续做单独 profile

请搜索nllb-200-distilled-600M这类seq2seq、transformer架构的模型，有哪些性能优化方案，提高线上翻译服务的吞吐量、降低耗时，搜索相关的在线推理服务方案，找到高性能的服务化方法

cnclip的性能优化

rerank 性能优化


超时
Query 分析阶段等待翻译/embedding 的硬超时
配置文件位置：config/config.yaml
配置项：query_config.async_wait_timeout_ms: 80
代码生效点：query/query_parser.py 使用该值换算成秒传给 wait(...)
2) Embedding HTTP 调用超时（Text/Image）
不再使用任何环境变量覆盖（之前提到的 EMBEDDING_HTTP_TIMEOUT_SEC 已不采用）
配置文件位置：config/config.yaml
配置项：services.embedding.providers.http.timeout_sec（已在 YAML 里补了示例默认 60）
代码生效点：
embeddings/text_encoder.py：requests.post(..., timeout=self.timeout_sec)
embeddings/image_encoder.py：requests.post(..., timeout=self.timeout_sec)




product_enrich : Partial Mode   :   done
https://help.aliyun.com/zh/model-studio/partial-mode?spm=a2c4g.11186623.help-menu-2400256.d_0_3_0_7.74a630119Ct6zR
需在messages 数组中将最后一条消息的 role 设置为 assistant，并在其 content 中提供前缀，在此消息中设置参数 "partial": true。messages格式如下：
[
    {
        "role": "user",
        "content": "请补全这个斐波那契函数，勿添加其它内容"
    },
    {
        "role": "assistant",
        "content": "def calculate_fibonacci(n):\n    if n <= 1:\n        return n\n    else:\n",
        "partial": true
    }
]
模型会以前缀内容为起点开始生成。
支持 非思考模式。





融合打分（已完成，2026-03）
1. `fuse_scores_and_resort` 已改为乘法融合，并通过 `matched_queries` 提取：
   - `base_query`
   - `base_query_trans_*`
   - `fallback_original_query_*`
   - `knn_query`
2. 文本相关性大分不再依赖 `phrase_query` / `keywords_query`，这两类查询已清理。
3. 当前融合策略：
   - `text_score = primary(weighted_source, weighted_translation, weighted_fallback) + 0.25 * support`
   - `fused_score = (rerank_score + 0.00001) * (text_score + 0.1) ** 0.35 * (knn_score + 0.6) ** 0.2`
4. `track_scores` 与 `include_named_queries_score` 已接入，调试字段与评估方法已同步到：
   - `docs/相关性检索优化说明.md`
   - `docs/搜索API对接指南.md`
   - `docs/Usage-Guide.md`






suggest 索引，现在是全量脚本，要交给金伟



翻译，增加facebook/nllb-200-distilled-600M
https://blog.csdn.net/qq_42746084/article/details/154947534
https://huggingface.co/facebook/nllb-200-distilled-600M


店铺的语言：英语能占到80%，所以专门增加一个en-zh的
https://huggingface.co/Helsinki-NLP/opus-mt-zh-en
https://huggingface.co/Helsinki-NLP/opus-mt-en-zh


opus-mt-zh-en

from transformers import AutoTokenizer, AutoModelForSeq2SeqLM
model_name = "./models/opus-mt-en-zh"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForSeq2SeqLM.from_pretrained(model_name)
data = 'test'
encoded = tokenizer([data], return_tensors="pt")
translation = model.generate(**encoded)
result = tokenizer.batch_decode(translation, skip_special_tokens=True)[0]
print(result)





Qwen3-Reranker-4B-GGUF
https://modelscope.cn/models/dengcao/Qwen3-Reranker-4B-GGUF/summary
1. 要确定选择哪种量化方式
2. 确定提示词



reranker 补充：nvidia/llama-nemotron-rerank-1b-v2
https://huggingface.co/nvidia/llama-nemotron-rerank-1b-v2
后端推理也建议使用vLLM
注意搜索相关资料，挖掘我的特斯拉 T4 GPU 的性能，充分挖掘性能
你有充足的自由度进行实验
encoder架构。
比较新。
性能更好。
亚马逊 电商搜索数据集比qwen-reranker-4b更好。
支持vLLM。





查看翻译的缓存情况

向量的缓存








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 （done）
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 （done）
选一个推理引擎，相比于我自己直接调 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