如何把Ornith-1.5-9B上下文扩到100万token：YaRN长上下文缩放完整实践-北京尧图网络

如何把Ornith-1.5-9B上下文扩到100万tokenYaRN长上下文缩放完整实践【免费下载链接】Ornith-1.5-9B项目地址: https://ai.gitcode.com/hf_mirrors/ornith-ai/Ornith-1.5-9BOrnith-1.5-9B 是一款 9B 参数的开源推理模型原生支持 262,144 token 上下文。本文带你用 YaRN 长上下文缩放把它扩到 100 万 token 完整实践涵盖修改 config.json 与 vLLM、SGLang 启动时覆盖两种方法以及缩放因子选择和显存估算的关键坑点。Ornith-1.5-9B 的原生长上下文能力Ornith-1.5-9B 是 Ornith-1.5 家族中最轻量的成员9B 稠密参数、bf16 精度约 19 GB单张 80GB 显卡即可部署。在模型的config.json中可以看到max_position_embeddings: 262144也就是说它的原生窗口约26 万 token日常对话、代码任务绰绰有余。但下面这些场景26 万就不够了整个代码库一次性塞进上下文做仓库级理解和跨文件重构长文档分析合同、论文、技术报告的完整解读多轮对话工具调用不断累积历史输入输出合计轻松超过 262,144 tokenYaRN 长上下文缩放一行配置把窗口翻倍RoPE旋转位置编码是模型感知位置的标尺量程在训练时就固定了。YaRNYet another RoPE extensioN是一种 RoPE 缩放方案按倍数外推位置编码在几乎不损失质量的前提下拉长窗口——这正是 Ornith-1.5-9B 官方验证过的方案。核心公式只有一个可用窗口 ≈ factor × 262,144factor可用窗口适用场景2.0约 524,28850 万级长文档4.0约 1,048,576100 万 tokenvLLM 和 SGLang 都已内置 YaRN无需任何训练改配置即可生效。方法一修改 config.json 永久启用 YaRN在模型目录的config.json顶层加入rope_scaling配置块{ rope_scaling: { rope_type: yarn, factor: 4.0, original_max_position_embeddings: 262144 } }三个字段分别表示rope_type: yarn启用 YaRN 缩放factor: 4.0缩放倍数4.0 × 262,144 ≈ 100 万 tokenoriginal_max_position_embeddings: 262144模型原生窗口保持不动保存后照常启动推理服务窗口自动变为 1M。这种方式适合这个部署长期跑长上下文的场景。方法二启动时覆盖不改动模型文件如果不想改动模型文件比如同一个权重既服务短文本又服务长文本可以用启动参数覆盖。vLLM 长上下文配置VLLM_ALLOW_LONG_MAX_MODEL_LEN1 vllm serve ornith-ai/Ornith-1.5-9B \ --served-model-name Ornith-1.5-9B \ --host 0.0.0.0 --port 8000 \ --hf-overrides {rope_scaling: {rope_type: yarn, factor: 4.0, original_max_position_embeddings: 262144}} \ --max-model-len 1000000SGLang 长上下文配置SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN1 python -m sglang.launch_server \ --model-path ornith-ai/Ornith-1.5-9B \ --served-model-name Ornith-1.5-9B \ --host 0.0.0.0 --port 8000 \ --json-model-override-args {rope_scaling: {rope_type: yarn, factor: 4.0, original_max_position_embeddings: 262144}} \ --context-length 1000000其中环境变量VLLM_ALLOW_LONG_MAX_MODEL_LEN1/SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN1是安全闸门——运行时不会无条件接受超大窗口需要显式放行。如何选择 factor别默认拉满到 100 万官方特别提醒 ⚠️开源运行时对 YaRN 是静态实现的——不管输入长短每个请求都会套用同一个factor缩放普通长度的输入质量可能略有下降。因此原则是只有工作负载真正需要长窗口时才开启rope_scaling并按实际需求把factor配小一点。速查目标窗口 factor × 262,144请求最长约 52 万 token →factor: 2.0确实要打满 100 万 →factor: 4.0显存与性能实践建议窗口越长KV cache 越大。以 Ornith-1.5-9B 粗略估算32 层中每 4 层只有 1 层是全注意力其余为状态大小恒定的线性注意力层KV 每 token 增量约 32KB262K 窗口KV cache 约 8 GB80GB 卡很从容100 万窗口KV cache 约 32 GB单张 80GB 卡仍可承载但并发空间明显变小建议降低并发或用--tensor-parallel-size切分到多卡其他实践要点运行时版本要求vLLM ≥ 0.19.1、SGLang ≥ 0.5.9、Transformers ≥ 5.8.1官方推荐采样参数通用任务temperature1.0, top_p0.95精确编码任务temperature0.6, top_p0.95Ornith-1.5-9B 是推理模型默认先输出think思考块再给答案需要分离思维链或解析工具调用时记得加上对应的--reasoning-parser/--tool-call-parser快速排障 FAQQ配完后报窗口超限检查--max-model-lenvLLM或--context-lengthSGLang是否与 YaRN 目标一致1000000以及放行环境变量是否已开启。Q小显存卡能跑 100 万上下文吗不建议。100 万窗口的 KV cache 本身约 32 GB80GB 单卡是官方推荐配置显存更小的卡请调小factor或降低并发。Q开启 YaRN 后短文本会变差吗静态缩放作用于所有请求普通长度输入可能有轻微质量损失。短文本服务保持不开启只在长上下文服务上启用最稳妥。小结只需一段rope_scaling配置Ornith-1.5-9B 的上下文就能从 26 万扩到 100 万 token。记住三件事按实际最大长度选factorfactor × 262,144 目标窗口、需要共享权重时优先用启动参数覆盖、给 KV cache 预留足够的显存【免费下载链接】Ornith-1.5-9B项目地址: https://ai.gitcode.com/hf_mirrors/ornith-ai/Ornith-1.5-9B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

如何把Ornith-1.5-9B上下文扩到100万token：YaRN长上下文缩放完整实践

相关推荐

Symfony Workflow七大事件全解：从Guard到Announce的状态流转钩子详解

MySQL搜索引擎深度解析：InnoDB、MyISAM与MEMORY的核心特性与选型实战

人工智能-位置编码

更多资讯

如何用8GB显卡玩转4K视频生成：阿里WanVideo_comfy完整指南

WanVideo_comfy：8GB显存玩转电影级视频生成，ComfyUI生态终极解决方案

腾讯SongGeneration：AI音乐创作的终极解决方案

70亿参数重塑音频智能：Kimi-Audio开源模型开启多模态交互新纪元

项目02--JsonRpc

无需验证器的推理革命：RLPR框架如何让大模型实现自我进化

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？