4090 48GB + 128GB RAM에서 측정한 내용: Strata의 28.8 GB n-gram 테이블을 RAM에 유지하는 것이 약 1% 향상을 가져오지만, 대화 기록 보관(conversation parking) 기능이 저에게는 35배의 이득을 주었습니다.
대안: 저는 Strata의 n-gram 테이블 배치 방법 4가지를 벤치마크했습니다. 기본 설정이 이미 올바르며, 실제로 변화를 준 것은 다음과 같습니다.
본문
아래 내용은 모두 하나의 장비에서 측정된 것입니다. 수치를 제시하지 않은 부분에 대해서는 주장을 하지 않습니다.
요약 (모두 측정됨)
RAM 전체 n-gram 테이블: 프리필(prefill) +0.65% / 디코드(decode) +1.2%, RAM 비용 +28.4 GiB. 가치가 없습니다.
--ple-io mmap: 첫 번째 긴 프롬프트에서 72.8초 대 19.5초 (3.7배 느림)였으며, --ple-row-cache를 조용히 비활성화합니다.
이전에 제가 제시했던 RAM 상주 테이블에 대한 "+4.7%"는 잘못된 기준선이었고 실제 효과가 아니었습니다. 변경되지 않은 설정에서 세션 간 확산(Session-to-session spread)은 11.5%였습니다.
대화 기록 보관 (Conversation parking): 91,836 토큰의 대화로 돌아가는 시간이 18.8초 → 537ms로 단축되었으며, RAM 비용은 3.1 GB입니다.
--prefill auto:32768: 78.7K 프롬프트에서 프리필 +9.7%, 디코드 +13.6%를 달성했습니다. --calibrate를 사용한 후에는 제가 추측하지 못했을 값(CPU 워커를 23개에서 12개로 변경)을 통해 +3.2%를 발견했습니다.
설정
CPU / GPU / RAM i9-13900K / RTX 4090 48 GB (드라이버 617.14) / 128 GB DDR5-6000
OS / 엔진 Windows 11, Strata 0.1.38 릴리스 빌드 (sm_89), IQ3_S
설정 262K context, --kv int8 --kv-resident 32768, --expert-cache auto --prefill auto --spec 4, vision on
모델 파일 shard1 54.8 GB + shard2 28.8 GB, 둘 다 sha256 == 게시된 값
시작 시 엔진 로그 (나중에 관련됨): 로드된 전문가(experts): 46.84 GiB를 5.12 GiB/s로 (19초) 그리고 expert cache auto: 40.69 GiB 여유, 700 MiB 예약 (+218 MiB 초안) -> 20880 슬롯, 39.79 GiB의 VRAM — 즉, 24,576개의 전문가 중 20,880개 (85%)가 VRAM에 존재하며, 디코드 적중률(decode hit rate)은 97.3%-99.3%입니다.
이 장비에서의 기준 처리량: 78K-92K 컨텍스트에서 디코드 128-151 tok/s, 프리필 4,249-5,154 tok/s (자체 하네스 및 lm-eval-harness로 측정).
28.8 GB n-gram 테이블이 존재하는 곳 — 4개 팔(arms)
동일한 91,836 토큰 실시간 프롬프트, 각 팔마다 새로운 엔진 시작, 동일한 벤치마크 스크립트, 팔당 한 번의 실행:
팔 --ple-io --ple-row-cache 사용 RAM 콜드 프리필(디스크 읽기 / tok/s) 웜 프리필(디스크 읽기 / tok/s) 디코드
A direct 1,048,576 행 (~90 MB) 68.2 GiB 3,114 MB / 4,872 242 MB / 5,201 128.7
B mmap same 68.0 GiB 72.8 s / 1,274 0.4 MB / 5,208 99.8
C direct whole table (320,001,536 행) 96.6 GiB 3,111 MB / 4,872 1.4 MB / 5,235 130.3
D mmap whole table 68.4 GiB 71.6 s / 1,295 0.4 MB / 5,193 127.9
결론:
A와 C가 유일하게 깨끗한 비교 대상입니다 (동일 모드, 캐시 크기만 다름): 웜 프리필 +0.65%, 디코드 +1.2%. C는 디스크에서 173배 적게 읽고 본질적으로 동일한 속도로 실행됩니다 → SSD에 있는 n-gram 테이블은 이 머신에서 병목 현상이 아닙니다.
The 기본 ~90 MB 행 캐시가 재사용 가능한 트래픽의 92%를 흡수합니다 (동일 텍스트에 대한 두 번째 패스에서 3,114 MB → 242 MB).
mmap이 더 나쁩니다: 첫 번째 긴 프롬프트가 3.7배 느립니다 (콜드 페이지 캐시), 그리고 팔 D는 68.4 GiB RAM만 사용했습니다 — 28.8 GB는 전혀 할당되지 않았으므로, row cache는 mmap 하에서 무효(no-op)입니다. (B/D의
대화 파킹(Conversation parking) — 측정된 가장 큰 효과 (35배)
"--conversation-cache-mib", "8192" 및 "--conversation-cache-slots", "4"를 추가한 후, 관련 없는 긴 대화를 번갈아 가며 진행했습니다:
| 단계 | 경과 시간(Wall clock) | 디스크 읽기 | 엔진 로그 |
|---|
| P1 첫 실행 | 19.5초 | 2,969 MB | 91836 토큰 = 0 재사용 + 91836 읽음 |
| P2 (다른 대화) | 17.2초 | 614 MB | P1 파킹됨: 91,870 토큰 / 493 ms / 1.88 GB |
| P1 복귀 | 1.2초 | 1.5 MB | 91829 재사용 + 7 읽음 (537 ms 만에) |
RAM 비용은 8 GiB 예산 중 3.1 GB였으며, 제거(evictions)는 없었습니다. 28.4 GiB 구매량 대비 1%; 3.1 GiB 구매량 대비 35배.
-
--prefill auto:32768
이전에는 로그에 prompt chunk auto: 8192 토큰이라고 표시되었으나, 이후에는 32768로 변경되었습니다. 78.7K 프롬프트에서 측정했을 때: prefill은 4,667 → 5,106-5,136 tok/s, 디코딩(decode) 시 해당 컨텍스트 내에서는 112.6 → 127.2-129.1 tok/s였습니다. 짧은 프롬프트는 변하지 않았으므로, 만약 짧은 프롬프트로 테스트한다면 아무 효과가 없다고 결론지을 수 있습니다.
-
--calibrate — 수동 조정 금지
코드 블록
PCIe 공유 0.00 -> 150.8 | 0.20 -> 153.0 | 0.35 -> 154.1 | 0.55 -> 155.0 | 0.75 -> 146.9 draft floor 0.30 -> 140.2 | 0.50 -> 143.4 | 0.70 -> 140.1 CPU 워커(CPU workers) 23 -> 148.0 | 15 -> 149.9 | 12 -> 152.7 <- 선택됨
이 값은 --pool-workers 23 → 12 (+3.2%)로 변경되었으며, 13900K에서 측정되었습니다. 나중에 파일을 확인하세요. JSON 편집에 실패하더라도 요약본을 출력합니다 (저에게는 한 번 실패했습니다). 구성 변경 후에는 다시 실행해 보세요: 제가 해봤고, 다시 12가 선택되었습니다.
-
expert_profile_save — 작동함, 측정 가능한 이득 없음
전체 체인(chain)을 검증했습니다: 엔진이 라우팅 카운트 → POST /unload는 192 KB 프로필을 작성하고 → 다음 서버 시작 시 구성의 --expert-profile은 학습된 파일로 대체됩니다 (실제 프로세스 명령줄에서 확인). 측정 효과: 긴 prefill은 5,059 vs 5,120 tok/s, 긴 decode는 118.4 vs 127.9 — 즉, 노이즈 속에서, 이미 히트율(hit rates)이 98-99%에 달할 때의 차이입니다. 비용은 192 KB이며 VRAM을 사용하지 않으므로 그대로 두었지만, 속도 이점은 아닙니다.
시간을 소비하게 만드는 작고 측정된 것들
256K 컨텍스트는 짧은 채팅에 부담을 주지 않습니다: 17 토큰 프롬프트가 128-133 tok/s로 디코드되며, 78.7K 프롬프트는 112.6 tok/s로 디코드되고 RAM에서 110 MiB의 KV를 읽습니다 (vs 0.6 MiB). 비용은 설정된 상한선이 아니라 사용한 것에 비례합니다.
Vision 기능은 작동하며 저렴합니다: 합성 테스트 이미지를 0.97초 만에 읽고 올바르게 설명했으며, 비용은 641개의 expert slot(-3.1%의 캐시)입니다. 텍스트 처리량은 약간 낮습니다 (짧은 문장 기준 128-133 vs 136-151, 긴 문장 기준 112.6 vs 117.1).
ComfyUI와 GPU 공유: POST /unload는 47.9 GB 전체를 해제하며, POST /load + 첫 토큰 복귀까지 18-19초가 걸렸습니다. 제가 현재 사용하는 방식입니다.
Windows 11에서 엔진의 콘솔 창을 최소화하지 마십시오: 45.8 → 36.6 tok/s(-20%)로 떨어지며, 엔진 자체 로그도 이를 보여줍니다 (E-cores(EcoQoS 백그라운드 모드)에서 실행 시 -20%). 다른 창으로 가리는 것은 괜찮습니다. 저는 0.1.38을 확인했는데, 수정 사항이 없습니다.
PowerShell 5.1은 비-ASCII 요청 본문을 손상시킵니다 (Invoke-RestMethod가 ISO-8859-1을 보내기 때문에 모델은 문자 그대로 ?????를 보게 됩니다). 대신 curl --data-binary @file 또는 Python의 원시 바이트를 사용하십시오 — 같은 바이트, 올바른 답변입니다.
수동으로 배치된 모델 파일에는 <filename>.done 마커가 필요하거나, 설정을 다시 다운로드해야 합니다 (저는 0.9 GB 다운로드를 낭비했습니다).
--setup 패스는 구성을 재작성하고 수동으로 추가한 인수를 삭제합니다. 한 번 실행한 후, 제가 측정한 최적 설정이 사라졌습니다 (자동으로 복귀, workers가 23으로 복귀) 그리고 처리량은 151.6에서 133.0-133.3 tok/s로 떨어졌습니다. 모든 setup 실행 후에는 구성을 비교하십시오.
CN의 느린 Hugging Face: 제 프록시를 통해 시간당 87 KB/s인 반면, ModelScope는 연결당 12.3 MB/s이며, 7개의 병렬 스트림으로 92 MB/s입니다 (약 12분에 83.6 GB). HF_ENDPOINT=https://modelscope.cn/models가 모델, MTP 및 mmproj에 작동했습니다.
세 가지 환경 플래그(STRATA_PREFILL_OWN_AUTO, STRATA_IQ256_GATHER, STRATA_KV_PREFETCH)를 일부 기여자 브랜치에서 문서화했지만 0.1.38 사전 구축 바이너리에는 없습니다 — 바이너리의 문자열을 읽어 확인했습니다. 자체 빌드를 하지 않으면 설정해도 아무 효과가 없습니다.
제가 테스트하지 않은 것들
어떤 종류의 품질(perplexity, KL, 태스크 스위트 없음), 다른 GPU나 AMD, 두 번째 GPU, --kv q4_0, 262K를 넘는 컨텍스트, 그리고 NVMe보다 느린 스토리지는 언급할 수 없습니다. 따라서 n-gram 테이블이 언제 중요할지 말할 수는 없지만, 여기서는 그렇지 않다는 것만 말씀드릴 수 있습니다. 섹션 1의 일부 디코드 샘플은 길이가 단지 45 토큰에 불과하며, 이것이 arm C에서 나타난 1.2% 차이에 가중치를 두지 않은 이유입니다.
재현 방법: strata-<model>.json 파일에서 해당 키 두 개를 수정하고, 서버를 재시작한 다음, /health가 loaded: true가 될 때까지 폴링(polling)하여 로드된 후 동일한 4개의 요청을 같은 순서로 보냈습니다. 유용하다면 주석에 스크립트를 남겼습니다.
제출자: /u/Shot-Ad-4147
[링크] [댓글]