점수만 보고 고르면 비싸집니다

86개 오픈 가중치 체크포인트를 일곱 개 벤치마크와 여섯 종 하드웨어에서 재고 실측 에너지와 점수를 함께 읽는 법을 정리했습니다.

원문 논문 보기
'점수만 보고 고르면 비싸집니다' 기사 커버 이미지

arXiv에 공개된 Measuring the Inference Energy Efficiency of Open-Weight LLMs across Benchmarks, Reasoning Modes, and Hardware는 arXiv 식별자 2610.14389로 등록된 연구입니다. 이 연구가 내세우는 주장은 벤치마크 점수는 특정 서빙 방식과 출력 예산 아래에서 실측된 추론 에너지와 함께 보고되어야 한다는 것입니다. 원문 링크는 제목 아래에 걸어 두었습니다.

점수표만 보고 고르던 습관에서 시작합니다

안녕하세요, 패트릭입니다. 저는 평소에 모델을 고를 때 점수표부터 펼치는 편이었는데요. 어느 벤치마크에서 몇 점을 받았는지, 전 버전보다 몇 점 올랐는지부터 확인했습니다. 그렇다면 전기 이야기는 언제 꺼냈을까요. 고백하자면 대체로 나중이었습니다. 서빙 비용은 클라우드 요금서에서 대충 짐작하고, 전력은 데이터센터 문제로 넘겼습니다.

이번 연구를 읽게 된 이유도 그 습관 때문이었습니다. 86개 오픈 가중치 체크포인트를 일곱 개 벤치마크와 여섯 종 하드웨어에서 직접 재었다는 설명이 눈에 밟혔습니다. 소비자용 GPU부터 여덟 장짜리 서버까지 묶어서 잰 셈인데, 이런 규모는 흔치 않으니까요. 제가 앞으로 보고 싶은 것도 바로 이 대목이었습니다. 점수가 아니라 전기요금까지 포함한 선택지가 어떻게 달라지는지였습니다.

점수와 에너지의 파레토 경계를 그린 산점도 일러스트
점수와 에너지의 파레토 경계를 그린 산점도 일러스트

점수와 전기를 한 그림에 올리면 무엇이 보일까

벤치마크 점수는 모델이 무엇을 할 수 있는지 말해줍니다. 하지만 그 일을 해내는 데 전기가 얼마나 들었는지는 말해주지 않는데, 이 간격이 생각보다 큽니다. 연구진은 그래서 점수를 가로축에, 실측 에너지를 세로축에 올린 그림부터 그렸습니다. 점수가 오른쪽으로 갈수록 일을 잘하고, 아래로 갈수록 전기를 적게 쓴다는 뜻이죠.

이 그림에서 눈에 들어오는 선이 파레토 경계입니다. 같은 점수를 내면서 전기를 더 적게 쓰는 선택, 혹은 같은 전기를 쓰면서 점수를 더 올리는 선택만 모아 이은 선인데요. 이 선 위에 있으면 같은 돈으로 더 좋은 결과를 내는 셈이고, 선에서 멀면 같은 점수를 비싸게 사는 셈입니다. 일상에서 장을 볼 때를 떠올리면 비슷합니다. 같은 분량의 장바구니를 들고도 계산대 금액이 두 배 넘게 차이 날 때가 있죠. 내용물은 같은데 경로가 달랐던 것입니다.

저는 이 그림을 처음 봤을 때 질문이 하나 생겼습니다. 그렇다면 대부분의 모델은 그 선 근처에 모여 있을까요. 답은 아니었습니다. 많은 설정이 경계에서 떨어져 있었고, 그 거리가 곧 낭비였는데요. 다음 대목에서 그 거리를 숫자로 확인해 보겠습니다.

대부분이 비효율 쪽에 서 있다는 말의 뜻

연구진이 잰 86개 설정 가운데 다수는 파레토 경계에서 떨어져 있었습니다. 같은 점수 이상을 내는 다른 설정보다 전기를 중앙값 기준으로 2.6배에서 4.8배까지 더 썼는데, 이 범위는 벤치마크에 따라 조금씩 달라졌습니다. 차이가 가장 크게 벌어진 쌍에서는 27배까지 벌어졌습니다.

