CODE_ASSISTANT/docs/tech/fabrix-model-perf.md

FabriX 모델 성능 실측 (고객사 -12, 2026-09-17)

같은 질문("Explain ABAP LOOP AT in 3 sentences.") 스트림, CodeAssist 게이트웨이 우회해서 FabriX 직접 호출.

id	모델	첫 토큰	전체	청크
605	Gemma4	1.8s	33.9s	304
339	GaussO Flash	0.2s	1.9s	149
581	GaussO Think	0.5s	8.0s	158

• 세 모델 다 같은 client key 로 열려 있음. 토큰은 Bearer 접두 필수(날것은 401), 클라이언트 헤더는 x-generative-ai-client·x-fabrix-client 둘 다 됨.
• Gemma4 는 토큰당 속도가 눈에 띄게 느림 → 텍스트 기본은 339, 이미지 있을 때만 605 로 보내는 게 맞음.

2차 (같은 날 저녁, "안녕" 한 단어)

id	모델	전체
339	GaussO Flash	0.7s
605	Gemma4	94.4s
580	Gemma4(다른 인스턴스)	188.5s

짧은 입력에 더 오래 걸림 → 출력 길이가 아니라 큐 대기/서빙 문제. 사용 불가 수준. FabriX 담당에 서빙 스펙 확인 요청. 대응: 기본 339, 이미지 붙은 요청만 605 (AAF_FABRIX_VISION_MODEL_ID, 게이트웨이 자동 분기).

3차 (9/18 오전, "안녕", 6개 모델, 첫 토큰/전체/청크)

id	모델	첫 토큰	전체	청크
339	GaussO Flash	0.3s	0.6s	20
81	GaussO	0.3s	1.0s	52
10	Gauss	1.2s	1.6s	27
581	GaussO Think (= GLM5.2)	0.3s	3.8s	72
605	Gemma4 31B (google-gemma-4-31b-it)	28.9s	114s	323
580	Gemma4 31B	0.9s	30.2s	315

• 580/605 가 측정마다 순위가 뒤집힘(2차 605 94s·580 188s → 3차 605 114s·580 30s) → 큐/서빙 편차. 모델 설정 문제 아님(추론 모드 off·max_tokens 로도 토큰당 0.4s 고정).
• Gauss 계열 멀티모달 여부 미확인(test.png 텍스트 추출 테스트 대기).