필자는 화웨이 Atlas 300I Duo 카드 두 장으로 다소 특이한 로컬 추론 머신을 구축해 왔다. 이 카드는 가격이 상대적으로 저렴하고 패시브 냉각 방식의 듀얼 가속기 PCIe 카드로 각각 96GB의 디바이스 메모리를 갖추고 있지만, 절대 CUDA의 드롭인 대체품은 아니다. 지난 2주 동안 Qwen3.8 Flash-Next를 처음 구동했을 때는 출력이 종종 무의미했고 생성 속도도 초당 약 1토큰 수준에 머물렀으며 그 이하로 떨어진 실행도 있었다. 그러나 오늘 같은 두 장짜리 머신은 짧은 디코드 벤치마크에서 요청 하나당 약 30토큰/초, 4중 동시성에서는 합산 약 61토큰/초의 일관된 출력을 내고 있으며 198문항 전체로 구성된 GPQA Diamond 세트도 완주했다. 이 글은 이 카드들을 위한 가이드의 시작으로 카드의 물리적 실체, 냉각 방법, 96GB의 실제 의미, vLLM과 vLLM Ascend에 적용한 변경 사항, 실제 효과가 있었던 최적화, 아직 남아 있는 문제들을 다룬다. 요약하면 하드웨어는 충분히 유능하며 필자의 작업은 대부분 ubuntu-26.04 드라이버 지원, 모델 아키텍처 지원, 메모리 레이아웃, 커스텀 연산자, 모든 비동기 상태 전환을 정확히 맞추는 일 등 소프트웨어 스택에서 이뤄졌다.

하드웨어 측면에서 한 장의 카드는 실제로 두 개의 디바이스다. 현재 시스템에는 Atlas 300I Duo 카드 두 장이 장착되어 Ascend 310P3 디바이스 네 개로 인식되며, 물리적 카드는 현재 2장에서 계획상 3장으로, Ascend 디바이스는 4개에서 6개로, 명판 기준 디바이스 메모리는 192GB에서 288GB로, 이 구성에서 런타임에 실제 보이는 메모리는 약 172GiB에서 약 258GiB로, 카드 합산 최대 전력은 300W에서 450W로 늘어난다. 각 카드는 가속기 SoC 두 개와 총 96GB의 LPDDR4X를 갖추고 칩 하나당 로컬 메모리는 48GB인데, 하나의 통합된 96GB 할당이 아니므로 48GB 디바이스 하나에 맞지 않는 모델은 여전히 텐서, 엑스퍼트, 파이프라인 등 어떤 형태로든 모델 병렬화가 필요하다. 카드는 PCIe Gen4 x16 규격의 풀하이트/풀레ング스에 놀랍도록 얇은 싱글슬롯 설계이며 화웨이는 집계 메모리 대역폭 408GB/s와 최대 보드 전력 150W로 규정하고 있고, 많은 가속기 소프트웨어가 쓰는 일반적인 HBM 용어와 달리 이 카드의 메모리는 LPDDR4X다. 칩 두 개가 카드 하나를 이루는 배치는 중요한 의미를 갖는다. 모델 내 통신은 여전히 분산 런타임을 거치고 메모리는 각 랭크에 로컬로 유지되며, 필자는 HCCL 컬렉티브를 사용해 텐서와 엑스퍼트 소유권을 네 개 칩 전체에 명시적으로 매핑한다. 이 머신을 96GB GPU 두 장이 아니라 48GB 랭크 네 개로 생각하는 것이 훨씬 유용하다.

패시브 냉각이 치명적인 장애물은 아니다. 카드에는 대형 히트싱크가 달려 있지만 자체 팬이 없고 서버 공기 흐름을 전제로 설계되었기 때문에 일반 워크스테이션에 넣고 후면 케이스 팬이 해결해 주기를 바라는 것은 나쁜 계획이며, 히트싱크와 히트파이프 배치를 확인할 수 있는 분해 리뷰도 공개되어 있다. 필자는 카드에 직접 대풍량 공기를 불어 넣고 방 전체를 에어컨과 히트펌프 냉각으로 유지하며, 수 시간에 걸친 실제 모델 부하에서도 카드는 아무 문제 없이 계속 돌아갔다. 기록된 Qwen 실행 전반에서 피크 디바이스 온도는 대체로 72~78도였고 워치독 한도는 96도이며 카드는 이에 근접한 적이 없어 패시브 카드를 한 장 더 추가하는 것도 전혀 꺼림침하지 않다. 체크리스트는 평범한데, 히트싱크 핀 사이 공기 흐름을 막지 않고 섀시 팬의 정압을 충분히 확보하며 카드당 보드 전력 150W에 호스트 나머지 소비까지 전력 예산을 잡고, 열을 랙으로 재순환하지 않고 방 밖으로 배출하며, 대기 상태 판독을 믿지 말고 긴 프리필, 디코드, 동시성 테스트 동안 온도를 기록해야 한다. 패시브가 저전력이나 자가 냉각을 의미하는 것은 아니며 섀시와 방이 곧 냉각 시스템이고, 이를 해결하고 나면 이 카드들은 일반적인 150W 서버 카드처럼 동작했다. 참고로 이 카드를 가장 뜨겁게 만드는 것은 메모리에 무언가를 적재하거나 옮기는 작업으로 풀 활용 상태의 NPU가 대형 블록 메모리 할당보다 더 시원하게 유지되며, 모델 서빙 코드 경로를 최적화할 때 이 점을 염두에 둔다.

ECC와 명판 메모리, 실제 사용 가능 용량 문제도 있다. 카드는 기본적으로 ECC가 활성화된 상태로 도착했고 필자는 디바이스 메모리를 되찾기 위해 이를 비활성화했다. 이 머신은 추론과 개발용 박스이므로 여기서는 ECC 보호보다 용량을 의식적으로 선택했으며 이는 신뢰성 트레이드오프이지 보편적 권고가 아니다. ECC를 끄더라도 펌웨어, 런타임, 통신 버퍼, 그래프 캡처, 워크스페이스, 할당자 예약이 메모리를 소비하며, 실제로 소프트웨어는 48GB 칩 하나당 약 43GiB를 보고 칩 네 개를 합치면 약 172GiB의 유효 용량이 되지만 여전히 별개의 로컬 풀 네 개다. 정확한 가용량은 CANN 빌드와 실행 구성에 따라 달라지며, 이 구분이 거의 모든 부분에 영향을 미쳤다.