在团队机器上运行 thai-chat（qwen38）模型一段时间后，必须用数据回答的问题是："它真的足以替代 z.ai 吗？" 没有数据的说法站不住脚，因此我们安排了完整的 50 个案例、5 个类别的测试，同时运行两个系统，然后让模型在不知晓答案来源的情况下进行评分。
测试方法
- bomLLM 端：通过 llm.siam2r.com 的 thai-chat 模型（我们机器上的 LiteLLM 路由器）
- 云端端：通过 z.ai API 直接调用 glm-4.5-flash（关闭 thinking 模式，按预算设置 max_tokens 为 2000）
- 5 个类别，每类 10 个案例：泰语 LINE Q&A、信号摘要（RAGSA）、分类器、翻译以及严格格式的边界情况
- 主要评判者：qwen38 模型对每个案例进行 1-10 分评分，并在配额允许的 18 个案例中使用 Gemini 2.5 Flash 作为交叉评判者
综合得分
| 类别 | bomLLM | z.ai | 比率 |
|---|---|---|---|
| LINE Q&A（泰语） | 8.93 | 6.33 | 1.41 |
| 信号摘要 RAGSA | 8.53 | 5.80 | 1.47 |
| 分类器 | 1.00 (accuracy) | 1.00 | 平局 |
| 翻译 | 9.63 | 8.50 | 1.13 |
| 边界情况（严格 JSON） | 8.10 | 8.47 | 0.96 |
| 50 个案例总计 | 7.24 | 6.02 | 1.20 |
速度差距更为显著：bomLLM p50 = 5.19 秒（p95 = 19.9），而 z.ai p50 = 35.1 秒（p95 = 85.6）——中位数速度快约 7 倍，bomLLM 的错误率为 2/50 个案例（两者均为运行时间超过 30 秒的严格格式案例）
必须对自己诚实的事项
在将此基准测试结果用于重大决策之前，需要仔细阅读以下几点：
- 评判者与参赛者同源——qwen38 评判 qwen38 的答案自然会有偏向。Gemini 自行评判的子集数据将比率降至 1.28，仍然获胜，但不如 1.44 那么悬殊
- 测试 prompt 较短（约 310 tokens）——实际工作中发送数千 tokens 长上下文是另一回事。我们遇到过真实案例，7,000 tokens 的 prompt 导致本地机器速度超过 EA 的 90 秒限制，不得不回退到云端（请参阅 6,928 tokens prompt 文章）
- 边界情况确实是弱点——严格 JSON 和混合语言案例是唯一输掉的类别（0.96）。固定格式的工作应路由到备用方案
对我们团队的结论
对于泰语聊天、信号摘要和翻译任务——我们机器上的 bomLLM 在质量和速度上均大幅领先，且无需按 token 付费。对于 prompt 超过 3-4K tokens 或格式严格不容出错的任务，目前最安全的路线是云端 + 备用方案，根据任务类型切换，这正是我们在路由器上已建立的架构。
实际系统迁移的决策始终由我亲自拍板——基准测试的职责只是呈现真实数据，而非代替决策。
