09 Apr, 2026
1 commit
-
问题背景： - scripts/ 目录下混有服务启动、数据转换、性能压测、临时脚本及历史备份目录 - 存在大量中间迭代遗留信息，不利于维护和新人理解 - 现行服务编排已稳定为 service_ctl up all 的集合：tei / cnclip / embedding / embedding-image / translator / reranker / backend / indexer / frontend / eval-web，不再保留 reranker-fine 默认位 调整内容： 1. 根 scripts/ 收敛为运行、运维、环境、数据处理脚本，并新增 scripts/README.md 说明文档 2. 性能/压测/调参脚本整体迁至 benchmarks/ 目录，同步更新 benchmarks/README.md 3. 人工试跑脚本迁至 tests/manual/ 目录，同步更新 tests/manual/README.md 4. 删除明确过时内容： - scripts/indexer__old_2025_11/ - scripts/start.sh - scripts/install_server_deps.sh 5. 同步修正以下文档中的路径及过时描述： - 根目录 README.md - 性能报告相关文档 - reranker/translation 模块文档 技术细节： - 性能测试不放常规 tests/ 的原因：这类脚本依赖真实服务、GPU、模型和环境噪声，不适合作为稳定回归门禁；benchmarks/ 更贴合其定位 - tests/manual/ 仅存放需要人工启动依赖、手工观察结果的接口试跑脚本 - 所有迁移后的 Python 脚本已通过 py_compile 语法校验 - 所有迁移后的 Shell 脚本已通过 bash -n 语法校验 校验结果： - py_compile: 通过 - bash -n: 通过
19 Mar, 2026
1 commit
-
中采用了最优T4配置：ct2_inter_threads=2、ct2_max_queued_batches=16、ct2_batch_type=examples。该设置使NLLB获得了显著更优的在线式性能，同时大致保持了大批次吞吐量不变。我没有将相同配置应用于两个Marian模型，因为聚焦式报告显示了复杂的权衡：opus-mt-zh-en 在保守默认配置下更为均衡，而 opus-mt-en-zh 虽然获得了吞吐量提升，但在 c=8 时尾延迟波动较大。 我还将部署/配置经验记录在 /data/saas-search/translation/README.md 中，并在 /data/saas-search/docs/TODO.txt 中标记了优化结果。关键实践要点现已记录如下：使用CT2 + float16，保持单worker，将NLLB的 inter_threads 设为2、max_queued_batches 设为16，在T4上避免使用 inter_threads=4（因为这会损害高批次吞吐量），除非区分在线/离线配置，否则保持Marian模型的默认配置保守。
18 Mar, 2026
1 commit
-
batch×并发矩阵”彻底分开展示。 改动在这几处： scripts/benchmark_translation_local_models.py：新增 --suite extended，支持 batch_size=1,4,8,16,32,64、concurrency=1,2,4,8,16,64、以及 batch_size * concurrency <= 128 的组合矩阵；并且单场景模式现在只加载目标模型，load_seconds 更干净，也支持 --disable-cache。 translation/README.md：把性能章节拆成了 batch_sweep、concurrency_sweep、batch x concurrency matrix 三块，补了这次复测的参数、复现命令和摘要表。 perf_reports/20260318/translation_local_models/README.md：新增本轮补测摘要。 完整结果在 translation_local_models_extended_221846.md 和 translation_local_models_extended_221846.json。 这次补测的核心结论很明确： 在线单条请求应该看 concurrency_sweep，也就是固定 batch_size=1 的表。 离线批量吞吐应该看 batch_sweep，4 个方向的最高 raw throughput 都出现在 batch_size=64，但更均衡的默认值仍更像 batch_size=16。 当前本地 seq2seq backend 有单模型锁，提升客户端并发几乎不涨吞吐，主要是把排队时间变成更高的 p95；所以并发更像“延迟预算”问题，不是“扩容吞吐”手段。 本轮在线单条里最快的是 opus-mt-zh-en；最慢、且并发放大最明显的是 nllb-200-distilled-600m en->zh。