이 숫자는 이렇게 읽으면 됩니다. A와 B가 같은 시험에서 같은 점수를 받았는데 A는 전기밥솥으로 밥을 하고 B는 캠핑 버너를 열 개 켜고 밥을 한 셈이죠. 밥맛이 같아도 집안 전기계량기는 다르게 돕니다. 모델 선택도 마찬가지인데요. 점수만 보면 A와 B는 동점이라서 아무거나 골라도 된다고 느끼지만, 계량기를 달면 이야기가 달라집니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 이 27배라는 숫자가 모든 상황에서 그대로 재현된다는 뜻은 아니기 때문입니다. 특정 벤치마크와 특정 서빙 조건에서 가장 벌어진 쌍을 가리키는데, 제가 이 대목에서 멈칫한 이유는 바로 그 조건 때문입니다. 출력 예산을 어떻게 묶었는지, 배치 크기를 어떻게 잡았는지에 따라 전기량은 달라질 수밖에 없으니까요. 그래서 연구진이 제안하는 보고 방식이 뒤에 이어지는데, 그 전에 생각 모드 이야기를 먼저 거쳐가겠습니다.

같은 점수를 내는 두 서빙 선택의 에너지 차이를 비교한 그림
같은 점수를 내는 두 서빙 선택의 에너지 차이를 비교한 그림

생각 모드를 켜면 전기요금은 얼마나 늘어날까

생각 모드를 켜면 모델은 답을 내기 전에 중간 추론을 길게 풀어씁니다. 단계별로 따져보고, 스스로 검토하고, 다시 고치는 과정을 거치는데요. 이 과정이 점수를 올릴 때가 있어서 많은 팀이 기본값처럼 켜두곤 합니다. 그런데 이 선택에는 전기요금이 따라붙습니다.

연구진의 측정에서 생각 모드를 켜면 에너지가 평균적으로 3.7배쯤 늘었습니다. 답이 길어지니 전기를 더 쓰는 것이 당연해 보이지만, 문제는 그 다음입니다. 점수가 오르는 폭은 모델 집안마다, 그리고 출력 예산에 따라 크게 달랐기 때문입니다. 어떤 집안에서는 점수가 눈에 띄게 올랐고, 다른 집안에서는 전기는 늘었는데 점수는 제자리였습니다.

저희가 새로운 AI 아키텍처를 볼 때도 벤치마크 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 생각 모드도 같은 잣대로 보면 되는데요. 출력 예산을 넉넉히 주면 풀어쓸 여지가 생겨 점수가 오를 수 있지만, 예산을 짧게 묶어두면 말만 길어지고 답은 그대로일 수 있습니다. 밤늦게 보고서를 쓰다가 분량만 늘고 요점이 그대로인 경우와 비슷합니다.

그렇다면 언제 켜야 할까요. 답은 벤치마크 이름보다 우리 서비스의 질문 분포에 가깝습니다. 수학처럼 중간 단계가 답을 바꾸는 일에서는 켤 이유가 뚜렷해지고, 단답형 지식 질문처럼 답이 바로 나오는 일에서는 끌 이유가 생기죠. 다음 대목에서는 이 판단을 토큰 수만으로 대신할 수 있는지 따져보겠습니다.

토큰 수로 전기를 짐작하면 어디에서 어긋날까

많은 현장에서 토큰 수를 전기의 대리 지표처럼 씁니다. 토큰이 두 배면 전기도 두 배쯤 들겠지 하고 짐작하는데요. 얼핏 보면 합리적으로 들립니다. 말이 길면 입도 아프고 전기도 더 드니까요. 하지만 연구진의 비교에서는 이 짐작이 모델 쌍의 18퍼센트에서 24퍼센트까지 순서를 뒤집었습니다.

순서를 뒤집었다는 말이 조금 낯설 수 있어서 풀어보겠습니다. A가 B보다 토큰을 적게 썼으니 전기 Uh도 적을 거라고 예상했는데, 실제로 재보니 A가 전기를 더 썼다는 뜻입니다. 토큰 적게 쓴 쪽이 전기 많이 쓴 쪽이 된 셈이죠. 이런 뒤집힘이 다섯 쌍 가운데 한 쌍꼴로 나왔다고 보면 됩니다.

