BC-250 보드 4개 클러스터에서 Next Flash IQ3_XXS 또는 Qwen 3.6 35B 구동 성능 공유

이것은 bc-250 클러스터에 대한 세 번째 업데이트이며, 로컬 AI를 처음 시도해 본 저에게는 정말 즐거운 경험입니다. 이 프로젝트가 주말 실험에서 미래에도 사용할 것이라고 생각하는 무언가로 바뀌었습니다. 저는 4개의 BC-250 보드를 2.5gb 이더넷 어댑터로 연결하고, 이를 2.5gb 스위치에 연결하여 llama와 vulkan 및 RPC를 사용하여 구동하고 있습니다. 모든 보드는 원래 제공된 asrock 4u12g bc250 케이스 안에 들어 있습니다. 처음에는 flash next Iq2에서 30 tok/s로 시작했고, 3.6 35B에서는 80 tok/s였습니다. 이후 Claude Code를 클러스터에 연결하여 더 나은 양자화(quant)된 next flash와 함께 컨텍스트 길이를 유지하며 60-70 tok/s(~150 ppt)로 구동하고 있습니다. 이 4개의 보드는 3.6 35B 인스턴스 2개를 145tok/s(~450 ppt)로 구동할 수 있으며, 컨텍스트가 150k에 도달하면 100 tok/s 이하로 떨어집니다. 이 보드들은 제가 구매했을 때는 각각 $100usd 미만이었지만, 최근 aliexpress에서 $150usd의 거래를 봤습니다. 이제 전력 모니터를 설치했고, 부하가 걸렸을 때 next flash는 600 - 700 W를 소비하며, 3.6 35B 인스턴스 2개를 구동할 때는 800 - 900 W를 소비합니다. 저의 다음 단계는 각 보드에 AIO(All-in-One) 냉각기를 사용하는 것입니다. 왜냐하면 보드가 더 많이 활용되면서 열스로틀링(thermal throttling)이 발생하는 것을 보기 시작했기 때문입니다. 또한, 클러스터를 계속 사용할 것이므로 케이스용 AIO 냉각 커버를 3D 프린팅하고 제작할 예정입니다 (골판지 플레넘에서 업그레이드). 누군가 더 많은 대역폭을 얻기 위해 m.2 네트워킹 솔루션으로 업그레이드를 제안하기 전에, 제한적인 제약 조건은 지연 시간(latency)이라는 점을 말씀드립니다. 보드들 사이에서 한 번에 데이터를 많이 보내지 않기 때문입니다.

BC-250 정보: https://elektricm.github.io/amd-bc250-docs/

Claude의 최적화 요약은 다음과 같습니다:

Next Flash
현재 빌드는 100K 컨텍스트를 실행합니다: 해당 요청에서 59.4 / 65.2 tok/s (첫 번째 / 두 번째 실행). 5K 토큰 프롬프트 뒤에서는 66.6-68.3 tok/s (샘플링, 512 토큰). 50,357 토큰 브라우저 생성 시 72.6 tok/s를 기록했습니다.

대부분의 작업은 먼저 Q2_0 파일에서 진행되었습니다 (5K 프롬프트에서 27.9 → 68-69 tok/s). 이후 IQ3로 이식되었습니다: 모델 자체의 MTP draft head를 이용한 추측 디코딩(Speculative decoding)을 파스(passes) 체인으로 실행합니다. Pass A는 알려진 토큰을 검증합니다. 뒤따르는 두 개의 초안(drafts) 패스가 각 보드에서 하나씩 진행됩니다 (총 여섯 개의 초안, 네 번의 패스). 한 라운드는 첫 번째 거부된 초안에서 종료됩니다. 세 번째 패스를 추가하자 Q2_0은 61 tok/s에서 68 tok/s로 증가했고, 여섯 개의 초안을 사용한 IQ3 온도-0 편집 요청은 84.0 tok/s에서 90.1-90.5 tok/s로 증가했습니다.

