Cloudflare의 소형 모델 서빙, 메모리는 줄였지만 안전성이 시험대에
Cloudflare의 소형 모델 서빙은 일반적인 동시성 수준에서는 처리 속도를 다소 희생하는 대신, 이제 GPU 메모리에 Kimi 컨텍스트를 두 배 더 담을 수 있다. 이 회사는 GLM 가중치도 압축하고, 지원되는 디코드 작업이 읽기 전에 공유 캐시 페이지를 검사한다. 이러한 변화는 GPU 메모리를 고정된 한계가 아니라 Cloudflare가 능동적으로 관리할 수 있는 자원으로 바꾼다.
이는 Moonshot AI의 Kimi 모델과 Z.ai의 GLM 모델이 단순히 추론 카탈로그에 추가되는 일반적인 모델이 아니기 때문이다. 이들은 대규모 파라미터 수, 긴 컨텍스트 윈도우, 전문가 혼합 아키텍처를 결합한다. 전문가 혼합 모델은 각 토큰마다 네트워크의 일부를 선택적으로 활성화해 계산량을 줄이지만, 저장된 가중치 자체가 작아지는 것은 아니다.
갈등의 구도는 단순히 Cloudflare와 다른 추론 제공업체 간의 경쟁이 아니다. 공유 하드웨어에서 높은 집적 활용도와 안전한 격리의 대결이다. 하나의 GPU에 더 많은 요청을 담으면 경제성과 전체 처리량은 개선되지만, 캐시 관리에 오류가 발생했을 때의 영향도 커진다.
Cloudflare는 새 구성이 모델 정확도를 유지하면서 용량을 늘린다고 말한다. 다만 이를 뒷받침하는 측정치 대부분은 Cloudflare 자체 평가 스위트와 인프라에서 나왔다. 다음 시험대는 이러한 이점이 다양한 워크로드, 하드웨어 세대, 훨씬 더 큰 규모의 프로덕션 환경에서도 안정적으로 유지되는지다.
Cloudflare가 Kimi와 GLM에 적용한 변화
Cloudflare는 단일 최적화만으로는 최전선 규모의 모델 서빙 문제를 해결할 수 없기 때문에 세 가지 메모리 기술을 결합했다.
회사는 8월 3일 기술 설명에서 이러한 변화를 자세히 소개했다. Kimi의 KV 캐시에는 FP8 양자화를 적용하고, GLM 가중치에는 INT4 압축을 적용하며, 공유 캐시 페이지에는 무결성 태그를 부여한다. 각 기술은 동일한 추론 시스템 안에서 서로 다른 제약을 해결한다.
KV 캐시는 모델이 이미 처리한 토큰에서 생성된 어텐션 키와 값을 저장한다. 이를 통해 모델은 생성되는 토큰마다 전체 프롬프트를 다시 계산하지 않고 대화를 이어갈 수 있다. 긴 프롬프트와 동시 요청은 이 캐시를 빠르게 키운다.
Cloudflare는 Kimi K2.6의 캐시 데이터를 BF16 대신 FP8 e4m3로 저장한다. FP8은 각 부동소수점 값에 8비트를 사용하며, BF16은 16비트를 사용한다. 이 변환으로 캐시의 메모리 사용량은 절반으로 줄어든다.
Cloudflare에 따르면 사용 가능한 메모리 내 컨텍스트는 약 686,000토큰에서 약 137만 토큰으로 늘어난다. 이는 한 사용자를 위한 새로운 컨텍스트 윈도우 한도가 아니라, 테스트된 배포 환경의 총 용량이다. 이 구분은 최적화가 주로 동시성을 높이기 때문이다.
Cloudflare는 GLM 5.2에는 별도의 변경을 적용했다. 모델 가중치를 FP8에서 4비트 정수 표현인 INT4로 압축했다. 체크포인트 크기는 705GB에서 421GB로, 약 40% 줄었다고 한다.
8방향 텐서 병렬 배포는 모델을 8개의 GPU에 나눠 배치한다. 이 구성에서 Cloudflare는 GPU당 메모리 사용량이 약 88GB에서 52GB로 감소했다고 말한다. 남은 공간에는 약 118만 개의 KV 캐시 토큰을 담을 수 있다.
세 번째 변화는 이처럼 더 촘촘한 배치로 만들어진 공유 캐시를 보호한다. 모든 물리적 캐시 페이지에는 페이지가 재할당될 때마다 변경되는 태그가 부여된다. 서버는 각 요청이 기대하는 페이지와 태그를 기록한다.
지원되는 디코드 작업이 해당 페이지를 읽기 전에 Cloudflare는 매핑을 확인한다. 불일치가 발견되면 영향을 받은 요청은 중단된다. 따라서 시스템은 다른 요청과 연결된 데이터를 읽는 대신 안전하게 실패해야 한다.
이러한 기술은 Cloudflare의 더 광범위한 대형 모델 아키텍처 위에 구축된다. 회사는 이전에 분산 GPU 네트워크용으로 설계된 Rust 기반 엔진인 Infire inference를 설명한 바 있다. 또한 프리필과 디코드를 서로 다른 리소스 풀로 분리한다.
프리필은 들어오는 프롬프트를 처리하고 초기 캐시 상태를 만든다. 디코드는 응답을 한 번에 하나의 토큰씩 생성한다. 두 단계는 GPU에 서로 다른 부담을 주므로 Cloudflare는 각 풀을 별도로 최적화할 수 있다.
이 분리는 새 설계에 필수적이다. Cloudflare는 계산이 지배적인 구간에서는 BF16 캐시와 FP8 가중치를 유지한다. 메모리 용량이나 대역폭이 제약 요인이 되는 곳에서는 더 작은 표현을 사용한다.
그 결과는 모든 상황에 적용되는 하나의 압축 모델 구성이 아니다. 워크로드에 따라 형식을 바꾸는 단계 인식형 서빙 시스템이다. 이는 운영 복잡성을 높이지만 전체 요청에 하나의 절충안을 강요하지는 않는다.
Cloudflare의 소형 캐시가 순수 속도를 앞서는 이유
Kimi KV 캐시 양자화의 이점은 각 요청을 개별적으로 더 빠르게 처리하는 데 있지 않고, 더 많은 작업을 수용하는 데 있다.
Cloudflare는 분리형 H200 배포 환경에서 Kimi K2.6 디코딩을 테스트했다. 동시 요청이 하나일 때 BF16 캐시는 초당 137토큰을 제공했다. FP8 버전은 125토큰을 제공했으므로, 이 부하에서는 압축 캐시가 더 느렸다.
동시성이 늘어나도 이 패턴은 이어졌다. 요청이 8개일 때 BF16은 초당 731토큰에 도달했고, FP8은 689토큰이었다. 요청이 16개일 때 측정값은 각각 초당 1,106토큰과 1,028토큰이었다.
BF16은 동시 요청 32개에서 초당 1,558토큰에 도달했다. 그러나 이후 사용 가능한 메모리를 모두 소진했다. Cloudflare는 FP8 캐시가 요청 64개까지 계속 처리했으며 초당 2,192토큰을 제공했다고 말한다.
이 마지막 수치는 BF16의 최고 측정 처리량보다 약 41% 높다. Cloudflare는 토큰당 비용도 약 30% 낮아졌다고 보고한다. 이 이점은 낮은 부하의 각 요청을 가속하는 것이 아니라, 동일한 배포 환경에서 더 많은 작업을 수행하는 데서 나온다.
이 구분은 그럴듯하지만 오해를 부를 수 있는 헤드라인을 막는다. 어텐션 커널이 캐시된 값을 읽을 때 양자화는 변환 작업을 추가한다. 동시성 조건을 맞춰 비교했을 때 Cloudflare의 BF16 결과는 여전히 수%포인트 더 빨랐다.
Kimi KV 캐시 양자화는 메모리 한계 때문에 더 큰 형식이 추가 요청을 수용할 수 없게 된 이후에야 가치가 생긴다. 요청당 효율을 소폭 교환하는 대신 훨씬 더 큰 총용량을 얻는다. 추가 공간을 활용할 만큼 수요가 충분히 높을 때는 합리적인 선택이다.
트래픽이 드문 경우에는 가치가 낮다. 동시에 몇 개의 요청만 처리하는 배포 환경은 추가 용량을 사용하지 못한 채 변환 오버헤드만 떠안게 된다. 따라서 Cloudflare의 접근 방식은 각 디코드 풀로 충분한 호환 작업을 라우팅하는 데 달려 있다.
바로 이 지점에서 글로벌 인프라가 전략적으로 중요해진다. 대형 제공업체는 많은 고객의 트래픽을 집계해 고가의 가속기를 계속 가동할 수 있다. 규모가 작은 운영업체는 종종 급격히 변동하는 수요에 직면하며, 같은 활용도 향상을 얻기 어렵다.
Cloudflare는 이미 Workers AI에서 세션 어피니티와 프리픽스 캐싱을 사용한다. 프리픽스 캐싱은 동일한 프롬프트 시작 부분의 계산된 상태를 재사용한다. 회사의 대형 모델 출시에서는 캐시된 토큰 사용량을 공개하고 더 나은 캐시 라우팅을 위한 세션 어피니티 헤더를 도입했다.
새 최적화는 다른 계층을 겨냥한다. 프리픽스 캐싱은 반복되는 프리필 작업을 피하고, FP8은 디코드 용량을 확장한다. 두 가지를 결합하면 중복 계산을 줄이고 더 많은 활성 시퀀스를 수용할 수 있다.
Cloudflare는 여러 평가에서 정확도를 비교했다. GSM8K에서 BF16은 94.24점, FP8은 94.09점을 기록했다. MMLU 결과는 각각 89.11점과 89.04점이었다.
FP8 캐시는 ARC-Challenge에서 67.49점을 기록했으며, BF16의 66.72점과 비교된다. MMLU-Pro에서는 FP8이 79.29점, BF16이 80.29점이었다. 도구 호출 유효성은 FP8이 92.6%, BF16이 92.2%로 측정됐다.
Cloudflare는 이 결과들이 구별되지 않는다고 설명한다. 보고된 평가 스위트 안에서는 그 결론이 타당할 수 있지만, 이 점수들이 보편적 동등성을 증명하는 것은 아니다. 작은 수치 변화도 드문 프롬프트, 긴 에이전트 추론 과정, 또는 선택된 평가 밖의 작업에 영향을 줄 수 있다.
여러 테스트는 비결정적 출력도 만든다. 미세한 점수 차이는 샘플링, 평가 잡음, 또는 양자화의 결과일 수 있다. 이 원인들을 구분하려면 반복 시험과 신뢰구간이 필요하다.
회사의 내부 mcxams 벤치마크는 두 구성 모두 63개 테스트 중 61개를 통과하며 동일한 결과를 냈다. 내부 평가는 프로덕션 요구를 잘 반영할 수 있지만, 외부에서는 그 범위를 독립적으로 검토할 수 없다.
따라서 Kimi KV 캐시 양자화는 고무적인 품질 근거를 갖춘 운영상 결과로 평가해야 한다. 모든 모델이 FP8 캐시 값을 안전하게 사용할 수 있다는 일반적 결론은 아니다. 어텐션 분포와 수치적 민감도는 아키텍처마다 다르다.
Cloudflare의 실질적 성과는 형식 변경이 효과를 내는 지점을 찾아낸 데 있다. 프리필은 여전히 연산 병목이므로 회사는 캐시를 BF16으로 유지한다. 디코드는 메모리 병목이 되기 때문에 더 높은 동시성에서 더 작은 FP8 표현이 유용해진다.
이 선택은 핵심 논지를 뒷받침한다. 더 나은 추론이 항상 하나의 요청을 더 빠르게 실행하는 것을 뜻하지는 않는다. 규모가 커질수록 하드웨어가 메모리 한계에 도달하기 전에 더 많은 유용한 작업을 완료하는 일이 더 중요해진다.
진짜 경쟁은 유용한 토큰당 메모리다
최전선 모델 호스팅은 이제 헤드라인을 장식하는 파라미터 수만이 아니라 메모리 효율성에 점점 더 좌우된다.
Kimi K2.6은 대규모 저장 가중치와 긴 컨텍스트, 에이전트 기능을 결합한 모델 계열에 속한다. Cloudflare의 현재 모델 문서에는 262,144토큰 컨텍스트 윈도우, 비전 입력, 도구 호출, 구조화된 출력이 명시돼 있다.
이러한 기능은 서로 겹치는 메모리 수요를 만든다. 생성 중에는 모델 가중치에 계속 접근할 수 있어야 한다. 각 활성 대화도 점점 커지는 KV 캐시를 구축하며, 배치 처리를 위해 서버는 많은 시퀀스를 동시에 추적해야 한다.
모델은 GPU 메모리에 들어가더라도 경제적으로 서빙하기 어려울 수 있다. 가중치가 캐시 페이지를 위한 공간을 거의 남기지 않으면, 각 배포 환경이 지원할 수 있는 활성 사용자 수는 줄어든다. 유휴 상태이거나 충분히 채워지지 않은 배치는 고가의 가속기 용량을 낭비한다.
이것이 Cloudflare의 더 작은 표현이 바꾸기 위해 설계된 경쟁 구도다. 관련 지표는 허용 가능한 지연 시간과 품질 한계 안에서 메모리 단위당 생성되는 유용한 토큰이 된다. 요청 하나에서의 순수 속도는 이 시스템의 일부만 보여준다.
이 변화는 표준 추론 스택에 주로 의존하는 제공업체에도 압박을 가한다. 두 서비스가 유사한 하드웨어와 모델 가중치를 사용한다면, 캐시 관리를 더 잘하는 제공업체가 더 많은 동시 작업을 수용할 수 있다. 고정 인프라 비용도 더 많은 생성 토큰에 분산할 수 있다.
다만 소프트웨어 개선이 하드웨어 차이를 없애지는 않는다. H200 GPU는 상당한 고대역폭 메모리를 제공하는 반면, 더 새로운 Blackwell 시스템은 서로 다른 저정밀 기능을 추가한다. 한 가속기 구성의 결과가 다른 구성으로 자동 이전되지는 않는다.
트래픽 형태도 그만큼 중요하다. 코딩 에이전트는 큰 프롬프트를 제출하고, 프리픽스를 재사용하며, 도구를 호출하고, 여러 턴에 걸쳐 이어갈 수 있다. 소비자 채팅 세션은 더 짧은 프롬프트와 예측하기 어려운 후속 상호작용을 사용할 수 있다.
에이전트형 워크로드는 시퀀스를 더 오래 메모리에 상주시킬 수 있다. 이는 캐시 용량의 가치를 높이지만 스케줄링도 더 어렵게 만든다. 유난히 긴 요청 하나가 메모리를 점유하는 동안 더 작은 여러 요청이 대기할 수 있다.
Cloudflare의 분리형 프리필 및 디코드 설계는 이러한 불균형에 대응한다. 연산 집약적인 프롬프트 입력 처리는 한 풀에서 실행된다. 메모리에 민감한 생성은 다른 풀에서 실행돼 각 풀이 독립적으로 확장되고 서로 다른 수치 형식을 사용할 수 있다.
이 설계는 조정 비용도 초래한다. 캐시 상태는 단계 경계를 넘어 이동하거나 계속 접근 가능해야 한다. 라우팅 결정은 사용 가능한 메모리, 기존 프리픽스, 대기열 깊이, 각 응답의 예상 길이를 고려해야 한다.
SGLang project는 Cloudflare가 실험 및 프로덕션 트래픽에 사용하는 서빙 프레임워크를 제공한다. Cloudflare는 이 프로젝트와 협력해 패치와 기능을 업스트림한다고 말한다. 이에 따라 일부 개선 사항은 한 제공업체를 넘어 활용할 수 있게 된다.
개방형 인프라는 대형 플랫폼과 독립 운영업체 사이의 소프트웨어 격차를 줄일 수 있다. 하지만 배포 경험은 여전히 중요하다. 공개된 커널이나 스케줄러 기능만으로 Cloudflare의 트래픽 규모, 텔레메트리 또는 용량 계획 역량이 자동으로 제공되지는 않는다.
이 차이는 경쟁 압력이 간접적이라는 뜻이다. Cloudflare는 Kimi나 GLM이 독점 모델이라고 주장하지 않는다. 대신 자사의 인프라가 오픈 웨이트 프런티어 모델을 공유형 서버리스 접근 방식에 충분할 만큼 효율적으로 운영할 수 있다고 주장한다.
모델 개발업체도 이 구조의 혜택을 본다. Moonshot AI와 Z.ai는 멀티 GPU 클러스터를 프로비저닝하고 싶지 않은 사용자에게 도달할 수 있다. 더 폭넓은 호스팅 지원은 채택을 늘리고 실제 워크로드에 대한 더 많은 피드백을 만들 수 있다.
그 대가로 제공업체는 더 어려운 책임을 맡는다. 수치 형식을 변환하면서 모델의 동작을 보존해야 한다. 또한 한 테넌트의 캐시 상태가 다른 테넌트의 출력에 영향을 주지 않도록 막아야 한다.
따라서 가장 뛰어난 운영업체는 메모리 용량, 출력 품질, 격리라는 세 변수를 함께 최적화할 것이다. 두 가지만 개선하면 서비스가 불안정해진다. 격리 없는 고밀도화는 보안 우려를 높이고, 품질 테스트 없는 압축은 조용한 성능 저하를 초래할 위험이 있다.
구매자에게 벤치마크 선도성은 여전히 중요하지만 충분하지는 않다. 인상적인 모델도 서빙 계층이 예측 가능한 지연 시간과 올바른 도구 호출을 제공할 때만 유용하다. 긴 대기열은 더 강력한 모델의 실질적 가치를 지워버릴 수 있다.
개발자는 모델 품질과 제공업체 품질도 구분해야 한다. 동일한 Kimi 또는 GLM 체크포인트라도 양자화, 샘플링 기본값, 캐시 정책, 서빙 소프트웨어에 따라 호스트별로 다르게 동작할 수 있다.
프로덕션 평가는 개별 답변이 아니라 전체 작업을 측정해야 한다. 유용한 신호에는 도구 호출의 유효성, 타임아웃 비율, 장기 세션 일관성, 현실적인 동시성 환경에서의 지연 시간이 포함된다. 이러한 지표는 메모리 최적화가 실제로 애플리케이션을 개선하는지 보여준다.
GLM 가중치 압축이 단계 간 트레이드오프를 바꾼다
GLM 가중치 압축은 더 작은 가중치가 메모리 트래픽을 줄이므로 디코드를 가속하지만, 연산 집약적인 프리필 단계를 늦춘다.
Cloudflare는 GLM 5.2 가중치를 FP8에서 INT4로 변환했다. 디코드 동안 시스템은 고대역폭 GPU 메모리에서 모델 가중치를 반복적으로 스트리밍한다. 메모리 대역폭이 병목일 때 더 적은 바이트를 이동하면 각 토큰을 더 빨리 생성할 수 있다.
낮은 동시성에서의 결과가 가장 뚜렷했다. 요청 1건에서 FP8은 초당 60개 토큰을 생성한 반면, INT4는 92개에 도달했다. 이는 보고된 기준으로 55%의 향상이다.
동시 요청 8건에서는 처리량이 초당 425개 토큰에서 513개로 증가했다. 향상 폭은 21%였다. 요청 16건에서는 INT4가 초당 825개 토큰을 생성했으며, FP8은 683개였다.
더 높은 부하에서도 개선은 유지됐다. INT4는 요청 32건에서 초당 1,267개 토큰에 도달했으며, FP8은 994개였다. 요청 64건에서는 각각 1,933개와 1,672개였다.
GLM 가중치 압축은 프리필에서 같은 이점을 만들지 않는다. INT4 가중치는 행렬 곱셈 전에 확장되어야 한다. Cloudflare는 INT4의 프리필 처리량을 초당 약 8,660개 토큰으로 측정했으며, FP8은 10,160개였다.
따라서 어디서나 INT4를 사용하면 프롬프트 처리 처리량을 희생하게 된다. 대신 Cloudflare는 프리필에는 FP8을 유지하고 디코드에는 INT4를 할당한다. 이 분리는 각 단계에 가장 적합한 것으로 측정된 형식을 보존한다.
이 결과는 Cloudflare의 이전 무손실 가중치 압축 작업과도 맥을 같이한다. 이 프로젝트는 배치 크기와 행렬 형태에 따라 압축 해제와 연산 사이의 균형이 달라지므로 여러 실행 경로를 탐색했다.
현재 GLM 접근 방식은 이전의 무손실 방식이 아니라 손실 양자화를 사용한다. FP8 가중치를 INT4로 변환하면 더 많은 값을 더 적은 표현 가능 상태에 매핑하게 된다. 원래 가중치를 정확히 복원할 수 없으므로 정확도 테스트가 필수적이다.
Cloudflare는 평가한 벤치마크 전반에서 차이가 0.8포인트 미만이었다고 보고했다. MMLU 평균은 FP8이 86.60, INT4가 86.54였다. MMLU-Pro의 정확한 점수는 80.80과 80.47이었다.
ARC-Challenge 정확도에서 FP8은 64.93%, INT4는 64.85%를 기록했다. 두 형식 모두 Cloudflare의 내부 mcxams 벤치마크에서 63개 사례 중 62개를 통과했다.
GSM8K는 다소 더 큰 차이를 보였다. FP8은 정확 일치 기준 94.39%를 달성했고, INT4는 93.56%에 도달했다. 유연한 채점에서는 94.24%와 93.48%를 기록했다.
Cloudflare는 압축된 모델의 품질이 구별할 수 없는 수준이라고 말한다. 공개된 수치는 평균 차이가 작다는 점을 뒷받침하지만, 몇 가지 질문은 남긴다. 회사는 모든 에이전트형 또는 다국어 동작에 대한 결과를 공개하지 않았다.
GLM은 코딩, 도구 사용, 다국어 작업에 흔히 사용된다. 일반 학술 벤치마크는 이러한 환경의 모든 실패 모드를 포착하지 못한다. 잘못된 함수 인자는 작은 평균 정확도 변화보다 더 중요할 수 있다.
드문 수치 오류는 특히 감지하기 어렵다. 벤치마크는 안정적인 집계 품질을 보일 수 있지만, 압축된 모델은 비정상적인 프롬프트에서 동작이 바뀔 수 있다. 긴 추론 궤적은 초기의 작은 차이를 증폭할 수 있다.
그렇다고 INT4가 부적합하다는 뜻은 아니다. 이는 배포 결정에 워크로드별 테스트와 지속적인 모니터링이 필요하다는 의미다. 제공업체는 참조 체크포인트뿐 아니라 사용자가 실제로 받는 정확한 모델 구성을 비교해야 한다.
같은 주의는 속도 주장에도 적용된다. 초당 토큰 수는 입력 길이, 출력 길이, 배칭, 하드웨어, 커널, 스케줄링에 따라 달라진다. Cloudflare의 측정치는 보편적인 GLM 성능 수준이 아니라 테스트한 시스템을 설명한다.
그럼에도 단계 분리는 유용한 아키텍처적 교훈을 제공한다. 양자화는 하나의 정적인 내보내기 결정으로 취급해서는 안 된다. 제공업체는 여러 표현 방식을 유지하고 각 단계에 맞는 형식으로 연산을 라우팅할 수 있다.
이 유연성에는 비용이 따른다. 여러 가중치 형식은 스토리지를 소비하고 배포를 복잡하게 만든다. 엔지니어는 호환성을 검증하고, 올바른 커널을 선택하며, GPU 풀 전반에서 구성 드리프트를 방지해야 한다.
운영상의 규율이 이 복잡성의 대가를 결정한다. 요청이 잘못된 풀에 도달하거나 모델 리비전이 수치적 동작을 바꾸면 이론적인 처리량 향상은 별 의미가 없다. 자동화와 관측 가능성은 최적화 자체의 일부가 된다.
Cloudflare가 보고한 결과는 제공업체가 왜 이 복잡성을 감수하는지 보여준다. 40% 더 작은 체크포인트는 활성 시퀀스를 위한 상당한 메모리를 남긴다. 더 빠른 디코드는 사용자가 토큰이 도착하는 것을 보는 구간에서 지연 시간을 개선한다.
이 트레이드오프는 추상적이 아니라 구체적이다. GLM 가중치 압축은 수치적 위험과 프리필 오버헤드를 추가하는 대가로 디코드 용량과 속도를 확보한다. Cloudflare는 이점을 얻는 단계에만 해당 형식을 적용해 그 거래를 관리한다.
공유 KV 캐시 안전성이 프로덕션 이슈가 된다
GPU 밀도가 높아질수록 모든 캐시 페이지의 가치가 커지는 한편, 잘못된 소유권 추적은 더 위험해진다.
페이징 어텐션은 요청마다 하나의 연속된 할당을 요구하는 대신 KV 캐시 스토리지를 재사용 가능한 블록으로 나눈다. 연속 배칭은 GPU가 바쁜 상태를 유지하는 동안 시퀀스를 추가하고 제거한다. 이 두 방식은 함께 낭비되는 메모리를 줄인다.
하지만 동시에 까다로운 관리 문제를 만든다. 물리적 캐시 페이지는 지속적으로 할당, 읽기, 해제, 재할당된다. 서빙 시스템은 모든 논리 시퀀스와 해당 물리 페이지 사이의 올바른 매핑을 보존해야 한다.
오래된 매핑은 요청이 잘못된 페이지를 읽게 할 수 있다. 이는 응답을 손상시키거나, 작업을 중단시키거나, 다른 시퀀스와 연관된 상태를 노출할 수 있다. 정확한 결과는 장애와 주변 통제 장치에 따라 달라진다.
Cloudflare는 자사의 요청 규모에서는 매우 드문 실수도 운영상 중요해진다고 말한다. 이 글은 10억 분의 1 오류를 예시적 임계값으로 사용한다. 이 진술은 공개된 사고율이 아니라 방어의 필요성을 설명한다.
회사의 무결성 메커니즘은 각 물리 페이지에 변경되는 태그를 연결한다. 요청은 자신이 예상하는 태그를 기록한다. 지원되는 디코드 작업은 공유 캐시를 읽기 전에 해당 값을 검증한다.
태그가 일치하지 않으면 영향을 받은 요청은 중단된다. 이 설계는 잘못된 상태에 기반한 출력을 반환하는 대신 명시적 실패를 택한다. 이는 다른 메모리 관리 시스템에서 사용되는 세대 카운터와 유사하다.
Cloudflare는 중간 규모 프로덕션 모델에서 프리필 워커 2개와 디코드 워커 2개를 사용해 이 검사를 평가했다. 테스트는 8,192토큰 입력과 1,000토큰 출력을 사용했다. 보고된 동시성은 1건에서 8건까지였다.
처리량은 이 테스트 전반에서 0.38~0.79% 감소했다. p95 지연 시간 증가는 0.42~0.80%였다. Cloudflare는 신뢰구간 상한도 약 1% 수준에 머물렀다고 말한다.
회사는 검증을 별도의 배치 검사로 실행한다. GPU 스레드 그룹이 경쟁 상태를 만들 수 있어 해당 작업을 어텐션 커널에 융합하는 방식을 피했다. 검사가 비활성화된 배포를 위해 no-op 트래커도 제공된다.
이 결과는 무결성 검사가 비용이 적은 것처럼 보이게 한다. 그러나 평가는 모든 모델 크기, 시퀀스 형태, 동시성 수준을 다루지는 않았다. 또한 지원되는 디코드 작업에 초점을 맞췄는데, 이는 주목할 만한 한정 조건이다.
독자는 이 메커니즘을 테넌트 격리에 대한 완전한 증명으로 해석해서는 안 된다. 캐시 무결성은 더 큰 서빙 시스템 안의 한 방어 계층이다. 라우팅, 메모리 할당, 커널 정확성, 프로세스 격리는 여전히 중요하다.
이 검사는 트래커가 이해하는 페이지 세대 불일치를 감지할 수 있다. 모든 수치 오류나 소프트웨어 결함을 자동으로 식별할 수는 없다. 유효한 태그가 페이지 내용이 의미적으로 올바르다는 것을 증명하지는 않는다.
선택적 배포와 보편적 보호 사이에는 긴장도 존재한다. Cloudflare는 배포별로 무결성 검사를 활성화한다고 말한다. 회사가 밝힌 목표는 이 기능을 어디서나 켜 둘 수 있을 만큼 비용을 낮추는 것이다.
그때까지 고객은 모든 모델 경로가 같은 보호를 사용한다고 가정할 수 없다. 적용 범위에 관한 명확한 문서는 개발자가 남아 있는 위험을 평가하는 데 도움이 될 것이다. 독립적인 보안 테스트는 성능 측정만으로는 얻기 어려운 더 강한 근거를 제공할 것이다.
그럼에도 이 안전성 논리는 추론 엔지니어링의 중요한 변화를 반영한다. 이제 성능 기능은 요청 간 상태에 관한 명시적인 추론을 요구한다. 메모리 최적화는 더 이상 처리량 그래프만으로 평가할 수 없다.
압축은 이러한 필요성을 강화한다. FP8 Kimi 캐시는 더 많은 요청을 활성 상태로 유지하게 한다. INT4 GLM 가중치는 캐시 페이지를 위한 더 많은 공간을 만든다. 두 변화 모두 하나의 배포가 처리하는 공유 상태의 양을 늘린다.
따라서 이 이야기의 주된 적은 안전하지 않은 고밀도화다. 목표는 어떤 대가를 치르더라도 최대한으로 채우는 것이 아니다. 요청 경계와 수용 가능한 모델 동작을 보존하면서 활용도를 높이는 것이다.
Cloudflare의 접근 방식은 공유되는 리소스 가까이에 안전성 검사를 배치한다. 이는 캐시된 데이터가 어텐션 연산에 들어가기 전에 할당 실수를 포착할 수 있다. 조기 종료는 손상된 상태의 전파도 제한한다.
중단된 요청도 신뢰성에 영향을 준다. 검사가 빈번하게 실행되기 시작하면, 격리가 설계대로 작동하더라도 사용자는 오류나 재시도를 경험하게 된다. 운영업체는 불일치율을 추적하고, 원인을 조사하며, 재시도 폭주를 방지해야 한다.
Cloudflare는 해당 글에서 프로덕션 환경의 불일치율을 공개하지 않았습니다. 이 누락된 지표는 합성 환경의 오버헤드만큼이나, 아니 그보다 더 중요합니다. 저비용 검증은 유용하지만, 실제 탐지 결과를 보고할 때 그 운영상 가치는 더 분명해집니다.
회사는 새 밀도가 안전하다고 제시할 유인도 있습니다. 따라서 그 근거는 시스템 운영자가 제공한 기술적 공개 자료로 봐야 합니다. 유익한 정보이지만 독립 감사와 동등하지는 않습니다.
개발자에게 더 큰 교훈은 실용적입니다. 공유 추론은 인프라 복잡성을 감추지만, 없애지는 않습니다. 공급업체 평가는 지연 시간과 모델 품질뿐 아니라 격리 제어, 장애 처리, 인시던트 투명성도 함께 포함해야 합니다.
최적화가 확산되면서 주목할 점
세 가지 신호가 Cloudflare의 소형 모델 서빙이 지속 가능한 우위가 될지, 아니면 특수한 구성으로 남을지를 보여줄 것입니다.
첫 번째 신호는 FP8 캐시 배포의 확대입니다. Cloudflare는 더 많은 플릿 전반으로 FP8 KV 캐시를 확장하고 있다고 밝혔습니다. 추가 모델과 하드웨어에서의 적용 범위는 Kimi KV 캐시 양자화가 하나의 측정된 구성 이상으로 일반화되는지를 보여줄 것입니다.
유용한 근거에는 다양한 시퀀스 길이에 대한 동시성, 테일 지연 시간, 품질 데이터가 포함됩니다. 이런 차원 전반에서 안정적인 결과가 나온다면 Cloudflare의 메모리 효율성 주장은 더 설득력을 얻을 것입니다. 모델별 예외가 빈번하다면 그 주장은 약해질 것입니다.
두 번째 신호는 Blackwell GPU에서의 NVFP4 검증입니다. NVFP4는 최신 하드웨어용 Nvidia의 4비트 부동소수점 형식입니다. Cloudflare는 더 작은 가중치를 위한 또 다른 경로로 이 표현 방식을 테스트하고 있다고 밝혔습니다.
성공적인 도입은 GLM 가중치 압축을 INT4 너머로 확장하고 프리필-디코드 균형을 다시 바꿀 수 있습니다. 또한 Cloudflare가 세대가 다른 가속기 전반에 단계 인지 전략을 적용할 수 있는지도 시험하게 됩니다.
중요한 결과는 단일 최고 처리량 수치가 아닙니다. 엔드투엔드 지연 시간, 품질 평가, 프로덕션 배치 환경에서의 메모리 용량을 살펴봐야 합니다. 이런 측정치는 낮은 정밀도가 애플리케이션 수준에서 유의미한 이득을 제공하는지 보여줄 것입니다.
세 번째 신호는 보편적인 캐시 무결성 적용 범위입니다. Cloudflare는 무시할 만한 비용으로 어디에서나 검사를 활성화하는 것을 목표로 하고 있습니다. 이 목표 달성은 더 높은 밀도와 일관된 기본 안전 제어를 연결하게 됩니다.
적용 범위 공개에는 지원되는 모델, 작업, 하드웨어가 명시되어야 합니다. 특히 Cloudflare가 불일치가 얼마나 자주 발생하는지와 그 원인을 설명한다면 탐지 지표는 더욱 큰 가치를 더할 것입니다.
이러한 신호가 중요한 이유는 회사의 현재 근거가 강력하지만 범위가 제한적이기 때문입니다. 이는 선택된 모델과 배포 환경에서 의미 있는 개선을 보여줍니다. 모든 워크로드가 같은 형식의 혜택을 받는다는 점까지 입증하지는 않습니다.
개발자는 현실적인 프롬프트, 도구 체인, 동시성을 사용해 호스팅된 Kimi 및 GLM 시스템을 테스트해야 합니다. 첫 토큰까지 걸리는 시간, 생성 속도, 타임아웃 비율, 전체 작업 성공률을 추적하세요. 공급업체 측 모델 업데이트 이후의 동작도 비교해야 합니다.
팀은 자체 평가 이력도 보존해야 합니다. 검색 가능한 엔지니어링 지식 베이스는 벤치마크 결과, 인시던트, 구성 변경, 공급업체 공지를 연결할 수 있습니다. 이러한 맥락은 모델 회귀와 인프라 변경을 구분하는 데 도움이 됩니다.
Cloudflare는 프런티어 모델에 관한 논점을 단순한 제공 여부에서 한 단계 발전시켰습니다. 더 어려운 질문은 공급업체가 실제 동시성 환경에서 대형 모델을 빠르고, 경제적이며, 정확하고, 격리된 상태로 유지할 수 있는지입니다. 세 가지 도입 신호를 지켜본 뒤, 하나의 벤치마크나 처리량 차트가 아니라 전체 워크로드를 기준으로 시스템을 판단해야 합니다.
