模型服务与边缘部署

共置服务如何处理干扰复制锚点链接

同一设备上的长 prefill 可以占据较长一次迭代，让已有 decode 等待。chunked prefill 把长输入分块，与 decode 按预算调度，限制单次 prefill 工作。块小可能增加调度次数和损害矩阵效率，块大则更容易造成间隔尖峰；选择需跟随输入分布和服务目标。Sarathi-Serve

持续批处理、切块、抢占和优先级可以组合。最大序列数、token 预算、KV 容量、队列长度和超时共同决定准入。拒绝过载、明确等待与取消资源回收，可以比无限排队取得更稳定的完成率。取消发送方等待不会自动释放引擎工作，需要服务链传递取消并观察实际回收。

分离阶段需要传递哪些状态复制锚点链接

prefill 与 decode 放到不同实例池，各自可以选择硬件、并行和复制规模。prefill 产生的 KV 必须传给 decode，模型、适配器、位置、格式和张量分片需一致。数据传输、路由和资源失衡进入首 token 路径。DistServe 将吞吐与延迟目标共同建模。

一条长输入的 KV 可以很大，网络传输若不能与计算重叠，会抵消隔离收益。缓存驻留 CPU、SSD 或远端池能够扩展复用，也带来访问成本、身份隔离、一致性和恢复问题。根据缓存命中路由，需要区分“可复用”与“所在节点当前可服务”。

负载的输入/输出比变化会改变最优池比例。规模小、吞吐型任务或简单运维约束下，共置可能更合适。严格流式目标和较高规模可能支持阶段分离的成本；两者之间需要有可比的工作负载证据。

边缘设备的约束复制锚点链接

端侧部署改变的是内存、带宽、功耗、算子支持和数据边界。低批 decode 常要读取大量权重，因此 CPU/GPU/NPU 峰值 TOPS 无法单独预测速度。不同设备共享内存、频率变化、温度限制和跨设备拷贝都影响端到端结果。

GGUF 等格式将模型张量与量化元数据打包，实际位宽还含块尺度和敏感张量的较高精度。模型文件能加载，不代表足够容纳长 KV、并发与应用其他数据。模型许可、分词器和聊天模板必须与权重一同确认。

浏览器可利用 WebGPU，部分任务以 WebAssembly/CPU 承担或回退。设备与浏览器版本、显存限额、上下文和算子覆盖差异很大；不能给所有浏览器统一的“可靠 3B”或“8B 上限”。大文件下载、初始化、缓存更新、离线行为和终止释放也是应用成本。

模型网关与推理引擎的分工复制锚点链接

引擎执行模型计算和设备调度，网关处理调用身份、路由、预算、限流、重试和记录。OpenAI-compatible 等接口兼容只覆盖具体字段和事件；工具、结构化输出、usage、推理预算和取消可能不同。网关不能只因接口相似就任意换模型。

降级需要定义最低质量、上下文能力、工具协议和数据区域。重试前确认请求是否执行以及是否已有副作用；模型计算重复会增加成本，Agent 动作重复还可能改变外部状态。缓存和观测日志要按用户隔离，并审查敏感数据保存范围。

部署验证同时看任务质量、服务目标和恢复：模型加载、完整流、截断、过载、取消、升级、缓存失效及节点失败。文档和配置只能说明预期接口，本页没有声称已经启动任何推理服务。