최대 3.2배 빠른 추론, LFM2.5-DSpark가 가리키는 방향

이번에 다룰 글은 Up to 3.2x Faster Inference with LFM2.5-DSpark라는 제목으로 Liquid AI가 Hugging Face 블로그에 올린 소개 글입니다. arXiv 번호처럼 별도의 식별자가 붙은 논문이 아니라 블로그 형태의 기술 소개라는 점을 먼저 밝혀둡니다. 이 글의 주장은 한 문장으로 정리할 수 있는데, LFM2.5라는 효율 중심 소형 모델 계열을 추론에 최적화된 형태로 다듬어 기준 구성보다 최대 3.2배 빠른 추론을 노렸다는 것입니다. 원문은 제목 아래에 걸린 링크로 연결해 두었으니 필요하면 그곳에서 직접 확인해 주세요.

제가 이 글을 굳이 꺼낸 이유는 숫자가 커서가 아닙니다. 3배가 넘는 가속은 언제나 조건이 먼저 궁금해지는 숫자이기 때문입니다. 어디에서 빨라졌고, 어디에서는 그대로이며, 무엇을 포기하지 않았다는 것인지가 숫자의 크기보다 중요하죠. 그래서 오늘은 그 조건을 하나씩 풀어보려고 합니다. 모델을 키우지 않고 서빙을 다듬는 선택이 무엇을 의미하는지, 그리고 그 선택이 실제 운영에서는 어떤 비용 구조로 이어지는지를 함께 따라가 보겠습니다.

속도가 궁금해서 집어 든 글인데 구조 이야기가 먼저 나왔습니다

안녕하세요, 패트릭입니다.

사람이 바빠지면 흔히 몸을 키우기보다 동선을 고칩니다. 자주 쓰는 물건은 손 닿는 곳에 두고, 잘 안 쓰는 상자는 창고로 보내죠. 모델 서빙도 크게 다르지 않습니다. 제가 이 소개 글에서 가장 흥미롭게 본 부분은 모델을 새로 키운 이야기가 아니라, 이미 있는 작은 모델을 어떻게 더 잘 움직이게 만들었는지에 대한 태도였습니다. LFM2.5-DSpark는 처음부터 거대한 모델을 새로 만들었다는 이야기가 아니라, LFM2.5라는 효율 중심 소형 모델 계열을 추론 친화적으로 다듬은 배포에 가깝다고 소개되고 있습니다.

이런 방향은 요즘 분위기와 잘 맞습니다. 많은 팀이 더 큰 가중치를 내려받는 데서 멈추지 않고, 받은 모델을 실제로 얼마나 싸고 빠르게 돌릴 수 있는지를 묻기 시작했거든요. 저도 같은 순서로 읽었습니다. 정확도가 유지되는지보다 먼저 물을 것은, 지연 시간과 처리량과 토큰당 비용이 함께 움직였는지입니다. 이 글은 그 질문에 대해 최대 3.2배라는 답을 앞으로 내밉니다. 그런데 여기서는 조금 조심해서 읽을 필요가 있습니다. 최대라는 말은 항상 그렇듯이, 모든 상황에서 같은 배율이 나온다는 뜻이 아니기 때문입니다.

그렇다면 이 흐름은 어디에서 갈라질까요. 그 이야기는 뒤에서 길이와 배치와 정밀도 조건을 따라가며 다시 다루겠습니다.

추론이 느려지는 이유는 대개 크기 때문이 아닙니다

모델이 느리다고 하면 많은 분이 파라미터 수부터 떠올립니다. 물론 크기가 영향을 주긴 하지만, 실제 서빙 현장에서 체감 속도를 가르는 것은 생각보다 자주 메모리 움직임입니다. 토큰 하나를 만들 때마다 이전 토큰들의 정보를 다시 읽어야 하고, 그 읽기가 대역폭을 계속 갉아먹기 때문입니다. 계산 자체보다 읽고 옮기는 일이 병목이 되는 구간이 분명히 존재하죠.

