1. 高通 IQ9075 跑大模型 Benchmark到底在测什么高通 IQ9075 属于跃龙 IoT-IQ 系列里面向工业级边缘推理的 SoCCPU 与 NPU 的算力配比、内存带宽、以及对 W4A16 / INT8 这类低精度格式的兼容性决定了它能不能把 0.5B 到 7B 量级的大模型稳稳跑在本地。很多人拿到 EVK 之后第一反应是「先跑个 demo 看看」但真正要判断这颗芯片适不适合你的产品得看四个维度的量化数据首字响应TTFT、编码速度prefill、解码速度decode、以及显存/内存占用。这四个指标合起来才构成一次完整的大模型 Benchmark。我这次实测的目标很明确把 IQ9075 上跑 LLM 和 VL 模型的完整评测链路拆开从环境准备、模型加载、推理脚本到用统一 Key 做多模型横向对比全部给出可复制的配置。你跟着做能复现出接近的吞吐和时延结论也能判断某个模型在你的场景里到底值不值得部署。先说清楚适合谁看如果你在做边缘端 AI 产品选型需要在 IQ9075 这类平台上决定用 0.5B 还是 3B、用纯文本还是多模态这篇的评测模板可以直接拿去改。如果你只是想了解大模型 Benchmark 的方法论也能从中学到怎么设计一组有对比价值的测试用例。Benchmark 的核心不是「跑分越高越好」而是「在你的任务分布下哪个模型能在可接受的时延和内存里给出可用输出」。所以我会把算力基准和场景实测分开前者测极限吞吐后者测长上下文、多轮对话、结构化输出这些真实负载。在开始之前先明确一个容易踩的坑IQ9075 的 NPU 对模型格式有要求W4A16 量化后的模型才能发挥出标称的编码速度。如果你直接拿 FP16 权重去跑首字响应会明显变慢解码速度也会掉一截。下面的配置模板里我会把量化格式和运行时参数一起写清楚。另外评测过程中需要频繁调用不同模型做对比。如果每个模型都单独配一套鉴权脚本会变得很难维护。我的做法是用 TaoToken 的统一 Key 来管理多模型接入这样在 IQ9075 本地跑推理的同时可以随时把同一批 prompt 发给云端模型做基线对照。这个思路在后面第 3 节会给出具体的 settings 片段。2. TaoToken 统一 Key 前置多模型评测链路怎么搭做 IQ9075 的 Benchmark 时一个很现实的问题是你不可能只测一个模型。至少要覆盖 0.5B、1.5B、3B、7B 几个档位还要对比纯文本和 VL 多模态。如果每个模型都去单独申请 Key、单独改 base_url脚本里会塞满硬编码换一个模型就要改一次代码。TaoToken 在这里的作用是提供一个统一的 API 入口把不同模型的调用收敛到一套鉴权和一套 base_url 上。你只需要在请求里换 model 字段就能在同一份脚本里切换模型。对于 Benchmark 这种需要批量跑多模型的场景这个收敛能省掉大量重复配置。先拿 Key。打开 https://taotoken.net/api-keys 登录后创建一个 API Key。这个 Key 就是后面所有请求的凭证。注意不要把它写进会提交到 git 的代码里建议用环境变量或者本地 .env 文件管理。拿到 Key 之后你需要确认两件事Base URL 和 Model ID。Base URL 统一用 https://taotoken.net/api Model ID 则根据你要测的模型来填。比如你要对比 Qwen2.5-7B-Instruct 和 Qwen2.5-3B-Instruct就在请求里分别指定对应的 model 名称。这里有个细节IQ9075 本地推理和云端 API 调用是两条链路。本地推理走的是板子上的 NPU 运行时云端对照走的是 TaoToken 的 API。两者不冲突但你要在脚本里把「本地推理结果」和「云端基线结果」分开记录否则最后汇总表格会混在一起。如果你用的是 Claude Code 这类编码工具来做评测脚本开发可以在 settings 里配置 TaoToken 的接入信息。下面是一个可复制的 settings 片段路径按你的实际项目调整{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的_TaoToken_Key, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }这段配置的作用是让编码工具走 TaoToken 的入口这样你在写评测脚本时补全和对话请求都走统一链路。注意 Base URL、Key、Model ID 三件套要写全缺一个都会导致请求失败。对于 Cline 或 MCP 类的工具配置逻辑类似核心还是 Base URL Key Model ID。如果你在 IQ9075 上跑的是本地模型这部分配置只影响你的开发工具不影响板子上的推理运行时。还有一个容易被忽略的点TaoToken 的 API 调用是有并发限制的。做 Benchmark 时如果一次性发太多请求可能会触发限流。建议在脚本里加一个简单的重试和退避逻辑或者在批量测试时控制并发数。这个在第 5 节的排错部分会展开。3. 可复制的 IQ9075 评测配置模板这一节给出完整的配置模板包括本地推理的运行时参数和云端对照的 API 调用脚本。你可以直接复制到项目里改掉模型路径和 Key 就能跑。先看本地推理部分。IQ9075 上跑 W4A16 量化模型通常需要一个运行时配置文件。下面是一个 TOML 格式的模板覆盖了模型路径、量化格式、上下文长度和线程数[model] path /opt/models/Qwen2.5-7B-Instruct-W4A16 format w4a16 context_length 4096 max_new_tokens 512 [runtime] npu_threads 4 cpu_threads 4 memory_limit_mb 8192 [benchmark] warmup_runs 3 test_runs 10 prompt_file ./prompts/long_context.txt这个配置里format w4a16是关键它告诉运行时用 4-bit 权重加 16-bit 激活的量化方式加载。context_length设成 4096 是为了匹配大多数 7B 模型在 IQ9075 上的可用上下文。warmup_runs和test_runs用来控制预热和正式测试的次数避免冷启动影响首字响应数据。接下来是云端对照的 API 调用脚本。用 Python 写一个通用的请求函数通过改 model 字段来切换模型import os import time import requests API_BASE https://taotoken.net/api API_KEY os.environ.get(TAOTOKEN_API_KEY) def call_model(model_id, prompt, max_tokens512): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: model_id, messages: [{role: user, content: prompt}], max_tokens: max_tokens, temperature: 0.2 } start time.time() resp requests.post(f{API_BASE}/v1/chat/completions, headersheaders, jsonpayload, timeout120) elapsed time.time() - start data resp.json() return { model: model_id, elapsed: elapsed, content: data[choices][0][message][content] }这个脚本里API_BASE用的是 TaoToken 的 API 地址API_KEY从环境变量读取。调用时只需要传不同的model_id就能在同一份代码里对比多个模型。elapsed记录的是端到端时延包含网络传输时间所以它和本地推理的首字响应不是同一个口径对比时要分开看。如果你要测结构化输出可以在 prompt 里明确要求 JSON 格式然后在返回结果里做解析校验。下面是一个测试用例的示例prompt 请以 JSON 格式输出以下信息 {name: IQ9075, vendor: Qualcomm, category: IoT} 只输出 JSON不要额外解释。 result call_model(qwen2.5-7b-instruct, prompt) print(result[content])跑完本地和云端两组数据后把结果汇总到一张表里。建议至少记录模型名称、参数量、量化格式、首字响应、编码速度、解码速度、内存占用。这样横向对比时能一眼看出哪个模型在 IQ9075 上性价比最高。4. 验证请求与成功结果从 TTFT 到结构化输出配置写完之后先做一次最小验证确认链路是通的。本地推理这边跑一个短 prompt看首字响应和解码速度是否在合理范围。云端对照这边发一个请求确认返回的 JSON 结构里有 choices 字段。先看本地验证。用上面 TOML 里的配置启动运行时然后发一个简单请求./iq9075-llm-runner --config ./benchmark.toml --prompt 你好请用一句话介绍你自己如果配置正确你会看到类似这样的输出[INFO] Model loaded: Qwen2.5-7B-Instruct-W4A16 [INFO] Warmup completed: 3 runs [INFO] TTFT: 0.32s [INFO] Prefill speed: 780 token/s [INFO] Decode speed: 11 token/s [INFO] Memory used: 4.6 GB这里的 TTFT 是首字响应时间Prefill speed 是编码速度Decode speed 是解码速度。对照第 1 节提到的参考数据Qwen2.5-7B-Instruct 在 W4A16 下的解码速度大约在 11 token/s 左右如果你测出来明显低于这个值先检查量化格式和线程数配置。再看云端对照。用第 3 节的 Python 脚本发一个请求result call_model(qwen2.5-7b-instruct, 用一句话说明边缘推理的优势) print(result[content]) print(f端到端时延: {result[elapsed]:.2f}s)成功的话你会看到模型返回的文本内容以及一个端到端时延数值。这个数值通常在 1 到 3 秒之间取决于网络状况和模型负载。如果返回的是 401 错误说明 Key 有问题如果返回的是 model not found说明 model_id 写错了。结构化输出的验证稍微复杂一点。你需要检查返回内容是否能被 JSON 解析器正确解析。下面是一个校验脚本import json result call_model(qwen2.5-7b-instruct, prompt) try: parsed json.loads(result[content]) print(JSON 解析成功:, parsed) except json.JSONDecodeError as e: print(JSON 解析失败:, e) print(原始内容:, result[content])如果解析失败通常是模型在 JSON 前后加了额外文字。你可以在 prompt 里加强约束或者在代码里做一次提取。实测下来Qwen2.5 系列在结构化输出上的表现比较稳定7B 版本基本能一次输出合法 JSON。长上下文测试是另一个重点。IQ9075 的 7B 模型在 4096 上下文下首字响应会随着输入长度增加而上升。你可以用不同长度的 prompt 做一组测试记录 TTFT 的变化曲线。如果 TTFT 在某个长度之后急剧上升说明内存带宽成了瓶颈这时候要考虑换更小的模型或者缩短上下文。多轮对话测试则需要维护一个 messages 列表把历史对话一起发给模型。本地推理和云端 API 都支持这种格式区别在于本地推理的上下文长度受限于板子内存云端则受限于模型本身的最大上下文。5. 本篇常见错排查401、local proxy failed、reading choices评测过程中最容易遇到的几个报错我在这里集中列一下方便你对照排查。第一个是 401 Unauthorized。这个通常出现在云端对照环节原因是 API Key 没传对或者已经失效。检查步骤确认环境变量TAOTOKEN_API_KEY已经设置确认请求头里的Authorization格式是Bearer 你的Key确认 Key 没有多余的空格。如果用的是 settings 文件检查ANTHROPIC_API_KEY字段是否写全。第二个是 local proxy failed。这个报错一般出现在本地推理运行时原因是运行时尝试连接一个不存在的本地代理。IQ9075 的推理运行时默认不走代理如果你在环境变量里设置了http_proxy或https_proxy运行时可能会误用。解决办法是清掉这些环境变量或者在运行时配置里显式禁用代理。第三个是 reading choices 相关的报错比如KeyError: choices或者list index out of range。这个说明 API 返回的 JSON 结构里没有 choices 字段通常是请求本身失败了返回的是错误信息。你可以在解析之前先打印完整的响应内容resp requests.post(url, headersheaders, jsonpayload, timeout120) print(状态码:, resp.status_code) print(响应内容:, resp.text)如果状态码不是 200响应内容里会有具体的错误描述。常见的原因包括 model_id 不存在、max_tokens 超出限制、请求体格式不对。第四个是 OAuth 相关的报错。如果你用的是 Claude Code 这类工具配置里同时存在 OAuth 和 API Key 时可能会冲突。解决办法是明确用 API Key 模式把 OAuth 相关的配置清掉。settings 里只保留 Base URL、Key、Model ID 三件套。第五个是模型加载失败。本地推理时如果提示模型文件找不到或者格式不支持先检查模型路径是否正确再确认量化格式是否匹配。W4A16 的模型不能用 FP16 的配置去加载反之亦然。第六个是内存不足。IQ9075 的内存有限7B 模型在 4096 上下文下大约占用 4.6 GB如果你同时加载多个模型或者开了太多线程可能会触发 OOM。解决办法是减少并发、缩短上下文或者换更小的模型。排查的时候建议按顺序来先确认网络和鉴权再确认模型 ID 和格式最后看资源占用。大部分报错都能通过打印完整响应内容定位到具体原因。6. 用统一 Key 打通评测链路把 Benchmark 做成可复现的流程评测做完之后最重要的不是某一个模型的跑分而是整套流程能不能复现。我建议你把配置模板、调用脚本、测试用例都放进一个 git 仓库用环境变量管理 Key用不同的配置文件区分本地推理和云端对照。这样下次换一个模型或者换一个平台只需要改配置不用重写代码。TaoToken 的统一 Key 在这里的价值是让云端对照这一侧变得可维护。你不需要为每个模型单独申请凭证也不需要改 base_url。同一份脚本改一个 model 字段就能切换模型这对于需要批量对比多个模型的 Benchmark 场景来说能省掉大量重复劳动。如果你要长期做边缘端模型的评测和选型可以考虑用 Coding Plan 来管理你的评测脚本开发。它适合这种需要反复迭代、多模型对比的编码任务。模型对话入口则适合快速验证某个模型的输出质量不用写完整脚本就能看到结果。最后给一个实用建议每次跑完 Benchmark把原始数据存成 CSV 或者 JSON不要只留一个汇总表格。原始数据里包含了每次请求的时延和输出后续做统计分析或者画曲线时会用到。我试过只留汇总数据结果想回头算 P95 时延的时候发现原始记录已经丢了只能重跑一遍。评测链路搭好之后你可以把同一套方法迁移到其他边缘平台只需要替换本地推理的运行时配置。云端对照部分因为走的是统一 API基本不用改。这样一套流程能让你在模型选型和硬件评估上都有可量化的依据。