B200(192GB) 8장 노드는 총 1.5TB의 VRAM과 NVLink를 통한 압도적인 대역폭을 제공한다.

측정에 앞서 모델 버전을 짚고 넘어가야 합니다. 2026년 8월 현재, GLM-5.3은 Zhipu AI(https://chat.z.ai/)의 자체 플랫폼과 API를 통해서만 서비스되고 있으며, Hugging Face에 오픈소스 가중치(Weights)로는 아직 공개되지 않았다.

따라서 사용 가능한 최신 오픈소스 버전이자 B200 8장의 VRAM(총 1.5TB)을 최대로 활용할 수 있는 GLM-5.2 (zai-org/GLM-5.2) 을 사용한다. (참고로 GLM-5 시리즈부터는 Hugging Face 저장소가 THUDM에서 zai-org로 변경되었다.)

Kimi의 경우 최근 공개된 Kimi-K3는 2.8T 파라미터 모델이므로 VRAM 요구량이 B200 8장의 용량을 초과한다. 따라서 동일한 인프라에서 실행 가능한 최적의 차선 버전인 moonshotai/Kimi-K2.6을 사용한다.

원본 가중치와 양자화(AWQ, GPTQ)

대형 언어 모델(LLM)은 수십억~수천억 개의 '파라미터(매개변수)'로 이루어져 있으며, 이 파라미터들이 숫자로 저장된 것이 바로 '가중치'이다.

  • 원본 가중치 (FP16 / BF16): 모델을 처음 학습시켰을 때의 상태 그대로, 1개의 파라미터를 저장하는 데 16비트(2바이트)를 사용한다. 데이터의 소수점 아래 아주 미세한 값까지 정확하게 보존하므로 모델이 낼 수 있는 최고의 추론 능력을 발휘한다.
  • 양자화 가중치 (AWQ, GPTQ, FP8 등): 16비트였던 숫자를 4비트(0.5바이트) 또는 8비트(1바이트)로 압축(반올림/근사치 변환)한 버전이다. 이미지로 비유하면 고해상도(원본) 이미지를 육안으로는 큰 차이가 없는 수준의 중간 해상도(양자화)로 압축해 용량을 줄인 것과 같다. AWQ와 GPTQ는 주로 4비트 정수(INT4)로 압축하는 기술이다.

LLM의 텍스트 생성 속도(TPOT)는 GPU의 '연산 속도'보다 'VRAM에서 GPU 코어로 데이터를 퍼 나르는 대역폭(Memory Bandwidth)'에 의해 결정되는 경우가 대부분이다.

  • 품질 (정확도와 추론력): 압축 과정에서 미세한 수치 손실이 발생하므로 양자화 모델의 지능이 원본 대비 약 1~5% 정도 미세하게 떨어질 수 있다. 복잡한 수학이나 코딩 문제에서 이 차이가 드러날 때가 있다.
  • 속도 (TPOT): 양자화 모델은 용량이 절반 이하로 줄어들었기 때문에, GPU가 VRAM에서 데이터를 읽어오는 속도가 2배 이상 빨라진다. 결과적으로 토큰이 훨씬 빠르게 출력(TPOT 감소)된다.

B200 8장 인프라는 장당 192GB로 총 1536GB(약 1.5TB)의 거대한 VRAM을 자랑한다. 하지만 GLM-5.2(744B)를 서빙할 때는 치명적인 수학적 제약이 발생한다.

  • 원본 가중치(BF16) 적용 시: 744B 파라미터 × 2바이트 = 모델 가중치 용량만 약 1.48TB입니다. 1.5TB의 VRAM에 1.48TB를 욱여넣으면, 사용자 요청의 문맥을 기억할 공간(KV Cache)이 사실상 0에 가까워진다. 이 상태에서는 질문을 조금만 길게 해도 즉시 OOM(Out Of Memory) 에러로 서버가 다운된다.
  • 양자화 가중치 적용 시: AWQ/GPTQ(4비트)를 적용하면 용량이 약 370GB 수준으로, FP8(8비트)을 적용하면 약 744GB 수준으로 줄어든다. 절반 이상의 VRAM(700GB 이상)이 KV Cache 여유 공간으로 남게 되어 수만~수십만 토큰의 긴 문맥도 넉넉하고 매우 빠르게 처리할 수 있다.
 
구분원본 (BF16 / FP16)양자화 (AWQ / GPTQ / FP8)
파라미터당 용량 16비트 (2 Byte) 4비트 (0.5 Byte) ~ 8비트 (1 Byte)
추론 능력 (지능) 100% (손실 없음) 95~99% 수준 유지
생성 속도 (TPOT) 느림 (메모리 병목 발생) 매우 빠름 (대역폭 효율 극대화)
B200 (1.5TB) 적용 가중치만 1.48TB 차지 (OOM 위험 높음) 적극 권장 (VRAM 여유 확보 및 고속 처리)

모델 다운로드 및 실행 (GLM-5.2, Kimi-K2.6)

1. 모델 다운로드 및 로컬 저장

GLM-5.2는 744B 크기의 Mixture-of-Experts(MoE) 모델이므로 다운로드 크기가 매우 크다. 안정적인 로드를 위해 Hugging Face CLI로 로컬 NVMe 스토리지에 미리 다운로드한다.

GLM-5.2-FP8

Kimi-K2.6

# Hugging Face CLI 설치
pip install -U huggingface_hub

# 모델 저장을 위한 디렉토리 생성
mkdir -p /models/ask
cd /models/ask

# GLM-5.2-FP8 다운로드
hf download zai-org/GLM-5.2-FP8 --local-dir ./GLM-5.2-FP8
#    --exclude "*f32*.safetensors" \
#    --exclude "*F32*.safetensors" \
#    --exclude "*bf16*.safetensors" \
#    --exclude "*BF16*.safetensors" \
#    --exclude "*.bin" \
#    --exclude "*.bin.index.json" \
#    --exclude "*.pt" \
#    --exclude "*.pth"

# Kimi-K2.6 다운로드
hf download moonshotai/Kimi-K2.6 --local-dir ./Kimi-K2.6-INT4
#    --exclude "*f32*.safetensors" \
#    --exclude "*F32*.safetensors" \
#    --exclude "*i32*.safetensors" \
#    --exclude "*I32*.safetensors" \
#    --exclude "*.bin" \
#    --exclude "*.bin.index.json" \
#    --exclude "*.pt" \
#    --exclude "*.pth"
 

 

Kimi-K2.6 은 16BF 일까 양자화 된 것일까??

du -sh /models/ask/Kimi-K2.6-INT4
555G   /models/ask/Kimi-K2.6-INT4
 

실제 다운로드된 가중치 파일들은 NVFP4패킹된 INT4(compressed-tensors) 같은 초고압축 포맷으로 구성된 파일들이다. 1조 개가 넘는 파라미터를 가진 Kimi-K2.6 모델이 이 초고압축 양자화를 거치면 디스크 용량이 정확히 550GB ~ 600GB 대역에 형성된다.

아래 config.json 을 보면 알 수 있다.

vi Kimi-K2.6-INT4/config.json

    "quantization_config": {
      ...
      "format": "pack-quantized",
      ...
      "quant_method": "compressed-tensors",
      "quantization_status": "compressed"
    }
 

또는 AWQ, GPTQ 같은 다른 양자화 방식일 경우 해당 이름이 적혀있다.

"quantization_config": {
  "quant_method": "fp8",
  "activation_scheme": "dynamic"
}
 

2. 모델 실행

B200 8장(총 1.5TB VRAM)의 NVLink 대역폭과 텐서 코어(Tensor Core) 가속을 끌어내기 위한 vLLM 실행 명령어와 성능 튜닝 옵션을 정리한다.

GLM-5.2는 가중치와 KV 캐시 모두 FP8로 처리하여 최고의 속도를 내고, Kimi-K2.6은 원본 가중치(BF16)를 유지하되 KV 캐시에 FP8 최적화를 적용하여 품질과 속도의 밸런스를 맞추도록 구성한다.

주요 성능 튜닝 옵션 및 상세 설명

핵심 아키텍처 및 메모리 설정:

  • --tensor-parallel-size 8: 8장의 B200을 하나의 논리적 유닛으로 묶어 텐서 병렬 처리를 수행한다. NVLink를 통해 노드 내 통신 병목을 없앤다.
  • --dtype bfloat16: 모델의 활성화(Activation) 연산 시 기본 데이터 타입을 BF16으로 설정한다. (가중치가 FP8이더라도 중간 연산의 정밀도 유지를 위해 BF16 캐스팅을 사용하는 것이 표준이다.)
  • --gpu-memory-utilization 0.90: 전체 1.5TB VRAM 중 90%(약 1.35TB)를 vLLM이 PagedAttention 알고리즘을 위해 시작 시점에 미리 할당받아 메모리 단편화를 방지한다.
  • --max-model-len 32768: 한 번의 요청에 처리할 수 있는 최대 컨텍스트 길이(입력+출력 토큰)를 제한한다. B200 8장의 VRAM 용량을 넘어서는 무한정 긴 프롬프트가 들어와 전체 서버가 OOM으로 다운되는 것을 방지하는 안전장치이다.
    • 32768 = 2^15 : 16비트에서 부호를 뺀 크기
    • 1. 단어 및 글자 수 기준 (대략적 환산)
      • 영어 기준:
        • 1 토큰 ≈ 약 0.75개 단어
        • 약 24,000 ~ 25,000개 단어 (Word)
      • 한국어 기준 (GLM / Kimi 최신 토크나이저 기준):
        • 1 토큰 ≈ 약 1.2 ~ 1.5글자 (어절/단어 기준 1단어당 1.5 ~ 2개 토큰 소모)
        • 약 15,000 ~ 20,000개 띄어쓰기 단어(어절)
        • 약 40,000 ~ 50,000 글자 (공백 포함)
    • 2. 파일 용량 기준 (kB)
      • 영어 텍스트: 1토큰당 약 4바이트 ➔ 약 128 kB ~ 130 kB
      • 한국어 텍스트: 1토큰당 약 4.5~5바이트 (한글 UTF-8은 문자가 3바이트 차지) ➔ 약 140 kB ~ 160 kB
    • 일반적인 텍스트 파일(.txt, UTF-8 인코딩) 형태로 변환했을 때의 용량이다.
    • 3. 실무 분량 체감 (어느 정도 양인가?)
      • A4 용지 기준: 폰트 10pt, 줄간격 160% 표준 문서 기준 약 50 ~ 60장 분량의 빽빽한 텍스트이다.
      • 소설/책 기준: 단편 소설 1권 전체, 혹은 일반 서적의 2~3개 장(Chapter) 분량 전체를 요약이나 생략 없이 한 번에 입력받거나 출력할 수 있는 수치이다.
    • 따라서 32,768 컨텍스트 길이는 웬만한 수십 페이지 분량의 논문 전체나 대용량 소스코드 파일 여러 개를 통째로 넘겨서 분석시키기에 충분한 용량이다.
  • --trust-remote-code: GLM과 Kimi 등 Hugging Face의 커스텀 모델 코드를 실행하기 위해 반드시 필요한 옵션이다.

속도(TTFT/TPOT) 설정 (B200 특화):

  • --quantization fp8 (GLM 전용): 디스크에서 읽어올 모델 가중치가 FP8 포맷임을 엔진에 알린다. VRAM 로드 속도와 GPU 연산 속도를 비약적으로 높인다.
  • --kv-cache-dtype fp8: (가장 중요한 성능 튜닝) 사용자의 문맥을 기억하는 공간(KV 캐시)을 BF16 대신 FP8로 압축하여 저장한다. 모델 가중치가 BF16(Kimi)이어도 KV 캐시를 FP8로 내리면 메모리 대역폭 소모가 절반으로 줄어들어 동시 처리량(Throughput)이 대폭 상승하고 TPOT가 감소한다. B200은 이를 하드웨어로 처리하여 품질 저하를 거의 발생시키지 않는다.
    • TPOT (Time Per Output Token) = 토큰 1개당 소요 시간
    • Throughput = 1 / TPOT (단일 사용자 기준)
  • --enable-chunked-prefill: 긴 프롬프트(Prefill)가 들어왔을 때 이를 한 번에 연산하지 않고 작은 청크(Chunk)로 쪼개어 생성(Decode) 연산과 번갈아 가며 처리한다. 첫 번째 토큰이 나오는 시간(TTFT)을 줄여 체감 응답 속도를 높인다.

구조 최적화 설정 (GLM-5.2 전용):

  • --speculative-config.method mtp & num_speculative_tokens 3: MTP(Multi-Token Prediction) 투기적 디코딩을 활성화한다. 한 번의 연산으로 다음 토큰을 예측하는 것에 더해, 그다음 3개의 토큰까지 동시에 예측하여 일치할 경우 한 번에 출력합니다. TPOT를 낮추는 기술이다.
  • --reasoning-parser glm45: GLM-5 계열 특유의 '생각하는 과정(Reasoning)' 텍스트 블록을 API가 정상적인 형태로 분리 파싱할 수 있게 해준다.
cd /models/ask

# GLM-5.2 (FP8 양자화 버전) 실행 명령어
python -m vllm.entrypoints.openai.api_server \
    --model /models/ask/GLM-5.2-FP8 \
    --served-model-name glm-5.2-fp8 \
    --tensor-parallel-size 8 \
    --dtype bfloat16 \
    --quantization fp8 \
    --kv-cache-dtype fp8 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 32768 \
    --enable-chunked-prefill \
    --speculative-config.method mtp \
    --speculative-config.num_speculative_tokens 3 \
    --reasoning-parser glm45 \
    --trust-remote-code \
    --port 8000


# Kimi-K2.6 (INT4 양자화 버전) 실행 명령어
python -m vllm.entrypoints.openai.api_server \
    --model /models/ask/Kimi-K2.6-INT4 \
    --served-model-name kimi-k2.6-int4 \
    --tensor-parallel-size 8 \
    --dtype bfloat16 \
    --quantization compressed-tensors \
    --kv-cache-dtype fp8 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 32768 \
    --enable-chunked-prefill \
    --trust-remote-code \
    --port 8000
 
 

모델 실행 시에 triton_kernels.matmu_orgs 가 없다고 에러가 난다면???

ERROR [config.py:29] Failed to import Triton kernels. Please make sure your triton version is compatible. Error: No module named 'triton_kernels.matmul_ogs'
 

vLLM 서버가 켜지고 작동 자체는 할 수 있다. (Triton 커널 로드에 실패하면 PyTorch의 기본 연산으로 대체(Fallback)하여 실행되도록 설계되어 있기 때문이다.)

에러 메시지의 Triton은 OpenAI에서 개발한 파이썬 기반의 GPU 커널 컴파일러이다. GLM 모델과 vLLM은 FP8 양자화나 MoE 모델의 행렬 곱 연산(matmul)을 극단적으로 가속하기 위해 이 Triton으로 작성된 커스텀 코드(triton_kernels.matmul_ogs)를 실행하려 시도한다. 하지만 현재 의 Triton 버전이 너무 낮거나 호환되지 않아 컴파일/임포트에 실패한 것이다.

vLLM 0.26.0 버전부터 대규모 MoE 모델 및 FP8 연산을 극도로 가속하기 위해 OpenAI의 공식 triton_kernels (특히 matmul_ogs 모듈)를 필수로 요구한다. 기본 파이썬 패키지 관리자(pip install triton)로는 이 커스텀 서브 패키지가 함께 설치되지 않기 때문에 수동으로 Github에서 직접 끌어와 설치해 주어야 한다.

vLLM 0.26.0 환경과 B200(Blackwell) 아키텍처의 텐서 코어 조합에 가장 최적화되고 안정적인 Triton 및 Triton Kernel 추천 버전은 3.6.0 이다.

아래의 명령으로 에러를 잡아야 한다.

# triton 버전 설치
pip install -U "triton==3.6.0"

# 특정 버전의 트리톤 커널 설치
pip install "triton_kernels @ git+https://github.com/triton-lang/triton.git@v3.6.0#subdirectory=python/triton_kernels"

# flash-attn 컴파일 (cpu 32개를 사용)
MAX_JOBS=32 pip install -U flash-attn --no-build-isolation -v

# vllm 버전 다시 확인용 설치
pip install vllm==0.26.0


# vLLM의 PyTorch 컴파일 캐시 삭제
rm -rf ~/.cache/vllm/torch_compile_cache

# Triton 커널 컴파일 캐시 삭제
rm -rf ~/.triton/cache
 
 

Step 3: TTFT 및 TPOT 측정 프로그래밍

LLM의 성능을 평가하는 핵심 지표는 다음과 같다.

  • TTFT (Time To First Token): 사용자가 요청을 보낸 시점부터 서버가 '첫 번째 단어(토큰)'를 반환하기까지 걸린 응답 대기 시간.
  • TPOT (Time Per Output Token): 첫 번째 토큰이 나온 이후, 후속 토큰들이 생성될 때 1개당 소요되는 평균 생성 시간.

이를 정확히 측정하려면 OpenAI 호환 API의 스트리밍(Streaming) 방식을 활용하여 서버로부터 쪼개져서(Chunk) 들어오는 데이터의 타임스탬프를 직접 프로그래밍하여 기록해야 한다.

mkdir -p /models/ask/scripts && cd /models/ask/scripts

# 1. 'bench-env'라는 이름으로 가상 환경 생성
python -m venv bench-env

# 2. 가상 환경 활성화 (프롬프트 앞에 '(bench-env)'가 생기면 성공)
source bench-env/bin/activate

# 3. 패키지 관리자(pip) 최신화
pip install --upgrade pip

# 4. 벤치마크 스크립트 구동에 필요한 필수 패키지 설치
# (OpenAI 호환 API 통신을 위한 라이브러리)
pip install openai requests

# 5. 스크립트 실행 (vLLM 서버가 8000번 포트로 띄워져 있어야 한다)
python requests_benchmark.py
 
 

성능 측정 및 데이터 확인용 Python 스크립트 (requests_benchmark.py):

import time
import json
import requests

# vLLM 서버 엔드포인트 주소
API_URL = "http://localhost:8000/v1/chat/completions"

MODEL_NAME = "glm-5.2-fp8" 
PROMPT = "B200 GPU 8장을 활용한 대규모 MoE 모델 병렬 처리 구조에 대해 자세히 설명해줘."

print(f"[{MODEL_NAME}] 모델 성능 측정 시작...")

headers = {"Content-Type": "application/json"}
payload = {
    "model": MODEL_NAME,
    "messages": [{"role": "user", "content": PROMPT}],
    "stream": True,
    "max_tokens": 1024
}

start_time = time.time()
first_token_time = None
output_tokens = 0
full_content = ""

try:
    response = requests.post(API_URL, headers=headers, json=payload, stream=True)
    response.raise_for_status()

    for line in response.iter_lines():
        if line:
            decoded_line = line.decode('utf-8')
            
            if decoded_line.startswith("data: "):
                json_str = decoded_line[6:] # "data: " 제거
                
                if json_str.strip() == "[DONE]":
                    break
                    
                try:
                    chunk = json.loads(json_str)
                    choices = chunk.get("choices", [])
                    
                    if not choices:
                        continue
                        
                    delta = choices[0].get("delta", {})
                    
                    # --- 핵심 수정 부분 ---
                    # 서버가 보내는 "content", "reasoning" 필드를 모두 확인
                    content = delta.get("content") or ""
                    # GLM-5.2는 "reasoning"을 사용하고, 다른 모델은 "reasoning_content"를 쓸 수 있으므로 둘 다 대응
                    reasoning = delta.get("reasoning") or delta.get("reasoning_content") or ""
                    
                    text_chunk = content + reasoning
                    
                    if text_chunk:
                        # 첫 실제 텍스트가 도착한 순간(TTFT) 기록
                        if first_token_time is None:
                            first_token_time = time.time()
                            
                        full_content += text_chunk
                        output_tokens += 1
                        
                        # 진행 상황을 콘솔에 실시간으로 살짝씩 출력 (선택 사항)
                        print(text_chunk, end="", flush=True)
                        
                except json.JSONDecodeError:
                    continue

except Exception as e:
    print(f"\n\n[API 통신 에러 발생]: {e}")
    exit(1)

end_time = time.time()

if first_token_time is None:
    print("\n\n❌ [측정 실패] 데이터를 받지 못했습니다.")
    exit(1)

# --- 지표 계산 ---
ttft = first_token_time - start_time
tpot = (end_time - first_token_time) / (output_tokens - 1) if output_tokens > 1 else 0.0
total_time = end_time - start_time
tokens_per_sec = 1 / tpot if tpot > 0 else 0

# --- 결과 출력 ---
print("\n\n" + "="*50)
print(f"=== {MODEL_NAME} vLLM 성능 측정 결과 ===")
print("="*50)
print(f"총 생성 토큰 수   : {output_tokens} tokens")
print(f"전체 소요 시간    : {total_time:.4f} 초")
print(f"TTFT (첫 토큰)    : {ttft:.4f} 초 (Prefill 지연)")
print(f"TPOT (토큰당 시간): {tpot:.4f} 초/토큰 (Decode 속도)")
print(f"Throughput        : {tokens_per_sec:.2f} tokens/sec")
print("="*50)
 
 

실행 결과

python requests_benchmark.py

==================================================
=== glm-5.2-fp8 vLLM 성능 측정 결과 ===
==================================================
총 생성 토큰 수    : 366 tokens
전체 소요 시간     : 4.3270 초
TTFT (첫 토큰)    : 0.0714 초 (Prefill 지연)
TPOT (토큰당 시간) : 0.0117 초/토큰 (Decode 속도)
Throughput       : 85.77 tokens/sec
==================================================
 
 

성능 측정 및 데이터 확인용 Python 스크립트 (openai_benchmark.py):

vLLM을 실행할 때 --reasoning-parser glm45 옵션을 넣었다. 최신 모델들은 딥시크(DeepSeek-R1)나 o1처럼 최종 답변을 내놓기 전에 혼자 '생각하는 과정(Reasoning)'을 거친다. 이 생각하는 과정에서 나오는 텍스트는 기존의 일반적인 content 필드가 아니라, reasoning 이라는 필드로 서버에서 전송된다. 일반적으로는 content 필드만 바라보고 있었기 때문에 데이터를 받을 수 없다.

이를 해결하려면 reasoningcontent를 모두 수집하도록 작성해야 한다.

import time
from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1"
)

