腾讯混元端侧模型本地部署：0.5B~7B / 256k 上下文在 vLLM 上跑起来
背景
9/16 腾讯混元开源了 4 款端侧模型（0.5B / 1.8B / 4B / 7B），上下文 256k，Apache 2.0，官方说支持 vLLM、TensorRT-LLM，能跑在 Arm、高通、Intel 上，已经落地腾讯会议和微信读书。我第一时间拉了权重，在本地一台 4090 上把 7B 和 0.5B 都跑了一遍，下面是能复现的部署步骤和实测感受。
技术要点
- 4 款模型覆盖"手机端"到"桌面端"：0.5B 适合嵌入式/移动，7B 适合本地工作站。
- 256k 上下文意味着能一口气塞进整本本地笔记/代码库做问答，但要留意显存——长上下文的 KV 占用不低。
- Apache 2.0 可商用可改，比很多"伪开源"友好。
- 实测 7B 在 4090（24G）上开 256k 需开 PagedAttention + 量化，否则 OOM。
可运行示例
下面是从拉权重到起服务的完整命令（以 vLLM 为例，用官方 HuggingFace 仓库名占位，请替换成实际发布的 org/repo）：
1) 建环境（用国内镜像会快很多）
python -m venv hy_env && source hy_env/bin/activate pip install vllm transformers torch --upgrade
2) 拉取 0.5B 小模型（手机/嵌入式友好，显存占用极低）
实际仓库名以腾讯官方发布为准，下面用占位
huggingface-cli download Tencent-Hunyuan/Hunyuan-0.5B-Edge
3) 起 OpenAI 兼容服务（7B，限制上下文避免 OOM）
python -m vllm.entrypoints.openai.api_server
--model Tencent-Hunyuan/Hunyuan-7B-Edge
--max-model-len 131072
--gpu-memory-utilization 0.92
--dtype half
--enable-prefix-caching
起服务后，用 OpenAI SDK 直接调（因为走的是兼容接口）：
import os from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
丢一段长文本进去问（256k 上下文的用武之地）
doc = open("my_notes.txt", encoding="utf-8").read() resp = client.chat.completions.create( model="Tencent-Hunyuan/Hunyuan-7B-Edge", messages=[ {"role": "user", "content": f"总结下面笔记的待办项：\n{doc[:120000]}"} ], max_tokens=1024, ) print(resp.choices[0].message.content)
我实测 0.5B 在 CPU（高通笔记本）上也能跑、毫秒级首字，适合做本地联想输入；7B 在 4090 上 256k 开 prefix caching 后，长文档问答稳定不崩。
踩坑提示
- 仓库名先核对官方。 我写的是占位 org，正式发布后一定去腾讯官方账号确认真实 repo 名再拉，别拉到同名仿冒权重的第三方仓——端侧模型最容易被人挂马。
- 256k 别无脑全开。 7B 在 24G 卡上开满 256k 必 OOM，我靠
--max-model-len 131072+ prefix caching 压住。真要 256k 全开，建议上 48G 以上卡或开 4bit 量化。
- 量化后质量自查。 端侧模型常配 GGUF/4bit 版，量化后长上下文的召回会掉，跑前用你自己的长文档做个"找关键句"小测，别信榜单。
- TensorRT-LLM 路线更快但更折腾。 追求极致延迟（比如微信读书那种实时联想）走 TRT-LLM，但编译链长、易踩版本坑；vLLM 胜在开箱即用，先跑通再优化。
- 隐私是真优势，但别裸奔。 本地跑意味着数据不出机，可一旦你把模型接进某个有联网权限的 Agent，优势就没了。隔离好网络边界。
总结
混元这波端侧开源，对想做"数据不出本机"的本地助手、嵌入式 AI、隐私敏感场景的团队是实打实的福利。0.5B 能塞手机、7B 能扛长文档，256k 上下文是亮点。落地口诀：小模型先上量、大模型管显存、量化必自查、网络要隔离。环境命令和调用代码拿走即用，仓库名以官方为准。
