왜 재봤나
AllenAI 블로그가 AstaBrief-8B를 소개하며 "기존보다 3.5배 빨라져서 리포트 하나에 50초면 된다"고 썼다(Threads 소개 글). 같은 하드웨어·같은 분량 기준 비교였는지 의문이 제기됐는데, 실제로 블로그 원문엔 테스트 조건(하드웨어, 쿼리 수, 비교 대상)이 전혀 안 적혀 있었다. 무료 Colab T4로 직접 재봤다.
처음엔 틀렸다
첫 시도는 그냥 AstaBrief랑 Claude를 같은 프롬프트로 돌려서 시간 재는 거였다. 근데 두 가지가 비교를 왜곡했다.
- 비교 대상이 잘못됐었다: AstaBrief는 사실 Qwen3-8B를 파인튜닝한 모델이다(블로그에 "We started from Qwen3-8B"라고 적혀있다). 파인튜닝 자체의 속도 영향을 보려면 베이스 모델이랑 비교해야 의미가 있다.
- 출력 길이를 안 고정했었다: AstaBrief는 1024토큰 상한까지 꽉 채워 답했고 Qwen은 367토큰에서 자연 종료됐다. 그 상태로 wall-clock을 그대로 비교하니 "AstaBrief가 4.29배 느리다"는 결론이 나왔는데, 이것도 틀린 비교였다 — 더 긴 글을 썼으니 더 오래 걸린 것뿐이다.
다시 맞춰서 잰 결과
출력 토큰을 200으로 고정하고(min_new_tokens=max_new_tokens=200), 같은 T4에서 3회씩 돌려 평균 냈다.
- AstaBrief-8B: 19.62초 (10.20 tok/s)
- Qwen3-8B(파인튜닝 전 베이스): 19.64초 (10.19 tok/s)
- 배율: 1.00배
파인튜닝은 속도에 아무 영향이 없었다. 그럼 블로그의 "3.5배"는 어디서 나온 숫자였나 — AstaBrief 단일 모델 호출(Fast mode)과, Claude 기반 멀티스텝 에이전트 파이프라인(Thinking mode: 검색+클러스터링+섹션별 생성 등 여러 단계)을 비교한 수치였다. 느린 건 그 파이프라인 구조 때문이지, AstaBrief가 일반 8B 모델보다 빠른 게 아니다. 원문에도 이 부분은 적혀 있다 — "대부분의 학습·평가는 2025년에 끝났고, 최신 프론티어 모델로 재평가하진 않았다"고.
그럼 파인튜닝은 뭘 위한 거였나 싶어서 찾아보니, ScholarQA-CS2 기준 인용 정확도가 베이스 모델 대비 올라가 있었다(90.5 vs 76.2). 아마 이게 진짜 목적이었을 거다 — 속도가 아니라 품질. Threads에도 이 검증 결과를 공유했다.
한계
GPU 한 종류(T4), 양자화 한 방식(4bit), 쿼리 하나로만 잰 결과다. 다른 환경에서는 숫자가 달라질 수 있다. "3.5배는 과장이다"라고 단정하긴 어렵고, "3.5배가 가리키는 게 모델 자체의 속도가 아니라 파이프라인 구조 차이"라는 정도까지만 말할 수 있다.
Top comments (2)
Fixing both generation limits to 200 tokens makes your rerun a clearer measurement of decoding throughput on that T4, while the one-query caveat keeps the 1.00x result appropriately narrow. The distinction between a single call and a retrieval-and-clustering pipeline is the key to interpreting the original headline.
I would keep two benchmark tracks: equal-length decoding with repeated queries, and end-to-end brief generation at a matched citation-quality target. The second should include retrieval time and the number of model calls. That would show whether Fast mode buys speed by doing less orchestration, while preserving the separate question of whether fine-tuning improves the useful output.
Rerunning with the generation length pinned is the right correction, and the 1.00x is close to forced: both models are the same 8B architecture, and 4-bit decoding on a T4 is memory-bandwidth bound, so tokens per second (10.20 vs 10.19) can't differ much. A fine-tune can only change latency through how many tokens it emits.
That makes the discarded first run more interesting than it looks. 1024 tokens (hit the cap) against 367 is a 2.8x difference in output length, and that is the only way AstaBrief could be faster or slower per report. If the report length the fine-tune produces is the intended product, the honest comparison is time per report at the length each model chooses, plus whether the extra length carries the citation gain (90.5 vs 76.2), rather than a throughput ratio. I'd report both rows: matched-length speed (1.00x) and natural-length wall clock with the cap hit rate.
One caveat on the setup: min_new_tokens=200 forces the model to keep generating past where it would have stopped, so the Qwen number includes tokens it didn't want to write. It doesn't change tok/s, but a second query or two would show whether 10.2 tok/s moves with prompt length, which on a T4 with a long retrieval context it usually does.