지난 글에서 휴대폰의 제약을 봤다. 그런데 기기가 감당 못 하는 일인데도 클라우드로 보낼 수 없는 자리가 있다. 공장 라인, 병원 내부망, 매장 계산대, 선박이나 광산 같은 회선이 불안정한 현장이다.
여기에 놓는 작은 서버를 엣지라고 부른다. 데이터센터의 축소판처럼 보이지만 고르는 기준은 꽤 다르다. 전기와 냉방이 제한되고, 옆에 사람이 없고, 고장 나면 누군가 차를 몰고 가야 한다.
왜 굳이 현장에 두는가
엣지 장비를 놓는 이유는 대개 넷 중 하나이고, 어느 것이냐에 따라 필요한 사양이 달라진다.
- 데이터가 밖으로 못 나간다. 규제나 계약 때문이다. 이 경우 성능보다 격리와 감사 기록이 먼저다.
- 회선을 믿을 수 없다. 끊겨도 라인이 서면 안 되는 곳. 장비 두 대와 자동 전환이 사양보다 중요하다.
- 지연이 공정에 들어간다. 검사 결과가 100ms 안에 나와야 하는 자리. 왕복 시간 자체가 예산이다.
- 올려 보낼 데이터가 너무 많다. 카메라 수십 대의 영상 같은 것. 현장에서 걸러 요약만 보내는 편이 회선비보다 싸다.
이 넷은 "품질 좋은 큰 모델을 쓰고 싶다"와는 다른 동기다. 그래서 엣지에서는 대개 작은 모델로 충분한 일을 골라 내리고, 어려운 것만 중앙으로 보낸다.
관문 ①: 들어가는가
가장 먼저 세는 것은 메모리다. 모델 가중치만 세면 반드시 모자란다.
7B 모델을 4비트로 누르면 가중치가 약 4GB다. 여기에 동시 세션마다 KV 캐시가 붙는다. 문맥 4k 기준으로 세션당 0.4GB쯤이라고 보면, 16명이 동시에 쓰는 상황은 6.4GB를 더 요구한다. 합이 10.4GB, 여유를 20% 잡으면 12GB급 이상이어야 한다는 결론이 나온다.
여기서 자주 하는 실수는 평균 동시 사용자로 세는 것이다. 매장이라면 점심시간, 공장이라면 교대 시각에 몰린다. 그 순간에 메모리가 모자라면 요청이 느려지는 것이 아니라 실패한다. 최대 동시 요청으로 세고, 넘칠 때 어떻게 할지(대기열에 세울지, 중앙으로 보낼지)를 함께 정한다.
관문 ②: 빠른가
두 번째 관문에서 카탈로그가 가장 크게 배신한다. 장비 소개서의 대문짝만 한 숫자는 대개 INT8 기준 피크 TOPS인데, 토큰을 하나씩 만드는 구간에서 이 숫자는 거의 쓸모가 없다.
생성 속도의 상한을 정하는 것은 메모리 대역폭이다. 4GB짜리 모델을 대역폭 100GB/s인 장비에서 돌리면 토큰당 40ms, 초당 25토큰이 이론적 상한이고 실제로는 그 6~7할이 나온다. 대역폭이 200GB/s면 그 두 배다. 연산 성능이 두 배 높아도 대역폭이 절반이면 결과는 절반이다.
그러면 TOPS는 언제 의미가 있는가. 입력을 한 번에 통과시키는 프리필과, 여러 요청을 묶어 한꺼번에 처리할 때다. 카메라 영상을 분석하거나 문서를 대량으로 처리하는 일이라면 TOPS가 실제로 결과를 정한다. 대화형이라면 대역폭을 본다. 우리 일이 어느 쪽인지부터 정하고 나서 카탈로그를 봐야 한다.
관문 ③: 몇 명인가
동시 사용자가 늘 때 벌어지는 일은 직관과 조금 다르다. 요청 하나를 처리하든 여덟 개를 묶어 처리하든 가중치를 읽는 비용은 한 번이다. 그래서 묶음 처리는 처리량을 거의 공짜로 몇 배 올려 준다.
대신 두 가지가 따라온다. 세션마다 KV 캐시가 자리를 먹고(관문 ①로 돌아간다), 묶기 위해 기다리는 만큼 개별 응답이 조금 늦어진다. 엣지에서는 사용자 수가 애초에 적어 묶을 것이 없는 경우도 흔하다. 동시 사용자가 늘 두세 명이라면 처리량보다 한 사람의 체감 속도를 기준으로 장비를 고르는 편이 맞다.
관문 ④: 돌볼 수 있는가
성능은 하루면 재 본다. 정작 프로젝트를 좌초시키는 것은 대개 소프트웨어 쪽이다.
확인할 것은 다음과 같다. 우리가 쓰려는 추론 런타임이 이 칩을 공식 지원하는가, 그 지원이 지금도 갱신되고 있는가, 모델을 새로 바꿀 때 변환 과정이 필요한가, 필요하다면 그 변환에서 정확도가 얼마나 떨어지는가, 커널이나 드라이버 버전을 우리가 고를 수 있는가.
특히 벤더 전용 가속기는 이 항목에서 무너지기 쉽다. 벤치마크는 화려한데 새 모델 구조가 나오면 지원까지 몇 달이 걸리거나 영영 안 오기도 한다. 엣지 장비는 한번 설치하면 3~5년을 쓰므로, 그동안 모델을 몇 번은 바꾸게 된다는 전제로 골라야 한다. 오늘 가장 빠른 장비보다 내년에도 새 모델이 올라가는 장비가 낫다.
급별로 보면
| 급 | 대략적 메모리 | 대역폭 감 | 어울리는 자리 |
|---|---|---|---|
| 내장형 SoC 모듈 | 8~16GB 공유 | 수십 GB/s | 1~3B, 카메라 몇 대, 무팬 함체 |
| 미니 PC·통합 GPU | 16~32GB 공유 | 100GB/s 안팎 | 3~8B, 소규모 사무실·매장 |
| 엣지용 GPU 한 장 | 16~24GB 전용 | 수백 GB/s | 8~14B, 동시 수십 명 |
| 랙 서버 GPU | 48GB 이상 | 1TB/s 이상 | 이미 엣지가 아니라 작은 데이터센터다 |
숫자는 세대마다 바뀌므로 그대로 믿을 값이 아니라 자릿수를 잡는 용도다. 후보를 두셋으로 좁힌 다음에는 반드시 우리 모델과 우리 프롬프트로 직접 재 본다. 같은 급이라도 메모리 구성이나 런타임 성숙도에 따라 두 배씩 갈린다.
전기와 열은 사양표에 안 적혀 있다
현장 장비에는 함체가 있고, 함체 안은 사무실보다 덥고 먼지가 많다. 여기서 두 가지가 발목을 잡는다.
전력 한도. 기존 배전에 여유가 없어 장비 하나를 못 넣는 경우가 실제로 흔하다. 정격 소비 전력만이 아니라 순간 최대치와 필요한 콘센트 종류를 미리 확인해야 하고, 무정전 장치가 있다면 그 용량 안에 들어가는지도 봐야 한다.
지속 성능. 함체 안에서는 휴대폰과 같은 일이 벌어진다. 처음 몇 분은 사양대로 돌다가 온도가 오르면 클럭이 내려간다. 용량 산정은 벤치마크 첫 구간이 아니라 한 시간을 계속 돌린 뒤의 값으로 해야 하고, 무팬 장비라면 특히 그렇다.
사는 것보다 운영이 어렵다
마지막으로, 장비 선정만큼 중요한 것이 그 뒤의 절차다. 세 가지를 처음부터 정해 두면 나중에 크게 아끼게 된다.
모델을 어떻게 바꿀 것인가. 현장에 사람이 가야 한다면 그 기능은 사실상 안 바뀐다. 원격으로 모델 파일을 내려 주고, 검증하고, 문제가 있으면 이전 버전으로 되돌리는 경로를 처음부터 만든다.
한 대가 죽으면 어떻게 되는가. 한 대만 놓는 구성은 정지 시간이 곧 업무 정지인 곳에서는 못 쓴다. 두 대를 놓거나, 죽었을 때 중앙으로 자동으로 넘어가는 경로를 만든다. 뒤의 방식은 회선이 살아 있을 때만 유효하다는 점을 잊지 않는다.
무엇을 보고 있는가. 현장 장비는 조용히 나빠진다. 초당 토큰 수, 온도, 대기열 길이, 실패율을 중앙으로 모아 두지 않으면 사용자 불만이 첫 신호가 된다.
여기까지 정리하면 엣지에서 쓸 장비의 윤곽이 잡힌다. 남는 질문은 어느 요청을 현장 장비가 처리하고 어느 요청을 중앙 모델로 넘길 것인가인데, 이것은 하드웨어가 아니라 라우팅의 문제다.
읽어주셔서 감사합니다. 😊