MODEL_NAME = "glm-5.2-fp8"      # GLM 측정 시
# MODEL_NAME = "kimi-k2.6-int4"   # Kimi 측정 시
PROMPT = "B200 GPU 8장을 활용한 대규모 MoE 모델 병렬 처리 구조에 대해 자세히 설명해줘."

print(f"[{MODEL_NAME}] 모델 성능 측정 시작...")

start_time = time.time()
first_token_time = None
output_tokens = 0
full_content = ""

try:
    response = client.chat.completions.create(
        model=MODEL_NAME,
        messages=[{"role": "user", "content": PROMPT}],
        stream=True,
        max_tokens=1024
    )

    for chunk in response:
        if not chunk.choices:
            continue
            
        delta = chunk.choices[0].delta
        
        # 1. 일반적인 텍스트가 담기는 필드
        content = getattr(delta, "content", "") or ""
        
        # 2. 생각하는 과정(Reasoning)이 담기는 필드
        reasoning = getattr(delta, "reasoning", "") or ""
        reasoning_content = getattr(delta, "reasoning_content", "") or ""
        
        # 두 데이터를 합쳐서 실제 글자가 하나라도 들어왔는지 판별
        text_chunk = content + reasoning + reasoning_content
        
        if text_chunk:
            if first_token_time is None:
                first_token_time = time.time()
                
            full_content += text_chunk
            output_tokens += 1

            # --- 화면에 순차적으로 실시간 출력 ---
            print(text_chunk, end="", flush=True)