생각해보면 사람도 비슷하게 일합니다. 책상 위에 필요한 자료가 다 펼쳐져 있으면 일이 빠르지만, 자료가 창고에 있으면 한 걸음마다 창고를 오가야 합니다. 토큰을 길게 이어갈수록 창고를 오가는 횟수가 늘어나고, 동시에 여러 요청을 처리할수록 복도가 붐빕니다. 그래서 추론 최적화는 책상을 넓히는 일이라기보다, 무엇을 책상 위에 둘지, 무엇을 접어둘지, 어떤 순서를 바꿀지를 정하는 일에 가깝습니다.

이런 관점에서 보면 LFM2.5-DSpark의 접근은 꽤 정직합니다. 모델을 키우는 대신 읽기와 계산의 배치를 다시 짰다는 것이니까요. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 3.2배라는 결과는 그 구조가 특정 조건에서 맞아떨어졌다는 신호이지, 구조 자체를 설명해주지는 않기 때문입니다.

그렇다면 그 구조는 무엇으로 이루어져 있을까요. 소개 글에서 암시된 방향을 따라가면 어텐션과 캐시, 양자화와 희소성, 그리고 하드웨어에 맞춘 실행이라는 세 갈래가 나옵니다.

그렇다면 3.2배라는 숫자는 어디에서 만들어질까요

3.2배라는 표현은 인상적이지만, 해석할 때는 문장을 끝까지 읽어야 합니다. 기준 구성보다 최대 그 정도 빨라졌다는 말은, 비교 대상이 되는 기준 설정이 있고, 가장 잘 나온 조건에서의 배율이라는 뜻이니까요. 모든 길이와 배치와 정밀도에서 같은 배율이 나온다고 읽으면 곤란합니다. 오히려 반대로 읽는 편이 안전합니다. 어디에서 가장 잘 빨라지는지를 알면, 어디에서는 덜 빨라지는지도 짐작할 수 있기 때문입니다.

저는 여기서 한 번 멈칫했습니다. 시스템과 커널 수준의 가속이라는 설명이 붙어 있기 때문입니다. 가중치를 바꾸지 않고도 실행 방식을 손보면 이렇게 큰 차이가 날 수 있다는 것은, 역으로 말하면 기존 실행 방식에 그만큼 여유가 있었다는 뜻이기도 합니다. 메모리 접근이 비효율적이었거나, 특정 연산이 하드웨어에 맞지 않게 돌아가고 있었거나, 캐시를 다루는 방식이 길이에 따라 손해를 보고 있었을 수 있죠.

좋은 건 알겠는데, 이걸 실제로 어떻게 나눠서 이해할까요. 저는 세 가지로 나눠서 봅니다. 읽는 일을 줄였는지, 숫자를 다루는 정밀도를 조정했는지, 하드웨어에 맞는 코드로 바꿨는지입니다. 다음 세 꼭지에서는 그 갈래를 하나씩 풀어보겠습니다. 숫자를 먼저 믿기보다 구조를 먼저 상상해보는 순서로요.

어텐션과 캐시를 손보면 문장이 길어질수록 표가 납니다

긴 문장을 처리할 때 모델은 앞부분을 계속 기억해야 합니다. 그 기억을 담는 그릇이 KV 캐시인데, 길이가 길어질수록 그릇이 커지고 읽어야 할 분량도 늘어납니다. 그래서 최적화된 어텐션과 KV 캐시 효율화라는 말은, 길이가 길어지는 구간에서 특히 의미가 커집니다. 짧은 질문 한 번에 답하는 경우보다, 긴 문서를 읽고 이어서 쓰는 경우에서 차이가 벌어지기 쉽죠.

여기서 재미있는 질문이 생깁니다. 같은 모델인데 왜 캐시 다루는 법 하나로 속도가 달라질까요. 이유는 캐시가 단순한 저장 공간이 아니라 매 토큰마다 읽히는 작업대이기 때문입니다. 작업대가 어질러져 있으면 손이 자주 헛돌고, 자주 쓰는 것만 앞으로 당겨두면 같은 일도 빨리 끝납니다. 불필요한 읽기를 줄이고, 메모리를 촘촘하게 배치하고, 다음에 읽을 것을 미리 당겨오는 식의 다듬기가 쌓이면 체감 속도가 바뀝니다.

