화웨이 Ascend 96GB 카드 2개로 Qwen3.8-flash-next 구동하기: 하드웨어 노트, vLLM 작업, 벤치마크 및 향후 계획

나는 직접적으로 강한 풍량을 쏘아주고 에어컨/히트펌프를 돌려서 방 온도를 관리한다. 몇 시간씩 모델을 돌려도 카드들은 문제없이 계속 돌아간다. Qwen을 돌리는 동안 기록된 장치 최고 온도는 보통 72~78°C였다. 내 워치독 제한 온도는 96°C인데, 거기까지 근처도 안 갔다.

그래서 패시브 카드 하나 더 추가하는 건 고민도 안 할 거다. 체크리스트는 별거 없다.

• 방열판 핀 사이로 공기 흐름이 막히지 않게 할 것.

• 섀시 팬의 정압이 충분한지 확인할 것.

• 카드당 보드 전력 150W와 호스트 전력을 추가로 예산에 잡을 것.

• 열기를 랙 안에서 돌리지 말고 방 밖으로 빼낼 것.

• 아이들 상태 온도만 믿지 말고 긴 프리필(prefill), 디코드(decode), 동시성 테스트를 돌리면서 온도를 기록할 것.

패시브라고 해서 저전력이나 자체 쿨링이 되는 게 아니다. 섀시와 방 전체가 쿨링 시스템이라는 뜻이다. 이것만 해결되면 나한테는 그냥 평범한 150W 서버 카드랑 똑같이 작동한다.

참고: 이 카드들은 램에서 데이터를 불러오거나 옮길 때만큼 열이 오르는 경우가 없음. NPU를 풀로 돌릴 때가 오히려 대용량 메모리 할당할 때보다 온도가 낮음. 모델 서빙 코드 경로 최적화할 때 이 점을 항상 염두에 두고 있음.

ECC, 명판 메모리, 그리고 실제로 쓸 수 있는 용량

내 카드들은 기본적으로 ECC가 켜진 상태로 왔음. 디바이스 메모리 좀 더 확보하려고 바로 꺼버림. 어차피 추론이랑 개발용 박스라 ECC 보호보다는 용량이 훨씬 중요하거든. 이건 신뢰성을 포기하는 대신 용량을 챙기는 트레이드오프지, 남들한테 무조건 이렇게 하라고 권장하는 건 아님.

ECC를 꺼도 펌웨어, 런타임, 통신 버퍼, 그래프 캡처, 워크스페이스, 할당자 예약 때문에 메모리가 꽤 나감. 실제로 소프트웨어에서 인식하는 건 48GB 칩 하나당 대략 43GiB 정도임. 칩 4개 합치면 총 172GiB 정도 쓸 수 있는데, 이것도 결국 4개의 독립된 로컬 풀로 나뉘어 있는 거임. 정확한 가용 메모리 수치는 CANN 빌드나 실행 설정에 따라 계속 바뀜.

이 차이 때문에 모델 관련 결정을 내릴 때마다 머리가 아픔. 단순히 "체크포인트 총용량이 192GB 안에 들어오나?"가 문제가 아님. "각 랭크의 가중치 샤드, 순환 상태(recurrent state), KV/캐시 할당, 그래프 캡처, 집합 통신 워크스페이스, 그리고 최악의 경우 임시 할당량까지 합쳐서 43GiB 안에 다 들어가나?"를 따져야 하니까.

vLLM이랑 vLLM Ascend를 따로 포크한 이유

