K3 部署推理引擎指南 ✍ vLLM🕐 2026-07-28📦 10.2 KB 🟢 已读 𝕏 文章列表 vLLM 宣布对 Kimi K3 模型提供首日支持。K3 是拥有 2.8 万亿参数的 MoE 模型，支持 100 万上下文窗口。vLLM 通过 DSpark 推测解码将吞吐量提升至 370 tok/s，并支持架构创新的混合缓存管理、预填充/解码分离及智能体服务，确保生产环境下的高性能与低延迟。 vLLMKimi K3MoE推理引擎性能优化DSpark部署指南大模型基础设施 # The Inference Engine Guide for K3 Deployment **作者**: vLLM **日期**: 2026-07-27T17:07:20.000Z **来源**: [https://x.com/vllm_project/status/2081788542079123939](https://x.com/vllm_project/status/2081788542079123939) ---  We're thrilled to announce Efficient Day-0 vLLM Support for Kimi K3, one of the most powerful open-weight models ever released. Last week, we previewed the production-scale integration work; today, Moonshot AI's weights are public and the support is live. Kimi K3 is a 2.8-trillion-parameter Mixture-of-Experts model (16 of 896 experts active per token) built on Kimi Delta Attention (KDA) and Attention Residuals (AttnRes), with a 1M-token context window and native vision. The challenge of K3 is making KDA, MXFP4 MoE execution, KV cache management, prefill/decode disaggregation, speculative decoding, and long-context deployment recipes work together in a serving engine you can actually run. This post is the practical guide. TL;DR Kimi K3 is a 2.8-trillion-parameter multimodal MoE (16 of 896 experts active per token) with a context window of up to 1M tokens, built on Kimi Delta Attention, Attention Residuals, the Stable LatentMoE design, and native MXFP4 (4-bit) weights. 🔷Up to 370 tok/s per user: vLLM serves Kimi K3 at 118 tok/s without speculative decoding and 370 tok/s (a 3.14× improvement) with DSpark, on NVIDIA GB300 NVL72. 🔷Broad feature support at launch: speculative decoding, prefill/decode disaggregation, agentic KV caching with Mooncake, tool calling, reasoning output, and structured output, on NVIDIA (B200, B300, GB200, GB300) and AMD ROCm. 🔷vLLM supports DSpark, a state-of-the-art speculative decoding algorithm for Kimi K3, trained with vLLM and open-sourced by Inferact. 🔷Serving K3's hybrid recurrent-plus-attention design required new vLLM core infrastructure: prefix caching over recurrent (KDA) state — a change that now benefits every hybrid linear model. Kimi K3's architecture, and how vLLM serves it K3 departs from a standard transformer in four ways, and each one changes what a serving engine has to do.  Kimi K3 architecture innovations, from original release blog post https://www.kimi.com/blog/kimi-k3 Kimi Delta Attention: a hybrid recurrent + full-attention stack. Most of K3's layers are KDA, a linear-attention mechanism that keeps a fixed-size recurrent state instead of a growing KV cache, interleaved with periodic full-attention layers that preserve exact global recall. That is what makes a 1M-token context affordable. A single hybrid KV-cache manager holds both kinds of memory under one scheduler: paged KV blocks for full-attention layers, and compact recurrent-state blocks for KDA layers. The hardest part is prefix caching over recurrent state: a KDA layer has no per-token KV to hash, so vLLM separates the physical state-block size from the prefix-match granularity and reuses state snapshots at block boundaries, so long shared prompts still hit cache.  Kimi K3 interleaves Kimi Delta Attention (linear) layers with periodic full-attention layers; vLLM's hybrid cache manages recurrent state and paged KV together. Attention Residuals: AttnRes mixes the outputs of previous layers with softmax attention, letting each token's representation adapt to its content across the depth of the network. vLLM implements a fused CUDA kernel that computes logits, softmax across previous layers, and aggregates in a single launch, folding the residual add and output RMSNorm into the same kernel. Stable LatentMoE: Each token is routed to 16 of 896 experts. Experts are sharded with expert parallelism; vLLM offers two MoE backends tuned for different topologies: TRT-LLM-Gen for tensor-parallel (TP>1) and MegaMoE for disaggregated/expert-parallel (DEP), plus optional Expert-Parallel Load Balancing (EPLB). MXFP4 weights and native vision. K3's weights are quantization-aware trained in 4-bit MXFP4, so low precision is native rather than a post-hoc conversion. Serving semantics: K3 ships without a Jinja chat template; its tokenizer renders messages through a Python program instead. vLLM implements the same render program in both the Python and Rust frontends, so tool calling, reasoning output, and structured output behave identically across both. Built for production Serving a 2.8T hybrid MoE well means being fast for one user, efficient for thousands, and sticky for agents. vLLM ships Kimi K3 ready on all three. Ultra-low latency: To reach ultra-low latency on a 2.8T model without accuracy loss, speculative decoding is the natural choice. This which is why vLLM supports DSpark from day 0, and why we trained and released our own DSpark speculator for K3. DSpark uses a block-diffusion backbone to generate multiple speculative tokens in one parallel pass, so drafting cost stays flat as the block deepens. We made the draft MLA-native, mirroring K3's own attention, so draft and target share a similar KV layout.  Kimi K3 DSpark positional acceptance rates across various datasets Measured with the same build, prompt, and method: 118 → 370 tok/s per user, a 3.14× improvement on 16 NVIDIA GB300 NVL72 GPUs (111 → 331 tok/s on TP8). The gain tracks how predictable the output is — for coding and other low-entropy tasks, DSpark accepts around 4.73 tokens per step; for high-entropy tasks such as creative writing, around 2.61 — so the speedup is a measurement at standard settings, not a universal constant. Both the draft model and the inference support are open source as of this release. Large-scale serving (prefill/decode disaggregation): for high-throughput fleets, vLLM serves K3 with expert and data parallelism across nodes, and with prefill/decode (PD) disaggregation, which runs prefill-heavy and decode-heavy work on separate replicas so each is sized for its own bottleneck. The validated topology routes TEP8 prefill → DEP16 decode, with KV/state moved between stages over NIXL.  Prefill/decode disaggregation flow Agentic serving: Agentic workloads (long multi-turn sessions, tool loops, large shared system prompts) require detailed KV reuse. vLLM's Mooncake integration lets K3 offload and reuse KV across turns and requests, so a repeated codebase, document, or agent scratchpad doesn't pay full prefill every turn. Combined with K3's prefix caching over recurrent state, this keeps long agent sessions responsive as context accumulates. Performance and benchmarks Everything below ran through a served OpenAI-compatible endpoint with the release parsers. 🔷GSM8K: 0.976 🔷GPQA-Diamond: 0.939 🔷OCRBench: 0.889 🔷MMMU Pro Vision: 0.818 On reasoning and knowledge, vLLM tracks Kimi K3's reported quality closely, which means the kernels, parsers, and caches preserve model quality end to end.  Kimi K3 decode throughput on batch size 1, measured on 2 GB300 trays with 8 GB300 GPUs. One field note: K3 reasons a lot before it answers. When a score comes in low, check for truncated answers before assuming wrong ones, and consider increasing the max_tokens budget generously. Deployment Quick start (the 2.8T MoE requires at least one 8× B300 node to run at all): vllm serve moonshotai/Kimi-K3 \ --tensor-parallel-size 8 \ --trust-remote-code \ --load-format fastsafetensors \ --enable-prefix-caching \ --max-num-seqs 512 --max-model-len 32768 \ --enable-auto-tool-choice --tool-call-parser kimi_k3 \ --reasoning-parser kimi_k3 Enable DSpark speculative decoding: --speculative-config '{"model":"Inferact/Kimi-K3-DSpark","method":"dspark","num_speculative_tokens":7,"attention_backend":"FLASHINFER_MLA","draft_sample_method":"probabilistic","rejection_sample_method":"block"}' Deployment notes, each from a real incident: 🔷--enable-prefix-caching turns prefix caching on, which is not on by default for K3. 🔷 Tool calling: validate on your own traffic; production agents should retry or fall back when tool_calls comes back empty, and consider strict/structured tool calling. 🔷 --moe-backend: deep_gemm_mega_moe for any DEP environment, flashinfer_trtllm for TP>1. 🔷 --all2all-backend: flashinfer_nvlink_one_sided for NVLink, deepep_v2 for RDMA. FAQ How many GPUs do I need? At least one 8× B300 (or GB300) node to run at all; most production deployments run multi-node with expert and data parallelism, over RDMA or NVLink. Does K3 support prefix caching, and is it on by default? It supports prefix caching over both full-attention KV and recurrent KDA state, but it is not on by default — pass --enable-prefix-caching. Does vLLM support K3 on AMD GPUs? Yes. ROCm support ships at launch, with broader tuning on the roadmap. Full recipes, kernels, and the complete write-up: 🔷 Model: huggingface.co/moonshotai/Kimi-K3 🔷 DSpark draft model: huggingface.co/Inferact/Kimi-K3-DSpark 🔷 Recipes & Docker images: recipes.vllm.ai/moonshotai/Kimi-K3 🔷Full blog: vllm.ai/blog/2026-07-27-k3 The infrastructure built for K3 now belongs to every model that comes after it. We can't wait to see what you serve. ## 相关链接 - [vLLM](https://x.com/vllm_project) - [@vllm_project](https://x.com/vllm_project) - [14K](https://x.com/vllm_project/status/2081788542079123939/analytics) - [https://www.kimi.com/blog/kimi-k3](https://www.kimi.com/blog/kimi-k3) - [huggingface.co/moonshotai/Kimi-K3](https://huggingface.co/moonshotai/Kimi-K3) - [huggingface.co/Inferact/Kimi-K3-DSpark](https://huggingface.co/Inferact/Kimi-K3-DSpark) - [recipes.vllm.ai/moonshotai/Kimi-K3](https://recipes.vllm.ai/moonshotai/Kimi-K3) - [vllm.ai/blog/2026-07-27-k3](https://vllm.ai/blog/2026-07-27-k3) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [1:07 AM · Jul 28, 2026](https://x.com/vllm_project/status/2081788542079123939) - [14.1K Views](https://x.com/vllm_project/status/2081788542079123939/analytics) - [View quotes](https://x.com/vllm_project/status/2081788542079123939/quotes) --- *导出时间: 2026/7/28 12:39:26* --- ## 中文翻译 # K3 部署推理引擎指南 **作者**: vLLM **日期**: 2026-07-27T17:07:20.000Z **来源**: [https://x.com/vllm_project/status/2081788542079123939](https://x.com/vllm_project/status/2081788542079123939) ---  我们很高兴地宣布，针对 Kimi K3（迄今为止最强大的开源权重模型之一）的高效 Day-0 vLLM 支持。上周，我们预览了生产级集成工作；今天，Moonshot AI 的权重已公开发布，支持也已上线。 Kimi K3 是一个拥有 2.8 万亿参数的混合专家模型，基于 Kimi Delta Attention (KDA) 和 Attention Residuals (AttnRes) 构建，拥有 100 万 token 的上下文窗口和原生视觉能力。K3 的挑战在于让 KDA、MXFP4 MoE 执行、KV 缓存管理、预填充/解码分离、推测解码和长上下文部署方案在实际可运行的服务引擎中协同工作。这篇博文就是实用的指南。 TL;DR Kimi K3 是一个拥有 2.8 万亿参数的多模态 MoE（每个 token 激活 896 个专家中的 16 个），上下文窗口高达 100 万 token，基于 Kimi Delta Attention、Attention Residuals、Stable LatentMoE 设计和原生 MXFP4 (4-bit) 权重构建。 🔷每位用户高达 370 tok/s：在 NVIDIA GB300 NVL72 上，vLLM 在不使用推测解码的情况下以 118 tok/s 的速度服务 Kimi K3，而在使用 DSpark 时达到 370 tok/s（提升了 3.14 倍）。 🔷发布时支持广泛的功能：推测解码、预填充/解码分离、与 Mooncake 的 Agent KV 缓存、工具调用、推理输出和结构化输出，支持 NVIDIA (B200, B300, GB200, GB300) 和 AMD ROCm。 🔷vLLM 支持 DSpark，这是由 Inferact 使用 vLLM 训练并开源的 Kimi K3 最先进的推测解码算法。 🔷服务 K3 的混合循环加注意力设计需要新的 vLLM 核心基础设施：循环 (KDA) 状态上的前缀缓存——这一改变现在惠及所有混合线性模型。 Kimi K3 的架构，以及 vLLM 如何服务它 K3 在四个方面不同于标准 Transformer，每一个都改变了推理引擎必须做的事情。  Kimi K3 架构创新，来自原始发布博客文章 https://www.kimi.com/blog/kimi-k3 Kimi Delta Attention：一种混合循环 + 全注意力栈。K3 的大多数层是 KDA，这是一种线性注意力机制，维护固定大小的循环状态而不是不断增长的 KV 缓存，并穿插定期的全注意力层以保留精确的全局召回能力。这就是 100 万 token 上下文成为可能的原因。 一个混合 KV 缓存管理器在单个调度器下管理这两种内存：用于全注意力层的分页 KV 块，以及用于 KDA 层的紧凑循环状态块。最难的部分是循环状态上的前缀缓存：KDA 层没有每个 token 的 KV 可以进行哈希，因此 vLLM 将物理状态块大小与前缀匹配粒度分离，并在块边界重用状态快照，这样长共享提示仍然能命中缓存。  Kimi K3 将 Kimi Delta Attention（线性）层与定期的全注意力层交织在一起；vLLM 的混合缓存共同管理循环状态和分页 KV。 Attention Residuals：AttnRes 将先前层的输出与 softmax 注意力混合，使每个 token 的表示能够适应其在网络深度中的内容。vLLM 实现了一个融合的 CUDA 内核，在一次启动中计算 logits、跨先前层的 softmax 并进行聚合，将残差加法和输出 RMSNorm 折叠到同一个内核中。 Stable LatentMoE：每个 token 被路由到 896 个专家中的 16 个。专家通过专家并行进行分片；vLLM 提供了两个针对不同拓扑优化的 MoE 后端：用于张量并行 (TP>1) 的 TRT-LLM-Gen，以及用于分离/专家并行 (DEP) 的 MegaMoE，加上可选的专家并行负载平衡 (EPLB)。 MXFP4 权重和原生视觉。K3 的权重经过 4 位 MXFP4 的量化感知训练，因此低精度是原生的，而不是事后转换。 服务语义：K3 发布时没有 Jinja 聊天模板；它的分词器通过 Python 程序渲染消息。vLLM 在 Python 和 Rust 前端都实现了相同的渲染程序，因此工具调用、推理输出和结构化输出在两者上的行为完全一致。 专为生产构建 要良好地服务 2.8T 混合 MoE，意味着对单个用户要快，对数千个用户要高效，对 Agent 要有粘性。vLLM 在这三方面都为 Kimi K3 做好了准备。 超低延迟：为了在不损失精度的情况下达到 2.8T 模型的超低延迟，推测解码是自然的选择。这就是为什么 vLLM 从第一天起就支持 DSpark，也是我们要为 K3 训练并发布我们自己的 DSpark 推测器的原因。DSpark 使用块扩散骨干在一次并行传递中生成多个推测 token，因此随着块的加深，草拟成本保持平稳。我们使草拟模型原生支持 MLA，镜像 K3 自己的注意力机制，因此草拟模型和目标模型共享类似的 KV 布局。  Kimi K3 DSpark 在各种数据集上的位置接受率 使用相同的构建、提示和方法测量：每位用户 118 → 370 tok/s，在 16 个 NVIDIA GB300 NVL72 GPU 上提升了 3.14 倍（在 TP8 上为 111 → 331 tok/s）。增益反映了输出的可预测性——对于编码和其他低熵任务，DSpark 每步接受约 4.73 个 token；对于创意写作等高熵任务，约 2.61 个——因此加速是标准设置下的测量值，而不是一个通用常数。自本版本发布起，草拟模型和推理支持均已开源。 大规模服务（预填充/解码分离）：对于高吞吐量集群，vLLM 通过节点间的专家并行和数据并行来服务 K3，并采用预填充/解码 (PD) 分离技术，它在不同的副本上运行重度预填充和重度解码工作，以便针对各自的瓶颈进行规模调整。经验证的拓扑结构为 TEP8 预填充 → DEP16 解码，KV/状态通过 NIXL 在各阶段之间传输。  预填充/解码分离流程 Agent 服务：Agent 工作负载（长多轮会话、工具循环、大型共享系统提示）需要详细的 KV 重用。vLLM 的 Mooncake 集成允许 K3 跨轮次和请求卸载和重用 KV，因此重复的代码库、文档或 Agent 便笺不需要在每一轮都进行完整的预填充。结合 K3 的循环状态前缀缓存，这即使在上下文累积时也能保持长 Agent 会话的响应速度。 性能和基准 以下所有结果均通过带有版本解析器的 OpenAI 兼容端点运行。 🔷GSM8K: 0.976 🔷GPQA-Diamond: 0.939 🔷OCRBench: 0.889 🔷MMMU Pro Vision: 0.818 在推理和知识方面，vLLM 紧密跟踪 Kimi K3 报告的质量，这意味着内核、解析器和缓存在端到端地保留了模型质量。  Kimi K3 在批次大小为 1 时的解码吞吐量，在 2 个 GB300 托盘（共 8 个 GB300 GPU）上测量。 一个实地说明：K3 在回答前会进行大量推理。当分数偏低时，在假设答案错误之前请先检查是否有截断的答案，并考虑慷慨地增加 max_tokens 预算。 部署 快速开始（2.8T MoE 至少需要一个 8× B300 节点才能运行）： vllm serve moonshotai/Kimi-K3 \ --tensor-parallel-size 8 \ --trust-remote-code \ --load-format fastsafetensors \ --enable-prefix-caching \ --max-num-seqs 512 --max-model-len 32768 \ --enable-auto-tool-choice --tool-call-parser kimi_k3 \ --reasoning-parser kimi_k3 启用 DSpark 推测解码： --speculative-config '{"model":"Inferact/Kimi-K3-DSpark","method":"dspark","num_speculative_tokens":7,"attention_backend":"FLASHINFER_MLA","draft_sample_method":"probabilistic","rejection_sample_method":"block"}' 部署说明，均来自真实事件： 🔷--enable-prefix-caching 开启前缀缓存，这对 K3 来说默认不是开启的。 🔷工具调用：在您自己的流量上进行验证；生产环境的 Agent 当 tool_calls 返回空时应重试或回退，并考虑严格/结构化工具调用。 🔷 --moe-backend: 对于任何 DEP 环境使用 deep_gemm_mega_moe，对于 TP>1 使用 flashinfer_trtllm。 🔷 --all2all-backend: 对于 NVLink 使用 flashinfer_nvlink_one_sided，对于 RDMA 使用 deepep_v2。 FAQ 我需要多少 GPU？至少一个 8× B300（或 GB300）节点才能运行；大多数生产部署通过 RDMA 或 NVLink 运行多节点专家并行和数据并行。 K3 支持前缀缓存吗，默认开启吗？它支持全注意力 KV 和循环 KDA 状态的前缀缓存，但默认不开启——请传递 --enable-prefix-caching。 vLLM 在 AMD GPU 上支持 K3 吗？支持。ROCm 支持随发布一同推出，更广泛的调优已在路线图上。 完整的方案、内核和完整文章： 🔷 模型: huggingface.co/moonshotai/Kimi-K3 🔷 DSpark 草拟模型: huggingface.co/Inferact/Kimi-K3-DSpark 🔷 方案 & Docker 镜像: recipes.vllm.ai/moonshotai/Kimi-K3 🔷完整博客: vllm.ai/blog/2026-07-27-k3 为 K3 构建的基础设施现在属于每一个随之而来的模型。 我们迫不及待地想看到您会部署什么。
从 从 Kimi K3 看下一代 MoE 架构的转折点：LatentMoE 文章分析了 2026 年大模型架构的新趋势 LatentMoE。通过对比 NVIDIA Nemotron 3 Super 和 Moonshot AI Kimi K3，揭示了 LatentMoE 如何通过将 token 投影到低维潜在空间，大幅降低内存和通信开销，从而在同等推理成本下激活更多专家，提升模型性能与效率。 技术 › LLM ✍ 青稞社区🕐 2026-07-20 LatentMoEKimi K3MoE架构设计大模型NVIDIAMoonshot AI推理优化量化负载均衡
2 2026年强化学习面试题库：算法与基础设施 本文汇总了35道2026年强化学习（RL）领域的面试核心问题。内容涵盖算法与基础设施两大方向，既包括PPO、GRPO等训练机制的原理探讨，也涉及分布式推理、显存优化等工程落地细节。作者强调现代RL岗位需要具备全栈理解能力，建议面试者不仅要熟记问题，更需深究背后的技术逻辑。 技术 › LLM ✍ Xiuyu Li🕐 2026-06-08 RL面试PPOGRPODeepSeekMoE基础设施算法强化学习大模型
K Kimi K3 技术报告拆解：全球首个开源 3T 级模型 本文拆解了 Kimi K3 的技术报告，这是一个全球首个开源的 2.8 万亿参数模型。文章详细解析了其混合注意力架构、注意力残差机制、MoE 设计以及在长文本训练和推理优化上的创新。报告指出 K3 性能虽略逊于顶级闭源模型，但在多项任务中表现优异，且具有极高的成本效率，甚至已能辅助团队进行内核优化和芯片设计。 技术 › LLM ✍ Berryxia.AI🕐 2026-07-29 Kimi K3模型架构MoE长文本技术报告开源模型AI芯片内核优化推理加速
聊 聊聊我对 Kimi K3 的体感 作者分享了使用 Kimi K3 模型的实际体验，通过 3D 坦克大战游戏、权力游戏地图动画和教学视频制作三个案例，展示了其在多模态和复杂任务处理上的强大能力。文章指出 K3 提供了 Claude 和 Codex 之外的优质选择，且具备合规性优势，但同时也面临算力短缺的局限。 技术 › LLM ✍ Wang Shuyi🕐 2026-07-21 Kimi K3多模态代码生成测评Agent教学应用大模型AI工具
K Kimi 3 完全使用指南 本文详细介绍了 Kimi K3 的实际使用方法，澄清了关于开源、1M 上下文和免费会员的常见误区。文章通过网页 Agent、Kimi Work、Kimi Code 和 API 四个入口的实战演示，指导读者如何利用 K3 完成数据处理、文件整理和工程开发任务，并提供了编写 Agent 任务的六段式方法论。 技术 › LLM ✍ Ando🕐 2026-07-18 KimiKimi K3Agent编程使用指南大模型实战测试API
O OpenRLHF 作者发布 Agentic RL 框架 Molt：9K 行核心代码支持超大规模 MoE 训练 OpenRLHF 作者发布了新的强化学习框架 Molt。该框架采用纯 PyTorch 栈，核心代码仅约 9000 行，专注于 Agentic RL 研究。它支持 Qwen3.5-397B 到 GLM-5.2 753B 等超大规模 MoE 模型训练，无需依赖 Megatron，具备高度的代码可读性和可修改性。 技术 › LLM ✍ 青稞社区🕐 2026-07-16 强化学习Agentic RLMoltPyTorchvLLMMoEOpenRLHF大模型训练深度学习框架
人 人工智能的工程全景（中）：推理，后训练，对齐和安全 本文是AI工程全景的中篇，深入探讨了模型训练完成后的工程化路径。首先详述了推理优化的核心手段，包括模型瘦身（量化、蒸馏、剪枝、MoE）、投机解码以及主流推理引擎（vLLM, TensorRT-LLM, SGLang）的生态格局。文章分析了成本、延迟与吞吐的“不可能三角”，并重点介绍了“测试时计算”这一范式转变，即通过在推理阶段增加计算量来动态提升模型智能。 技术 › LLM ✍ snowboat🕐 2026-07-03 LLM推理优化量化投机解码测试时计算MoEvLLMAI工程
下 下一代 LLM 推理网络：ZCube 如何缓解网络瓶颈 文章探讨了随着长上下文推理和 Prefill-Decode 解耦成为主流，网络如何成为 LLM 推理集群吞吐量和延迟的关键瓶颈。Z.ai、Harnets.AI 和清华大学联合开发了 ZCube 网络架构，通过扁平化拓扑和混合轨道设计，有效解决了传统 ROFT 架构下的流量负载不均衡问题。生产环境基准测试显示，ZCube 仅通过架构优化便实现了交换机成本降低 33%、吞吐量提升 15% 以及 TTFT 延迟降低 40.6% 的显著收益。 技术 › DevOps ✍ Z.ai🕐 2026-05-21 LLM推理网络架构ZCube性能优化Prefill-Decode负载均衡ROFT基础设施清华大学
M Mixture of Experts (MoE): Scaling AI with Specialized Models 文章深入探讨了混合专家模型（MoE），这是一种通过激活特定子网络来高效扩展 AI 模型的架构策略。文章回顾了 MoE 的历史背景，详细解释了其由门控网络和专家组成的结构及稀疏路由机制，并分析了其在 Transformer 中的应用、优势（如高效计算、参数扩展）以及面临的负载平衡和通信开销等挑战。 技术 › LLM ✍ Jayanth🕐 2026-05-07 MoE混合专家大模型架构设计Transformer稀疏路由AI深度学习模型扩展机器学习
大 大语言模型训练与服务背后的数学原理 本文基于 Reiner Pope 的播客内容，深入剖析了大模型在集群中的运行机制。文章通过 Roofline 分析和 KV Cache 等核心概念，解释了推理延迟、Batch Size、API 定价策略及 MoE 架构背后的物理与经济逻辑，揭示了硬件限制如何塑造 AI 进展。 技术 › LLM ✍ Saito🕐 2026-05-01 LLM推理架构设计数学原理MoEAPI定价性能优化Transformer
L LLM 中的 KV 缓存机制详解 文章深入解释了大型语言模型（LLM）中的 KV 缓存技术。作者指出，LLM 生成文本时首个令牌较慢而后续令牌迅速的现象，归功于 KV 缓存的工程优化。该技术通过存储已计算键值向量，避免在自回归生成过程中的冗余计算，以 GPU 内存为代价换取显著的计算加速。文中详细解析了注意力机制的冗余问题、KV 缓存的工作原理、首令牌延迟（TTFT）的产生原因，以及内存与计算资源之间的权衡取舍。 技术 › LLM ✍ Avi Chawla🕐 2026-03-22 KV缓存注意力机制Transformer模型推理LLM性能优化GPU内存预填充TTC大模型
K Kimi K3 memory savings vs Jevon's paradox 本文深入分析了Kimi K3通过Kimi Delta Attention (KDA)技术实现的内存节省突破，对比了传统MLA和DeepSeek的架构，讨论了其在长上下文场景中的优势及对行业的影响。 技术 › LLM ✍ GDP🕐 2026-07-30 Kimi K3KDA内存节省长上下文DeepSeekMLA混合线性注意力KV cache