문제는 그다음입니다. 이런 다듬기는 길이에 따라 효과가 다르게 나타납니다. 짧은 구간에서는 캐시가 작아서 다듬을 여지가 크지 않고, 긴 구간에서는 읽기가 많아서 다듬은 효과가 크게 드러납니다. 그래서 최대 배율이 나온 조건이 궁금해지는 것입니다. 어떤 길이에서, 어떤 배치에서, 어떤 정밀도로 쟀을 때 3.2에 가까워지는지를 알아야 숫자가 실제로 가리키는 바를 이해할 수 있죠.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 메모리를 아끼는 방식이 품질에는 영향을 주지 않았는지입니다. 캐시를 압축하거나 접근 순서를 바꾸는 일은 속도와 정확도가 맞물리는 지점이라서, 빠르다는 말만으로는 절반만 들은 셈입니다. 그 절반의 이야기는 뒤에서 품질 preservation 이야기를 하며 이어가겠습니다.

양자화와 희소성 이야기는 늘 조건을 달고 읽어야 합니다

양자화와 희소성은 추론 가속 이야기에서 단골로 등장하는데, 숫자 표현을 가볍게 만들면 읽을 분량이 줄고 계산하지 않아도 되는 부분을 건너뛰면 곱할 분량까지 함께 줄어들기 때문입니다. 그런데 이 절약은 이론적으로는 당연해 보여도, 현장에서는 무엇을 얼마나 어디까지 가볍게 만들었는지, 그리고 그 대가로 무엇이 달라졌는지를 묻지 않으면 숫자가 공중에 뜨기 때문에 곧바로 다음 질문을 달고 다닙니다.

이 지점을 저는 일종의 다이어트에 비유해 읽곤 하는데, 무게를 줄이면 분명히 빨리 움직이는 것은 같지만 어디를 줄였는지에 따라 결과가 완전히 달라지기 때문입니다. 겉옷을 벗는 것과 근육을 줄이는 것은 다른 일이죠. 그래서 양자화도 어떤 층을 어떤 정밀도로 두는지에 따라, 그리고 희소성도 어떤 패턴을 건너뛰는지에 따라 속도와 품질의 교환 관계가 함께 움직입니다. 그러다 보니 저는 이런 단어가 나오면 습관적으로 조건부터 찾게 되는데, 정밀도는 무엇이었고 평가는 어디에서 했으며 떨어진 지점은 없었는지를 먼저 묻는 식이죠.

그렇다면 이 소개 글은 그 조건을 얼마나 보여줄까요. 사실 이 글은 구체적인 정밀도표나 층별 설정을 길게 펼치는 형태가 아닌데, 블로그 소개라는 형식이 원래 그렇기 때문입니다. 그래서 저는 이 부분을 확정된 사양이 아니라 방향으로 읽었는데, 읽기와 계산을 함께 줄이는 쪽으로 손봤을 가능성이 크다는 신호로 받아들였기 때문입니다. 다만 여기서 해석이 너무 앞서 나가지 않도록 선을 긋고 싶은데, 어떤 양자화를 썼다고 단정할 근거는 아직 손에 없기 때문이죠.

그렇다면 이 방향이 맞다고 가정하면 무엇을 확인해야 할까요. 그 답은 품질 쪽에 있는데, 추론과 코딩과 지시 따르기 같은 과제에서 품질이 유지됐는지를 보는 일이기 때문입니다. 속도는 조건을 타지만 품질은 타협을 드러내니까요.

하드웨어에 맞춘 코드는 왜 범용 코드보다 빠를까요