왜 이런 일이 생길까요. 전기는 토큰 수만으로 정해지지 않기 때문입니다. 같은 토큰이라도 모델 크기가 다르면 한 토큰을 만드는 데 드는 연산이 다르고, 메모리에서 가중치를 읽어오는 양도 다릅니다. 배치 처리 방식이나 하드웨어 궁합에 따라서도 전력 곡선이 달라지는데요. 차로 비유하면 주행 거리만 보고 기름값을 짐작하는 셈입니다. 거리가 짧아도 오르막에서 공회전을 오래 하면 기름은 더 나가죠. 추론도 대기 전력, 메모리 접근, 연산 밀도가 함께 얽혀 있습니다.

저는 이 숫자를 보고 토큰 기반 요금제의 한계도 떠올렸습니다. 토큰 요금은 과금에는 편리하지만, 실제 전력 부담과는 어긋날 때가 있다는 뜻이니까요. 그렇다면 전기를 아끼는 다른 방법은 없을까요. 정밀도를 낮추는 선택이 다음 후보입니다.

생각 모드가 토큰과 열로 바뀌는 과정을 그린 일러스트
생각 모드가 토큰과 열로 바뀌는 과정을 그린 일러스트

정밀도를 낮추면 점수는 그대로일까

FP8은 숫자를 표현하는 칸을 줄여 연산과 메모리 이동을 가볍게 만드는 방식입니다. 16비트 대신 8비트로 어림해서 계산한다는 뜻인데요. 처음 들으면 점수가 떨어질 것 같아서 손이 망설여집니다. 어림셈으로 시험을 보면 틀릴 것 같으니까요.

그런데 측정 결과는 의외로 담담했습니다. FP8은 에너지를 대략 4분의 1쯤 줄였고, 점수는 크게 흔들리지 않았습니다. 전기밥솥의 보온 단계를 낮췄는데 밥맛은 그대로인 경우와 비슷합니다. 물론 모든 벤치마크에서 완전히 같았다는 뜻은 아니고, 평균적인 흐름이 그렇다는 뜻인데요. 이 대목은 운영 관점에서 바로 써먹을 수 있습니다. 당장 내일 적용할 수 있는 절약책에 가깝기 때문입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 우리 하드웨어에서 FP8 경로가 제대로 타는가 하는 점입니다. 연산기가 받쳐주지 않으면 이론상 절약이 실제로 이어지지 않을 때가 있으니까요. (참고로 연구진은 여섯 종 하드웨어에서 폭넓게 쟀다고 밝혔는데요. 저는 이 대목에서 하드웨어별 편차가 작았다는 다음 결과가 더 눈에 밟혔습니다.)

그렇다면 하드웨어를 바꾸면 모델 순위가 뒤집힐까요. 작은 GPU에서 1등이 큰 서버에서도 1등일까요.

토큰 수와 실측 에너지의 순서 어긋남을 보여주는 개념도
토큰 수와 실측 에너지의 순서 어긋남을 보여주는 개념도

하드웨어를 바꾸면 순위가 뒤집힐까

직관적으로는 뒤집힐 것 같습니다. 소비자용 GPU와 여덟 장짜리 서버는 체급이 다르니까요. 작은 차가 잘 달리던 골목에서 큰 버스가 1등을 할 수도 있고, 고속도로에서는 다시 작은 차가 유리할 수도 있죠. 하드웨어마다 전력 특성도 다르고, 메모리 대역폭도 다르니까요.

하지만 이번 측정에서는 순위가 크게 흔들리지 않았습니다. 하드웨어를 바꾸면 에너지의 절대값은 달라졌지만, 모델 사이의 상대 순위는 대체로 유지됐는데요. 말하자면 전체 물가만 오르내리고 우열은 그대로인 셈입니다. 작은 GPU에서 전기를 적게 쓰던 모델은 큰 서버에서도 전기를 적게 쓰는 쪽이었고, 많이 쓰던 모델은 어디서나 많이 쓰는 쪽이었습니다.

이 결과는 마음에 들지만, 여기까지 일반화하기에는 데이터가 부족합니다. 연구진이 고른 여섯 종 하드웨어와 특정 서빙 방식 아래에서 성립한 이야기이기 때문입니다. 배치 크기를 극단적으로 키우거나, 동시 요청이 몰리는 피크 시간대처럼 조건이 바뀌면 곡선이 달라질 여지는 남아 있죠. 그럼에도 당장 쓸 수 있는 교훈은 있습니다. 일단 한 환경에서 효율 순위를 잡아두면, 다른 환경으로 옮길 때도 그 순위를 출발점으로 삼을 수 있다는 것입니다.

