补在 部署启动专题 下的历史案例。2024 年 11 月，enardo7 在 Windows 11 Pro 笔记本的 Docker 环境加载 Mistral-Nemo-12B-Instruct，报 No available memory for the cache blocks。 原帖写的“4090”只有 16GB 显存；监控输出为 16022 / 16376 MiB。不能直接对应桌面 24GB 卡。作者已经试过把 gpu_memory_utilization 调到 1.0，仍然来求助。 后续 neal.vaidya 回复称，当时 NIM 在 4090 上只支持 FP16，该模型仅加载权重就需要约 25GB 以上显存，并建议寻找更小模型。这只是当时 NIM 的支持条件，不能推广到今天的所有框架和格式。 错误提示让人调高利用率，但参数不能凭空增加显存；设备容量与运行格式还得一起看。 来源：NVIDIA 论坛原帖与回复 · 2024-11-10—11，历史资料。

fenghuohuo2001 在 2025 年 11 月报告了一个明确的对照：同一项 Qwen3-VL-4B 的 INT8 量化部署，在 RTX 5090 上报 Int8 not supported for this architecture，他同时说在 RTX 4090 上可以正常运行。推理框架版本是 vLLM 0.11.0，量化使用 llmcompressor。 这份记录的价值，在于它把模型、量化格式、框架版本和两张卡的不同表现放到了同一个场景里。“模型大小差不多，换张卡就应该能跑”没有覆盖这类兼容性条件。 但原帖里的对照，仍是作者报告的结果。已读内容没有展示一套完整的复现环境，也没有看到作者后续提供新版复测。楼中机器人建议改用 FP8，不能因此把它写成已验证解决方案。 我会把这条保留在兼容性历史案例里：用于识别“报错可能与量化执行路径有关”的线索，不用于判定今天 5090 是否支持某种 INT8 组合。若要继续做成部署建议，应补量化配置、运行后端及对应版本的官方支持说明，再做同条件验证。 来源整理：fenghuohuo2001 · 2025-11-19 · 原帖

vlad 留下了一组从单张 4090 到多张 H200 的启动记录。里面最值得带走的，是把“权重装得下”和“服务能启动”分开看。下面都是作者在 vLLM v0.29/v0.30 环境下的观察。 并发占用的账。 作者在 v0.30、单张 H100 上运行 Nemotron-3.5-Lightning，遇到默认 max_num_seqs 超过 Mamba cache blocks 的情况；他报告降低该值后启动成功。这是特定模型和配置的处理记录，不是给所有模型统一降并发的结论。 失败阶段的账。 Qwen3.8-27B 在 v0.29 的一条记录中，分配 KV cache 时内存不足，表面报错却出现在 FlashAttention 调用里。作者说降低 max_num_seqs 后可以启动，并报告 v0.30 下能够启动。只看报错所在模块，可能会错过前面的资源分配。 主存的账。 作者还记录了 DeepSeek-V4.1-Flash 使用 pinned host RAM 的情况：仅核算 GPU 容量，会漏掉主存需求。 这份材料适合用来辨认失败发生在哪一步。要迁移其中的处理，仍需匹配模型、版本和启动配置；文中的硬件组合也不代表水华当前可提供的资源。 来源整理：vlad · 2026-10-03 · 原帖 相关历史条目：16GB笔记本4090与缓存不足。设备容量和运行格式应随案例一并看。

HN 用户 netsroht 为手头的 4090 fork 了 ninfer，围绕 Qwen 3.8 27B 做优化。他给出的机器并不神秘：约八年前的 16 核 AMD Threadripper、64GB 内存、三星 NVMe，以及水冷 RTX 4090。 他的性能口径分成三项： 解码约 149 tok/s； 并发时合计约 270 tok/s； 预填充超过 2500 tok/s。 这里最容易读错的是把 270 当成单条回答的出字速度，或者把 2500 和 149 放到同一列比较。它们描述的阶段或统计方式不同。作者还提到完整 262k 上下文使用了量化，不能省掉这个条件。 优化也涉及实际使用。他想同时使用 opencode、pi 及它们启动的子 agent，因此增加了缓存层，让算过的上下文能从 RAM 或磁盘更快加载；接下来关注的是功率限制与 J/token 之间的取舍。 这些数字是原作者个人报告，当前帖子不足以构成可复现基准；具体量化方案、并发数和完整测试命令仍需进一步核对。 来源：netsroht 的 HN 帖及配置回复 · 作者 fork；核对于 2026-10-27。

Coder5424 这条记录同时保留了正常和异常请求，差别很明显。 Coder5424 用两张 24GB RTX 4090，运行 vllm/vllm-openai:v0.31.0，模型是 QuantTrio/Qwen3.5-35B-A3B-AWQ，TP=2。任务是文档分析，每次输入约 3万—5万 token。 按作者口径，正常单请求平均约 15 秒完成；异常请求等了约 20 分钟仍在生成。把其他请求全部清掉、只留这一条，现象依旧，因此单靠“排队太多”解释不了这份记录。 异常日志里，Running 为 1、Waiting 为 0，生成吞吐仍有数值，KV cache 使用率逐步上升。这和“服务完全停止工作”是两种现象。 还有一个后续：作者取消请求后，把相同请求重新提交，有时需要重复几次才能完成。但重试成功不等于根因解决，记录没有给出已确认修复。 接着排查时，我会优先对齐同一条请求的请求体、终止设置、服务日志和客户端响应；先分清生成没停，还是结果没传完，再逐项改变设置。这个排查顺序是整理建议，不是原帖结论。 来源整理：Coder5424 · 2026-10-22 · 原帖