except Exception as e:
    print(f"\n[API 통신 에러 발생]: {e}")
    exit(1)

end_time = time.time()

if first_token_time is None:
    print("\n❌ [측정 실패] 데이터를 받지 못했습니다.")
    exit(1)

# --- 지표 계산 ---
ttft = first_token_time - start_time
tpot = (end_time - first_token_time) / (output_tokens - 1) if output_tokens > 1 else 0.0
total_time = end_time - start_time
tokens_per_sec = 1 / tpot if tpot > 0 else 0

# --- 결과 출력 ---
print("\n" + "="*50)
print(f"=== {MODEL_NAME} 벤치마크 결과 ===")
print("="*50)
print(f"총 생성 토큰 수   : {output_tokens} tokens")
print(f"전체 소요 시간    : {total_time:.4f} 초")
print(f"TTFT (첫 토큰)    : {ttft:.4f} 초")
print(f"TPOT (토큰당 시간): {tpot:.4f} 초/토큰")
print(f"Throughput        : {tokens_per_sec:.2f} tokens/sec")
print("="*50)
print(f"[생성된 텍스트 샘플]\n{full_content[:300]}...\n")
 
 

실행 결과

python openai_benchmark.py

==================================================
=== glm-5.2-fp8 벤치마크 결과 ===
==================================================
총 생성 토큰 수   : 389 tokens
전체 소요 시간    : 4.8275 초
TTFT (첫 토큰)    : 0.3401 초
TPOT (토큰당 시간): 0.0116 초/토큰
Throughput        : 86.46 tokens/sec
==================================================
반응형
Posted by seungkyua@gmail.com
,