같은 요리라도 주방 구조에 따라 동선이 달라집니다. 불의 위치와 도마의 크기가 다르면 손의 순서가 바뀌죠. GPU와 엣지 NPU처럼 성질이 다른 하드웨어에서 같은 코드를 돌리면 비슷한 일이 생깁니다. 어디에 메모리가 있고, 한 번에 얼마나 옮길 수 있으며, 어떤 연산이 잘 돌아가는지가 다르기 때문입니다. 그래서 하드웨어 맞춤 커널 컴파일이라는 방향은, 주방에 맞춰 동선을 다시 짜는 일에 가깝습니다.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 커널을 손본다는 것은 연산의 수학을 바꾼다기보다, 그 수학을 하드웨어가 좋아하는 순서와 크기로 나눠서 실행한다는 뜻입니다. 메모리 계층을 고려해 미리 당겨두기(prefetch)를 조정하고, 병렬로 나눌 수 있는 단위를 맞추고, 불필요한 동기화를 줄이는 식이죠.

여기서 놓치기 쉬운 지점이 있습니다. 특정 하드웨어에서 나온 가속을 다른 하드웨어로 그대로 옮길 수 있다고 믿는 일입니다. GPU에서 잘 나온 숫자가 엣지 NPU에서도 같은 비율로 나온다는 보장은 없습니다. 메모리 대역폭과 연산기의 비율이 다르고, 배치 처리의 여유도 다르며, 전력과 발열의 제약도 다르기 때문입니다. 그래서 하드웨어 이름과 측정 조건은 숫자의 일부입니다. 조건 없이 배율만 옮기면 이야기가 쉽게 어긋납니다.

그렇다면 실무자는 이 대목을 어떻게 써먹을 수 있을까요. 자기 환경과 비슷한 조건을 찾는 일부터 시작하면 됩니다. 내가 돌릴 길이와 배치와 정밀도가 최대 배율이 나온 조건과 가까운지를 보는 것이죠. 멀다면 그 배율은 남의 주방 이야기일 수 있습니다.

길이가 길어지고 배치가 쌓이면 숫자는 늘 갈라집니다

추론 속도는 하나의 숫자로 고정된 성질이 아닙니다. 문장이 길어지면 캐시가 커지고, 배치가 쌓이면 메모리가 바빠지며, 정밀도를 바꾸면 읽을 바이트가 달라집니다. 그래서 실제 가속 배율은 조건에 따라 갈라질 수밖에 없습니다. 짧고 가벼운 요청에서는 원래도 빨라서 개선 폭이 작게 보일 수 있고, 길고 무거운 구간에서는 개선 폭이 크게 벌어질 수 있죠.

이런 갈라짐을 이해하려면 지연 시간과 처리량을 나눠서 봐야 합니다. 지연 시간은 한 요청이 답을 받기까지 걸리는 시간이고, 처리량은 같은 시간에 시스템 전체가 토해내는 분량입니다. 캐시 효율화는 대개 지연 시간에 먼저 나타나고, 배치 처리와 커널 최적화는 처리량을 함께 끌어올립니다. 토큰당 비용은 그 두 가지가 합쳐진 결과죠. 어느 지표를 재는지에 따라 3.2라는 숫자의 의미가 달라집니다.

제가 앞으로 보고 싶은 것은 바로 이 조건표입니다. 길이를 바꿀 때 곡선이 어떻게 휘는지, 배치를 늘릴 때 어느 지점에서 포화되는지, 정밀도를 바꿀 때 품질과 속도가 어떻게 함께 움직이는지 말이죠. 블로그 소개만으로는 그 곡선을 다 알 수 없습니다. 다만 방향은 분명합니다. 이 가속이 시스템과 커널에서 나왔다면, 곡선의 모양은 하드웨어와 워크로드에 따라 달라질 수밖에 없다는 점입니다.

여기서는 조금 과장해서 말해보겠습니다. 최대 배율만 기억하고 돌아가면 남는 것이 없고, 조건을 기억하고 돌아가면 남는 것이 많습니다. 3.2는 천장이고, 내 워크로드는 어딘가 그 아래에 있기 때문입니다. 그 위치를 찾는 일이 실무의 시작이죠.

