1. Model Introduction
GLM-4.7 is a powerful language model developed by Zhipu AI, featuring advanced capabilities in reasoning, function calling, and agent workflows. GLM-4.7 brings improvements across all major domains:- Extended Context Window: Expanded context window supporting even longer documents and complex multi-turn conversations
- Enhanced Reasoning: Improved reasoning capabilities with better chain-of-thought processing
- Superior Coding: Significantly improved code generation and understanding, with better real-world application performance
- Advanced Tool Use: More robust tool calling and agent capabilities for complex workflows
- Optimized Performance: Better throughput and latency characteristics across all hardware platforms
- State-of-the-Art Reasoning: Enhanced reasoning capabilities for the most complex problem-solving tasks
- Multiple Quantizations: BF16, FP8, and NVFP4 variants for different performance/memory trade-offs
- Hardware Optimization: Tuned for NVIDIA Blackwell (B200, GB200) and AMD MI300X/MI325X/MI355X GPUs
- High Performance: Optimized for both throughput and latency scenarios
- BF16 (Full precision): zai-org/GLM-4.7
- FP8 (8-bit quantized): zai-org/GLM-4.7-FP8
- NVFP4 (4-bit, NVIDIA Blackwell): nvidia/GLM-4.7-NVFP4
2. SGLang Installation
SGLang offers multiple installation methods. You can choose the most suitable installation method based on your hardware platform and requirements. Please refer to the official SGLang installation guide for installation instructions. Docker Images by Hardware Platform:| Hardware Platform | Docker Image |
|---|---|
| NVIDIA H100 / H200 / B200 | lmsysorg/sglang:v0.5.12 |
| NVIDIA GB200 / B300 / GB300 (aarch64) | lmsysorg/sglang:v0.5.12-cu130 |
| AMD MI300X / MI325X | lmsysorg/sglang:v0.5.12-rocm720-mi30x |
| AMD MI355X | lmsysorg/sglang:v0.5.12-rocm720-mi35x |
3. Model Deployment
This section provides deployment configurations optimized for different hardware platforms and use cases.3.1 Basic Configuration
Interactive Command Generator: Use the configuration selector below to automatically generate the appropriate deployment command for your hardware platform, quantization method, deployment strategy, and thinking capabilities.3.2 Configuration Tips
Pick a weight format by hardware: NVFP4 on NVIDIA Blackwell (B200, GB200), FP8 on H100/H200/AMD, BF16 as the full-precision fallback. The recommended tensor-parallel size per platform:| Hardware | NVFP4 | FP8 | BF16 |
|---|---|---|---|
| B200 (8×, single node) | tp=2 / 4 / 8 | tp=4 / 8 | tp=8 |
| GB200 (NVL72, 4× per tray) | tp=2 / 4 | tp=4 | — |
| H200 (8×) | — | tp=8 | tp=8 |
| AMD MI300X / MI325X / MI355X | — | tp=2 / 4 / 8 | tp=4 / 8 |
- EAGLE Speculative Decoding: Supported for GLM-4.7. Add
--speculative-algorithm EAGLE --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4. The spec-v2 overlap scheduler is enabled by default; pass--disable-overlap-scheduleto disable. Enable via the interactive command generator above. - Thinking Budget: Use
--enable-custom-logit-processorflag and passGlm4MoeThinkingBudgetLogitProcessorin requests to cap the model’s thinking token count (see section 4.2.3).
4. Model Invocation
4.1 Basic Usage
For basic API usage and request examples, please refer to:4.2 Advanced Usage
4.2.1 Reasoning Parser
GLM-4.7 supports Thinking mode by default. Enable the reasoning parser during deployment to separate the thinking and the content sections:Command
Example
Output
4.2.2 Tool Calling
Parser names by model: GLM-4.5 and GLM-4.6 use
--tool-call-parser glm45. GLM-4.7 and GLM-4.7-Flash use --tool-call-parser glm47. All GLM models use --reasoning-parser glm45 regardless of generation.Command
Example
Output
- The reasoning parser shows how the model decides to use a tool
- Tool calls are clearly marked with the function name and arguments
- You can then execute the function and send the result back to continue the conversation
Example
4.2.3 Thinking Budget
Limit the number of thinking tokens usingCustomLogitProcessor. Launch with --enable-custom-logit-processor:
Example
5. Benchmark
This section uses industry-standard configurations for comparable benchmark results.5.1 Speed Benchmark
Test Environment:- Hardware: NVIDIA B200, NVIDIA GB200, AMD MI300X/MI325X/MI355X (8x)
- Model: GLM-4.7-NVFP4 on NVIDIA Blackwell; GLM-4.7-FP8 or GLM-4.7 (BF16) on AMD
- SGLang Version: 0.5.12 (NVIDIA Blackwell), 0.5.6.post1 (AMD)
- Best per-GPU throughput config on B200: TP=2 NVFP4 bf16-KV (NVFP4 weights, no EP). Numbers below come from this config.
5.1.1 Standard Test Scenarios
Four core scenarios reflect real-world usage patterns:| Scenario | Input Length | Output Length | Use Case |
|---|---|---|---|
| Chat | 1K | 1K | Most common conversational AI workload |
| Reasoning | 1K | 8K | Long-form generation, complex reasoning tasks |
| Summarization | 8K | 1K | Document summarization, RAG retrieval |
| Throughput | 4K | 1K | Mixed RAG / agent / multi-turn conversation (used for the inline B200 / GB200 results below) |
5.1.2 Concurrency Levels
Test each scenario at three concurrency levels to capture the throughput vs. latency tradeoff (Pareto frontier):- Low Concurrency:
--max-concurrency 1(Latency-optimized) - Medium Concurrency:
--max-concurrency 16(Balanced) - High Concurrency:
--max-concurrency 100(Throughput-optimized) — the Throughput (4K/1K) scenario uses--max-concurrency 128to match the inline B200/GB200 results below.
5.1.3 Number of Prompts
For each concurrency level, configurenum_prompts to simulate realistic user loads:
- Quick Test:
num_prompts = concurrency × 1(minimal test) - Recommended:
num_prompts = concurrency × 5(standard benchmark) - Stable Measurements:
num_prompts = concurrency × 10(production-grade)
5.1.4 Benchmark Commands
Scenario 1: Chat (1K/1K) - Most Important- Model Deployment
Command
- Low Concurrency (Latency-Optimized)
Command
- Medium Concurrency (Balanced)
Command
- High Concurrency (Throughput-Optimized)
Command
- Low Concurrency
Command
- Medium Concurrency
Command
- High Concurrency
Command
- Low Concurrency
Command
- Medium Concurrency
Command
- High Concurrency
Command
nvidia/GLM-4.7-NVFP4 weights and report the full bench_serving output verbatim. The same commands apply to other NVIDIA hardware after substituting the deployment line from §3.1.
Note: These runs use EOS-enabled generation (no --disable-ignore-eos), so generated-token counts reflect natural model behavior rather than a strict fixed-OSL pin. Compare against other EOS-enabled runs at the same workload, not against fixed-output-length benchmarks.
5.1.4.1 NVIDIA B200
Model Deployment (NVIDIA B200, TP=2 NVFP4 — max tok/s/gpu config):Command
- Low Concurrency (Latency-Optimized)
Command
Output
- Medium Concurrency (Balanced)
Command
Output
- High Concurrency (Throughput-Optimized)
Command
Output
5.1.4.2 NVIDIA GB200
Model Deployment (NVIDIA GB200, TP=2 NVFP4 — max tok/s/gpu config):Command
- Low Concurrency (Latency-Optimized)
Command
Output
- Medium Concurrency (Balanced)
Command
Output
- High Concurrency (Throughput-Optimized)
Command
Output
5.1.5 Understanding the Results
Key Metrics:- Request Throughput (req/s): Number of requests processed per second
- Output Token Throughput (tok/s): Total tokens generated per second
- Mean TTFT (ms): Time to First Token - measures responsiveness
- Mean TPOT (ms): Time Per Output Token - measures generation speed
- Mean ITL (ms): Inter-Token Latency - measures streaming consistency
- 1K/1K (Chat): Represents the most common conversational AI workload. This is the highest priority scenario for most deployments.
- 1K/8K (Reasoning): Tests long-form generation capabilities crucial for complex reasoning, code generation, and detailed explanations.
- 8K/1K (Summarization): Evaluates performance with large context inputs, essential for RAG systems, document Q&A, and summarization tasks.
- 4K/1K (Throughput): Realistic mixed workload typical of production deployments (RAG context + medium response). Long enough input that prefill matters, long enough output that decode steady-state dominates. Used for the inline B200 / GB200 results above.
- Variable Concurrency: Captures the Pareto frontier - the optimal tradeoff between throughput and latency at different load levels. Low concurrency shows best-case latency, high concurrency shows maximum throughput.
- Compare your results against baseline numbers for your hardware
- Higher throughput at same latency = better performance
- Lower TTFT = more responsive user experience
- Lower TPOT = faster generation speed
5.2 Accuracy Benchmark
Document model accuracy on standard benchmarks:5.2.1 GSM8K Benchmark
- Benchmark Command
Command
- Test Result (NVIDIA B200, TP=2 NVFP4)
Output
- Test Result (NVIDIA GB200, TP=2 NVFP4)
Output
