Strata 엔진은 128K에서 생성이 2~4배 빨랐지만, 실사용에서는 원래 엔진으로 돌아왔습니다
EVO-X2에서 Strata v0.1.40을 llama.cpp와 비교했습니다. 단일 요청에서는 128K 생성이 2~4배, 첫 토큰이 4.5배 빨랐지만, 두 요청을 동시에 받으면 출력이 깨졌고 하루 실사용 시험에서는 본문 없이 끝나는 답이 나와 원복했습니다.
EVO-X2(Ryzen AI Max+ 395, gfx1151, 128GB)에서 llama.cpp 대신 Strata v0.1.40 추론 엔진을 시험했습니다. Strata는 Strix Halo용 최적화와 MTP(speculative decoding)를 기본으로 넣은 엔진입니다. 모델은 Qwen3.8 Flash Next Uncensored IQ4_XS로 같은 파일을 썼습니다.
결과는 세 단계로 갈렸습니다. 요청 하나씩 재면 Strata가 크게 빨랐습니다. 두 요청을 동시에 보내면 기본 설정에서 출력이 깨졌습니다. 보수적인 설정으로 하루 실사용을 해 보니 사고 과정만 내고 본문 없이 끝나는 답이 나와서 llama.cpp로 되돌렸습니다. 빠르다는 것과 답변을 끝까지 내는 것은 별개였습니다.
단일 요청 비교
8K, 32K, 128K 입력을 각각 처음부터 한 번에 넣고 256토큰을 생성했습니다. 공통 벤치마크의 32K 누적 방식이 아니라, 고정 원문을 통째로 prefill하는 비교입니다. 조건마다 3회, 총 54건을 쟀고 모든 건에서 입력 전체 처리와 출력 256개를 확인했습니다.
| llama.cpp | Strata | |
|---|---|---|
| 엔진 | db00347a4, HIP ROCm 10 |
v0.1.40 1735d647, HIP ROCm 7.14 |
| KV | Q8_0 | int8 |
| MTP | off | 기본: MTP + lookup-chain, 고속: 여기에 prefill 최적화 옵션 추가 |
| prefill 단위 | batch 2048 / ubatch 512 | 16,384 |
생성 속도 (tok/s)
| 입력 | llama.cpp | Strata 기본 | Strata 고속 |
|---|---|---|---|
| 소설 8K | 28.32 | 25.47 | 29.87 |
| 소설 32K | 25.20 | 27.36 | 26.35 |
| 소설 128K | 14.00 | 27.19 | 25.21 |
| 코드 8K | 28.30 | 52.24 | 51.64 |
| 코드 32K | 25.14 | 49.80 | 48.41 |
| 코드 128K | 14.00 | 56.00 | 57.23 |
Strata의 이득은 긴 문맥과 코드에서 컸습니다. llama.cpp는 128K에서 생성이 절반으로 떨어졌지만 Strata는 거의 떨어지지 않았습니다. 코드는 MTP 제안이 잘 맞아서(전체 초안 수락률 64~84%) 128K에서 4배가 됐습니다. 반대로 소설 8K에서는 기본 Strata가 llama.cpp보다 10.1% 느렸습니다. 소설은 수락률이 15~24%로 낮아 draft 비용이 이득을 깎았습니다.
입력 처리와 첫 토큰
| 입력 | llama.cpp prefill | Strata 고속 prefill | llama.cpp 첫 토큰 | Strata 고속 첫 토큰 |
|---|---|---|---|---|
| 소설 32K | 397.58 | 1096.26 | 82.44초 | 29.93초 |
| 소설 128K | 242.89 | 1080.85 | 539.70초 | 121.34초 |
| 코드 128K | 236.86 | 1065.41 | 553.43초 | 123.09초 |
prefill 단위는 tok/s입니다. 고속 옵션에서는 128K를 넣어도 prefill이 초당 1,000토큰 이상을 유지해, 128K 문서를 처음 넣고 첫 토큰을 받기까지 9분이 2분으로 줄었습니다. 고속 옵션은 생성 결과의 토큰이 기본 모드와 달라지는 실험 설정입니다. 짧은 입력에서는 편차가 커서 코드 8K의 세 값이 969, 595, 952 tok/s였습니다.
메모리 여유도 Strata가 더 컸습니다(최소 가용 47.5GiB 대 24.4GiB). 전문가 가중치 24,576개가 전부 GPU 캐시(약 61.8GiB)에 들어가는 구성이라, 메모리가 작은 GPU의 스트리밍 성능과는 다릅니다.
두 요청을 동시에 받으면
같은 서버를 두 사람이 쓰는 상황(슬롯 2개, 각 128K)을 시험했더니 문제가 나왔습니다.
gfx1151자동 최적화를 켠 기본 설정에서 두 요청을 동시에 보내면 출력이 깨졌습니다. 공식 batch 테스트에서도 두 응답이 첫 토큰부터 단독 실행과 달라졌고 무의미한 반복을 냈습니다. 고속 prefill을 꺼도 같았습니다.- 여러 요청을 묶어 MTP를 쓰면 엔진이
unsupported native MMVQ GGML type으로 종료되고 API가 멈췄습니다. 공유 draft head의 타입 정보가 복사되지 않는 것이 코드상 원인 후보지만 고쳐서 확인하지는 않았습니다.
자동 최적화를 끄고 batch MTP도 끈 보수적인 구성은 동시 요청을 통과했고, 이 구성으로 llama.cpp와 2슬롯 서비스를 비교했습니다.
| 지표 | llama.cpp | Strata 보수적 구성 |
|---|---|---|
| 짧은 동시 2요청 합산 생성 (3회 평균) | 45.56 tok/s | 35.86 tok/s |
| 두 대화의 첫 120K 입력과 응답 완료 (1회) | 993.42초 | 299.58초 |
| 번갈아 이은 후속 질문 첫 토큰 (3회 평균) | 1.94 / 1.98초 | 1.75 / 1.69초 |
| 후속 질문의 캐시 재사용 | 약 99.93% | 약 99.93% |
짧은 동시 요청은 Strata가 약 21% 느렸고, 긴 첫 요청 두 개를 처리하는 시간은 약 70% 짧았습니다. 다만 첫 요청은 한 번만 잰 값이고 두 엔진이 요청을 받는 순서도 달랐습니다. 긴 대화를 동시에 이어 가는 속도도 쟀지만, 양쪽 모두 일부 응답이 10~19토큰에서 일찍 멈춰 출력 길이가 달랐기 때문에 비교에 쓰지 않았습니다.
하루 실사용 시험과 원복
보수적 구성을 슬롯 1개(다른 요청은 대기), 128K로 실제 서비스에 올려 하루 써 보기로 했습니다. 올리기 전에 55건의 기능 검사를 했습니다. 여러 대화 교대, 제목 생성 뒤 일반 대화, 이미지, 도구 호출을 모두 통과했고 대화 간 내용 혼입도 보이지 않았습니다.
그런데 Open WebUI에서 소설을 요청하자 사고 과정만 출력되고 본문 없이 끝나는 답이 나왔습니다. 원인을 좁혀 보려고 무해한 합성 소설 요청 3건을 보냈습니다. 기본 사고 설정에서는 진단용 상한 4,096토큰을 사고에 다 써서 본문이 0이었고, 사고를 끄거나 사고 예산을 128로 줄이면 본문이 나왔습니다. 원래 문제가 된 요청의 입력과 종료 토큰을 확보하지 못해 같은 원인이라고 확정하지는 못했습니다. Strata 저장소에도 사고 도중 일찍 끝나는 비슷한 보고가 있습니다.
결국 시험을 끝내고 llama.cpp 2슬롯 구성으로 되돌렸습니다. 이미지, 도구 호출, 사고 후 본문 반환까지 다시 확인했습니다. Strata 파일과 기록은 남겨 두었고, 자동으로 다시 바꾸지는 않습니다.
정리하면
Strata는 긴 문맥에서 llama.cpp보다 확실히 빨랐습니다. 128K 코드 생성이 4배였고 긴 문서의 첫 토큰이 4.5배 빨랐습니다. 하지만 이 기계와 모델 조합에서는 기본 설정의 동시 서비스가 깨졌고, 보수적 설정으로 바꾼 뒤에도 실사용에서 답을 끝내지 못하는 경우가 나왔습니다. 벤치마크의 처리량 이득만 보고 운영 엔진을 바꾸지 않는 이유가 여기 있습니다. 기능 검사 55건을 통과한 것도 장문 답변을 끝까지 내는 신뢰성을 보장하지는 않았습니다.
이 결과는 이 기계와 이 모델(Uncensored IQ4_XS)에 한정됩니다. 다른 GPU나 모델에서 Strata에 같은 문제가 있다는 뜻은 아닙니다. 제작자가 보고한 50 tok/s 이상의 수치는 원본 Unsloth 모델 기준이라 위 숫자와 직접 비교하지 않습니다.