빨라졌는데 답이 나빠지면 아무 소용이 없지 않을까요

속도 이야기가 길어질수록 품질 이야기가 궁금해집니다. 빨리 답해도 엉뚱한 답이면 운영에서는 쓸 수 없기 때문입니다. 그래서 추론과 코딩과 지시 따르기 같은 과제에서의 품질 유지 여부는 이 글의 숨은 절반입니다. 가속이 품질을 깎아먹지 않았다는 점이 확인돼야 3.2라는 숫자가 비로소 의미를 갖죠.

개인적으로 인상 깊었던 점은, 이 글이 작은 모델 계열의 배포 최적화라는 자리를 잡았다는 것입니다. 처음부터 큰 모델을 새로 만들었다면 품질 비교의 축이 달라졌을 텐데, 기존 계열을 다듬은 이야기라면 묻는 방식도 달라집니다. 다듬기 전과 후가 같은 과제에서 같은 수준을 내는지, 특히 긴 맥락이나 까다로운 지시에서 무너지지 않는지를 보게 되죠. 작은 모델은 원래 가벼운 대신 여유가 크지 않아서, 최적화의 대가가 품질로 전가되기 쉽기 때문입니다.

물론 여기서도 조건을 봐야 합니다. 어떤 과제에서, 어떤 길이에서, 어떤 평가 방식으로 품질을 쟀는지에 따라 결론이 달라집니다. 추론 과제는 긴 사슬을 요구하고, 코딩 과제는 정확한 형식을 요구하며, 지시 따르기는 미묘한 뉘앙스를 요구합니다. 한 축에서 유지됐다고 해서 모든 축에서 같다고 장담할 수는 없죠. 그래서 저는 품질 유지라는 말을 점이 아니라 범위로 듣습니다. 어디까지 확인됐고, 어디는 아직 덜 확인됐는지를 묻는 방식으로 말이죠.

그렇다면 품질이 유지됐다는 신호를 어떻게 읽을까요. 저는 숫자의 절대값보다 전후 비교를 봅니다. 최적화 전후의 차이가 오차 범위 안에 있는지, 특정 과제에서만 튀는 하락이 없는지, 긴 입력에서만 벌어지는 틈이 없는지 말이죠. 이 질문에 답할 수 있을 때 속도 이야기는 비로소 완성됩니다.

저희가 새 설계를 볼 때 숫자 너머로 함께 보는 것들

숫자는 입구이고 구조는 본론이라는 말을 저는 자주 떠올립니다. 저희 팀에서 새로운 설계를 볼 때도 먼저 묻는 것은 배율이 아니라 배치입니다. 전체 파라미터와 실제로 활성화되는 파라미터가 어떻게 다른지, 학습에 든 계산과 추론에 드는 비용이 어떻게 갈라지는지, 같은 연산량(FLOPs)이 같은 wall-clock 지연을 뜻하는지를 따져봅니다. 같은 연산량이라도 메모리 움직임이 다르면 wall-clock은 다르게 나오기 때문입니다.

이 글에 그 잣대를 대보면 몇 가지가 남습니다. 전체 모델 크기와 메모리 테이블 이야기를 구분했는지, 처리량과 요청당 토큰 속도를 나눴는지, 백분율과 백분율 포인트를 헷갈리지 않았는지 같은 것들이죠. 블로그 소개는 짧아서 그 구분을 다 펼치지 않습니다. 그래서 읽는 쪽에서 대신 구분해야 합니다. 3.2배가 처리량의 이야기인지, 지연 시간의 이야기인지, 특정 배치에서의 이야기인지를 말이죠.

또 하나는 같은 예산 비교입니다. 같은 연산량으로 맞췄다고 해서 같은 하드웨어 비용이나 에너지나 메모리 사용량이 같아지는 것은 아닙니다. 그래서 공정한 비교란 무엇을 맞췄는지를 밝히는 일입니다. 길이와 배치와 정밀도와 하드웨어를 맞췄을 때 격차가 남는지를 보는 것이죠. 이 글이 말하는 기준 구성과의 비교도 같은 잣대로 읽어야 합니다. 기준이 무엇이었는지를 알아야 가속의 결이 보이기 때문입니다.

