据报道，DeepSeek 正在开发自有 AI 芯片，而且目标不是训练，而是推理。这个区别很关键：训练芯片解决“把模型做出来”的问题，推理芯片解决“每天把模型便宜、稳定、低延迟地跑起来”的问题。对一家面向真实用户提供模型服务的公司来说，后者往往才是长期成本的大头。
为什么是推理芯片，而不是训练芯片
训练和推理对硬件的要求不完全一样。
训练阶段需要巨大的并行计算、显存容量、互联带宽和集群稳定性。模型训练完成后，推理阶段的核心压力变成：单次请求延迟、吞吐量、显存占用、批处理效率、能耗，以及服务峰值下的稳定性。
DeepSeek 如果自研的是推理芯片，意味着它更可能瞄准以下场景：
- 已训练模型的大规模在线服务；
- 对话、代码生成、搜索增强生成等高频请求；
- 在固定模型架构和固定运行时上做深度优化；
- 降低对通用 GPU 的长期依赖。
这不是一个“替代所有 GPU”的叙事。更现实的路径是：训练仍依赖成熟 GPU 或现有加速卡，推理逐步迁移到更可控、更便宜的硬件平台。
H800、昇腾与自研芯片之间的现实张力
摘要提到，DeepSeek 当前基础设施建立在 Nvidia H800 和华为昇腾芯片之上。这个组合本身就说明了一个趋势：大模型公司正在避免把算力命脉完全压在单一供应链上。
美国出口管制限制了中国公司获得 Nvidia 最新高端 GPU。H800 是在限制环境下仍可用的一类选择，但它不是长期无限扩容的确定答案。华为昇腾则提供了本土替代路径，但生态、工具链、算子覆盖、模型适配和工程迁移成本都需要实际验证。
自研推理芯片的吸引力在于控制权：
- 可以围绕自家模型的推理模式设计硬件；
- 可以把编译器、运行时、量化策略和服务调度一起优化；
- 可以减少外部供应约束对线上服务成本的影响；
- 可以在规模足够大时摊薄芯片研发和部署成本。
但边界也很清楚。芯片不是写一个 CUDA kernel 就能交付的项目。流片、良率、驱动、编译器、算子库、故障诊断、集群调度、运维体系，每一层都会吃掉大量时间。
真正的战场是每 token 成本
大模型服务的商业压力最终会落到几个指标上：每秒生成 token 数、首 token 延迟、单位功耗 token 吞吐、每百万 token 成本、峰值请求下的错误率。
推理芯片如果要有意义，不能只在宣传页上写“算力很高”。它必须在真实 workload 下跑赢现有方案，尤其是长上下文、多并发、流式输出、KV cache 管理、量化模型这些实际场景。
工程团队评估这类变化时，不应该只问“是不是国产芯片”或“是不是替代 Nvidia”。更应该问：
- 我的模型能不能无损或低损迁移？
- 常用算子是否完整支持？
- 推理框架是否支持连续批处理和 KV cache 复用？
- p95 / p99 延迟是否稳定？
- 故障时是否能自动回退到 GPU 池？
- 成本下降是否足以覆盖迁移和维护成本？
可以这样实践：给推理后端做一套基准测试
下面这个示例不假设 DeepSeek 自研芯片已经可用，而是给团队一个可改造的推理基准脚本。你可以用它比较不同后端：Nvidia GPU、昇腾实例、CPU fallback，或者未来的专用推理芯片服务。
运行前需要准备一个兼容 OpenAI Chat Completions 风格的接口，并修改 BASE_URL、API_KEY 和 MODEL。
import os
import time
import statistics
import requests
from concurrent.futures import ThreadPoolExecutor, as_completed
BASE_URL = os.getenv("BASE_URL", "http://localhost:8000/v1/chat/completions")
API_KEY = os.getenv("API_KEY", "change-me")
MODEL = os.getenv("MODEL", "your-model-name")
CONCURRENCY = int(os.getenv("CONCURRENCY", "8"))
REQUESTS = int(os.getenv("REQUESTS", "32"))
PROMPT = "用三句话解释为什么大模型推理成本会影响产品毛利。"
def call_once(i: int):
started = time.perf_counter()
response = requests.post(
BASE_URL,
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
},
json={
"model": MODEL,
"messages": [{"role": "user", "content": PROMPT}],
"temperature": 0.2,
"max_tokens": 256,
"stream": False,
},
timeout=120,
)
elapsed = time.perf_counter() - started
response.raise_for_status()
data = response.json()
text = data["choices"][0]["message"]["content"]
usage = data.get("usage", {})
output_tokens = usage.get("completion_tokens", len(text))
return {
"id": i,
"latency_s": elapsed,
"output_tokens": output_tokens,
"tokens_per_s": output_tokens / elapsed if elapsed > 0 else 0,
}
def percentile(values, p):
values = sorted(values)
index = int(round((len(values) - 1) * p))
return values[index]
def main():
results = []
with ThreadPoolExecutor(max_workers=CONCURRENCY) as pool:
futures = [pool.submit(call_once, i) for i in range(REQUESTS)]
for future in as_completed(futures):
item = future.result()
results.append(item)
print(
f"request={item['id']} latency={item['latency_s']:.2f}s "
f"tokens_per_s={item['tokens_per_s']:.2f}"
)
latencies = [r["latency_s"] for r in results]
speeds = [r["tokens_per_s"] for r in results]
print("\n=== summary ===")
print(f"requests: {len(results)}")
print(f"concurrency: {CONCURRENCY}")
print(f"latency avg: {statistics.mean(latencies):.2f}s")
print(f"latency p95: {percentile(latencies, 0.95):.2f}s")
print(f"tokens/s avg: {statistics.mean(speeds):.2f}")
if __name__ == "__main__":
main()
可以这样运行：
pip install requests
export BASE_URL="http://localhost:8000/v1/chat/completions"
export API_KEY="test-key"
export MODEL="your-model-name"
export CONCURRENCY=16
export REQUESTS=100
python benchmark_inference.py
如果你在比较多个推理后端，建议固定同一个模型、同一批 prompt、同样的 max_tokens 和并发数。否则测出来的数字很容易只是“请求不一样”，不是“芯片或后端不一样”。
落地建议：把芯片选择放进服务架构，而不是 PPT
对应用团队来说，自研推理芯片的新闻不必立刻转化成采购动作，但应该转化成架构准备。
一套更稳妥的策略是：
- 把模型服务封装在统一 API 后面，避免业务代码绑定某个硬件后端；
- 保留多后端路由能力，例如 GPU、昇腾、CPU fallback 或未来专用推理芯片；
- 建立标准 benchmark，包括延迟、吞吐、错误率、成本和输出质量；
- 对关键业务保留回退路径，不把线上 SLA 直接押给新硬件；
- 关注工具链成熟度，而不只看理论算力。
DeepSeek 自研推理芯片如果推进顺利，代表大模型竞争从模型参数、训练方法，继续下沉到推理基础设施。真正能改变行业成本结构的，不只是“有没有芯片”，而是芯片、编译器、运行时、模型和服务调度能不能拧成一个可运维的系统。