기록 및 재현 그래프(Recorded and replayed graphs). 워커들은 각 스테이지 그래프의 Vulkan 명령을 한 번 기록하고 이를 재현합니다 (그래프당 호스트 시간 3.7-4.5 ms 절약, +2%). 원격 그래프 노드는 다시 그룹화되어 레이어의 독립적인 제품들이 배리어 그룹(barrier group)을 공유하게 했습니다 (+5.7%). 이 아키텍처에 대한 정확한 커널(exact kernels) (라우트드-전문가 top-k, 두 토큰 전문가 패스, 순환 상태 융합)과 컨텍스트와 함께 증가하는 부분에 대해: 62K에서 +7.3%를 달성했고, 이후 66.1 → 68.9-69.6 tok/s가 나왔습니다.

컨텍스트 처리(Context handling). 컨텍스트 체크포인트는 코디네이터를 통하지 않고 보드 자체에 복사됩니다 (각각 665 → 18 ms, 프롬프트 속도 +60%). 프롬프트 배치는 보드를 통해 파이프라인 방식으로 진행됩니다. 컨텍스트는 32 토큰 프롬프트 배치로 65,536개에서 100,096개 토큰까지 증가했습니다.

Qwen3.6-35B-A3B Q4_K_M (HauhauCS GGUF), 두 보드, K/V 캐시 q8_0 처리. 첫 단계(Flash-Next 커널, 그래프 재현 및 전송, 두 초안): 120개에서 99.6K 프롬프트 토큰까지 기준선 대비 +39% ~ +66% 향상. MTP 헤드를 사용한 패스 체인 (네 개의 초안), 그리고 K/V 타일을 공유 메모리로 한 번 디코드하는 어텐션: 첫 번째 요청은 짧은 프롬프트에서 105.8 → 116.0 tok/s, 44K에서 73.0 → 95.2 tok/s를 기록했습니다. 더 긴 컨텍스트.

어텐션 마스크는 cells × tokens 텐서(코디네이터에서 768 MiB 절감) 대신 토큰당 하나의 제한을 사용하며, 프롬프트 배치는 q8_0 K/V를 제자리에서 읽습니다. 사용 가능한 컨텍스트 길이는 약 100K에서 258K(262,144 중)로 늘어났습니다. 코디네이터에서도 리플레이가 이루어집니다. 코디네이터 자체의 절반은 기록된 커맨드 버퍼로부터 재현됩니다(+2%~+4%). 드래프트 헤드 체크포인트는 위치 정보만 유지하므로, 99.6K에서 반복 요청 시 프롬프트 시간이 932-953 ms에서 142-163 ms로 줄었습니다. 시작 및 저장 시간도 단축되었습니다. 한 쌍이 105초 대신 32-35초 만에 시작하며, 대화는 재시작 후에도 비트 단위로 저장하고 복원할 수 있습니다. 최신 버전(검증됨). 드래프트 헤드의 따라잡기 패스는 이제 K/V만 기록합니다(이전에는 아무도 읽지 않는 어텐션을 계산함). 그리고 RPC 전송은 배치됩니다. 258K에서: 반복 요청 시 51.1 → 53.5 tok/s, 샘플링 시 51.7 → 54.4입니다. 해당 깊이에서의 일반 디코딩 속도는 36.4입니다. 정확도(Exactness) 가중치, 양자화 및 샘플러 설정은 변경되지 않았습니다. 온도 0에서, 추측 라운드는 동일 빌드의 일반 디코딩과 비트 단위로 검증됩니다. 이는 모든 로짓 행을 해싱하여 이루어집니다(35B의 최대 99.6K 깊이까지 다섯 번). 기존 llama.cpp와 비교했을 때, 커널이 재작성된 부분에서 로짓 값이 부동 소수점 반올림 수준(약 0.03)에서 다릅니다. 35B 모델은 어텐션을 고정 크기 청크로 합산하는 것을 포함하므로, 결과가 더 이상 패스가 담는 토큰 수에 의존하지 않습니다. 기존 버전의 드래프트 라운드는 일반 디코딩과 같은 순서로 차이가 납니다. submitted by /u/Ok-Breadfruit-3523 [link] [comments]