<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[模型部署与推理]]></title><description><![CDATA[选型、量化、推理性能与服务端参数。写明硬件、模型和版本。]]></description><link>https://shuihualab.tunex.chat/category/5</link><generator>RSS for Node</generator><lastBuildDate>Thu, 29 Oct 2026 14:24:32 GMT</lastBuildDate><atom:link href="https://shuihualab.tunex.chat/category/5.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 29 Oct 2026 10:58:59 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[历史案例｜16GB 笔记本 4090 加载 Mistral-Nemo-12B 时没有缓存块]]></title><description><![CDATA[补在 部署启动专题 下的历史案例。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，历史资料。
]]></description><link>https://shuihualab.tunex.chat/topic/13/历史案例-16gb-笔记本-4090-加载-mistral-nemo-12b-时没有缓存块</link><guid isPermaLink="true">https://shuihualab.tunex.chat/topic/13/历史案例-16gb-笔记本-4090-加载-mistral-nemo-12b-时没有缓存块</guid><dc:creator><![CDATA[阿川]]></dc:creator><pubDate>Thu, 29 Oct 2026 10:58:59 GMT</pubDate></item><item><title><![CDATA[5090 报 INT8 架构不支持、4090 却能跑：vLLM 0.11.0 的一条旧记录]]></title><description><![CDATA[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 · 原帖
]]></description><link>https://shuihualab.tunex.chat/topic/12/5090-报-int8-架构不支持-4090-却能跑-vllm-0.11.0-的一条旧记录</link><guid isPermaLink="true">https://shuihualab.tunex.chat/topic/12/5090-报-int8-架构不支持-4090-却能跑-vllm-0.11.0-的一条旧记录</guid><dc:creator><![CDATA[小禾]]></dc:creator><pubDate>Thu, 29 Oct 2026 10:58:59 GMT</pubDate></item><item><title><![CDATA[模型权重能装下，vLLM 还是没启动：一份失败记录里的三笔账]]></title><description><![CDATA[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与缓存不足。设备容量和运行格式应随案例一并看。
]]></description><link>https://shuihualab.tunex.chat/topic/11/模型权重能装下-vllm-还是没启动-一份失败记录里的三笔账</link><guid isPermaLink="true">https://shuihualab.tunex.chat/topic/11/模型权重能装下-vllm-还是没启动-一份失败记录里的三笔账</guid><dc:creator><![CDATA[阿川]]></dc:creator><pubDate>Thu, 29 Oct 2026 10:58:28 GMT</pubDate></item><item><title><![CDATA[一张水冷 4090 的本地推理分享：149 和 270 tok/s 不是同一个指标]]></title><description><![CDATA[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。
]]></description><link>https://shuihualab.tunex.chat/topic/7/一张水冷-4090-的本地推理分享-149-和-270-tok-s-不是同一个指标</link><guid isPermaLink="true">https://shuihualab.tunex.chat/topic/7/一张水冷-4090-的本地推理分享-149-和-270-tok-s-不是同一个指标</guid><dc:creator><![CDATA[拾光]]></dc:creator><pubDate>Thu, 29 Oct 2026 10:57:57 GMT</pubDate></item><item><title><![CDATA[双 4090 分析长文档：请求没结束，服务端却还在生成]]></title><description><![CDATA[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 · 原帖
]]></description><link>https://shuihualab.tunex.chat/topic/6/双-4090-分析长文档-请求没结束-服务端却还在生成</link><guid isPermaLink="true">https://shuihualab.tunex.chat/topic/6/双-4090-分析长文档-请求没结束-服务端却还在生成</guid><dc:creator><![CDATA[阿川]]></dc:creator><pubDate>Thu, 29 Oct 2026 10:57:57 GMT</pubDate></item></channel></rss>