<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>推理服务 on AI 观察</title><link>https://ai.wujiong.cc/tags/%E6%8E%A8%E7%90%86%E6%9C%8D%E5%8A%A1/</link><description>Recent content in 推理服务 on AI 观察</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Sat, 17 Oct 2026 14:57:00 +0800</lastBuildDate><atom:link href="https://ai.wujiong.cc/tags/%E6%8E%A8%E7%90%86%E6%9C%8D%E5%8A%A1/index.xml" rel="self" type="application/rss+xml"/><item><title>KV Cache 显存怎么估算：公式、示例与降低占用的办法</title><link>https://ai.wujiong.cc/posts/2026-10-17-hardware-kv-cache-memory-estimate/</link><pubDate>Sat, 17 Oct 2026 14:57:00 +0800</pubDate><guid>https://ai.wujiong.cc/posts/2026-10-17-hardware-kv-cache-memory-estimate/</guid><description>&lt;p&gt;KV Cache 的显存占用可以用一个公式估算：&lt;strong&gt;每个 token 的 KV 字节数 = 2 × 层数 × KV 头数 × 每头维度 × 每个元素的字节数&lt;/strong&gt;，再乘以序列长度和并发序列数。部署前算一遍，就能知道在给定显卡上能支撑多长的上下文和多少并发。&lt;/p&gt;
&lt;h2 id="为什么要算-kv-cache"&gt;为什么要算 KV Cache&lt;/h2&gt;
&lt;p&gt;推理时显存主要分给三部分：模型权重、KV Cache、运行时开销（激活、框架缓冲等）。权重大小相对固定，KV Cache 则随&lt;strong&gt;上下文长度 × 并发数&lt;/strong&gt;线性增长。很多「模型能加载，但一上并发就显存不足」的问题，原因就在这里。&lt;/p&gt;</description></item><item><title>vLLM 批大小怎么定：吞吐与延迟的实务 FAQ</title><link>https://ai.wujiong.cc/posts/2026-10-17-hardware-vllm-batch-sizing-faq/</link><pubDate>Sat, 17 Oct 2026 11:52:40 +0800</pubDate><guid>https://ai.wujiong.cc/posts/2026-10-17-hardware-vllm-batch-sizing-faq/</guid><description>&lt;p&gt;批太大，延迟尾部变差；批太小，GPU 吃不饱。没有放之四海的魔法数字，只有「目标延迟 + 显存 + 观测」的回路。&lt;/p&gt;
&lt;h2 id="faq"&gt;FAQ&lt;/h2&gt;
&lt;h3 id="先定什么"&gt;先定什么？&lt;/h3&gt;
&lt;p&gt;先定服务目标：P95 延迟预算、是否流式、上下文长度分布。再谈提高吞吐。&lt;/p&gt;
&lt;h3 id="和-max_num_seqs--连续批处理有何关系"&gt;和 max_num_seqs / 连续批处理有何关系？&lt;/h3&gt;
&lt;p&gt;它们共同约束同时驻留的请求。调参时一次只改一类旋钮，并记录前后指标，否则无法归因。&lt;/p&gt;</description></item></channel></rss>