(참고로 저는 이런 조건 찾기를 귀찮은 숙제라고 생각하지 않습니다. 오히려 숫자를 믿고 쓰는 쪽이 나중에 더 비싸게 치르더라고요. 서빙 비용은 한 번 고르면 바꾸기 어려워서, 처음에 조건을 읽는 시간이 결국 돈을 아껴줍니다.)

한 줄 요약이 놓치는 지점은 늘 같은 곳에 있습니다

빠른 기술 소식은 흔히 한 줄로 줄어드는데, 작은 모델이 3배 빨라졌다는 식으로 말이죠. 그런데 이런 요약은 절반만 맞는데, 무엇이 빨라졌는지와 어디에서 빨라졌는지, 그리고 무엇을 포기하지 않았는지가 빠졌기 때문입니다. 그래서 저는 한 줄 요약을 볼 때마다 뒤에 붙은 조건을 찾게 되는데, 조건이 없으면 이야기는 구호에 가까워진다고 느끼기 때문이죠.

표면적으로 보면 이 이야기는 단순해 보이는데, 최적화해서 빨라졌다는 한 마디로 끝나기 때문입니다. 하지만 실제로는 그렇지 않은데, 읽기를 줄이는 선택과 정밀도를 조정하는 선택과 하드웨어에 맞추는 선택이 서로 다른 대가를 치르기 때문입니다. 어떤 선택은 긴 문맥에서 빛나고, 어떤 선택은 배치 처리에서 빛나며, 어떤 선택은 특정 칩에서만 빛나죠. 그런데 한 줄은 그 빛의 위치를 말해주지 않기 때문에, 운영자는 한 줄만 믿고 기계를 빌렸다가 낭패를 보기 쉽습니다.

여기서 재미있는 반전이 생기는데, 작은 모델을 다듬는 일은 큰 모델을 만드는 일보다 덜 화려해 보이지만 현장의 돈과 직결된다는 점에서는 더 묵직하기 때문입니다. 토큰당 비용이 내려가면 같은 예산으로 더 많은 요청을 받거나 같은 요청을 더 싼 기계에서 돌릴 수 있게 되는데, 이 계산이 바로 운영자의 관심과 맞닿아 있죠. 지연 시간이 줄면 사용자 경험이 바뀌고, 처리량이 늘면 서버 대수가 바뀌는데, 숫자의 크기가 아니라 숫자가 가리키는 지갑이 다른 셈입니다. 저는 이 대목에서 숫자의 크기보다 그 지갑의 방향을 보게 되더라고요.

그렇다면 이 글을 한 줄로 줄이지 않고 읽으면 무엇이 남을까요. 모델을 키우지 않고도 서빙을 다시 짜는 것만으로 큰 폭의 개선 여지가 있었다는 사실이 남는데, 그 여지가 어디에 있었는지를 묻는 질문까지 함께 남기 때문입니다. 그래서 다음 꼭지에서는 그 질문을 품질과 운영 쪽으로 이어가겠습니다.

운영의 아침을 지키는 장치로 읽어보면

이 장치를 길게 보면 결국 운영의 문제로 돌아옵니다. 밤사이 트래픽이 몰리거나 아침에 긴 문서 요청이 쌓여도 예측 라인은 멈추면 안 되기 때문입니다. 저는 그래서 이 추론 최적화를 연구실 점수 이상으로 평가했습니다. 운영의 아침을 지켜주는 장치에 가깝기 때문입니다. 지연이 줄면 타임아웃이 줄고, 처리량이 늘면 대기열이 줄며, 토큰당 비용이 줄면 같은 예산으로 버틸 수 있는 시간이 늘어납니다.

