腾讯混元 Hunyuan-7B旧代际
关于 腾讯混元 Hunyuan-7B 的完整介绍（点开看；上面就是结论表）
腾讯混元稠密小模型（HF: tencent/Hunyuan-7B-Instruct，**2025-08-04 开源，旧代际**——Step 清单标 2026 是笔误，多源已勘误）。config.json 一手核到（2025-07-30 首发上传）：32 层 / 32 查询头 / 8 KV 头 / head_dim 128。**上下文口径已核清（2026-11-08 复核）**：config `max_position_embeddings=32768` 是**原生位置上限**；「256K」是 `rope_scaling: dynamic (alpha=1000)` 外推宣称——同仓 tokenizer_config 的 `model_max_length` 于 2025-08-04 由 1,048,576 改为 262,144，README 宣称原生 256K，第三方（slm.expert）按 config 记 32K。按站内纪律「外推不算原生」（同 Qwen3.8-27B 的 YaRN 处理法），本站按 config 记 **32K、不打 long-context**；要跑 256K 需在框架里启用对应 RoPE scaling 参数（效果自负，本站不背书）。**更正上一轮记录**：此前怀疑「vocab 128167 区别于兄弟 120818，疑主仓挂 2025-01 旧 7B」——经查 config 上传日期（2025-07-30）与 tokenizer 更新（2025-08-04）均为家族首发时间线，**主仓就是 2025-08 家族 7B**，vocab 差异只是家族内成员不同，此怀疑撤回。许可 **Tencent Hunyuan Community License**。7B Q4 ~4.2G / Q8 ~7.5G，16G 卡可跑。
实测速度：什么卡、什么量化、多少 token
上传实测数据
每行是一次真实测量的完整口径：哪张卡、几张卡、什么量化、多大上下文、哪个框架哪个版本、单流还是并发、开没开投机—— 缺一项就会标出来，缺项的行不参与对比与偏差计算。本站实测行没有外链，但日志路径就是原始数据所在。 想看同一张卡跑别的模型，从这个表的显卡名点进那张卡的页面。
速查：什么卡、跑多少 token
推算值按 Q8_0、8K 上下文、单流；真实测量看下面的实测速度表。没有实测的模型这里只有推算，本站不把推算写成实测。
架构常数（已核实）
来源：tencent/Hunyuan-7B-Instruct / config.json（抓取于 2026-11-08）。KV 公式：2 × 层数 × KV头数 × 头维 × 精度字节 × token（滑窗层按 — 封顶）。
上下文档位（按 Q8_0）
| 上下文 | KV | 总需显存 | 16G 水位内 |
|---|---|---|---|
| 4K | 0.5 G | 8.9 G | 够 |
| 8K | 1 G | 9.4 G | 够 |
| 32K | 4 G | 12.4 G | 够 |
| 128K | 16 G | 24.4 G | 超 |
* 含 1G 框架开销；可用水位按 Windows 口径 88% = 14.1G。
各显存档位能开多大
| 显存 | 推荐量化 | 8K 总需 | 最多可开 |
|---|---|---|---|
| 4G | 装不下 | — | — |
| 6G | IQ3_K（估算） | 5.1G | 9728（约 10K） |
| 8G | Q5_K_M（估算） | 6.9G | 8704（约 9K） |
| 10G | Q6_K（估算） | 7.7G | 16384（约 16K） |
| 11G | Q8_0（估算） | 9.4G | 10240（约 10K） |
| 12G | Q8_0（估算） | 9.4G | 17408（约 17K） |
| 16G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 20G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 22G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 24G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 32G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 48G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 64G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 96G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 128G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 256G | Q8_0（估算） | 9.4G | 32768（约 32K） |
| 512G | Q8_0（估算） | 9.4G | 32768（约 32K） |
「最多可开」已扣掉权重与 1G 开销；标注为「模型原生上限」时表示显存还有余但模型只支持这么长。净可用还要再减聊天模板与系统提示词的 250 token（估算值，未逐项核实）。量化档后带「（估算）」= 官方仓库没核到这档、按公式算的权重体积（方向保守偏高）；不带 = 核过官方仓库真实文件体积。
估算速度（Q8_0 · 8K）
推算 本站暂无这一模型的实测记录。
| 显卡 | 状态 | 估算 tok/s |
|---|---|---|
| NVIDIA RTX 5090 32G | 流畅 | 145–200 |
| NVIDIA RTX 5090 D 32G | 流畅 | 145–200 |
| NVIDIA CMP 170HX 64G（矿卡魔改） | 流畅 | 120–170 |
| NVIDIA RTX PRO 5000 Blackwell 48G（工作站） | 流畅 | 108–154 |
| AMD Instinct MI100 32G（老数据中心卡） | 流畅 | 99–140 |
| AMD Instinct MI50 32G（数据卡） | 流畅 | 83–117 |
| AMD Radeon VII 16G | 流畅 | 83–117 |
| NVIDIA RTX 4090 24G | 流畅 | 81–115 |
| NVIDIA RTX 3090 Ti 24G | 流畅 | 81–115 |
同一套公式也用于显卡页，两页数字必然一致。带宽按 60–85% 效率折算（offload 场景更低），并对单流解码设经验上限，因此这里的数字比纯带宽公式保守。 总需显存 = 9.4G，对比各卡可用水位。
实测数据区
上传实测数据
推理框架命令
llama.cpp
# 1) 取 GGUF 权重（本站核实过的仓库名）
huggingface-cli download tencent/Hunyuan-7B-Instruct config.json
# GGUF 量化版通常在第三方转换仓库，搜「tencent/Hunyuan-7B-Instruct GGUF」
# 2) 起服务（Linux/macOS 用 ./llama-server，Windows 用 llama-server.exe）
llama-server -m HUNYUAN-7B-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080Ollama
# 本站没核实到 Ollama 仓库里有 腾讯混元 Hunyuan-7B 的可用标签，所以不给命令
# 自己去查一眼：https://ollama.com/search?q=%E8%85%BE%E8%AE%AF%E6%B7%B7%E5%85%83%20Hunyuan-7B宁可不给命令，也不给一条跑不通的命令——照抄未核实的标签是新手最常见的卡死原因。
vLLM
vLLM 直接吃 Hugging Face 仓库名，这条最可靠：
vllm serve tencent/Hunyuan-7B-Instruct --max-model-len 8192 --gpu-memory-utilization 0.90LM Studio
模型页搜「tencent/Hunyuan-7B-Instruct」→ 选 Q8_0 或 Q4_K_M → Load →
Chat Context Length 设 8192 → GPU Offload 拉到最大仓库名 tencent/Hunyuan-7B-Instruct 是本站核实过的（架构常数就取自它）。Ollama 标签与 GGUF 文件名会随发布方变动，本站不保证一定存在，拉取失败请搜同名前缀。
优化要点
- Q4_K_M 权重 4.2G（估算）、Q6_K 5.7G（估算）、Q8_0 7.4G（估算）：带「估算」的是公式值（官方仓库没核到这档），不带的核过真实文件；先在容量表里确认 8K 上下文还剩多少，再决定档位
- 上下文从 8K 提到 32K，KV 增加约 3G（本模型 32 层 / 8 KV头 / 头维 128）
- 模型原生上下文上限是 32K，把 -c 设得更高属于超纲使用，质量不保证
- 想要更长上下文：-ctk q8_0 -ctv q8_0 让 KV 减半，几乎不掉质量
- 稠密模型每个 token 都要读全部权重，所以速度上限就是带宽 ÷ 权重大小
- 本站对单流解码设了经验上限 200–200 tok/s（依带宽分档），超出上限的数字是公式失真而不是你的卡快