팀 서버에서 thai-chat 모델(qwen38)을 운영한 지 어느 정도 지나자, 수치로 답해야 할 질문이 생겼습니다. "정말 z.ai를 대체할 만큼 좋은가?" 숫자가 없는 답변은 말할 자격이 없습니다. 그래서 5개 카테고리, 50개 케이스의 완전한 테스트 세트를 구성하고 두 시스템을 동시에 실행했으며, 모델이 어느 쪽에서 온 것인지 모르게 점수를 매기게 했습니다.
테스트 방법
- 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(정확도) | 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의 에러율은 50개 중 2개 케이스였으며(둘 다 런타임이 30초를 초과한 엄격한 포맷 케이스였습니다)
스스로에게 솔직해야 할 점
이 벤치마크는 큰 결정을 내리기 전에 주의 깊게 읽어야 할 몇 가지 점이 있습니다:
- 판정자와 참가자가 같은 계열 — qwen38이 qwen38의 답변을 판정하면 당연히 유리합니다. Gemini가 직접 판정한 하위 집합에서는 비율이 1.28로 낮아지지만 여전히 승리합니다. 다만 1.44만큼 압도적이지는 않습니다.
- 테스트 프롬프트가 짧음(~310 토큰) — 수천 토큰의 긴 컨텍스트를 전송하는 실제 작업은 별개의 문제입니다. 7,000 토큰 프롬프트가 로컬 서버를 EA의 90초 한계를 넘게 느리게 만들어 결국 클라우드로 돌아가야 했던 실제 사례를 겪었습니다(6,928 토큰 프롬프트 글 참조).
- 엣지 케이스가 실제 약점 — 엄격한 JSON 및 언어 혼합 케이스는 유일한 패배 카테고리입니다(0.96). 고정 포맷 작업은 폴백으로 라우팅해야 합니다.
우리 팀을 위한 결론
태국어 채팅, 신호 요약, 번역 작업에는 — 우리 서버의 bomLLM이 토큰당 비용 없이 품질과 속도 모두에서 압도적으로 승리합니다. 프롬프트가 3-4K 토큰을 초과하거나 틀리면 안 되는 엄격한 포맷 작업에는 현재 가장 안전한 경로는 클라우드 + 폴백이며, 작업 유형에 따라 교차 사용하는 것입니다. 이것이 이미 라우터에 설정해 둔 아키텍처입니다.
실제 시스템 이주 결정은 항상 제가 직접 내립니다 — 벤치마크의 역할은 실제 숫자를 보여줄 뿐, 버튼을 대신 누르는 것이 아닙니다.