구체적인 장면을 떠올려보겠습니다. 오후에 고객 상담 요약 요청이 몰리는 시간대를 생각해보세요. 문장은 길고, 요청은 겹치고, 답은 빨리 나와야 합니다. 캐시가 무거워지는 구간에서 읽기를 다듬어두면 첫 토큰까지의 시간이 줄고, 배치 처리를 다듬어두면 겹친 요청이 덜 밀립니다. 하드웨어에 맞춘 실행까지 얹으면 같은 기계에서도 여유가 생기죠. 이런 장면에서는 3.2라는 천장 숫자보다, 내 피크 구간에서 몇 배가 나오는지가 훨씬 중요합니다.

반면 조심할 대목도 있습니다. 최적화가 특정 길이와 배치에 맞춰져 있다면, 그 범위를 벗어난 요청에서는 효과가 줄어들 수 있습니다. 짧은 채팅에서는 원래도 빨라서 체감이 작을 수 있고, 극단적으로 긴 맥락에서는 다른 병목이 튀어나올 수 있죠. 그래서 도입 전에는 자기 트래픽의 분포를 봐야 합니다. 어디에 요청이 몰려 있고, 어디에서 지연이 터지는지를 먼저 재고, 그 구간에서의 개선을 묻는 순서입니다.

이 차이는 생각보다 중요합니다. 벤치마크의 천장을 사는 것이 아니라 내 구간의 개선을 사는 것이기 때문입니다. 저는 그래서 이 글을 읽으며 가격표보다 설계도를 먼저 봤습니다. 어떤 읽기를 줄였고, 어떤 실행 순서를 바꿨는지를 알아야 내 아침에도 통할지 판단할 수 있으니까요.

그래서 다음에 저는 무엇을 확인할까요

앞에서 미뤄뒀던 질문으로 돌아올 차례입니다. 이 가속을 어디까지 믿고 써야 할까요. 저는 세 가지를 차례로 확인하고 싶습니다. 먼저 기준 구성의 정체입니다. 무엇을 기준으로 3.2배인지가 분명해야 비교가 성립합니다. 다음은 조건별 곡선입니다. 길이와 배치와 정밀도를 바꿀 때 배율이 어떻게 움직이는지를 보고 싶습니다. 마지막은 품질의 범위입니다. 추론과 코딩과 지시 따르기에서 전후 차이가 어디까지 없는지를 보고 싶죠.

이 순서에는 이유가 있습니다. 기준이 없으면 배율은 방향을 잃고, 곡선이 없으면 도입 범위를 정할 수 없으며, 품질 범위가 없으면 운영에 올릴 수 없기 때문입니다. 블로그 소개가 그 전부를 담지 못하는 것은 자연스러운 일입니다. 소개는 문을 여는 글이고, 검증은 그다음에 오는 글이니까요. 저는 그래서 이 글을 확정된 답이 아니라 잘 차려진 문으로 읽었습니다.

그렇다면 사람의 역할은 무엇일까요. 시스템이 빨라질수록 무엇을 재고 무엇을 물을지를 정하는 일이 더 중요해집니다. 최대 배율을 외우는 대신 자기 워크로드의 분포를 재고, 한 줄 요약을 옮기는 대신 조건을 읽고, 속도 하나만 보는 대신 품질과 비용을 함께 보는 일이죠. 앞으로 비슷한 최적화 소식이 이어진다면, 저는 같은 질문을 다시 던질 것 같습니다. 어디에서, 무엇과 바꿔서, 얼마나 빨라졌는지를 말이죠.

오늘 글을 닫으며 한 가지만 남기겠습니다. 작은 모델을 잘 돌리는 일은 작은 일이 아닙니다. 읽기와 실행을 다듬는 선택이 쌓이면 같은 기계에서 더 많은 일을 할 수 있고, 그 여유는 곧바로 서비스의 안정과 가격으로 이어집니다. LFM2.5-DSpark가 가리키는 방향도 그곳에 있습니다. 더 큰 가중치를 기다리기 전에, 손에 있는 모델을 얼마나 깊이 이해하고 있는지를 묻는 방향 말이죠.