指南：Token Usage and Cost Tracking on EXAIV: Reading Usage Data and Turning It Into a Budget
指南：Token Usage and Cost Tracking on EXAIV: Reading Usage Data and Turning It Into a Budget
本文关于Token Usage and Cost Tracking on EXAIV: Reading Usage Data and Turning It Into a Budget的所有数字，都直接对照 HuggingFace API 与对应仓库的原始 config.json 核实，采样时间为 2026 年 11 月。不编造跑分、价格或仓库名；config 无法证明的部分一律标注「需实测」。
30 秒版本
在 EXAIV 上，一切以 /models 实时目录为准：目前只有 kimi-k3 可调用，端点是 https://exaiv.com/api/ai/v1 的 OpenAI 兼容接口。接入只改 base_url、api_key、model 三项，流式与工具调用保持标准格式。价格一律以实时 /pricing 为准，本文不写死。建议记录模型
已核实的规格
| Component | Typical direction | Note |
|---|---|---|
| Input tokens | Usually the cheapest | Prompt length dominates in chat workloads |
| Output tokens | Often dearer than input | Long generations cost noticeably more |
| Cached input | Usually cheaper than fresh input | Reported as its own counter |
Reference table
| Metric | Why it matters |
|---|---|
| Tokens per successful request | Rising tokens with flat quality usually means the prompt grew |
| Output tokens per request | A jump means answers got longer — check for a prompt change |
| Cache hit ratio | Low hits on a stable prefix mean you are re-sending identical context |
| Cost per completed task | The only number that connects spend to something you sell |
| Retries per request | Retries double the spend of every failed request |
| Tokens by model tier | Shows whether traffic drifted to a stronger tier than it needs |
Reference table
| Field | Type | Purpose |
|---|---|---|
request_id | string | Join key across systems |
timestamp | timestamp | Time-series aggregation |
feature | string | Slicing spend by product area |
model | string | Detecting tier drift |
input_tokens | integer | Cost calculation |
output_tokens | integer | Cost calculation and runaway detection |
cached_tokens | integer | Cache efficiency |
latency_ms | integer | Correlating slow calls with long contexts |
status | string | Separating successful from retried spend |
error_code | string, nullable | Diagnosing failed spend |
Reference table
| Dimension | Useful for |
|---|---|
| Customer or account | Finding the largest spenders and who to talk to |
| Feature or route | Finding the expensive endpoint |
| Model | Detecting traffic drifting to a stronger tier |
| Time of day | Separating batch load from interactive load |
数字能证明什么
多模态措辞最容易夸大，所以事实与断言必须分开：官方 config 里的 vision_config 与 image_placeholder 能证明这是带视觉输入能力的条件生成架构，但本身不能证明视频生成、某种具体请求格式或某项跑分。HuggingFace 的 image-text-to-text 标签描述的是输入方向。最终以官方模型卡为准。
Configuration and troubleshooting
显存规划对所有万亿级 MoE 一样：算力按激活参数算，显存按总参数算。1T 模型即使 4-bit，权重本身也约需 500GB，2.78T 更大，属于多卡服务器场景，不是单张消费卡能跑的。单卡请看轻量家族。本地路径是 vLLM 或 SGLang 配官方权重；社区转换文件先核对来源与量化标签。
可用边界
在 EXAIV 上，一切以 /models 实时目录为准：目前只有 kimi-k3 可调用，端点是 https://exaiv.com/api/ai/v1 的 OpenAI 兼容接口。接入只改 base_url、api_key、model 三项，流式与工具调用保持标准格式。价格一律以实时 /pricing 为准，本文不写死。建议记录模型 ID、token 数与延迟，日后换模型才有同一套基线。
术语与上线前检查清单
总参数、激活参数与 KV cache 是三个不同的量。总参数是必须加载进显存的全部权重，激活参数是计算单个 token 时真正参与的那部分；KV cache 是随上下文长度线性增长的临时显存，所以 1M 窗口是上限而不是可随手使用的默认值。量化降低的是权重的存储精度以缩小文件，并不减少参数量；config.json 里的 vision_config 描述的是架构，不是可以自行编造的报文格式。
在把基于本文说明的东西发布之前，请走完六项检查。第一，发布当天从实时来源重新核对数字，下载计数每周都在变。第二，打开 /models 实时目录，确认打算调用的 ID 仍然存在；目录一变，所有写死模型名的说明都会失效。第三，价格去 /pricing 看，不要把数字抄进应用里写死。第四，凡是没对照官方参考验证过的请求体，一律不要写死；config 能证明架构，不能证明线上格式。第五，用一组有代表性的提示词记录模型 ID、输入输出 token 数与延迟，并固定这组用例，之后换模型才有可比读数。第六，商用前读模型卡里的许可条款，厂商自定义条件不等于宽松许可。另外，对可重试请求加指数退避、设置超时，并按错误类别记录日志，401、404、429 绝不能用同一套处理逻辑。还要给敏感配置留出轮换路径：密钥不要写进代码库，环境变量与密钥管理系统的交接要有回滚方案。若模型能加载却输出乱码，先怀疑聊天模板而不是权重；把模板和权重放在一起便于一起审计。这个习惯只花几分钟，却能挡掉最常见的一类误报。
FAQ
EXAIV 上该用哪个模型 ID？
本文数字核实过吗？
config 能证明视频生成吗？
需要换 SDK 吗？
价格在哪里看？
能用本地权重吗？
相关阅读
- Kimi K3 API guide — first API call
- GLM family overview — callable catalog
- hy4 model selection guide — sizing and selection
- Claude Code third-party models — support boundary
- pricing — live credit packs
数据来源
参数与文件数据为 2026 年 11 月采样，随时间变化。