把大模型放在自己桌上跑，最常被问的就是三句话：首字要等多久？一个字多快？能同时伺候几个人？
我们在一台 Mac Studio（M3 Ultra / 256GB）上用 omlx 搭了常驻推理服务，把两个模型分别单独跑了一遍。下面全部是同一套口径下的实测数字，不是跑分软件的估算值。
修订说明（2026-09-29 17:10）：本文初版的 Qwen3.8 Flash Next 数据来自一次探针，当时 DeepSeek 仍常驻内存、未独占资源，数字失真。现已按"内存中只放一个模型"重新完整测试，全文数据已替换。初版数据作废。
0.0.0.0:8000，OpenAI 兼容接口 /v1/chat/completions，模型目录 ~/.omlx/models服务端几个和结果直接相关的配置：
max_concurrent_requests：4max_context_window：409600max_tokens：20000chunked_prefill：关闭被测的两个模型：
Deepseek-V4-Flash-oQ3e-mtp —— oQ3e 量化，24 个分片，磁盘占用 123 GB，常驻内存实测 119.10 GBQwen3.8-Flash-Next-4bit —— 常驻内存实测 104.07 GB四个指标，先说清楚各自测的是什么：
服务端自己会上报 time_to_first_token、generation_tokens_per_second、prompt_eval_duration 等字段，我们直接取这些值，并在客户端用时间戳二次校验。
短提示（约 30 字），三轮：
首轮 TTFT 稍高（0.34 s）是正常的预热效应，之后稳定在 0.1 s 出头。0.1 秒的首字，用户是感觉不到"等"的 —— 这个数字对语音交互很关键，因为语音链路里还有识别和合成两段，留给大模型的空间并不多。
长上下文预填充（8472 token 输入）：
4 路并发（每路生成 128 token）：
并发 4 路时，单路速度从 30.5 tok/s 降到约 15.2 tok/s（差不多腰斩），但总吞吐从 30.5 提升到 55.5 tok/s，接近翻倍。
同一个平台、同一套口径，内存里只放它一个模型：
短提示（约 30 字），三轮：
解码速度的三次波动只有 0.2 tok/s，非常稳。
长上下文预填充（8700 token 输入）：
4 路并发（每路生成 128 token）：
这一项很关键：并发时单路速度只从 33.35 降到约 25 tok/s（降幅约 25%），合计吞吐反而涨到 89.2 tok/s，是单路的两倍多。并发效率比 DeepSeek 那一档明显更好。
同一台机器、同样 4 路并发，横向对比：
结论有点反直觉：参数量感更"轻"的 Qwen3.8 Flash Next，在这台机器上的每项指标都更好。 它的 4bit 量化对统一内存更友好，预填充性能尤其突出。
如果你只跑一个模型，优先选 Qwen3.8 Flash Next。 DeepSeek V4 Flash 的优势在上下文窗口（服务端可开到 40 万 token 级别）和长文本处理定位，适合"长文档、长会话"这类场景，而不是拼吞吐。
先说清楚一个前提：这台 256GB 的机器，同时只装得下一个模型。
我们实测过：DeepSeek 常驻时（服务端进程 RSS 一度在 88 ~ 126 GB 之间浮动），再去请求 Qwen3.8 Flash，服务直接返回：
HTTP 507 Insufficient Storage
不是磁盘满，是统一内存分不出来。按服务端日志，两个模型的常驻占用分别是 119.10 GB 和 104.07 GB —— 光权重加起来就 223 GB，再算上 KV 缓存和系统本身的开销，256GB 没有余地。
所以：想换模型，就得让前一个先退出内存。 如果业务要求"两个模型随时待命、来什么请求用什么模型"，256GB 这一档不够，得往上走。
服务自己记了从上线到现在的账（截至 2026-09-29 17:10）：
分模型看：
89.6% 的缓存命中率是这台机器上最值钱的一项优化。同样的一段系统提示词、同样的历史上下文，第二次来就不用重新预填充了 —— 前面那个 17.8 s 的长上下文首字延迟，在缓存命中后会大幅缩短。做本地推理，把提示词前缀稳定住，收益比换硬件大。
一句话总结这台 M3 Ultra 的能力边界：
对我们做语音盒子的意义很直接：唤醒、识别、合成都在端侧和本地完成的前提下，本地放一个模型做兜底对话是可行的。前提有两个：把上下文控制短，把提示词前缀做稳定。云端大模型负责复杂语义，本地模型负责"断网也能聊"，这个分工在实测数据上站得住。
测试环境补充说明：以上为单次测试结果，未做多次重复取极值；客户端与服务端同局域网，网络延迟未单独剥离。机器负载、散热状态、后台进程都会影响数字，换一台机器或换一天重测，可能上下浮动 10%。
文中引用的数据均来自 omlx 服务端自报的计时字段（time_to_first_token、generation_tokens_per_second、prompt_eval_duration）与服务端日志、累计统计（stats.json），未做任何外推或换算。