Chunk 17.0
This chunk covers the pivot from GLM-5 to deploying **nvidia/Kimi-K2.5-NVFP4**, a 1T-parameter MoE model (DeepSeek V3 architecture) quantized by NVIDIA. The old GLM-5 GGUF weights (402GB) were removed, the 540GB model was downloaded across 119 safetensor shards, and vLLM was configured to serve it. A critical blocker emerged: the NVFP4 checkpoint ships with FP8 KV cache configuration, but **no MLA attention backend on SM120 (RTX PRO 6000) supports FP8 KV cache** — TRITON_MLA, the only viable backend, hardcodes `NotImplementedError` for FP8. This was resolved by removing `kv_cache_quant_algo` from `hf_quant_config.json` and `kv_cache_scheme` from `config.json`, falling back to fp16 KV cache. A systemd service (`vllm-kimi-k25.service`) was created with NCCL_PROTO=LL, tool calling, reasoning parser, and 128k context, achieving ~60 tok/s single-request throughput. The second half investigates whether previous GLM-5 optimizations apply and whether coherence issues stem from leftover patches. **All GLM-5-specific patches were verified absent** — the vLLM installation is clean stock code. The NCCL_PROTO=LL and P2P_LEVEL=SYS settings were already carried forward. FP8 KV cache was confirmed **architecturally impossible on SM120** without writing FP8 dequantization into the Triton MLA kernel — a major engineering effort. Coherence testing across four prompts (factual, multi-step, multi-turn, creative) showed **fully coherent, correct output** with proper reasoning traces, suggesting the earlier "coherence issues" were either transient or caused by the user's specific prompts rather than systemic model corruption. The fundamental PCIe allreduce bottleneck remains the primary throughput limiter, with ~65-70% of decode time spent in NCCL communication.
From GLM-5 to Kimi-K2.5-NVFP4: A 1T-Parameter Model Deployment Saga on Blackwell GPUs
Message Articles
- The Knowledge Consolidation: How One Message Captured an Entire Debugging Odyssey
- The Pivot Point: How a Seven-Word Message Delegated the Fate of a 744B-Parameter Model Deployment
- The Pivot from Analysis to Action: A Message of Intent in the GLM-5 Deployment Saga
- The Moment the Service Started: A Diagnostic Check That Revealed Success
- The Unexpected Success: When a Systemd Service Starts on Its Own
- The Moment of Cautious Optimism: Watching a 402GB Model Load Across 8 GPUs
- The Systemd Service That Wouldn't Start: Operational Debugging at the Edge of ML Deployment
- The Art of Clean Slates: A Deep Dive into a vLLM Service Recovery
- The Verification Step: A Study in Systematic Infrastructure Debugging
- The Art of Clean Slates: Shared Memory Hygiene in Large-Scale ML Deployment
- The Diagnostic Pivot: Uncovering a GPU Memory Race Condition in systemd Service Restarts
- The Cascading Failure Loop: Diagnosing a GPU Memory Race Condition in systemd Service Restarts
- The Edit That Broke a Cascade: How One Line Fixed a GPU Service Death Spiral
- The Smallest Fix With the Largest Impact: A Systemd ExecStartPre That Saved a 744B-Parameter Model
- The Critical Transition: Deploying a Systemd Fix After Diagnosing a Cascading GPU Memory Race Condition
- The Final Fix: Breaking a Cascading Failure Loop in vLLM Systemd Deployment
- The Quiet Pivot: A Status Update That Marks a Turning Point
- The Moment of Verification: Watching a Distributed Model Come Online
- The Moment of Relief: Watching a 402GB Model Load After Debugging Hell
- The Waiting Game: Monitoring a 402GB Model Load Across 8 GPUs
- The Moment of Arrival: Watching a 402GB Model Come Online
- The Moment of Arrival: A Server Comes Online
- The First Token: A 744B-Parameter Model Speaks
- The Moment of Truth: Verifying a 744B-Parameter Model After Days of Debugging
- The Validation Milestone: Benchmarking a 744B-Parameter LLM After a Deployment Marathon
- The Validation Milestone: Confirming 55 tok/s on a 744B-Parameter Model Across 8 Blackwell GPUs
- The Final Status Report: Debugging a GPU Memory Race Condition in vLLM Systemd Deployment
- The Four-Word Pivot: How "Enable tool calling on vllm" Transformed a Model Deployment into a Usable Service
- The Pivot Point: Enabling Tool Calling on a Custom vLLM Deployment
- The Art of Discovery: Investigating Tool Calling Support for GLM-5 in vLLM
- Verifying Tool Calling Compatibility: The Critical Bridge Between Model and Parser
- The Art of Parser Selection: How a Single Bash Command Confirmed GLM-5 Tool Calling in vLLM
- The Moment of Decision: Confirming the Tool Parser for GLM-5 on vLLM
- The Quiet Pivot: Enabling Tool Calling on a 744B-Parameter Model
- The Deceptively Simple Deploy: How a Single Bash Command Enabled Tool Calling on a 744B-Parameter Model
- The Watchful Pause: Monitoring a Tool-Enabled GLM-5 Deployment on vLLM
- The Six-Minute Wait: What a Simple Status Check Reveals About Large-Scale ML Deployment
- Validating Tool Calling on a 744B-Parameter Model: The Final Integration Test
- The Verification Checkpoint: Confirming Tool Calling on a Deployed GLM-5 Inference Server
- The Quiet Confirmation: How a Single Line of Configuration Unlocked Tool Calling on a 744B-Parameter Model
- The 200k Context Threshold: A Pivotal Moment in the GLM-5 Deployment
- The Diagnostic Pivot: Probing Context Limits in a 1T-Parameter Model Deployment
- The Calculus of Context: Reasoning About KV Cache Budget for 200k-Token Inference
- The Diagnostic Pivot: Uncovering Context Window Constraints in a 744B Parameter Model
- The KV Cache Calculation: Expanding GLM-5 Context from 8K to 200K
- Deploying the Context Expansion: A Calculated Risk in LLM Infrastructure Tuning
- The 30-Second Check: Monitoring a High-Stakes Model Deployment Through Journalctl
- The 420-Second Wait: Confirming 200k Context on a 744B-Parameter Model
- The Silence of the Compiler: Watching vLLM's AOT Compilation and CUDAGraph Capture
- The Silent Server: Monitoring CUDAGraph Compilation in a 200k-Context vLLM Deployment
- The Final Verification: Confirming a 200k Context Deployment on GLM-5
- From 8K to 200K: Expanding Context for GLM-5 on vLLM
- The Pivot: Abandoning GLM-5 GGUF for NVFP4 — A Strategic Reset in Model Deployment
- Pivoting to NVFP4: A Strategic Reset in Model Deployment
- The Pivot: Reconnaissance Before Deployment — Analyzing the Kimi-K2.5-NVFP4 Transition
- The Two-Word Instruction That Freed 402GB
- The Pivot: From GLM-5 GGUF to Kimi-K2.5-NVFP4
- The Cleanup Command: Pivoting from GLM-5 to Kimi-K2.5-NVFP4
- The Clean Slate: A Pivot Checkpoint in the Kimi-K2.5-NVFP4 Deployment
- The Art of the Clean Slate: Pivoting from GLM-5 to Kimi-K2.5-NVFP4
- The One-Line Correction That Saved Hours: "It's a 1T model, need TP8"
- The Pivot Point: Acknowledging Scale and Committing to Parallel Execution
- The Pivot: From GLM-5 to Kimi-K2.5-NVFP4
- The Silent Failure: A Case Study in Dependency Management and Operational Verification
- The Moment of Discovery: When Parallel Operations Collide
- The Debugging Pivot: Diagnosing a Missing CLI Tool in the Kimi-K2.5-NVFP4 Deployment
- The Race Condition That Nearly Derailed a 540GB Model Download
- A Status Check That Marks a Turning Point: Monitoring the Kimi-K2.5-NVFP4 Download
- Reading the Blueprint: How a Single Config Inspection Shaped the Kimi-K2.5-NVFP4 Deployment
- The Pivot Point: Inspecting Kimi-K2.5-NVFP4's Architecture Before the Storm
- The Patience of Giants: Monitoring a 540GB Model Download in an OpenCode Session
- The Ten-Minute Wait: Monitoring a 540GB Model Download in the Pivot from GLM-5 to Kimi-K2.5
- The 540GB Threshold: A Pivot Point in Deploying Kimi-K2.5-NVFP4
- The 540GB Cleanup: A Moment of Methodical Verification in ML Model Deployment
- The Launch: Deploying Kimi-K2.5-NVFP4 on Blackwell GPUs
- The Moment of Failure: Debugging the Kimi-K2.5-NVFP4 Launch on Blackwell
- The Art of Diagnostic Grep: Tracing a vLLM Launch Failure on Blackwell GPUs
- The Art of the Targeted Grep: Debugging vLLM's Model Loading Failure for Kimi-K2.5-NVFP4
- The Art of Diagnostic Narrowing: Debugging a vLLM Launch Failure on Blackwell GPUs
- The Debugging Needle: How a Single Grep Uncovered the FP8 KV Cache Blocker on Blackwell
- Diagnosing the FP8 KV Cache Wall: How an Attention Backend Incompatibility Nearly Derailed a 1T-Parameter Model Deployment
- The Silent Diagnostic: Reading Stale Logs in a Distributed ML Debugging Session
- The Stale Log Problem: A Debugging Pivot in the Kimi-K2.5-NVFP4 Deployment
- The Moment the vLLM Server Died: Debugging Process Lifecycle in Remote ML Deployment
- The Zero-Memory Check: A Systematic Pause in High-Stakes Model Deployment
- The Second Attempt: Launching Kimi-K2.5-NVFP4 with KV Cache Override
- The Moment the Workaround Failed: Diagnosing FP8 KV Cache Incompatibility on Blackwell
- The Diagnostic Turn: Uncovering the FP8 KV Cache Impasse on Blackwell SM120
- The FP8 KV Cache Wall: Diagnosing a Hardware-Software Mismatch in Blackwell MLA Attention
- The Dead End of vLLM ≥ 0.16: A Dependency Resolution Failure That Forced a Strategic Pivot
- The Pivot Point: When Upgrades Fail, Patch the Config
- The Blackwell Divide: Diagnosing FP8 KV Cache Incompatibility on SM120
- The Surgical Config Patch: Unblocking Kimi-K2.5-NVFP4 on Blackwell by Removing FP8 KV Cache
- The Config Patch That Saved the Deployment: Resolving FP8 KV Cache Incompatibility on Blackwell SM120
- The Missing Log File: A Critical Checkpoint in Deploying Kimi-K2.5-NVFP4 on Blackwell GPUs
- The Silent Failure: Diagnosing a Broken Shell Command in vLLM Deployment
- When Shell Escaping Eats Your Command: Debugging Remote Process Launch in a Multi-GPU ML Deployment
- The Quiet Pivot: How a Single Bash Command Resolved an Architecture Showdown
- The Verification That Broke the Logjam: Patching FP8 KV Cache to Launch Kimi-K2.5-NVFP4 on Blackwell
- The Turning Point: A 540GB Model Begins to Load
- The Quiet Pivot: Monitoring the Kimi-K2.5-NVFP4 Load After the FP8 KV Cache Crisis
- The Weight of Waiting: A Status Check During a 540GB Model Deployment
- The Moment of Arrival: When a 540GB Model Finally Loads — and Fails
- The Diagnostic Pivot: Uncovering a KV Cache Failure in vLLM's EngineCore
- The Diagnostic Pivot: Uncovering the KV Cache Memory Limit in vLLM's Kimi-K2.5-NVFP4 Deployment
- The 128k Context Decision: Memory Budgeting for a 1T-Parameter MoE Model on Blackwell GPUs
- The Final Launch: Deploying Kimi-K2.5-NVFP4 with Proper Configuration
- The Moment of Truth: A 540GB Model Finally Loads
- The Moment of Truth: Loading a 1T-Parameter Reasoning Model on Blackwell Workstation GPUs
- The First Breath: Validating a 1T-Parameter Reasoning Model on Blackwell GPUs
- Benchmarking a 1T-Parameter MoE Model on Blackwell GPUs: The Moment of Truth
- The Benchmark That Closes the Loop: 60 tok/s on a 1T-Parameter MoE Model
- The Pivot Point: From Manual Testing to Production Deployment
- The Quiet Pivot: Formalizing a Production Service for Kimi-K2.5-NVFP4
- The Final Deployment: Systemd Service Registration for a 1T-Parameter Model
- The Diagnostic Pivot: Understanding Why a systemd Service Won't Start
- The Dollar Sign That Almost Broke Production: Debugging a Systemd Escaping Gotcha in ML Model Deployment
- The Dollar Sign That Almost Broke a 1T-Parameter Model Deployment
- The Systemd Deployment Fix: A Single Command That Wraps a Debugging Journey
- The $free That Wasn't: A Systemd Variable Escaping Bug in a 1T-Parameter Model Deployment
- The Debugging Dance: A Single Systemd Reset in a 1T-Parameter Model Deployment
- The Stubborn 96.6 GiB: A Post-Mortem of GPU Memory Cleanup
- The Stubborn 96,619 MiB: A Diagnostic Pivot in Deploying Kimi-K2.5-NVFP4
- The Stale Resource Tracker: A Case Study in GPU Memory Management on LXC
- The Stuck GPU Memory: A Diagnostic Pivot in the Kimi-K2.5 NVFP4 Deployment
- The Last Kill: Resolving Stuck GPU Memory Through Precise PID Targeting
- The Moment of Relief: Starting a Systemd Service After GPU Memory Liberation
- The Systemd Escaping That Wasn't: A Lesson in Debugging Patience