저는 이 대목을 읽으면서 파레토 그림을 다시 떠올렸습니다. 하드웨어가 바뀌어도 경계 근처에 있던 모델은 근처에 남는다는 뜻이니까요. 그렇다면 경계에 남는 모델과 멀어지는 모델은 무엇이 다를까요.

같은 점수인데 전기가 다른 이유는 무엇일까

같은 점수를 받고도 전기가 다르게 나오는 이유는 대체로 출력 길이에 있습니다. 답을 길게 풀어쓰는 모델은 맞히는 문제에서도 전기를 더 씁니다. 특히 생각 모드에서는 중간 추론이 길어지면서 이 경향이 더 뚜렷해지는데요. 짧게 맞히는 모델과 길게 맞히는 모델이 같은 점수를 받으면, 계량기는 길게 쓴 쪽에 더 많은 숫자를 매깁니다.

두 번째 이유는 모델 크기와 구조의 차이입니다. 한 토큰을 만드는 데 읽어와야 하는 가중치 양이 다르고, 그 읽기가 전력에 직접 이어지니까요. 큰 모델이 점수를 조금 더 올리면서 전기를 훨씬 더 쓰는 경우가 여기에 해당합니다. 시험 점수로만 보면 큰 모델이 이긴 것처럼 보이지만, 전기까지 합치면 작은 모델이 같은 일을 더 싸게 해낸 셈이 됩니다.

세 번째 이유는 서빙 조건입니다. 출력 예산을 어떻게 묶는지, 요청을 어떻게 모아서 처리하는지에 따라 같은 모델도 전기량이 달라집니다. 마라톤 코스를 얼마로 잡는지에 따라 기록과 체력 소모가 함께 바뀌는 것과 비슷합니다. 연구진이 서빙 방식과 출력 예산을 함께 적자고 말하는 이유도 여기 있습니다. 점수 옆에 조건을 적지 않으면 같은 점수끼리 비교하는 셈이 안 되니까요.

낮은 정밀도 연산이 전력 부담을 줄이는 모습을 그린 그림
낮은 정밀도 연산이 전력 부담을 줄이는 모습을 그린 그림

점수 옆에 전기를 함께 적자는 제안이 말하는 것

연구진이 내놓은 제안은 단순합니다. 벤치마크 점수를 발표할 때 특정 서빙 방식과 출력 예산 아래에서 실측된 에너지도 함께 적자는 것입니다. 점수만 적던 칸 옆에 전기 칸을 하나 더 만들자는 뜻인데요. 얼핏 보면 서식 이야기로 들리지만, 실제로는 평가의 축을 하나 더 만드는 일입니다.

이 제안이 설득력을 얻는 이유는 비교가 가능해지기 때문입니다. 지금까지는 A 논문의 점수와 B 논문의 점수를 놓고 어느 쪽이 낫다고 말하기 어려웠는데, 조건이 달랐기 때문입니다. 출력 예산이 다르고, 하드웨어가 다르고, 생각 모드의 켜짐 여부가 달랐는데 점수만 나란히 놓였던 것이죠. 에너지와 조건을 함께 적으면 적어도 같은 선상에서 견줄 수 있습니다.

여기서 반론도 생각해 볼 수 있습니다. 에너지는 환경에 따라 달라지니 표준으로 삼기 어렵다는 지적이죠. 실제로 연구진도 절대값이 하드웨어마다 달라진다고 밝혔으니까요. 하지만 상대 순위가 유지된다는 이번 결과가 그 반론을 누그러뜨립니다. 절대값이 흔들려도 우열이 유지된다면, 함께 적는 것만으로도 선택에 도움이 되기 때문입니다. 완벽한 저울이 아니어도 집게 손가락보다는 낫죠.

저는 이 제안보다 그 뒤의 태도가 더 오래 남는다고 봅니다. 점수를 무엇을 할 수 있는지의 기록으로만 보지 않고, 얼마를 내고 해냈는지의 기록으로 보자는 태도인데요. 이런 태도가 퍼지면 모델 발표문의 문장도 조금 바뀔 것입니다. 몇 점을 받았다는 말 뒤에 어떤 예산에서 얼마를 쓰고 받았다는 말이 따라붙겠죠.