공개된 작업물은 OpenSensor vLLM Ascend 포크(https://github.com/opensensor/vllm-ascend)와 그에 맞춰 수정한 vLLM 포크(https://github.com/opensensor/vllm)에 있음. 단순히 디바이스 커널 하나가 없어서가 아니라 양쪽 다 건드려야 했기 때문에 이렇게 함.

현재 이 포크들을 개발하는 건 나 혼자임. 소프트웨어 버스 팩터가 1이라는 소리임. 나름 진척은 많이 냈지만, 혼자서 빠르게 굴리는 포크를 NVIDIA 메인라인 vLLM의 성숙도나 테스트 커버리지, 지원 수준이랑 똑같이 생각하면 곤란함.

그리고 툴 사용 관련해서 골 때리는 문제도 있었음. 내가 작업할 때 Claude한테 이 아키텍처 관련 프롬프트를 넣으면 자꾸 거부하더라고. 카드가 중국 화웨이 하드웨어라는 이유 때문임. 그냥 서빙, 샤딩, 쿨링, 성능 같은 순수 엔지니어링 얘기였는데도 제한된 애플리케이션 만드는 거냐면서 튕기는 거임. 모든 Claude 버전이나 계정이 다 똑같이 행동한다고 단정 짓는 건 아니지만, 내 경험상 이 프로젝트 개발할 때 Claude는 믿을 게 못 됐음. 정치적인 입장을 떠나서, 이런 하드웨어 쓸 때 툴 선택에 있어 아주 현실적인 제약임.

Qwen3.8 Flash-Next는 MoE 라우팅, Gated DeltaNet 순환 레이어, 희소 2차 어텐션(sparse quadratic-attention) 레이어, 압축된 저비트 전문가 모델, 긴 컨텍스트, MTP 드래프트 모델을 다 때려 박았음. 이걸 깔끔하게 지원하려면 모델 통합, v1 러너, 캐시 계산, 스케줄링, 그래프 캡처, 분산 상태, 모델 로딩, 그리고 Ascend 전용 연산자까지 다 건드려야 했음.

지금 개발 스프린트는 거의 2주 반 동안 쉬지 않고 빌드하고 최적화하는 과정이었음. 포크 커밋만 수백 개고, 체크포인트 로드 수십 번 반복하고, 프로파일러 캡처 뜨고, 연산자 마이크로 벤치마크 돌리고, 몇 시간씩 걸리는 품질 테스트까지 돌렸음. 마법 같은 커널 패치 하나로 해결된 게 아님.

Qwen을 1 tok/s 수준의 멍청이에서 지금 상태로 끌어올린 방법

결정적인 변화를 만들어낸 아키텍처 수정 사항들은 다음과 같음.

1. 하이브리드 모델을 빠르게 만들기 전에 제대로 작동하게 만들기

초기 모델도 토큰 생성은 됐지만, 그게 제대로 작동한다는 뜻은 아니었음. 실제 프로덕션 환경에서만 터지는 문제들을 발견했거든. Gated DeltaNet 게이트 벡터 처리 오류, 순환 상태 정밀도 및 수명 주기 문제, 불완전한 희소 어텐션 스코어 폭, 호스트 연산자 API와 설치된 커널 패키지 간의 불일치 같은 것들임.

특히 GDN 이슈 하나는 진짜 골치 아팠는데, 헤드 수가 적은 테스트에서는 멀쩡하다가 실제 36개 순환 레이어를 다 돌리면 상태 에러가 누적되면서 횡설수설하는 텍스트를 뱉어냈음. 순환 상태를 FP32로 유지하고 프로덕션 환경에 맞게 데이터 이동 방식을 고친 게 핵심이었음. 커스텀 OPP 패키지와 파이썬 호스트 코드를 하나의 ABI 버전 단위로 관리한 것도 중요했고. 커널 버전 꼬이면 모델 문제인 줄 알고 한참 삽질하게 됨.

1. 모델을 통째로 올리지 말고 로드할 때 샤딩(Shard)하기

Qwen 체크포인트는 대략 169 GiB 정도고 safetensor 파일만 1,610개나 됨. 개별 NPU 메모리는 고사하고, 내가 테스트하던 환경 중 하나에선 호스트 RAM 용량보다도 컸음.

그래서 각 랭크(rank)가 필요한 전문가(expert) 데이터만 읽어오고, 밀집/공유 텐서는 필요한 곳에만 남겨두는 '전문가 인식 로더(expert-aware loader)'를 만들었음. 전문가 뱅크 전체를 메모리에 올렸다가 대부분 버리는 짓을 안 하게 된 거지. 호스트 측 전문가 데이터는 매핑해서 필요할 때만 가져오도록 바꿨음. 덕분에 모델 로딩이 메모리 뻥 터지는 사고에서 TP4/EP4 레이아웃에 맞춘 깔끔한 작업으로 변신함.

2. 저비트 가중치는 압축 상태로 두고 NPU에서 바로 처리하기

처음 만든 W4 레퍼런스는 eager 경로에서 압축된 가중치를 다 풀고 일반 matmul을 돌렸음. 정확도 확인용으로는 쓸만했는데, 테스트 케이스 하나 돌려보니 0.229 tok/s라는 처참한 속도가 나오더라.

실전용은 가중치를 압축된 상태 그대로 두고, 토큰을 장치 내 전문가에게 바로 쏴버림. 그룹화된 전문가 프로젝션에는 커스텀 AscendC Cube 커널을 썼음. FRACTAL_NZ 레이아웃 적용하고, 게이트/업(gate/up) 처리 합치고, 타일 리덕션, 경로 및 타일 재사용, 그리고 W4 가중치를 큰 임시 데이터로 계속 늘리지 않고 바로 W4A8로 실행하게 바꿨음.

이게 속도랑 용량 둘 다 잡는 방법임. 임시로 확장된 전문가 뱅크를 안 만드니까 메모리가 남아서 상태값, 캐시, 그래프, 동시성 처리에 더 쓸 수 있게 됨.

3. 지금 내 모델에 딱 맞는 캐시 만들기

Flash-Next는 일반적인 올 어텐션(all-attention) 트랜스포머가 아님. 내 설정은 36개의 순환 GDN 레이어랑 12개의 희소(sparse) QSA 레이어로 구성됨. 이걸 그냥 일반적인 dense KV 캐시로 다루면 메모리 낭비도 심하고 상태값 의미도 다 놓침.

그래서 순환 상태 관리, 압축된 물리적 캐시 레이아웃, 프리픽스 상태 계층, 희소 페이지 선택, 다이렉트 NZ 수집, 310P 전용 QSA 경로를 따로 구현했음. 서비스는 262,144 토큰 컨텍스트 제한으로 설정했고, 캐시 플래너는 그런 윈도우를 4.08개 정도 담을 용량을 확보함. 이건 메모리 계획 결과치지, 262K짜리 4개를 동시에 돌리는 부하 테스트를 완벽하게 끝냈다는 소리는 아님.

4. 토큰 루프에서 동기화랑 런칭 오버헤드 걷어내기

이런 장치들은 장치에서 호스트로 스칼라 값을 하나만 잘못 읽어도 파이프라인 전체가 멈춰버림. 그래서 핫패스(hot-path)에 있는 .item() 호출 다 지우고, 스텝별 텐서 재사용하고, 작업 뒤로 집단 연산 미루고, CPU 어피니티 빡빡하게 잡고, 라우팅이랑 희소 선택 로직은 파이썬 밖으로 빼버렸음.

eager 경로가 제대로 돌아가길래 decode 전용 ACL 그래프랑 MTP2 추론 디코딩도 추가함. 그래프 하나가 만능인 척하지 않고, 실제로 서비스하는 동시성 형태를 그대로 캡처해서 씀. 디코딩 스텝 하나가 작은 커널 수십 개를 띄우는 구조라, 연산 합치기(fused operators)랑 그래프 재사용이 진짜 중요함.

5. 커널 하나만 튜닝하지 말고 서비스 전체를 최적화하기

마이크로 벤치마크에선 1등 먹었는데 전체 서비스 돌려보면 느려지는 커널들이 꽤 있었음. 그래서 실제 요청 시간을 줄여주는 놈들만 남기고 나머지는 다 쳐내거나 격리함. 다중 요청 QSA, 그룹화된 MTP 전문가, 전문가 경로 캐싱, 캐시 회계, 콜드 프리필 청킹, 집단 연산 오버랩 같은 것들은 전부 API 경계에서 측정했음.

마지막 부분이 핵심인데, 요청 하나당 30 tok/s 정도 나오는데 요청 4개를 동시에 때리면 61 tok/s가 나오는 이유가 이거임. 단일 토큰 스트림일 땐 놀고 있던 장치 자원을 추가 작업들이 꽉 채워서 쓰는 거지.

현재 Qwen 성능

이건 통제된 단일 변수 벤치마크가 아니라, 단계별로 작업하면서 찍은 마일스톤임:

Qwen3.8 Flash-Next 마일스톤 / 측정 결과

초기 비통제 서비스: 대략 0.2–1.9 tok/s, 자주 횡설수설함

정상적인 eager W4 디퀀트 레퍼런스: 0.229 tok/s

안정적인 W8 서비스 베이스라인: 약 18–19 tok/s

네이티브 W4A8, MTP2, 그래프, 단일 요청: 중앙값 29.74 tok/s; 최대 34.34

동일 최적화 서비스, 4개 요청 동시 처리: 합계 중앙값 60.88 tok/s

40K 웜 프리픽스 요청 2개 동시 처리: 합계 30.76 tok/s

40K 콜드 프롬프트: TTFT 약 120초; 이후 30–32 tok/s

30/61 tok/s 수치는 짧고 고정된 출력의 디코드 테스트 결과일 뿐임. 긴 추론 요청을 처리해보면 훨씬 더 현실적이고 유용한 결과가 나옴.

.buffering-track-fill { stroke-dasharray: 100; stroke-dashoffset: 50; }

품질 측면에서, 4개의 칩이 장착된 Ascend W4 서비스에서 198개의 GPQA Diamond 질문 전체를 돌려봤고, 비교군으로 llama.cpp에서 다른 IQ4_XS GGUF를 구동하는 RTX 6000 Pro를 사용했음. 둘 다 AISBench 스타일의 답변 추출기를 사용했을 때 140/198(70.71%)의 점수를 기록함. 이건 Ascend 경로가 제대로 작동한다는 증거임. 런타임, 양자화, 챗 템플릿, 동시성 처리가 서로 다르기 때문에 순수한 하드웨어나 양자화 비교라고 보긴 어렵지만 말이야.

마지막으로 끊김 없이 진행된 106개 케이스의 Ascend 단계에서, 4개의 워커가 2시간 52분 46초 동안 507,256 토큰을 뱉어냈는데, 합산 속도는 48.93 tok/s였음. 이 긴 추론 생성 과정에서 요청당 클라이언트 중앙값은 12.50 tok/s였음. 서버는 해당 단계의 모든 요청을 이글 폴백(eager fallback)이나 수락 불가 구간 없이 완벽하게 처리함. RTX 비교군이 요청당 속도는 훨씬 빨랐으니, 이걸 NVIDIA 킬러라고 주장하려는 건 아님. 다만 처음엔 느리고 헛소리만 하던 하드웨어에서 대형 모델이 제대로, 그리고 유용하게 돌아가고 있다는 걸 보여주는 거임.

다음은 더 빡센 GLM 모델 차례

약 304B 파라미터 규모의 GLM-5.3-Flash 아키텍처도 올리는 중임. 이건 34개의 KDA 선형 어텐션 레이어, 11개의 DSA 희소 어텐션 레이어, 288개의 전문가(expert), 잠재 MLA 히스토리, mHC 믹싱, 그리고 W2/W4 혼합 전문가 체크포인트를 결합한 구조임. 체크포인트 용량은 약 151.6 GiB이고, 4랭크 프로필 기준으로 랭크당 약 35.6 GB의 가중치가 로드됨.

이제 같은 머신에서 로드와 생성이 다 됨. 지금까지의 속도 향상 과정은 다음과 같음:

GLM 4칩 마일스톤 / 단일 요청 / 4개 요청 합산

초기 풀 서비스 프로필 / 0.764 tok/s / 1.474 tok/s

배치 처리 NZ 워크스페이스 쓰기 / 0.912 tok/s / 1.822 tok/s

NZ 패킹 코드 레이아웃 / 1.386 tok/s / 2.946 tok/s

Fused mHC/MLA 작업 / 1.743 tok/s / 3.269 tok/s

최근 측정된 통합 러너 / 2.236 tok/s / 4.476 tok/s

8,232 토큰짜리 GLM 프롬프트는 약 39.1 prompt tok/s로 프리필(prefill)되고, 이후 약 2.16 tok/s로 디코딩됨. 이 수치는 내가 목표로 하는 것과는 거리가 멀고, 32토큰 테스트 완료로는 답변 품질을 판단하기엔 너무 짧음. GLM은 현재 서비스 권장 단계가 아니라, 이제 막 올리고 최적화하는 단계임.

여기서 중요한 양자화 교훈을 하나 얻었음. 초기 W2 체크포인트에서 마지막 레이어의 RMS가 525까지 치솟는 잔차 증가 현상이 보였거든. 영향을 받는 전문가들을 클립이 없는(no-clip) W4 처리로 옮기니까 네트워크가 안정됨. 별개로, 내가 직접 짠 블록 디퀀트(blocked-dequant) Cube 커널은 격리 테스트에서 이글(eager) 레퍼런스보다 약 17배 빨랐음. Qwen 때도 느꼈지만, 수치적인 동작과 엔드 투 엔드 통합이 모두 통과해야 비로소 "끝났다"고 할 수 있는 거임.

세 번째 카드: 단순한 여분이 아니라 메모리와 코어 50% 추가

이 시스템에 Atlas 300I Duo를 하나 더 추가할 계획임. 그러면 머신에 310P 장치가 4개에서 6개로 늘어나고, 명목상 장치 메모리도 192 GB에서 288 GB로 늘어남. 동일한 ECC와 런타임 예약을 적용하면, 런타임에서 인식 가능한 용량이 약 86 GiB 추가되어 6개 랭크 전체에서 약 258 GiB 정도 확보될 것으로 예상함.

n-카드 아키텍처는 이걸 활용하도록 설계됨. 전문가 소유권이 랭크별로 분산되어 있어서, 새로 추가되는 칩 2개는 단순히 저장 공간만 늘리는 게 아니라 로컬 전문가 용량과 가속기 코어를 더해줌. 토큰은 해당 전문가를 가진 랭크로 라우팅되고, 추가된 랭크들은 모델의 연산과 집합 통신(collectives)에 참여하게 됨. EP6에서 유의미한 규모 확장을 기대하고 있는데, 정확한 속도 향상 폭은 미리 광고하는 게 아니라 직접 측정해 볼 예정임.

추가된 용량으로 얻을 수 있는 이점들:

• 더 큰 전문가 세트나 더 높은 정밀도의 레이어를 상주시키기.

• 호스트 오프로드 없이 4칩 제한을 살짝 넘는 모델 돌리기.

• 긴 컨텍스트 상태와 캐시에 메모리 더 할당하기.

• 품질 대비 효율이 떨어지는 구간에서 과도한 양자화 줄이기.

• 다른 소규모 서비스나 평가 작업을 돌릴 여유를 남겨두면서 대규모 분산 모델을 실행한다.

비용은 카드 한 장, 최대 보드 전력 150W, 디바이스 랭크 두 개, 그리고 제대로 된 공기 흐름이 필요한 패시브 히트싱크 하나가 더 들어간다는 점이다. 냉방이 잘 되는 방이라면 이런 건 구조적으로 전혀 문제 될 게 없다. 진짜 흥미로운 비용은 통신 쪽이다. 랭크가 6개가 되면 경로 밸런스, 집합 연산(collective) 크기, PCIe/HCCL 트래픽이 싹 다 바뀐다. 이 토폴로지는 나중에 튜닝하고 벤치마크 돌려볼 생각인데, 소프트웨어는 이미 하드코딩된 4-way 방식이 아니라 n-카드 전문가 분산 처리에 맞춰져 있어서 다행이다.

알려진 문제 및 진행 중인 작업

현재 내 작업대 상황은 이렇다:

• 크로스 스트림 레이스 컨디션 하나를 방금 잡았다. prefix-Mamba 상태 슬롯이 NPU 쓰기 작업이 끝나기도 전에 덮어쓰이거나 재사용되면서, 예전 체크포인트가 복구되는 문제가 있었다. 이 수정 사항은 NPU 회귀 테스트를 거쳤다. 나중에 106개 케이스를 돌려봤는데 성능 저하 없이 상태 스필(spill) 12번을 무사히 통과했다. 고무적이긴 하지만 근본적인 해결책이라고 확신하긴 이르다. 지금도 혼합 부하랑 제거/재사용 테스트를 계속 돌리는 중이다.

• Qwen 콜드 프리필(cold prefill). 40K 콜드 프롬프트는 이후 디코딩이 빨라도 여전히 2분 정도 걸린다. 프로파일링 해보니 주범은 12개의 QSA 레이어, 특히 희소 선택(sparse selection)과 타일드 어텐션(tiled attention) 쪽이다. 이제는 자잘한 디코딩 최적화보다 이쪽을 잡는 게 훨씬 중요하다.

• Qwen 긴 문맥(long-context) 검증. 플래너 용량은 충분한데, 지금 설정된 문맥, 할당된 용량, 그리고 끝까지 마친 긴 문맥 테스트를 하나씩 분리하는 중이다. 그냥 실행 플래그 띄운 스크린샷 말고, 진짜 검색이랑 동시 채우기(concurrent-fill)가 되는지 증거를 남기고 싶다.

• GLM 일관성 및 성능. KDA, MLA, QSA, 러너 통합 변경 사항을 적용한 뒤에 전체 모델을 다시 검증하고 있다. 그다음엔 그룹화된 혼합 W2/W4 전문가 경로, 캐시 레이아웃, 그래프 리플레이, 그리고 마지막으로 MTP까지 Qwen에 썼던 것과 똑같은 엄격한 검증 과정을 거칠 예정이다.

• GLM 로딩 및 메모리. 필터링된 로더를 쓰면 텐서가 실제로 만들어지기 전에 피어 소유거나 구버전인 체크포인트 페이로드를 대량으로 건너뛸 수 있다. 로딩 시간이 20% 정도 줄어드는 걸 확인했는데, 확실한 결과라고 말하기 전에 제어된 환경에서 다시 돌려보고 바이트 단위로 계산해봐야 한다.

• 6-디바이스 전문가 병렬 처리. 세 번째 카드가 도착하면 6-랭크 토폴로지에서 랭크 밸런스, 카드별 온도, 집합 연산 시간, 모델 용량, c1/cN 처리량을 측정할 거다.

• 기타 모델 어댑터. 지금 쓰고 있는 로더, 패키지 전문가, 캐시, 오퍼레이터 인프라는 DeepSeek나 다른 하이브리드/MoE 작업에도 그대로 쓰인다. 기본 계약을 일반화할 수 있는 부분은 모델 이름에 따라 조건문을 다는 짓을 최대한 피하고 있다.

살 만한 가치가 있을까?

다음 주에 OpenSensor 스토어(https://www.opensensor.io/)에 첫 번째 추가 카드를 2,900달러에 올릴 생각이다. 아직 리스팅은 안 됐다. 하드웨어 성능이랑 소프트웨어로 뚫릴 잠재력을 생각하면 꽤 괜찮은 가격이라고 본다. 물론 메인라인 vLLM을 돌리는 NVIDIA 카드처럼 사자마자 바로 돌아가는 '턴키' 제품은 아니다.

내 생각에 이 물건은 개발자, 연구실, 아니면 시스템 쪽을 좀 아는 사용자한테 적합하다. 아래 두 가지를 다 감당할 수 있어야 한다.

1. 공기 흐름(쿨링)은 알아서 해결해야 한다. 이건 패시브 쿨링 방식의 서버용 카드다. 케이스랑 메인보드에 따라 고정압 케이스 팬을 달든, 덕트를 쓰든, 3D 프린터로 슈라우드를 뽑든 해야 한다. 나는 Fusion 360을 쓰니까 슈라우드 설계가 필요하면 기꺼이 도와줄 수 있다. 메인보드 레이아웃, 카드 간격, 팬 크기, 케이스 모양이 너무 제각각이라 모든 상황에 맞는 설계 하나를 딱 내놓을 수는 없다.

2. 활발하게 개발 중인 포크 버전을 써야 한다. 지금 vLLM 작업은 나 혼자 하고 있다. 업스트림은 미국에서 구할 수 없는 서버급 가속기 모듈에만 집중하고 있어서다. 진행 상황은 확실하고 이 글에 있는 벤치마크도 실제 하드웨어에서 뽑은 거지만, 버그는 계속 나올 거고 더 좋은 방법도 계속 발견될 거다. CUDA나 메인라인 vLLM보다 훨씬 거친 환경이라는 걸 감안하고, 고정된 버전을 따라가고, 런북을 읽고, 실패 사례를 보고하고, 가끔은 새로운 하드웨어나 모델 조합을 진단하는 데 기꺼이 시간을 쓸 사람만 사길 바란다.

스택을 건드리지 않고도 임의의 모델을 돌릴 수 있는 완성된 어플라이언스가 필요하다면, 지금 당장 이 제품을 추천하진 않겠다. 하지만 이 가격대에 많은 추론 메모리가 필요하고, 좀 거친 환경에서도 작업할 자신이 있으며, 오픈 Ascend 서빙 스택을 확장하는 데 가치를 느낀다면 꽤 괜찮은 개발 플랫폼이 될 수 있다.

이 카드들이 잘하는 것

Atlas 300I Duo는 세련된 CUDA 생태계보다 가용 용량이 더 중요하고, 시스템 구축 작업을 직접 할 의향이 있을 때 매력적이다. 싱글 슬롯 150W 카드 두 장이면 4개의 가속기 랭크와 넉넉한 로컬 모델 메모리를 확보할 수 있다. MoE 모델은 특히 궁합이 좋은데, 토큰마다 선택된 전문가만 실행하면 되니까 전문가 가중치를 분할해서 쓰기 딱 좋다.

단점은 카드가 패시브 쿨링 방식이라거나 150W로 제한된다는 게 아니다. 진짜 문제는 310P에서 여전히 모델별 런타임과 커널 작업을 직접 다 해줘야 한다는 점이다. 레이아웃, 지원하는 데이터 타입(dtype), 그래프 세이프 메타데이터, 커스텀 연산자, 스파스 어텐션, 상태 소유권, 툴링, 그리고 문서화까지 전부 다. 그냥 Hugging Face에 있는 아무 모델이나 가져다가 vLLM에 바로 꽂아서 쓸 생각을 한다면, 그런 경험은 기대하지 않는 게 좋다.

그래도 밑바닥부터 하드웨어를 세팅하는 걸 즐기는 사람이라면, 이 폼팩터에서 뽑아낼 수 있는 성능은 상당하다. 처음엔 1 tok/s 정도로 횡설수설하던 게 이제는 스트림당 30 tok/s, 합계 61 tok/s 수준으로 Qwen을 돌릴 수 있게 되니 이 플랫폼의 가능성에 대해 훨씬 낙관적이게 됐다. 세 번째 카드를 장착하면 모델 용량과 전문가 병렬 처리량을 더 끌어올릴 수 있을 텐데, 측정되는 대로 결과가 좋든 나쁘든 공유하겠다.

젠장, 그거 정말 안됐네요.

좋네요, 친절한 답변 감사합니다.