그래서 다음에 모델을 고를 때 무엇을 물을까

그렇다면 실무에서는 무엇을 바꿔야 할까요. 저는 이 논문을 덮으면서 체크리스트를 세 가지로 정리했습니다. 첫째는 출력 예산을 먼저 정하는 일입니다. 생각 모드를 켜기 전에 답의 최대 길이를 정하고, 그 안에서 점수와 전기를 함께 재는 것이죠. 예산 없이 점수만 올리면 전기요금이 어디까지 늘어날지 알 수 없으니까요.

둘째는 토큰 짐작을 걷고 실측으로 묻는 일입니다. 토큰이 적으니 싸겠지 하고 넘기지 말고, 우리 서빙 방식에서 와트시로 얼마나 나오는지 직접 재보는 것입니다. 이번 연구에서 다섯 쌍 가운데 한 쌍꼴로 순서가 뒤집혔다는 사실이 이 습관을 뒷받침하는데요. 견적서를 볼 때 총액 대신 단가만 보고 결정하는 실수를 피하는 셈입니다.

셋째는 정밀도와 하드웨어 궁합을 먼저 확인하는 일입니다. FP8처럼 당장 쓸 수 있는 절약책이 우리 장비에서 실제로 도는지, 한 환경에서 잡은 효율 순위가 옆 서버에서도 이어지는지 확인하는 것이죠. 작은 GPU에서 싼 모델을 골라 큰 서버로 옮겼는데 갑자기 비싸지면 곤란하니까요. 다행히 이번 결과는 그 옮김이 대체로 안전하다고 말해줍니다.

작은 GPU부터 여덟 장 서버까지 순위가 유지되는 모습을 그린 일러스트
작은 GPU부터 여덟 장 서버까지 순위가 유지되는 모습을 그린 일러스트

전기를 잰 뒤에 남는 질문은 무엇일까

앞에서 미뤄둔 질문으로 돌아올 차례입니다. 이 흐름은 어디까지 이어질 수 있을까요. 저는 앞으로 보고 싶은 것이 세 가지 남았습니다. 하나는 장기 서빙에서의 곡선입니다. 이번 측정은 정해진 벤치마크와 예산 아래에서의 기록인데, 실제 서비스에서는 밤낮의 부하 차이, 캐시 적중률, 동시 접속자 수가 함께 얽히니까요. 실험실 계량기와 현장 계량기가 얼마나 어긋나는지 궁금합니다.

다른 하나는 모델 집안별 생각 모드의 사용법입니다. 평균 3.7배라는 숫자 뒤에는 집안마다 다른 사연이 숨어 있는데요. 어떤 집안은 짧은 추론으로도 점수를 올리고, 다른 집안은 길게 써야 오릅니다. 그렇다면 집안마다 다른 예산을 주는 것이 맞을까요. 아니면 같은 예산에서 견주는 것이 맞을까요. 저는 후자만 고집하기보다 두 그림을 함께 보는 쪽이 솔직하다고 봅니다.

마지막은 보고 양식의 표준화입니다. 에너지와 조건을 함께 적자는 제안에는 많은 분이 고개를 끄덕이겠지만, 막상 적으려면 서식이 필요합니다. 어떤 전력 구간을 잴지, 대기 전력까지 포함할지, 배치 크기를 무엇으로 둘지 정해야 하죠. 이 합의가 만들어지기 전까지는 각 팀이 자신의 조건을 또렷이 적는 것만으로도 도움이 됩니다. 완벽한 표준을 기다리느라 기록을 미루는 것보다 낫니까요.

다행히 막는 방법만큼 고르는 방법도 단순해 보입니다. 점수 옆에 전기 칸을 하나 더 만들고, 출력 예산을 먼저 정하고, 토큰 짐작 대신 직접 재는 것이죠. 앞으로 모델이 더 커지고 요청이 더 길어질수록, 점수 하나가 아니라 점수와 전기의 쌍으로 말하는 팀이 더 좋은 선택을 할 것 같습니다. 여러분의 다음 모델 선정 회의에서는 어떤 숫자가 먼저 올라올까요.

참고 자료

  1. Measuring the Inference Energy Efficiency of Open-Weight LLMs across Benchmarks, Reasoning Modes, and Hardware · arxiv.org

    리뷰 원문